Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Grasping architectures for ISO 26262 systems

Posted: 23 Feb 2015 ?? ?Print Version ?Bookmark and Share

Keywords:in-vehicle electronics? electronic control units? ISO 26262? ASIL? OS?

ISO 26262 acknowledges this problem through the importance it places on isolation. If software componentsand especially components of different ASILscan be isolated from each other, then the failure of one component will be contained. The failure won't compromise other components or the entire system. Indeed, many errors, such as writing data into the memory of other processes, may not cause the component that contains the offending code to fail, but may interfere with another component and bring it or the entire system down.

Thus, a resilient system not only uses components that are sufficiently dependable to meet their respective safety requirements (their ASILs for automotive systems), but also isolates safety-related components from the effects of failures in other components. Current strategies for ensuring isolation involve virtualisation and microkernel OS architecture.

Virtualisation
Developers can choose from two main virtualisation techniques: in a Type 1 hypervisor, the different guest OSs run on the virtualisation layer, and in a Type 2 hypervisor, a guest OS runs nested inside another OS.

A hypervisor can help provide the component isolation required of an ISO 26262 system. Two OSs could run on the virtualisation layer, each in a separate environment. One OS would run the safety-related components and the other would run everything else, such as multimedia applications and 3D navigation. Each OS would run as if it were the only OS on the board, using the resources allocated to it by the virtualisation layer.

Things to consider when evaluating virtualisation
Virtualisation is attractive and seemingly simple, but there are many factors, both technical and financial, to consider before adopting a virtualisation solution.

Visibility
Much of the functionality of the virtualisation layer depends on the hardware. The hardware providing virtualisation support is as complex as a memory management unit (MMU). But unlike MMU technology, which has now had years to prove itself in use, on-chip virtualisation support is still relatively new. If a bug on a chip compromises dependability or software component isolation, either the chip has to be replaced, or work-arounds must be found and implemented in the hypervisor and possibly in the safety-related guest OSall expensive undertakings.

Performance
Virtualisation adds another layer of software to the system. New hardware technologies have gone a long way to minimise the latency introduced by the virtualisation layer, but the virtualisation layer itself may still affect performance of critical components. This can be especially problematic for hardware peripherals that require high bandwidth, such as a graphics processing unit (GPU). In a head unit that, for example, combines a low ASIL level infotainment system with a high ASIL level pedestrian-detection warning system, both systems could need to share high-bandwidth GPU resources. The virtualisation layer would need to distribute the GPU resources intelligently so as to guarantee the smooth function of the pedestrian warning system.

Complexity
Hypervisor designs typically involve different OSs: one for the safety-related components and one for everything else. This, of course, is a more complex proposal than building a system with a single OS.

Granularity
Virtualisation isolates the two OSs from each other, but it doesn't isolate components running on each guest OS. The OS running the safety-related components doesn't have to protect these components from non-safety-related components, but it must still be able to isolate safety-related components from each other.

For example, a system that includes an infotainment system, digital instrument cluster, adaptive cruise control system, and lane departure warning system might run the infotainment system on guest OS A and the other components on guest OS B. This approach would isolate the safety-related components from the infotainment system, but does nothing to protect, say, the lane departure warning from interference from the digital instrument cluster or adaptive cruise control. This protection would have to be handled by additional isolation and separation mechanisms within OS B, as specified in ISO 26262, Part 6, 7.4.11:

If software partitioning... is used to implement freedom from interference between software components it shall be ensured that... the shared resources are used in such a way that freedom from interference of software partitions is ensured

Figure 5 illustrates how, even with virtualisation, OS B must provide partitioning to protect the safety-related components from each other.

Figure 5: With virtualisation, the OS running the safety-related components remains responsible for isolating these components from each other.

Long-term cost
The runtime licensing of a hypervisor commands its own share of the Bill of Materials (BOM). Thus, while a hypervisor-based design can reduce hardware costs, it does not necessarily reduce the overall BOM for the software.

?First Page?Previous Page 1???2???3???4???5?Next Page?Last Page



Article Comments - Grasping architectures for ISO 26262...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top