With a century of experience behind them, automakers have the building of the mechanical part of the car down to constant improvement and refinement of details. In-vehicle electronics, which include dozens of electronic control units (ECUs) and a head unit running complex infotainment software are a different matter. Not only are these systems evolving rapidly, but consumer demand for new applications and services is straining automakers’ ability to deliver.
Of course, automakers must provide all these new features without breaking the bank. The need to control costs, together with the availability of high-performance, low-cost processors, is driving consolidation of multiple in-vehicle systems onto one board. A design that eliminates one $50 module per vehicle translates into a substantial sum when multiplied by 5 million vehicles.
This consolidation creates its own challenges, however. In particular, many in-vehicle systems are safety-related, while others are consumer applications and impossible to prove as safe — yet all these disparate systems may need to run on the same CPU. Moreover, any in-vehicle system may now be connected, directly or indirectly, to the outside world. While this connectivity opens many new possibilities, such as over-the-air (OTA) firmware updates, it also creates new security and safety challenges.
The problem, then, is how to design and validate a system that incorporates components unlikely to require safety certification (for instance, a 3D display running consumer-grade applications) with components whose dependability and freedom from undesired interference must be rigorously engineered and proven (for instance, a blind spot detection module).
It is no accident that a main task set out by ISO 26262 Road vehicles—Functional safety is the isolation of components.
ISO 26262 ASILs
Adapted from IEC 61508, which specifies safety integrity levels according to probability of failure, ISO 26262