Smart Approaches to Consolidating ECUs in Modern Connected Architecture
Add bookmark
Open any industry publication and you’ll be met with images of the "connected car": A sleek, intelligent, digital appliance on wheels, where convenience, comfort, safety, and performance merge with powerful network technologies to keep drivers and passengers connected on the go.
To stay abreast with these developments modern vehicles require the computing power of 20 personal computers and must be capable of processing about 100 million lines of programming code at up to 25 gigabytes of data an hour.
These systems typically rely on several electronic control units (ECUs) to control everything from dashboard instruments, to ADAS, to powertrain components, to in-vehicle infotainment (IVI) systems.
This has resulted in the number ECUs in the average car doubling over the past ten years, with cars now typically having more than 125 ECUs. The growing number of units units take up space, increase power draw and the additional weight impacts on energy efficiency.
To overcome the drawbacks of these "federated architectures" many OEMs are turning to the consolidation of ECUs as a possible solution to the growing demands. But, this consolidation does not come without challenges:
- Increased software complexity
- Consolidation creates complex integration issues
- Intricate testing threatens to extend time-to-market
Multicore processors
The fundamental benefit of multi-core processing is the execution of multiple program instructions in parallel and independent of each other. Traditional processors have one core and execute one instruction at a time. Nevertheless the novelty of the technology is actually not in having multiple cores processing in parallel but having those cores on the same processor.
When considering multicore architectures in automotive applications it’s important to reflect on the following:
- Separation of functions and mixed-criticality support: Different functions need to be able to run simultaneously (in so-called partitions) without affecting each other. In the case of functions that are safety critical, these need to be able to run alongside non-safety-critical functions without their safety characteristics being compromised.
- Multi-OS support and integration: Because different functions are best served by different operating systems, e.g. AUTOSAR (AUTomotive Open System Architecture) for safety-critical functions and GenIVI Linux for automotive infotainment, the multicore system needs to be able to run multiple operating systems at the same time. The main considerations here are flexibility, and the ability to run widely different operating systems.
- Efficient shared use of SoC resources: Different functions make use of the same dedicated system resources. Examples of this include accelerated graphics from different integrated functions, or the shared use of communication channels. This requires the software design to facilitate efficient resource sharing.
A good example of one such multiprocessor is the S32V processor from Freescale. According to Ray Cornyn, vice president of automotive engineering for microcontrollers, using quad ARM Cortex-A53 cores, the S32V is designed to meet automotive-grade quality standards. These standards ensure the device has a large amount of redundancy integrated into the circuitry, and also includes safeguards against wireless interference. The quad-core ARM-based processor uses second-generation smart image processing from CogniVue, and can receive and process data from a number of sensors.
[eventpdf]
The new SoC, in addition to advanced vision algorithms and sensor data-fusion capabilities, provides protection against potential external wireless attacks, a much needed feature in the era of the Connected Car.
Other safety features enabled in the SoC include redundant signal paths, software-error checking, hardware-fault detection and hard partitioning allowing the system to safely shut down and perform a controlled reboot without compromising safety critical systems such as braking and steering.
The chip has been supplied in limited quantities since July 2015 and will probably be available for series production vehicles in 2017.
Using multi-core processors unused resources can provide redundancy to compensate for permanent faults; for example, by switching computations from a failing core onto an unused core which can have its own cache memory. In addition to multiple cores, chips can also have multiple power pins, I/O ports and other resources.
Running the same computations on multiple cores in parallel not only allows an easier switch to using the results of a redundant core, but also the comparison of the results to verify accuracy: For example, three parallel processors provide a triple modular redundancy (TMR) structure. Different versions (by different design teams) of the software provide diversity that could allow a TMR scheme to discover design errors in addition to hardware failures.
Virtual partitioning
Virtualization technology has proven to be the best solution for ensuring that these powerful multicore processors are exploited to their full potential. Within this concept the multicore-SoC can host several partitions, where each partition acts as an independent virtual machine.
With the rapid adoption of automotive virtualization, manufacturers can now run multiple systems on a single computer, from highly reliable Linux software for mission-critical functions to highly customizable Android software for infotainment services.
By way of example specialist embedded automotive software company, OpenSynergy, has successfully adapted this technology to software systems with different timing requirements and safety levels; allowing these to run without interfering with one another. Practically this means that Linux-based infotainment software can run on one partition while automotive systems run on another.
However, this system requires an additional integration step, potentially slowing down the process.
Virtualized ECU combined with Multi-Core
To further optimize the process Wind River, a world leader in embedded software for intelligent connected systems, has developed the virtualized ECU approach by adding multi-core processing capabilities.
The basic concept is to centralize computational power into function-orientated regions, decouple software functionality from the underlying hardware using virtualization technology, and deploy virtual ECUs on multi-core processors so there is little interference between them.
This model creates the opportunity to consolidate a large num¬ber of software-driven functions onto a smaller number of more powerful hardware platforms. Equally important, it helps solve the separation/latency trade-off dilemma. Each application is "walled off" from the others, but each can still receive configurable, adjust¬able CPU resources to meet performance requirements.
The virtual ECU/multi-core approach also moves integration to an earlier stage of the project, so development and testing teams can identify bugs and other issues sooner, solve problems faster, and accelerate time-to-market. And legacy software and individual functions can be upgraded or replaced at any time, over the air, eliminating the need to bring the car in for servicing to deal with software issues.
From a security perspective, there are several advantages to the virtual ECU/multi-core approach:
- First, it fundamentally simplifies threat analysis, because it is possible to build a virtual security appliance into the ECU once, rather than build a separate one for each indi¬vidual ECU. This approach saves time and money and minimizes the performance impact of security inspection and analysis.
- Second, security researchers can use sophisticated simulation tools such as Wind River Simics to systematically test and gain a deeper understanding of every aspect of system behavior. Simulation can help create an improved integration and testing environment, and it can also expose flaws in hardware and software design and allow systems to be debugged faster and more effectively.
- Third, the Wind River approach makes it possible to combine safe and unsafe functions without increasing risk to other software ele¬ments or impacting compliance.
Whilst ECU consolidation has been a goal of automakers for years, it’s only recently that manufacturers have taken action – largely because of the imminent arrival of hoards of connected and selfdriving cars. The critical electronically controlled systems in these vehicles will only be viable if the complexity and cost is reduced and performance and functionality improved.
