Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > 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?

In simpler systems, scheduling policies and tools such as rate- and deadline-monotonic scheduling can help ensure that processes meet their real-time deadlines. For example, with rate-monotonic scheduling, the processes with greater execution rates receive the highest priorities. For some systems it is then possible to provide mathematical proofs that real-time deadlines will be met.

Preventing illegal memory access
A hardware MMU can prevent illegal memory access in conjunction with the OS. If the OS supports this feature, the MMU will prevent a process from reading, or writing to, the memory of another process. This should be a required feature of any software architecture used for a safety-related system.

Preventing data corruption
Protection against data corruption includes checksums, simple replication, data diversification, and sanity checks. Of all these options, a checksum or cyclical redundancy check (CRC) added to the data probably uses the least memory, but does not allow repair of corrupted data. Replication simply copies the data over to more than one location, sometimes remotely. With diversification, the same data is stored in more than one location, in different semantic ways. Sanity checks ensure that the data read is within acceptable parameters and rejects anomalies.

These techniques can all increase memory or CPU overhead. However, they can all be useful in systems that require guaranteed operation under adverse conditions, so the cost of implementing them should be considered during system design.

Preventing babbling
Babbling and malicious denial-of-service attacks can be contained by an anomaly detection program that learns what constitutes normal behaviour and takes corrective action when the system begins to behave outside expected boundaries. Also helpful for this type of testing is "fuzzing," where you intentionally call program functions with malformed inputs or in unexpected ways as a way to uncover conditions that the system cannot handle correctly.

Preventing deadlocks
Deadlocks occur when cooperating processes wait for each other to complete an action. Because both processes are waiting for the other to finish, progress stops.

Priority inheritance can help prevent deadlocks. It solves the problem of priority inversion, where a low-priority task prevents a task with a higher priority from completing its work. Priority inheritance prevents priority inversions by assigning the priority of a blocked higher-priority task to the lower-priority thread doing the blocking until the blocking task completes (figure 8).

Hardware watchdogs can also help address deadlocks, but they may not always detect a deadlock because they are oblivious to processes from which they are not expecting a "kick." In comparison, a software watchdog, or high-availability manager, can help ensure that progress is being made. If the system architecture allows separate components to be stopped and restarted without a complete system refresh, a software watchdog can stop and reset the offending process or processes while the rest of the system continues to run.

Figure 8: Priority inheritance can prevent lower-priority threads from blocking the execution of higher-priority threads.

In response to customer demands for more applications, features and services, and to economic pressures, automakers are consolidating non-safety-related and safety-related components on a single platform in their vehicles.

A microkernel OS can provide a full set of OS features to support consumer demands while ensuring that the system meets its safety requirements. The trusted code in a microkernel OS is simple and small, with a well-tested and short execution path that is granted system-level privileges. In short, a microkernel OS is inherently appropriate for safety-related systems. When a system design calls for two different operating systems to co-exist on a single piece of hardware, a hypervisor is an effective solution. Nonetheless, our experience building both in-vehicle infotainment systems and safety-critical systems (including systems built with the IEC 61508 SIL3-certified QNX OS for Safety) suggests that a single microkernel OS can provide all the features needed for infotainment systems and the dependability and isolation guarantees required by ISO 26262.

About the author
Yi Zheng is Product Manager, Safe and Secure Systems at QNX Software Systems.

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

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


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

Back to Top