We have all heard the (apocryphal) story of the motor-home driver who sets the cruise control and then goes back to make coffee, since he/she was told that the cruise control looked after everything. The story has been around the internet for years and while wholly untrue (at least I hope it is) it still has, at its heart, one of the essential questions of safety – who is responsible? Presumably the cruise control did exactly what it was meant to do, control the speed of the vehicle, but this wasn’t what the driver expected it to do.
The cruise control is now electronic, as are many of the control and related functions in today’s cars, and the motor car is by far the most dangerous artefact in human hands. Even in the United States it is responsible for more deaths than any other single cause, including guns. And where gun deaths are mostly deliberate, either other people or suicide, the overwhelming majority of car deaths are “accidents.” Yet, while there are safety standards for the electronic systems for nuclear installations, for aeroplanes and for railways, until now there has been no safety standard for electronic systems in cars. Some possible reasons for this have been discussed by the York University Safety Critical Newsgroup, and we will return to these after we have looked at the new standard (ISO DIS 26262 – Road Vehicles, Functional Safety). Like all standards, this has taken a long time to appear and is now out for discussion.
Firstly we need to look at who prepared the standard: like all standards, 26262 has emerged from an industry effort, involving auto manufacturers and tier one suppliers from around the world, but with a strong European element. (Organisations from Austria,France, Germany, Italy, Japan, Sweden, the UK, and the USA all contributed to the standard.)
One thing that was discussed on the York list is the difference in attitudes in determining acceptable levels of safety from different countries. IEC 61508 – Functional safety of electrical/electronic/programmable electronic safety-related systems, is the root standard for much of the safety work in civil applications. It establishes SILs (Safety Integrity Levels) as a measure of safety. SILs range from SIL 1 (lowest) to SIL 4 (highest) and are indicators of Probability of Failure on Demand (PFD) with SIL 1 being highest PFD (0.1 – 0.01) and SIL 4 lowest (.0001 – 0.00001) or, if you prefer, their inverse, the Risk Reduction Factor, where SIL 4 has the highest RRF (10,000 – 100,000) and SIL 1 the lowest.
26262 doesn’t use SILs, unlike the other descendents of 61508. Instead it uses ASILs (Automotive Safety Integrity Levels). To make the difference clear, ASILs run from A (lowest) to D (highest) and there is no one-to-one matching between 61508 SILs and 26262 ASILs. The approximate correspondence between SILs and ASILs is that ASIL A is approximately SIL 1, ASIL B is approximately SIL 2, ASIL C falls between SIL 2 and SIL 3 and ASIL D is approximately SIL 3. There is no equivalent in 26262 to SIL 4.
One thread on the argument suggested that there was reluctance among some car manufacturers to use the term “safety system” preferring instead to use a phrase like “driver assistance,” which puts the onus for safety on the driver, not the system. Systems like lane following (where cameras attempt to keep the car from crossing lane markings) or distance tracking (where cameras/radar or whatever measure the distance from the car in front), while they can control the car, are easily over-ridden by the driver. This is in contrast to, for example, rail safety systems in use in Europe and elsewhere, where the system can over-ride the driver by applying brakes in a hazardous situation. There are, of course, differences. The most obvious is that you are working in a different environment; the train is constrained directionally by rails. Also the train can be carrying several hundred passengers, who are entirely at the mercy of the railway system.
To return to ISO DIS 26262. It is concerned with “safety-related systems that include one or more E/E (electrical/electronic) systems and that are installed in series production passenger cars with a maximum gross weight up to 3.5t.” (This is the metric tonne of 2,205 lbs.)
The ten parts of the standard are published as separate volumes, and go from Part 1, Vocabulary, through Management of functional safety, Concept phase, Product development: system level, Product development: hardware level, Product development: software level, Production and operation, Supporting processes, and ASIL-oriented and safety-oriented analyses, to finish with Part 10, Guideline on ISO 26262.
An interesting element is part 7 Production and operation. 61508 and the nuclear standards are concerned with industrial process and related technologies, where the developments are one-off or very low single figures. Cars, of course, are built in multiples of many thousands, and so the standard covers the different elements of the automotive product lifecycle; management, development, production, operation, service and decommissioning.
Parts 3 to 6 in the standard cover the development process. The standard uses a V model for system development, with hardware and software development following their own V models within it.
The phases recommended for software development are:
Initiation of product development at the software level
Specification of software safety requirements
Software architectural design
Software unit design and implementation
Software unit testing
Software integration and testing
Verification of software safety requirements.
Each phase of the development is a Clause in the standard, and a Clause has a standard structure of Objectives, General, Inputs, Requirements and recommendations and Work Products. The Work Products of one Clause normally form the Inputs to the next.
The Requirements and recommendations are the core, the things that have to be followed for a system to be compliant with the standard. For example, Clause 5.4.8 is “The criteria to be considered when selecting a suitable modelling or programming language…” This covers such matters as an unambiguous definition, the support for embedded real-time software and runtime error handling; and the support for modularity, abstraction and structured constructs. It is interesting that graphical modelling is an acceptable approach to system development.
Language properties also surface in the discussion on ASILs in Part 9. For example, “Initialisation of variables” is highly recommended for all ASILs. “Limited use of pointers” is highly recommended for ASIL D, while for ASIL C and ASIL B it is only “recommended” and for ASIL A there is no recommendation. Table 9 also has a NOTE: “For the C language, [MISRA C] covers many of the methods listed in Table 9.” In the languages of 26262, “A NOTE is only for guidance in understanding, or for clarification of, the associated requirement and shall not be interpreted as a requirement itself.”
Now that the draft has appeared, how important is it? Why do we need a standard? Nobody is knowingly going to build unsafe systems, are they? One reason is that we need a common vocabulary to describe what we are doing. Another is that the vertically integrated model of car manufacturing that Ford created at Rouge River and elsewhere, where coal and iron went in one end and cars came out the other, has long been replaced by hierarchies of suppliers. This makes a common set of processes and measurements very important. Whether or not 26262 is adopted formally next year, or in ten years’ time, the very existence of a standard is going to play a part in the considerations when designing or upgrading an automotive system. If a legal case takes place, someone is bound to point at 26262 as at the very least an example of best practice when assigning blame.
But there is another programme among car manufacturers that suggests that 26262 will be adopted: AUTOSAR (AUTomotive Open System ARchitecture), an open-software architecture for automotive applications. The intention is that AUTOSAR will provide a common software infrastructure, with standard interfaces, to make the development of software and systems modular, scaleable, transferable, and reuseable. AUTOSAR starts from Software Components, each carrying out a specific function. These go through an AUTOSAR interface to the AUTOSAR runtime environment, including OS, drivers, etc, and run on the underlying hardware. This approach decouples the applications and their hardware, making it easier, for example, to transfer applications to different hardware or to upgrade applications.
Last week the AUTOSAR consortium published an updated roadmap, and before the end of the year, release 4.0 of the AUTOSAR environment will be available. Amongst other things, it will “provide support for functional safety requirements as described in ISO standard 26262.”
But back to the original question. ISO 26262 will provide evidence that systems within the car are by some formal measure “safe.” These systems will do everything that the car manufacturers can think of to provide drivers with information and support for safe driving and to protect them and their passengers when an accident takes place. But the final responsibility falls on the driver. Five years ago I heard an expert on auto safety finish a presentation on new safety tools, such as lane following, by saying that the easiest way to reduce death on American and other roads was to immobilise the car if the driver was not sober. The technology exists, but his view was that no government was brave enough to mandate it. So perhaps we have to resign ourselves to creating systems to protect idiots from the consequences of their own behaviour, since we all drive extremely well.
