Functional Safety for Autonomous Vehicles (Part1)

[Author’s Note: This series of articles predates my joining the AV industry. It may have some inaccuracies, but I am leaving it up in case it helps people]

When they are not spontaneously combusting or crashing into parked cars (again, again, and again) autonomous vehicles are the coolest thing since sliced bread.  You want one, and so do I… as long as it doesn’t kill me (either accidentally or SkyNet style).

Autonomous cars are essentially sophisticated control systems and safety instrumented systems on wheels.  The design of the safety functions in these vehicles is governed by the international standard ISO 26262, which is itself an adaptation of IEC 61508.  Unsurprisingly, the principles of functional safety apply to these systems in much the same way they are applied in the chemicals (IEC 61511), nuclear (IEC 61513), rail (IEC 62279), and machinery (IEC 62061) fields, all of which are derived from the umbrella IEC 61508 standard.

In today’s post, we will provide a brief overview of the automotive ISO 26262 standard and highlight some of the key similarities and differences from IEC 61511.  This will be the first in a series of posts to fully cover the automotive standard.  By the end of these articles, you will be well on your way to becoming an automotive functional safety engineer!  Or at least a little closer.

[DISCLAIMER:  I am not an automotive functional safety expert. This post is written from the perspective of an IEC 61511 expert trying to interpret ISO 26262. My interpretations of ISO 26262 may be in error and should not be considered authoritative.]

Structure of ISO 26262

The ISO 26262 standard, Road Vehicles – Functional Safety, was first published in November 2011 and consists of 10 parts, of which 9 are normative and 1 is informative:

1. Vocabulary
2. Management of functional safety
3. Concept phase
4. Product development at the system level
5. Product development at the hardware level
6. Product development at the software level
7. Production and operation
8. Supporting processes
9. Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis
10. Guideline on ISO 26262 (Informative)

Don’t let the number of documents intimidate you.  The normative documents average only 43 pages, the longest being Part 5 at 87 pages.  The informative guideline document is the longest at 97 pages.  Overall, ISO 26262 weighs in at a little more than 1/3 of IEC 61508 and a little more than 1/2 of IEC 61511.

Although ISO 26262 is an adaptation of IEC 61508, it does not claim compliance with IEC 61508.  Unlike IEC 61511, ISO 26262 does not list IEC 61508 as a normative reference.  This will become obvious later as we see that some key concepts have been modified for the automotive industry (e.g. ASIL vs. SIL).

For the remainder of this post, we will discuss parts 1-4 of the standard and highlight commonalities and differences from IEC 61511.

Part 1: Vocabulary

One of the obstacles to getting up to speed with any new standard is the new jargon.  ISO 26262 introduces some unfamiliar terms not found in IEC 61508 or 61511.  However, many of these terms are at least roughly analogous to familiar IEC61511 terms.  Some of the key vocabulary additions include:

• Automotive Safety Integrity Level (ASIL) – One of four qualitative levels (A-D), notionally corresponding to an IEC 61508 high demand SIL, but not equivalent. Can be applied to a Safety Goal or an individual element.
• Functional safety requirements are specified hierarchically, from most general to most specific:
  • Safety Goal – Roughly equivalent to a risk assessment recommendation. Safety Goals are assigned ASILs, but these ASILs may be achieved by multiple systems. Roughly equivalent to the “IPL gap” in a LOPA.
  • Functional Safety Concept – Identifies the functional safety requirements necessary to achieve the safety goal (i.e. close the gap) and allocates to elements (i.e. functions). Similar to allocating SILs to SIFs to close a LOPA gap.
  • Functional Safety Requirement – Specification of implementation-independent safety behavior. Sort of like the definition of the safe state and required actions without specifying hardware.
  • Technical Safety Requirement – Specifies detailed requirements for detection of faults, self-testing, responses to inputs, response times, etc.
  • Hardware / Software Safety Requirements – Specifies the detailed performance requirements and architecture requirements. Includes the probabilistic metrics.
• There is a hierarchy of equipment comprised of, from top to bottom:
  • Item – A system or array of systems that implements a function for the vehicle, e.g. the steering system. Similar to the IEC Equipment Under Control and the Control System. Items have Safety Goals with assigned ASILs.
  • System – A set of elements that relates at least a sensor, controller, and actuator.
  • Element – A collection of components that make up a system or part of a system
  • Component – logically and technically separable part made up of hardware parts (or software units).
  • Hardware part – a piece hardware which cannot be subdivided
• Faults and failures use a somewhat different nomenclature:
  • Perceived Fault – detected by the driver (we might call this operator surveillance or response to alarm)
  • Permanent Fault – fault that stays until repaired (the default in SIS)
  • Residual Fault – a “portion of a fault” that leads to system failure and is not covered by a safety mechanism. Similar to DU failure where some failures are detected by diagnostics and converted to DD failures.
  • Single Point Fault – a “portion of a fault” that leads to system failure and is not covered by a safety mechanism. Similar to a DU failure where HFT = 0.
  • Dual / Multiple Point Fault – ISO does not use the term Hardware Fault Tolerance, but instead talks about single-, dual-, and multiple-point failures. Similar to a DU failure with HFT > 0.
  • Safe Fault – Equivalent to SU and SD failures
  • Detected Fault – fault that is detected by a safety mechanism
• Dedicated measure – There is not really a single term for this in IEC, but includes things to increase confidence in failure rates, like derating, separation, supplier monitoring, etc.
• Safety Mechanism – technical solution to detect faults or control failures. Includes sensors, diagnostics, self-tests, etc.
• Fault reaction time – time from detection of a fault to reaching the safe state. Roughly equivalent to SIF response time.
• Fault Tolerant Time Interval – time from the fault to the hazardous event. Equivalent to Process Safety Time.

