There is a shift in automotive electronics design from having multiple electronic control units (ECUs) – one for multiple individual onboard systems – to having a few consolidated ECUs, each managing numerous functions.
While there are significant benefits to this approach, there are also additional risks that need to be considered, particularly during the software development process (and the future of ECUs will very much be software-defined). The potential advantages, however, can outweigh the risks, particularly if those risks are adequately addressed.
Modern vehicle electronics have come a long way from the origins of a single ECU for engine management. There are now ECUs for antilock brakes, power steering, dashboard instrument displays, heads-up displays (HUDs), in-vehicle infotainment (IVI) systems, a variety of Advanced Driver Assistance Systems (ADAS), and the list continues to grow.
In fact, current models typically have a hundred or more individual ECUs on board.
As vehicles evolve and become increasingly ‘clever’ - and more akin to a software platform on wheels to which OEMs and third parties sell services - even more ECUs need to be added. However, simply adding more ECUs for more systems is not sustainable. The wiring alone to connect all these components adds a huge amount to the vehicle’s cost, weight, and power consumption.
In addition, with all these separate, individual ECUs - which are generally specialist hardware - there is a sourcing and supply chain issue, where the supply of a single ECU chip can delay an entire model on the production line.
ECU consolidation trends
Therefore, a new trend is emerging, where ECUs are consolidating, with fewer ECUs, and each one handling several functions, with access to common resources. For example, sensors, cameras, and memory. As a result, ECU consolidation could substantially reduce weight, component volumes and overall cost.
Ultimately, there could even be just one ‘super’ ECU acting as a giant brain and controlling all onboard systems. However, the more likely short-term approach is grouping ECUs with shared commonalities.
One example is the IVI system ECU, which may include the driver instrument clusters, the navigation system, audio and visual entertainment systems (for passengers), telematics systems, and even augmented reality (AR) applications for future driver assistance systems. All these functions share the need for high-performance graphics processing, high-throughput data streaming, and mobile communications. Therefore, combining these functions could reduce the need for certain (and costly) components, such as graphic processing units (GPUs) and network interfaces, which would additionally reduce hardware costs. Consolidated ECU groups for areas of vehicle functionality are often referred to as ‘domain controllers’ or ‘zone controllers’.
Software-centric risks
These heavily software-centric, consolidated future environments introduce several fundamental performance, safety, and security concerns that must be considered.
Firstly, in a consolidated ECU environment, one chip shares central resources, such as memory and signal inputs, so a failure in one piece of shared hardware or one hardware interface could affect multiple systems, which in turn could compound the effects of a failure.
Secondly, shared resources also mean potential issues in the scheduling and prioritisation of processes. For example, it is obviously essential to ensure that any systems with higher safety requirements (such as drive function or driver instruments) get priority over less critical systems.
Thirdly, if the traditional barriers provided by separate ECUs and limited communications interfaces (such as CAN, LIN, and Flexray) are replaced with direct software interfaces, and software-enforced limits and controls will also be necessary.
Without controls in place, consolidated software components could interfere with each other, either inadvertently or intentionally, at the hands of a malicious actor. For example, security vulnerabilities in the IVI telematics system could more easily allow for attacks on driver information and instrument systems.
The ECU virtualisation solution
The quick and perhaps most obvious solution to the challenge of ECU consolidation is afforded by virtualisation of the individual ECUs, which then run on a hypervisor. Several such hypervisors are available, both commercially and from the open-source community. However, a number are developed specifically for safety-critical and embedded systems, where ‘lightweighting’ and low power are additional key requirements.
Hypervisors providing support for unmodified guest operating systems (O.S.s) and Real-Time O.S.s (RTOSs) significantly ease portability for legacy applications and therefore provide the most straightforward solution to ECU consolidation by ‘simply’ virtualising the existing independent ECUs and allowing them to run on shared (more generic) hardware.
However, there are still several concerns with respect to the levels of interaction and prioritisation of these individual systems. And one could also argue that simply virtualising large numbers of discreet systems to run on shared hardware does not ultimately resolve the issue of the sheer numbers of systems nor provide the most optimal use of the hardware resources available.
While virtualisation provides a great intermediate solution, moving toward shared hardware resources, the long-term approach is likely to include integrated or multi-functional systems too. In this case, multi-threading and more complex code will be an inevitable part of ECU consolidation, putting additional pressure on developers to ensure that every single line of code is as robust, safe, and secure as possible.
Impacts on safety certification
The ISO 26262 functional-safety standard for automotive systems already provides guidance for handling components with differing safety levels, known as the Automotive Software Integrity Levels (ASILs).
In situations where common components are used by multiple systems, or there are dependencies on another component or system, the higher ASIL level prevails. Therefore, if there is a software component that has been developed to ISO 26262 ASIL A and this co-exists with a second component that requires compliance to ASIL D, then the whole system has to be developed to the ASIL D requirements. Clearly, this scenario will generate additional effort, higher costs, and increased requirements for providers of external components, including hypervisors.
The alternative option, allowed by the ISO 26262 guidelines, is to prove that the lower ASIL components do not interfere with the function of the higher ASIL components. This will be easier where separate systems are running via virtual machines (VMs) but less easy where two software systems co-exist within one environment.
Secure and safer ECU software
Fortunately, there are some tried-and-tested techniques, resources, and tools to improve software quality and security as well as reduce or show dependencies. These include static analysis (SA) tools for architectural comprehension, vulnerability detection, and coding standards enforcement.
Coding standards, such as MISRA and CERT, are sets of guidelines or rules that aim to reduce complex, confusing, and insecure coding practices and prevent undefined behaviours, which may lead to software vulnerabilities and system malfunction. For example, buffer overflows, which guidelines like CERT seek to avoid, can lead to the system behaving in an unexpected manner or for a malicious external actor to gain control via the program counter.
Coding standards are already recommended as part of ISO 26262 compliance, and for compliance with the new ISO/SAE 21434 automotive cybersecurity standard. The latter has been more recently introduced to specifically focus on addressing the cybersecurity risks associated with vehicle electronic systems, covering all aspects of the vehicle’s lifecycle, including secure software development.
Coding standards are typically enforced using a SA tool or static application security testing (SAST) tool, and compliance to the specified standard or guidelines can then also be reported via the tool output. Enforcing coding guidelines via tools as part of the developer’s daily workflow typically helps to engender better coding practices among the individual developers. Even though more aspects of software development are being automated, it is still important for all team members to understand why these rules are being enforced, why it matters, and how to write code that is more robust and more easily maintained in the future; it creates better programmers.
More advanced SA or SAST tools can not only check against rules from coding standards, but also use dataflow analysis, to perform ‘what if’ testing of all possible paths through the code to determine where additional runtime failures or security vulnerabilities may exist. And as sophisticated SA tools build up an internal view of the full system dependency tree and call tree to perform the dataflow analysis, it is usually possible to also output this information to visualise software component inter-dependencies.
SA tools often do not require an entire software system to be built or even present for the analysis to happen, which means that checks can be performed before the code has been run. This enables the opportunity to ‘shift-left’ checking and remediation actions for coding errors, leading to improved productivity. Functional testing is required but is often a time-consuming process within ISO 26262 compliant development, so the more code issues that can be weeded out during the software development phase, the lower the time spent finding and fixing these issues (and dependencies) downstream. And, of course, the larger and more complex the systems being developed, the greater these savings become.
All these techniques and tools will help contributors to the automotive electronic design process to adopt ECU consolidation safely and securely and, therefore, make the most of the potential benefits: lighter vehicles, fewer hardware components, and better cost control.
Author details: Steve Howard, Field Engineering Manager, Static Analysis Tools, Perforce Software
