Enabling the software-defined autonomous car

The current autonomous car architecture is an ever-increasing number of engine control units (ECUs) connected by low-speed Controller Area Network (CAN)/Local Interconnect Network (LIN) communication buses. This architecture has several limitations, however. 

For example, software development, maintenance and validation are complex. Each ECU has software written by a different supplier. For vehicle systems to operate effectively, software must be aligned across systems in the car. Adding features to an existing system can be a complicated, slow and error-prone process. Achieving autonomy and connectivity by adding new functionalities and capabilities to vehicles is difficult or impossible to implement with distributed ECUs. 

Semi-autonomous and autonomous vehicles require the use of multiple cameras, radars and LIDAR. Communicating all of that raw data around the vehicle requires many ECUs to be able to handle Gigabit Ethernet. Processing raw data and drawing conclusions drives up the processing requirements and cost. Vehicle electrification currently requires batteries that can be expensive, making it challenging to stick within system budgets. 

The first step toward overcoming these challenges is to centralise functions into functional domains that support actions either a section of the car or for a particular function of the car (ex: HEV/EV operations). Figure 1 shows an example of a vehicle compute architecture that incorporates functional domains. Functional domains act as a gateway between the high-bandwidth interconnect to other domains and the lower-bandwidth CAN/LIN interconnect of the remaining domain ECUs. Decreasing the number of ECUs, the amount of wiring in the vehicle and the number of connectors helps achieve significant cost savings. 

Limiting high-bandwidth data processing to the functional domains minimises the complexity and cost of the sensors and actuators in the remaining ECUs. Implementing software features/applications in the functional domains only (rather than being distributed over multiple ECUs and suppliers) enables a structured software development process.

There is an emerging trend to create a software-defined vehicle through an architecture comprising one to three vehicle compute platforms per vehicle that integrate functionality. A critical enabler of the software-defined vehicle is the employment of a service-oriented architecture (SOA). SOA systems consist of loosely couple services that communicate through simple interoperable interfaces to distinct functions, typically over a network.

Some benefits of SOA include hardware independence, simplified testing, faster deployment and cross-discipline application development. A note on that last point: Since services are presented as black boxes with abstract interfaces, it’s not necessary to use the same technology or even the same supplier to implement each service. 

SOAs have a long history in other markets, such as web services, software as a service and platform as a service (aka cloud computing). An automotive example is a simple ECU that provides tire pressure information. Multiple applications use tire pressure data: one may be a human machine interface displaying current vehicle information; another may be a mph calculator that itself feeds an electric vehicle battery manager. It is possible to replace the tire pressure ECU using a different hardware vendor or for it to be integrated into a larger, multifunction ECU. Because upstream applications use an abstract interface to the ECU’s services, they are not affected by a change in ECU or integration into another ECU when using an SOA. In the tire pressure example, the components supporting the tire pressure sensor system can be from different companies or use different sensing technologies because the tire pressure data is aggregated in smaller ECU.

Vehicle compute gateway platforms clearly increase the compute requirements per platform, which can use one or multiple compute system on chips (SoCs) depending on the processing required. Compute SoCs have to efficiently share data between them. Peripheral Component Interconnect Express (PCIe) is a high-bandwidth backbone that interconnects the compute SoCs and mass storage, while Gigabit Ethernet is the high-bandwidth communication from the vehicle compute platform to the rest of the vehicle. 

TI’s DRA829V application processor is the first processor to integrate a PCIe switch on-chip to share high bandwidth data between the compute processors to enable faster high-performance processing. The PCIe switch integrated into the DRA829V efficiently moves data between the SoCs. There is no need for central processing unit intervention or temporary storage. 

Because the vehicle compute platform must be able to manage data communication with the rest of the vehicle, the DRA829V processor includes an eight-port, Gigabit Ethernet switch to communicate outside the box, along with the multiple traditional automotive CAN-Flexible Data Rate/LIN interfaces for communicating to the rest of the vehicle. 

There are functional safety requirements for a portion of the functions. The DRA829 leverages more than 20 years of functional safety experience to support mixed criticality processing. Lockstep Arm Cortex-R5Fs enable ASIL- D while the entire SOC is ASIL-B capable. Extensive on chip firewalls enable the freedom from interference required to manage mixed criticality safety and non-safety functions simultaneously. Figure 2 compares a typical vehicle compute platform with one using the DRA829V. The DRA829V requires half as many packages saving cost, power and physical size.

Automotive vehicle architectures are evolving to meet the demands of the industry trends. There is emerging vehicle architecture to enable the software defined vehicle based on a SOA, which means one to three vehicle compute platforms are needed per vehicle. TI’s new DRA82x family of processors was purpose-built for these requirements and help automakers and Tier-1 suppliers efficiently develop vehicle compute platforms that meet system needs and system cost constraints.