In this scenario, the central gateway controller plays a fundamental role as a medium of communication between different ECU networks to manage the exchange of data with external interfaces like CAN (low, high speed), LIN, FlexRay, and Automotive Ethernet protocols.

Introduction

In the early days, vehicle makers used single wires to connect the switches and actuators like wipers, speedometers, and lights. In present-day vehicles, communication network complexity has increased manifold due to the need for Advance Driver Assistance Functions (ADAS), data transfer, safety, security, and compliance requirements. Automotive protocols/interfaces in the form of CAN, LIN, Flexray and Automotive Ethernet have been designed to support high-rate data transfer between a multitude of sensors and actuators.

The communication/data transfer between all the automotive protocols and the communication/data transfer between the vehicle and the cloud has to be managed by a central authority. This is where the central gateway functionality comes into the picture.

A central gateway is a hub that interconnects and transfers data across the many different networks found in vehicles in a secure, reliable, and dependable manner. It is supposed to provide physical isolation between different ECU’s (controlling various sensors and actuators) and protocol portability/translation to route signals between functional domains in a vehicle (for e.g. powertrain, chassis and safety, body control, infotainment, telematics, ADAS) that share data. In short, the Central Gateway acts as a router and enables communication between multi-protocol and connected services.

Capability Expectations from the Central Gateway Modules

The humongous computational and data exchange requirements by multimedia applications and advanced driver assistance systems (ADAS) require computationally powerful and secure central gateways. With the growing need for reliability, security and interface of multiple sensors and actuators, the internal system architectures of the future Central Gateways will become more complex as it will require multiple cores and large internal/external memories for processing the data.

The following changes will have to be incorporated in the future vehicles as we move towards fully autonomous vehicles with ASIL-D certifications:

• High speed wireless interfaces for faster and Over The Air (OTA) communication facilities (for software updates and recalls) for data transfers and data analytics.
• High-end security systems (e.g. Intrusion Detection and Prevention Systems (IDPS), High Performance Firewalls, Secure messages, Network key management, physical ECU isolations, and encryptions over communication channels).
• Gigabit Ethernet interfaces for high bandwidth inter-ECU communication and data transfers within the vehicle as well as for on-board diagnostics and remote monitoring of the vehicles.
• Advanced routing capabilities for enabling efficient multiple protocol translations.
• ASIL-D and fail operational features.

In short, the Central Gateways will also act as high-end central compute systems for processing and for the consolidation of the data collected from the sensors and actuators in a vehicle for decisive strategies to drive the vehicles safely to their destinations.

As a central node for communications between the individual ECUs, the central gateways will support a growing number of bus systems for data exchange. These bus systems will help establish complex communication mechanisms by enabling cloud connectivity and will also check for Over-The-Air (OTA) software updates for vehicle systems and forward them to their respective destinations. The central gateways will be equipped with security features such as intrusion detection and prevention systems (IDPS) and firewalls to provide secure external vehicle communications.

In the past, automotive diagnostics systems used to rely on diagnostics connectors. In the present day, wireless connections serve the same purpose. Hence, the onboard diagnostic data is read/interpreted through the central gateway using a mobile app. As the central gateway is the epicenter of the communications network, if it carries enough computing power, a multitude of internet based online services can be designed for the driverless/autonomous vehicle.

A Simple Use-Case of an Automotive Central Gateway Module

One good example could be newly placed road barriers (placed due to an accident or construction) on a highway. The use of GPS data, extracted from the navigation device, and vehicle motion information, extracted from the Electronic Stability Program (ESP) control unit, can be collated with other sensor and actuator data. This collated data is then transmitted to a cloud service. Once a multitude of data from various vehicles passing on the same highway is collected, the vehicle can determine the road barrier’s exact location on the highway. This notification can be sent to other vehicles approaching the road barrier. This will help them avoid the barrier altogether, by changing the vehicle travel path to destination or at least making the driver aware of the problems ahead.

Conclusion

The Futuristic Automotive Gateways should be able to handle massive data, protocol-to-protocol translation capabilities, over the air communication, cloud connectivity, built-in deep learning mechanisms, high end network security capabilities and any additional processing that is needed. To enable such a futuristic Central Gateway system, the future CPU architectures will have to incorporate multiple CPU’s, massive memory and bus systems, and the SoC will need built in hardware accelerators for driving the data security mechanisms and accelerators for enabling faster data movement on the SoC.

eInfochips is a CMMi Level 3 & ISO 9001:2008 certified Product Engineering Services company. We at eInfochips, create value across the Software Development Life Cycle (SDLC) by providing Firmware/BSP design & porting, Device driver development, Board Bring Up, Peripheral Testing, System Validation, AUTOSAR RTE, BSW and COM stack configuration and integration, AUTOSAR MCAL development, AUTOSAR SWC / Application development and migration, ECU platform migration from non AUTOSAR to AUTOSAR compliant OS, Software integration of OEM specific AUTOSAR modules, AUTOSAR module functional & integration testing, ISO26262 Functional Safety Engineering – Hardware and software consulting services, Hazard Analysis, Fault Tree Analysis, Technical Safety Requirement,   ASIL- A to D compliant ECU development. We help our customer’s set-up Offshore Development Centers, supplementing the right teams and appropriate execution Models. For more information, contact us today.