New processors have been developed with vehicle safety and connectivity in mind.

David Maples, Texas Instruments
The trend towards autonomous driving, electrification and connectivity to the cloud is making software a priority. That’s why automotive designers are reworking the architecture of modern-day vehicles and migrating toward a software-defined car.

Many systems within cars today are a collection of electronic control units (ECUs) with independent functions. These ECUs communicate through a traditional Controller Area Network, Local Interconnect Network, and other low-bandwidth networks. ECUs are also grouped into functional domains such as powertrain control. The hundred or more ECUs in high-end vehicles makes it impractical to implement next-generation functions into each one, however.

To work around this limitation, one approach is to replace ECUs with several computing platforms. For example, the vehicle architecture could employ one computing platform to control the features of the interior cabin such as infotainment or the instrument cluster. Another computing platform controls the motion of the vehicle. A software-defined vehicle architecture enables a variety of benefits across the functional domains of the car, including simpler development and deployment of new features, more efficient communication within the vehicle, and access to cloud computing through edge processing.

One of the limitations of a vehicle architecture centered around ECUs is the complexity involved in adding new functions and capabilities. The process of adding features to an existing system can be complicated, slow and error-prone. Aligning software across functional domains in the vehicle simplifies the updating of cars for maintenance and user features.

A software-defined vehicle architecture groups functions and systems together into functional domains. Rather than treating individual ECUs or systems separately, OEMs can consider them as a single platform. Once OEMs have developed new features, software-defined vehicle architectures make it easier to add them.

Traditionally, drivers purchase a vehicle with features that are fixed. The process of updating them is difficult and expensive. A software-defined vehicle architecture enables over-the-air (OTA) updates, or wireless delivery of software features. Instead of being a complex undertaking involving hundreds of ECUs, the updating process is much more straightforward. OEMs can provide a wide range of software services to customers and use these services as a revenue stream. With OTA updates, adding and updating features can be just as easy as adding features to a phone or tablet.

Updating with SOA

In a software-defined vehicle, a service-oriented architecture (SOA) consists of loosely coupled services that communicate through simple, interoperable interfaces, typically over a network. In a vehicle, for example, the GPS functions might be made available via service calls over the in-vehicle network. Some benefits of an SOA include hardware independence, simplified testing, faster deployment and cross-discipline application development.

SOAs have a long history in other markets such as web services, software-as-a-service, and platform-as-a- service, better known as cloud computing. Another automotive example is that of an ECU specifically designed to provide tire pressure data. It is possible to replace the tire-pressure ECU or to integrate its tasks into a larger, multifunction ECU. Upstream applications use an abstract interface to communicate with an ECU, so changing an ECU or integrating tasks into another ECU via SOA doesn’t affect them. In the case of tire pressure, components of the tire pressure sensor system can be from different vendors or use different sensing technologies because tire pressure data is aggregated in a smaller ECU.

Machine learning can help accomplish tasks such as driver assist and predictive maintenance. Machine learning is already widely used in industrial environments where the monitoring of machinery detects and helps anticipate faults. It is possible to integrate machine learning into the vehicle itself, but remote processing centers may provide additional machine-learning features. Another possibility is the use of remote data centers to train machine learning algorithms, then onboarding data to intelligent systems via OTA updates.

The processors in a software-defined car require a great deal of compute power, high bandwidth communication, functional safety, and security. Compute resources can be further split into those for real time and non-real time functions. The higher-level logic of an implemented feature (i.e. unlock the doors) is not time sensitive. An anti-lock braking system is time sensitive. The brakes must be modulated fast enough to avoid a skid.

A functional block diagram for the DRA821. A solid black box indicates the IP is part of the Extended MCU (EMCU). A dashed black box indicates that some instances of the IP are present in the EMCU and some instances are present in the non-EMCU portion of the main domain. Click image to enlarge.

Non-realtime functions are typically executed in a HLOS based (high-level operating system) compute system similar to that available on a personal computer. Real- time functions execute in an RTOS-based (real time operating system) compute system. There is also a balance between vehicle features that require functional safety and security and features that don’t.

For example, the TI DRA821 is designed with these features in mind. At the heart of the DRA821 is a dual-core ARM Cortex A72 cluster with enough processing power to execute all non-real time functions. Four integrated Cortex R5Fs sit alongside the main processor (A72 cluster) to execute the real-time functions.

DRA821 integrates the latest security features in an integrated secure subsystem. Further, the device is functional-safety certified by a third-party assessor to the highest ASIL (Automotive Safety Integrity Level), ASIL-D. The DRA821 includes a variety of high-speed I/O, such as a four-port Gigabit TSN Ethernet switch, PCIe and USB3, and traditional automotive peripherals such as CAN-FD and UART/LIN.

As safety is paramount in automotive applications, the DRA821 incorporates a range of safety features, including ECC on calculation-critical memories and internal databus, firewalls, self-test diagnostic tools, and error-signaling modules for capturing errors related to functional safety. The DRA821 also integrates a range of security features to protect from external attacks, including secure boot, cryptographic acceleration, trusted execution environment, secure storage, on-the-fly encryption, and a co-processor for security management.

A software-defined car is well within the realm of possibility today. The use of software and machine learning systems helps better predict vehicle maintenance while also keeping passengers safe. Software-defined cars will fundamentally change how we see automotive technology, and the ability to move vehicles into the software realm allows planning for long-term vehicle updates.