Trends toward autonomous driving, electrification, and connectivity to the cloud are making software a priority, which is why automotive designers are reinventing the architecture of modern cars and migrating to software-defined vehicles.
Many systems in today’s cars are collections of electronic control units (ECUs) with independent functions. These ECUs communicate via traditional controller area networks, local interconnect networks, and other low-bandwidth networks. ECUs are also divided into various functional domains, such as powertrain control. However, a hundred or more ECUs in high-end cars make it impractical to implement next-generation functions in each ECU.
To address this limitation, one approach is to replace the ECU with several computing platforms. For example, a vehicle architecture could employ a computing platform to control interior cabin functions, such as the infotainment system or instrument cluster. Another computing platform controls the movement of the vehicle. A software-defined vehicle architecture can bring various benefits in various functional domains of the car, including easier development and deployment of new functions, more efficient communication within the vehicle, and access to cloud computing through edge processing.
One of the limitations of ECU-centric automotive architectures is the complexity when adding new functions and capabilities. The process of adding functionality to an existing system can be complex, slow and error-prone. Software upgrades in various functional domains of the vehicle can simplify the update maintenance and user functions of the car.
A software-defined automotive architecture combines functions and systems into functional domains. Rather than treating individual ECUs or systems individually, OEMs can treat it as a single platform. Software-defined vehicle architecture makes it easier to add various functions once OEMs develop new capabilities.
Traditionally, the functionality of the vehicle purchased by the driver is fixed. The process of updating them is difficult and expensive. Software-defined automotive architecture enables OTA updates. The update process is no longer a complex job involving hundreds of ECUs, but more straightforward. OEMs can provide customers with a wide range of software services and use these services as a source of revenue. With OTA, adding and updating functionality can be as simple as adding functionality 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, usually over a network. For example, in a car, the GPS function can be implemented through service calls from the in-vehicle network. Some of the benefits of SOA include hardware independence, simplified testing, faster deployment, and cross-domain application development.
SOA also has a long history in other markets such as web services, SaaS and PaaS, otherwise known as cloud computing. Another car example is an ECU specially designed to provide tire pressure data. It is possible to replace the tire pressure ECU or consolidate its tasks into a larger multifunction ECU. Upstream applications communicate with ECUs using abstract interfaces, so changing ECUs or integrating tasks into another ECU via SOA does not affect them. In the tire pressure system, the components of the tire pressure sensor system can come from different suppliers or use different sensing technologies, because the tire pressure data is aggregated in a smaller ECU.
Machine learning can help with tasks such as driver assistance and predictive maintenance. Machine learning is already widely used in industrial settings, where the monitoring of machines can detect and help predict failures. Integrating machine learning into the vehicle itself is possible, but remote processing centers may provide additional machine learning capabilities. Another possibility is to use remote data centers to train machine learning algorithms and then upload the data to the intelligent system via OTA updates.
Processors in software-defined cars require massive computing power, high-bandwidth communications, functional safety, and information security. Computing resources can be further divided into resources for real-time and non-real-time functions. The high-level logic of an implemented function (such as unlocking a car door) is time-insensitive, whereas an anti-lock braking system is time-sensitive. The brakes must be modulated fast enough to avoid slipping.
Functional block diagram of the DRA821. A solid black box indicates that the IP is part of an extended MCU (EMCU). The dashed black box indicates that some instances of this IP exist in the EMCU, and some instances exist in the non-EMCU part of the main domain.
Non-real-time functions are typically performed in HLOS (High Level Operating System) based computing systems, similar to computing systems on personal computers. The real-time functions are executed in an RTOS (real-time operating system) based computing system. There is also a balance between vehicle features that require functional safety and security and those that are not.
For example, the TI DRA821 was 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 perform all non-real-time functions. Four integrated Cortex R5Fs run in parallel with the main processor (A72 cluster) and are responsible for executing real-time functions.
The DRA821 incorporates the latest safety features in an integrated safety subsystem. In addition, the device is functional safety certified by a third-party evaluation agency to the highest ASIL standard (Automotive Safety Integrity Level) ASIL-D. The DRA821 includes a variety of high-speed I/Os such as a quad-port Gigabit TSN Ethernet switch, PCIe and USB 3.0, as well as traditional automotive peripherals such as CAN-FD and UART/LIN.
As safety is paramount in automotive applications, the DRA821 integrates a wide range of safety functions including ECC for computationally critical memory and internal data buses, firewalls, self-check diagnostic tools and error signaling modules to capture functional safety related Mistake. The DRA821 also integrates a range of security features to protect against external attacks, including secure boot, cryptographic acceleration, trusted execution environment, secure storage, on-the-fly encryption, and a coprocessor for security management.
Today, software-defined cars are entirely possible. The use of software and machine learning systems helps to better predict vehicle maintenance while also keeping passengers safe. Software-defined cars will fundamentally change the way we think about automotive technology, and the ability to move vehicles into the software realm allows planning for long-term updates to vehicles.