The above is not nearly an exhaustive list, but I found that it is enough to start to understand the similarities and differences between the standards without being hopelessly lost in new jargon.  (Now I know how the non-SIS folks feel when we start talking about SIFs, SIL, PFD, HFT, DU, DD, etc.)

Many familiar IEC 61511 terms are also recognizable in ISO 26262, including common cause failures, systematic failures, diagnostic coverage, proven-in-use, and validation, to name a few.  Some important IEC 61511 terms (e.g. hardware fault tolerance, verification) are missing from the definitions list, but we will see later that these concepts are still there in the ISO standard.

Frankly, some of this new jargon seems entirely unnecessary, as the existing IEC 61508 terms seem completely adequate, but maybe I am biased!

Part 2: Management of Functional Safety

Part 2 of the ISO standard outlines the process for management of functional safety and introduces the automotive safety lifecycle, shown below (click to see a larger version).

Safety Lifecycle Figure

Some quick observations on similarities and differences:

• Terms such as safety lifecycle, hazard analysis, validation, and functional safety assessment should be comfortingly familiar.
• Item definition can be thought of as similar to the process design. You need some level of process design definition prior to performing the risk assessment.
• A key difference in the ISO standard is the distinction between production and operation because it deals with mass-produced products (i.e. cars) rather than unique process plants.
• The boxes for Allocation to other technologies, Controllability, and External Measures may seem strange until you know that unlike IEC 61508/61511, the ISO standard mandates a specific risk assessment process in the standard.
• Operation & Production planning are analogous to clause 16 in IEC 61511, but make the aforementioned distinction between production and operation.

The rest of the document includes discussion of other concepts familiar to IEC 61511 users, including: safety culture, competence management, functional safety planning, and verification.

The terminology for verification processes differs a bit from IEC, but the underlying concepts are very similar.  Part 2 outlines the following verification activities:

• Confirmation reviews are intended to check the compliance of selected work products to the corresponding requirements of ISO 26262;
• Functional safety audit evaluates the implementation of the processes required for the functional safety activities;
• Functional safety assessment evaluates the functional safety achieved by the item.

Further detail on verification is found in Part 2 Appendix D which details a list of required verifications.

Part 3: Concept Phase

While Part 2 of the ISO standard introduces the framework and concepts, Part 3 begins to delve into the details of the work processes, beginning with the Concept Phase.  The main activity in this part is the risk assessment, and the main deliverable is the Functional Safety Concept.

This section introduces the “items”, “elements”, “systems” terminology defined above.  The standard then shows how risk assessment must be performed on an item.  This is a key difference from IEC 61508 and IEC 61511, neither of which mandate a particular risk assessment methodology.

The process, called the ASIL Determination process, is fairly straightforward.  It consists of the following inputs:

1. Severity classes: The consequence of an anomaly is classified on a scale of S0 – S3 (Table 1)
2. Probability of Exposure:  The likelihood is classified on a scale of  E0 – E4 (Table2)
3. Controllability: The likelihood that the driver can mitigate the anomaly is classified on a scale of C0 – C3. Similar to a conditional modifier or operator response to alarm. (Table 3)

These three inputs are fed into a risk matrix:

4. ASIL Determination Matrix: Selects the ASIL on a scale of A-D (Table 4)

Note that ASILs are assigned to safety goals, which are roughly equivalent to HazOp or LOPA recommendations.  This may be a little confusing, because later we will see that ASILs can be “decomposed” so that multiple elements can be combined to meet the ASIL requirement.

This section defines the required content of the Functional Safety Concept, which is what is sometimes called the initial SRS, i.e. the SRS that includes the basic safety requirements without any design details.  The section also introduces Technical Safety Requirements Specification, roughly equivalent to a detailed SRS such as we might produce in FEED package

The hierarchical structure of the safety requirements specifications in ISO 26262 is one of their more interesting innovations.  I have long that that the SRS definition in IEC 61511 did a poor job of conveying how the SRS is a living document (actually a set of documents) that develops throughout the safety lifecycle.  The ISO 26262 approach gives some much-needed structure to the SRS development, and the process industries should learn from this approach.

Part 4: Product development at the system level

Once Part 3 has developed the Functional Safety Concept, Part 4 gives the requirements for the Technical Safety Requirements Specification (TSRS).  For example, some items required to be covered by this specification include:

• Safety mechanisms, including detection and indication of faults, measure to achieve safe state, degradation logic, and tests to prevent latent faults
• Logic to transition to safe state (i.e. similar to Cause & Effect) and actions to maintain a safe state.
• Time constraints, including fault tolerant time interval, emergency operation interval,

The TSRS defines the function-level details of what the safety systems must do.  So, it makes sense that this is where ASIL Decomposition is introduced, i.e. breaking down the ASIL requirement for a Safety Goal into more than one lower ASIL allocated to different elements.  This is entirely equivalent to what I would call “stacked SIFs”, i.e. using a SIL1 plus a SIL1 to meet SIL2.

This section also enumerates specific measures for the control of both systematic failures and random hardware failures.  This is essentially equivalent to some of the qualitative methods and guidance given in the IEC standards for the control of systematic failures.

Wrap Up

This post covered Parts 1-4 of the ISO 26262 standard for automotive functional safety and compared it to IEC 61511.  Key takeaways should be:

• One of the challenges is the difference in terminology between the standards, although many concepts are similar.
• The ISO safety lifecycle differentiates between production and operation due to the different business structure
• The automotive standard has a hierarchical structure of SRS that might benefit IEC 61511

The next post will be entirely dedicated to Part 5 of ISO 26262.  This part gets in to the details of calculating ASIL and other metrics.  It will become very clear that ASIL is not the same as SIL!

Thanks for reading! To ensure you don’t miss anything, please follow us on LinkedIn.