The development, testing, and maintenance of software in today’s automotive industry is inflexible and unnecessarily demanding. Today each vehicle’s code is made up of monolithic blocks of software structured to define each and every function in the car as a self-contained service. This makes customizations, aftermarket feature modifications or enhancements virtually impossible to perform.
Instead, the industry should shift to a system where software components can communicate through well-defined messages independent of knowledge relating to location or implementation of any other software components.
Untangling Monolithic Software with Automotive SOA
This can be achieved by a Service-Oriented Architecture (SOA) customized for the automotive environment. This automotive SOA would allow for the decoupling of software from hardware, enabling software services to be requested and provided dynamically and use the fundamental concept of service providers and service consumers in the automotive software lifecycle utilizing:
- Abstraction layers - Every ECU will use layers of abstraction to hide the complexities of network topology, communication, and implementation
- Service directory - Interactions between software components will no longer be hard-coded, yet services and their message-based interfaces will be available in a service directory. Every new service is represented in this directory from where its service can be offered, and it can find the services that it needs to use.
Multiple different operating systems can run in parallel on an ECU, supported by a hypervisor. Thus, popular OSs like Windows, MacOS, iOS, Android, will be supported, enabling the installation of standard applications and enabling OEMs to offer an app market that’s more accessible to developers, similar to how smart phones support and maintain app stores.
Are All ECUs Equal?
The ECUs installed in new cars today can be roughly classified into two categories.
- High-performance microprocessor-based computing platforms that support the infotainment systems, run navigation systems, perform external communications, or support vehicle cameras. They use networking interfaces like Ethernet or MOST.
- Low-cost microcontroller-based devices which have been optimized for their respective applications and which are manufactured in large quantities. They use legacy interfaces like CAN or LIN.
The high-performance ECUs, like in PCs and Smartphones, will need more processing power as applications become more and more demanding. This is especially relevant to the industry shift to autonomous vehicles. Consequently, these ECUs are regularly replaced in manufacturing even during the lifetime of a particular model.
The low-cost devices support simple functions which will only change slightly. For example, a microcontroller-based ECU that operates seat adjustment is idle most of the time and has no strict real-time requirements. These ECUs are very stable, sometimes spanning even several vehicle model generations. It is highly likely that they will continue to be used going forward and will continue to be supported by future E/E Architectures. Any shift to new, cost optimized devices that support a native SOA approach and use Ethernet interfaces will happen gradually.
The Steps to an Automotive SOA Future
In the automotive industry, the first step towards abstraction of ECU’s interfaces and the topology began with the introduction of AUTOSAR Classic in 2004, while first steps towards service orientation came with AUTOSAR Adaptive first released in 2017. Since OEMs and suppliers have implemented a large amount of software built to be compatible with the AUTOSAR framework, they will also have to be supported by a new Automotive SOA approach. Only over time can this software be phased out and be replaced with newer software components.
Therefore, in order to reach the automotive SOA vision both new hardware and software solutions have to be brought into the automotive development environment in well-defined steps.
How We Can Untangle Vehicle Architecture with Automotive SOA
An initial step will be the introduction of universal microprocessor-based ECUs. Such ECUs have sufficient performance and memory size to support fully-featured automotive SOA implementations. The automotive SOA middleware provides the secure separation layer, hypervisor and the SOA-specific modules.
This allows applications or services to run in dedicated partitions on top of standard operating systems that have many available applications with a central management partition that organizes the overall SOA framework. Support for AUTOSAR Adaptive will be provided from the beginning to ensure legacy compatibility and these ECUs typically support high-speed Ethernet versions (e.g. Gigabit Ethernet) supporting fast, new network-demanding applications.
The high-performance universal ECUs, on the one hand, allow a consolidation of these devices and lead to a significant cost reduction. On the other hand, additional ECUs can be introduced relatively easily if overall computing performance requires it due to the SOA framework approach, even after a car has left the manufacturing plant.
Message Router Supporting Legacy ECUs
To support existing low-performance ECUs, interfaces have to be adapted, their message formats converted, and the messages routed properly. For example, message routing protocols up to layer 5 have to be handled when using AUTOSAR.
This requires a fast hardware-based routing solution with a rich set of Ethernet and legacy interfaces. This solution can either be integrated into the new high-performance ECUs or implemented as a stand-alone device, like an internal communications hub.
Domain Controller for External Communication
Connected and autonomous vehicles have strong needs for external communication. This includes all the V2X scenarios, download and installation of third-party applications, regular software maintenance by the automaker, audio and video calls by the user and entertainment content.
All communication to the external world has to be highly secure in order to prevent malicious actors and applications from compromising the vehicle’s functionality and impacting driving safety. To perform these secure external functions, a dedicated domain controller needs to be introduced that is physically separate from other ECU implementations. This domain controller will support both wireline (Ethernet) and wireless (WLAN, mobile radio – 4G, 5G) external communication.
Low-Cost MCU-Based ECUs
Over time, the legacy low-cost ECUs will become technologically obsolete. More powerful microcontrollers with more integrated functions, like interfaces and more memory, will become available at a low cost which will enable the consolidation of these ECUs.
It will allow a consistent implementation of the SOA framework also in these devices. When this is achieved, along with the implementation of Ethernet interfaces across the entire E/E Network, the communication infrastructure will become significantly simplified.
Don’t forget to share this post
