Architectures for ISO 26262 systems with multiple ASIL requirements

February 03, 2015 //By Yi Zheng, QNX
Architectures for ISO 26262 systems with multiple ASIL requirements
The exponential increase in the number and complexity of in-vehicle electronics has transformed the automobile. At one time, the car was primarily an assembly of mechanical components; it has now become a system that integrates both mechanical and electronic components, with the electronic components representing a substantial portion of the added value and a disproportionate share of the headaches.

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.

Figure 1. In-vehicle safety-related and non-safety-related systems distributed across different modules throughout the vehicle.

Figure 2. The same safety-related and non-safety-related systems shown in Figure 1, consolidated in the head unit.

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

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.