Automotive Functional Safety: What It Is and Why You Should Care
Historically, functional safety has been measured by reliability as determined by various statistical methods including Markov analysis and fault tree analysis. But as the automotive industry accelerates into an era marked by increasingly complex embedded software solutions associated with advanced driver assistance systems (ADAS) and autonomous driving (AD), it is clear that such a general definition is not sufficient.
Therefore, the International Organization for Standardization (ISO) developed ISO 26262 – adapted from the more general International Electrotechnical Commission (IEC) 61508 – for defining the functional safety of a vehicle’s electrical systems. This includes risks that might arise from hardware or system faults, software development, or during production. ISO 26262 prescribes properties and criteria that must be fulfilled as a part of functional and technical safety.
As Chris Hobbs and Patrick Lee cogently explain in their article, “Understanding ISO 26262 ASILs,” ISO 26262 is not a reliability standard like IEC 61508. It goes beyond mere probability of failure. The ISO 26262 does not, say Hobbs and Lee, set dependability requirements but rather provides “guidance to help establish dependability requirements, based on the probability and acceptability of harm.”
The Anatomy of an ASIL
ISO 26262 defines five Automotive Safety Integrity Level (ASIL) classifications, from ASIL-QM (no safety ramifications) to ASIL-D (the most stringent safety requirements). At ASIL-D, if something goes wrong, the error must be detected and the system brought into a safe state within a specific time period.
An ASIL classification has three ingredients: severity (S), probability of exposure (E), and driver controllability (C). Any hazardous event is assessed in terms of severity of possible injuries within the context of the relative amount of time a vehicle is exposed to the possibility of the hazard happening as well as the relative likelihood that a typical driver can act to prevent the injury.
The reason for including all three variables is that the severity of a possible injury is affected by the likelihood of injury; that is, for a given hazard, a hazardous event is considered lower-risk if it is less likely to happen. Think of it this way: if you never fly in an airplane, the risk of your dying in a plane crash is almost zero, even though plane crashes are likely to cause life-threatening injuries. Even if you fly often, having an ace pilot can reduce your risk of dying in a plane crash compared to a baboon piloting the plane.
ISO 26262 establishes categories for each of these variables:
ISO 26262-3, section 7 of ISO 26262 explains how you can combine these variables to determine an ASIL classification. But even so, the process is far more subjective than the IEC 61508 SIL determination process. The work-in-progress SAE J2980 standard may help by providing guidance for classifying vehicle-level hazards. As well, Hobbs and Lees suggest that methods such as “as low as reasonably practical” (ALARP), “globally at least as good” (GAMAB), and “minimum endogenous mortality” (MEM) may be used to set numerical values for dependability. There’s no question – ISO 26262 is a giant step in the right direction, but there remains more to be done before automotive functional safety is as well defined as functional safety in other industries.
So Why Should You Care about ASILs?
Familiarity with ISO 26262 and ASIL determination is likely to become a differentiating quality for embedded software engineers and suppliers all along the automotive food chain. Here are two more reasons you should brush up your functional safety skills:
-
Consumer confidence. Functional safety is becoming an important aspect of consumers’ purchase decisions.
-
Time to market. Setting the wrong ASIL for a system or component can negatively affect the cost and schedule of the development.
The industry is definitely starting to emphasize functional safety. In addition to the new SAE standard mention above, organizations are forming functional safety groups. One example is the UK’s Automotive Electronic Systems Innovation Network’s (AESIN) ADAS & Autonomous Vehicles workstream.
What’s Your Next Step?
As the above discussion illustrates, there’s a lot going on behind the scenes for automotive functional safety and ASIL determination. Several companies and organizations offer ASIL training. And then there’s certification to consider. An embedded software solution consists of many hardware and software components, each of which has its own ASIL. ASIL certification can be considered as a “technical passport” which can speed overall solution development.
If you want to further explore automotive functional safety and its importance to embedded software solutions, read the following two white papers:
