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

Examining ISO 26262 from a developer's viewpoint

Posted: 01 Dec 2014 ?? ?Print Version ?Bookmark and Share

Keywords:Advanced Driver Assistance Systems? ADAS? ISO 26262? Automotive Safety Integrity Level? ASIL?

Both GSN and Bayesian representations are tree-based and each leaf resolves to a piece of evidence: a document, a test result, a formal analysis, etc. Listing these against each subclaim in the argument makes it easier to check that all the necessary evidence has been identified and speeds up the audit: "You agreed the structure of the argument previously, so all we need to do is check that each piece of evidence really does support the associated subclaim."

Confidence from use
ISO 26262 uses the term "proven in use" for an argument of the form: "We have had X of these devices in the field for Y hours and only had Z failures, and we therefore claim that the device meets the requirements of ASIL B." As no proof is involved, I prefer the term "confidence from use" or "confidence through use" and this is the term that ISO 26262 uses for tools.

Part 8 of ISO 26262 provides some standard statistical formul? to quantify the number of hours of use needed to support a confidence from use argument:

Equation 1

where: t is the necessary number of hours, CL is the required confidence level (ISO 26262 suggests 0.7), is the mean observed time to failure, f is the number of safety-impacting incidents, and

Equation 2

is the chi-squared distribution with error probability a and n degrees of freedom. For example, for an ASIL C system, the requirement is that t>1.2 x 10^8. Note that 1.2 x 10^8 hours is approximately 13,700 years.

A Structured Approach
ISO 26262 certainly adds some overhead to the development process that is normally applied to software on which system safety depends. In particular, it requires a more structured approach that would perhaps otherwise be applied.

The standard mandates three fundamental documents on which all the others are built:

1. The Hazard and Risk Analysis that identifies the safety requirements and residual risks of the system. This must be created early and updated as the project progresses.

2. The Safety Manual that accompanies the product to the field and sets the constraints within which the product must be deployed.

3. The Safety Case that presents the claim made about the product and the argument for believing that the claim is justified. This is built throughout the project development; it would be very difficult to recreate the evidence retrospectively.

The development team must also adopt the tools and techniques (highly) recommended within ISO 26262 or present a good argument as to why they have not been adopted. That said, any team working on a safety-critical development project would probably apply most of the recommended techniques, even without the stimulus of ISO 26262.

It would be good to think that, once ISO 26262 systems are ubiquitous in cars, there will be no more Mary Wards. In reality, no specification is perfect, no design is perfect, no implementation is perfect, no audit is perfect, and no system can ever be 100% safe. But the application of the techniques described in ISO 26262 can move most development projects in the direction of increased safety.

Some have criticised ISO 26262 because, if it is mis-applied, it can become a checklist rather than a source of useful techniques whose applicability needs to be assessed for each project. Effectively a system can be designed to meet ISO 26262 rather than to be safe. But it is our role as professional designers to avoid this pitfall.

About the author
Chris Hobbs is Senior Developer, Safe Systems at QNX Software Systems.

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

Article Comments - Examining ISO 26262 from a developer...
*? 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