The car in which Mary was travelling in 1869 is not reported to have had software-controlled systems, but today an often-quoted comparison states that a modern airliner contains about 7 million lines of software code, whereas a modern car contains 20 million. In the past much of the car's software has been related to non-safety-critical applications such as infotainment, but increasingly, ADAS systems and cars with semi-autonomous capabilities are making use of software in applications that directly affect safety.
ISO published the ISO 26262 standard in 2011/2012. This standard recommends tools, techniques, and methodologies for developing such systems and affects many departments within an organisation producing software for cars. This article provides an introduction to the standard from the point of view of the system designer and implementer and is based on QNX Software System’s recent experience certifying its operating system to ISO 26262.
ISO 26262 at a glance
There is an old joke about someone asking the way to a destination and being told “well, if I wanted to go there, I wouldn’t start from here”. This quandary also applies to ISO 26262, which is based on the IEC 61508 standard, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems. The linkage between the two standards is beyond the scope of this article, but any reader who wants a deep understanding of ISO 26262 should first study IEC 61508.
ISO 26262 applies the techniques of IEC 61508 to electrical and electronic systems that provide functional safety in production passenger cars lighter than 3500 kg. It does not apply to trucks, buses, special-purpose vehicles, or cars adapted in some way (e.g., for disabled drivers).
“Functional safety” is a key concept: safety can be provided in a system in several ways, and functional safety describes an architecture where the safety component has to continue functioning to maintain the overall safety of the system. The component may have to function continuously or only on