Is ISO 26262 just a pain in the ASIL?

Their increasing levels of integration and connectivity provide almost as many challenges as their proliferation, with non-critical systems such as entertainment systems sharing the same communications infrastructure as steering, braking and control systems. The net result is a necessity for exacting functional safety development processes, from requirements specification, design, implementation, integration, verification, validation, and through to configuration.

ISO 26262 ‘Road vehicles – Functional safety’ was published in response to this explosion in automotive E/E/PE system complexity, and the associated risks to public safety. Like the rail, medical device and process industries before it, the automotive sector based their functional standard on the (largely) industry agnostic functional safety standard IEC 61508 which, in turn, drew heavily from the guiding principles of the aerospace standards such as DO-178B /C. The net result is that proven tools are available to help with the implementation of ISO 26262 which are longer established than the standard itself.

ISO 26262:2011 consists of ten parts with three focused on product development: system level (Part 4), hardware level (Part 5), and software level (Part 6). It provides detailed industry specific guidelines for the production of all software for automotive systems and equipment, whether it is safety critical or not.

ISO 26262:2011 specifies a number of hazard classification levels, known as ASILs (Automotive Safety Integrity Levels). ASILs range from A to D, so that the overhead involved in producing a safety critical ASIL D system (e.g. automatic braking) is greater than that required to produce an ASIL A system with few safety implications (e.g. the in-car entertainment system).

ASILs are assigned as properties of each individual safety function, not as a property of the whole system or system component, and each assigned ASIL is in infuenced by the frequency of the situation (‘exposure’), the potential impact should it occur (‘severity’), and how easily it can then be managed (‘controllability’).

Security isn’t explicitly identified as a consideration in ISO 26262, perhaps reflecting the fact that automotive embedded applications have traditionally been isolated, static, fixed function, device specific implementations, and practices and processes have relied on that status. Connection to the outside world changes things dramatically because it makes remote access possible while requiring no physical modification to the car’s systems.

However, as for any other risk, as soon as there is potential for security vulnerabilities to threaten safety, ISO 26262 demands safety goals and requirements to deal with them. In short, the action to be taken to deal with each safety threatening security issue needs to be proportionate to the risk (and hence ASIL).

ISO 26262 process objectives
A key element of ISO 26262-4:2011 is the practice of allocating technical safety requirements in the system design specification, and developing that design further to derive an item integration and testing plan.

It applies to all aspects of the system including software, with the explicit subdivision of hardware and software development practices being dealt with further through the lifecycle.

The relationship between the system-wide ISO 26262-4:2011 and the software specific sub-phases found in ISO 26262-6:2011 can be represented in a V-model (below). Each of those steps is explained further in the document which can be download at the bottom of this page).