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?

Unlike ISO 61508 SILs, which are for more general applications, ISO 26262 ASILs take into account the specifics of failures in an automobile. Each ASIL is based on a combination of three factors:
???The probability that an event will occur.
???The harm that will likely result from the event.
???The probability that the driver will be able to control the vehicle following the event.

Components whose failure will result in an event that is unlikely to occur, unlikely to cause much harm, and unlikely to interfere with the driver's control of the vehicle may only require a safety level of ASIL A. Components whose failure will result in a common event that may cause great harm (such as serious injury or death) will likely require ASIL C or D, depending on the probability that the driver will lose control of the vehicle.

Interference
A violation of safety requirements occurs when ASIL components interfere with each other. The violation can occur when a component of any ASIL interferes with another component of a higher, equal, or even lower ASIL. Interference can take place when components are working together, or are supposed to work independently of each other. This is of particular concern when the components share a single CPU and memory sub-system.

For example, a communications module of ASIL B might interfere with an adaptive cruise control system of ASIL D. The communication module, in supplying data about ice on the road to the cruise control system, might rapidly broadcast an excessive number of messages (babbling), preventing the cruise control system from doing anything but receive messages. This same communications module might also interfere with a lower ASIL component such as the multimedia player by not releasing memory that the multimedia player needs to buffer music from the Internet.

Table 1: Common ways software components can interfere with the correct behaviour of other software components.

Figure 3: Ways in which other processes can interfere with the correct behaviour of a safety-related process.

Building a resilient system
All design techniques have limitations and drawbacks. Fortunately, design only represents one line of defence. Techniques such as formal design and static analysis should also be used at appropriate stages in the project. And, as specified in ISO 26262, isolation of components from interference by components of different ASILs offers another technique for building resilient systems that can meet safety requirements.

Faults, errors, and failures
Paradoxically, a fundamental principle of safe system design is the recognition and acceptance that the system will contain faults. As Tom Anderson, a professor at Newcastle University's Centre for Software Reliability, wrote in Safety Systems journal:

The inherent complexity of present-day software systems (including single-threaded), compounded by the vast range of possible input sequences with which such systems interact, leads to a pace of behavioural possibilities of enormous magnitude, a space where the notion of determinism becomes a matter of philosophy or even sophistry.

Modern software systems have become so complex that is impossible to empirically prove them fault-free; that is, to test all possible paths and states. Automotive systems are no exception. Quoted in the IEEE's Spectrum magazine in 2009, Manfred Broy, a professor of informatics at the Technology University, Munich, noted that "a premium-class automobile '...probably contains close to 100 million lines of software code'." The authors of ISO 26262 make the point rather less dramatically, but no less accurately:

With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.

Figure 4 presents an adaptation of James Reason's model of how faults become errors, which lead to failures. In short, something is bound to go wrong. Anyone building a safe system must keep this assumption in mind.

Figure 4: James Reason's model (adapted) of how faults become failures.


?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