What Is ISO 26262? Overview and ASIL
ISO 26262, titled “Road vehicles — functional safety”, is a functional safety standard used in the automotive industry, and ASIL is a key component to determine safety requirements for software development.
Complying with this standard is critical for . OEMs, their suppliers, and developers of automotive components all need to comply.
Here, we give an overview of ISO 26262, ASIL (Automotive Safety Integrity Level), and ISO 26262 functional safety compliance tips for software development teams.
Read along or jump ahead to the section that interests you the most:
- What Is the ISO 26262 Functional Safety Standard?
- The 10 Part of ISO 26262
- ISO 26262 Functional Safety For Software Developers
- ISO 26262 Tool Qualification
- What Is ASIL? And, Why Is It Important?
- How to Determine ASIL?
- Guide to ISO 26262 Functional Safety Software Compliance
- ➡️ Start Your Free Helix QAC Trial
What Is the ISO 26262 Functional Safety Standard?
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 functional safety standard covers all of the functional safety aspects of the entire development process:
Why Is ISO 26262 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.)
The 10 Parts of ISO 26262
- 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 the safety of the intended function — SOTIF. However, SOTIF has since been published as its own standard — ISO/PAS 21448.
ISO 26262 Functional Safety 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.
📕 Related Resource: How to Comply with the ISO 26262 Standard >>>
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 — comes with certificates of compliance that make the qualification process easier.
What Is ASIL? And, Why Is ASIL Important?
Automotive Safety Integrity Level (ASIL) is a key component of ISO 26262 and it is used to measure the 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 Automotive Safety Integrity Level values, named A–D. ASIL A is the minimum level of risk and ASIL D is the maximum, as you go from A to D, the compliance requirements get stricter.
When determining Automotive Safety Integrity Levels, 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 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 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 a 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 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.
Once you’ve determined severity, probability, and controllability, you can determine the Automotive Safety Integrity Level. Table 4 of Part 3 provides guidance on this.
Guide to ISO 26262 Functional Safety 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 embedded software development lifecycle. ). And it’s critical to maintain compliance throughout your
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.
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.
And, if you're developing semiconductors for automotive, using a tool like Methodics IPLM will help you establish verification traceability for your designs. Plus, Methodics IPLM can help you manage your ISO 26262 functional safety certification.
Storing your code in — 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.
📕 Related Resource: Traceability For Safety Standards >>>
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 Helix QAC.® or , makes it easier to verify your code against the safety standard guidelines. Especially when you use a static analyzer like
Learn more about applying coding standards for compliance with the safety standard.
📕 Related Resource: How to Comply with ISO 26262 >>>
Ensure ISO 26262 Functional Safety with Perforce
Ensuring that your code is functionally safe can be difficult without the right tools. By using Helix QAC, you are able to easily apply a coding standard to verify that your code meets the specific safety standard guidelines.
See how simple it is to use Helix QAC to ensure the functional safety of your code.