Evolving automotive gateways for next-generation vehicles
A processor can address in-vehicle connectivity. Subbu Venkat, systems engineer, automotive processors, Texas Instruments explains how it works
As automotive OEMs continue to push for semi-autonomous and ultimately self-driving vehicles, technology developments will continue enabling a safer, more secure, connected and energy-efficient driving experience. Advanced driver assistance system (ADAS) technologies, like lane-keep assist, adaptive cruise control and surround view, are growing in popularity and the number of sensors and cameras equipped in vehicles is increasing.
While ADAS applications help ease the strain of driving, digital cockpit systems for infotainment and digital instrument clusters are evolving to be more interactive, and less distractive, for a more enhanced user experience. Automotive OEMs are not only advancing digital cockpit and ADAS technologies but differentiating them with features like smart access, car sharing, over-the-air (OTA) updates, fleet management and predictive maintenance. These advances complement the path toward autonomous driving and result in an increase in the number of electronic control units (ECUs) and SoCs needed to process the rising amount of data routed throughout the vehicle.
The automotive gateway
An automotive gateway’s core function is to safely and securely transfer data within the vehicle. There is the potential for several gateways in the vehicle, they can be a centralised gateway and multiple domain gateways.
A centralised gateway safely and securely transfers data between domains, such as the telematics control unit (TCU), powertrain, body, infotainment system, digital cockpit and ADAS applications.
A domain gateway (or domain controller) has a similar function but routes data between ECUs within its respective domain.
Centralised gateways typically require more processing performance, interfaces and higher-bandwidth networking protocols than domain gateways. Figure 1 illustrates how to implement the two types of gateways in a vehicle.
Figure 1. Example SoC architecture, featuring a centralised gateway and two domain gateways
The TCU provides connectivity to the internet and the cloud. More cars are connecting to, as manufacturers are fitting vehicles with Wi-Fi, Bluetooth and cellular data options.
Such connectivity enables emergency calling (eCall) and access to entertainment and other content online while travelling, and also provides OTA software updates to the digital content in the car.
Newer trends, such as car sharing, replacing key fobs with mobile phone access, fleet management and tracking, insurance providers monitoring driving habits remotely, and car dealers monitoring vehicle health remotely to schedule preventive maintenance such as oil changes, all require a connection to the internet and cloud.
Another emerging trend towards full autonomy is a vehicle’s ability to communicate with entities such as cars, infrastructure (such as traffic lights) or even people. This is vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) and vehicle-to-pedestrians (V2P) connectivity. Dedicated short range communication (DSRC), or c-V2X connectivity, usually facilitates such communication. (See Figure 2.)
Application processors
Automotive gateway processors have traditionally been 32-bit microcontrollers with embedded flash and supported gateway interfaces that were lower speed interfaces such as controller area network (CAN), local interconnect network (LIN) and FlexRay. As cars are increasing in ADAS and connectivity functionality, vehicles have to process and communicate an increasing amount of data securely and safely, at very low latencies, between various domains.
Figure 2: Examples of telematics
Interfaces such as controlled area network - flexible data rate (CAN-FD) and LIN are not designed to handle vast amounts of data at low latencies, therefore car manufacturers are migrating to an Ethernet TCP/IP-based protocol for handling higher bandwidth data movement. TCP/IP is attractive because it is a well-established communication protocol in the consumer space and holds less risk than a less-proven protocol.
Microcontrollers do not have the same level of compute power as applications processors (or microprocessors). To process and route data, they are being replaced – or augmented – with higher-performing application processors to handle larger amounts of data within the car. As in-vehicle networks migrate to an Ethernet-based network, automotive gateways supported by an application processor can help process and route data between various domains quickly and efficiently.
Connectivity choices
Connectivity is typically necessary for OTA updates to maps and other software components, as well as vehicle sharing and remote vehicle access. TCUs have a cellular or Wi-Fi modem to provide connectivity and an application processor to process data received from the modem. Processing involves decrypting the data, validating the data and routing it to the gateway or to a different domain ECU. In current architectures, the modem and processor are integrated on a single semiconductor device. However, because modem standards are constantly evolving, car manufacturers are moving to an architecture that separates the modem from the processor. Both automotive gateways and TCUs are migrating to an Ethernet-based network powered by an application processor with high speed connectivity peripheral support, like PCIe, and high compute power to process and route data between the various domains.
Standard updates
The advantage of separating the processor from the modem is that the ECU can be quickly migrated to a new modem standard by replacing only the modem, preserving the processor and all associated software running on it.
Safety and security are also gaining importance in automotive gateways and TCUs as cars become more connected and autonomous. A dedicated embedded security processor or subsystem can help protect access to vehicle security keys, enhance communication channels security and ensure that trusted software updates cannot be used as part of a cyber attack. Safety functions are typically implemented in discrete microcontrollers that are certified to be safe. An SoC that integrates both application processors and a safety microcontroller offers automotive OEMs a lower bill of materials (BoM) cost.
Development cost
The increasing complexity of gateway and TCU systems results in a high development cost for car manufacturers. Ideally, this cost would not have to be incurred for every tier/model of a vehicle.
OEMs and Tier 1 suppliers can streamline development costs by working with an automotive processor, like Jacinto DRA8x automotive processors, that provide a scalable and software-compatible platform to help address the needs of next-generation gateway and TCU systems. Automotive processors help enhance connectivity throughout the vehicle by supporting for a variety of high speed I/O such as PCIe, USB3.x and Gigabit Ethernet and traditional automotive peripherals, such as CAN-FD and LIN. These processors are also tailored for use in automotive gateways and include on-chip microcontroller subsystems to help meet the real-time processing demands and performance required for TCUs, application processors and automotive gateways.
This particular processor family includes support for several high-level and real-time operating systems in the processor software development kit, along with compatible and scalable software development kits that enable OEMs to leverage and reuse design elements, which ultimately results in lower development costs. With unified software, car manufacturers are able to scale costly software R&D investments and deploy software through the centralised gateway platform for entry- to premium-level vehicles.
The architecture of automotive gateways and TCUs is changing rapidly to efficiently process and move large amounts of data between the various domains in the car. A scalable SoC with integrated microcontroller subsystem, application processors and high speed I/O functionality would help meet the demands of this new architecture with a reduced system BoM.