ISO 26262 includes different functional safety requirements based on ASIL levels.
January 3, 2019

What Is ISO 26262? An Overview

Security & Compliance
Static Analysis

ISO 26262 is a functional safety standard used in the automotive industry. It’s titled “Road vehicles — functional safety”.

Complying with this standard is critical for automotive product development. OEMs, their suppliers, and developers of automotive components all need to comply.

Here, we give an overview of the standard and ASIL (Automotive Safety Integrity Level) — plus compliance tips for software development teams.

ISO 26262 Functional Safety Overview

ISO 26262 is a risk-based safety standard that’s derived from IEC 61508. It applies to electric and/or electronic systems in production vehicles. This includes driver assistance, propulsion, and vehicle dynamics control systems.

The standard covers functional safety aspects of the entire development process:

Why ISO 26262 Is Important

The goal of the standard is to ensure safety throughout the lifecycle of automotive equipment and systems.

Specific steps are required in each phase. This ensures safety from the earliest concept to the point when the vehicle is retired.

By complying with this standard, you’ll avoid or control systematic failures. And you’ll detect or control random hardware failures. (Or, you’ll mitigate the effects of failure.)

Explore Other Functional Safety Standards >>

Parts of ISO 26262

There are 10 parts to the standard:

  • Part 1: Vocabulary.
  • Part 2: Management of functional safety.
  • Part 3: Concept phase.
  • Part 4: Product development at the system level.
  • Part 5: Product development at the hardware level.
  • Part 6: Product development at the software level.
  • Part 7: Production and operation.
  • Part 8: Supporting processes.
  • Part 9: ASIL-oriented and safety-oriented analysis.
  • Part 10: Guideline on the safety standard.

The second edition of the safety standard was going to have a section focused on safety of the intended function — SOTIF. However, SOTIF has since been published as its own standard — ISO/PAS 21448.

ISO 26262 For Software Developers

Part 6 is the most important part for software developers. It details the steps developers must take to ensure the safety of each component.

What's more, Part 6 includes several tables that define the methods that must be considered in order to achieve compliance with the standard.

See what’s covered in these tables >>

ISO 26262 Tool Qualification

Any tools used in automotive development need to be qualified. Part 8 provides guidance for tool qualification.

It requires the following:

  • Software tool qualification plan.
  • Software tool documentation.
  • Software tool classification analysis.
  • Software tool qualification report.

Some tools are easier to qualify than others. For instance, Helix QAC — a C/C++ static code analyzer — comes with certificates of compliance that make the qualification process easier.

Why Automotive Safety Integrity Level (ASIL) Is Important

Automotive Safety Integrity Level (ASIL) is a key component of the safety standard. ASIL is used to measure risk of a specific system component. The more complex the system, the greater the risk of systematic failures and random hardware failures.

There are four ASIL values, named A–D. ASIL A is the minimum level of risk. And ASIL D is the maximum. So, ASIL D has stricter compliance requirements than ASIL A.

When determining ASILs, there’s also a fifth option — QM (quality management). This is used to note that there isn’t a safety requirement for that component. (But it’s typically still a good idea to comply in order to improve product quality.)

How to Determine ASIL

ASIL is determined by three factors — severity, exposure, and controllability.

Severity

Severity measures how serious the damages are of a system failure. Damages include both people and property.

There are four classes of severity:

  • S0: No injuries.
  • S1: Light to moderate injuries.
  • S2: Severe to life-threatening (survival probable) injuries.
  • S3: Life-threatening (survival uncertain) to fatal injuries.

Exposure

Exposure is the likelihood of the conditions under which a particular failure would result in a safety hazard.

The probability of each condition is ranked on five-point scale:

  • E0: Incredibly unlikely.
  • E1: Very low probability (injury could happen only in rare operating conditions).
  • E2: Low probability.
  • E3: Medium probability.
  • E4: High probability (injury could happen under most operating conditions).

Controllability

Controllability is a measure of the probability that harm can be avoided when a hazardous condition occurs. This condition might be due to actions by the driver or by external measures.

The controllability of a hazardous situation is ranked on a four-point scale:

  • C0: Controllable in general.
  • C1: Simply controllable.
  • C2: Normally controllable (most drivers could act to prevent injury).
  • C3: Difficult to control or uncontrollable.

Determining ASILs

Once you’ve determined severity, probability, and controllability, you can determine the ASIL. Table 4 of Part 3 (ISO 26262-3) provides guidance on this.

You can use this chart to calculate ASIL A-D using severity, exposure, and controllability.
Use this chart to determine ASIL based on severity, exposure, and controllability.

 

Guide to ISO 26262 Software Compliance

Compliance with the safety standard is important, whether you’re developing traditional automotive components (e.g., integrated circuits) or virtual ones (e.g., automotive hypervisors). And it’s critical to maintain compliance throughout your software development lifecycle.

But complying can be difficult for development teams. Systems and codebases grow complex. And that makes it difficult to verify and validate software.

You can make it easier by using software development tools. Here's how you can simplify compliance with Perforce >>

Establish Requirements Traceability

Fulfilling compliance requirements — and proving you met them — is a tedious process. You need to document the requirements and trace them to other artifacts — including tests, issues, and source code.

Establishing requirements traceability makes your verification process easier — especially with a tool like Helix ALM. And it helps you manage risk in the development process.

Storing your code in Helix Core — version control from Perforce — securely manages revision history for all your digital assets. You'll get fine-grained access controls, high-visibility audit logs, strong password security, and secure replication. So, you can be confident in your code.

Learn more about leveraging traceability for compliance.

Traceability For safety standards

Apply a Coding Standard

Ensuring that code is safe, secure, and reliable can be difficult. You need to fulfill specific coding and design guidelines.

Applying a coding standard, such as MISRA® or AUTOSAR, makes it easier to verify your code against the safety standard guidelines. Especially when you use a static analyzer like Helix QAC.

Learn more about applying coding standards for compliance with the safety standard.

Coding Standards for ISO 26262