Skip to main content
SAIF Autonomy to use RVS to verify their groundbreaking AI platform
RVS 3.22 Launched
Hybrid electric pioneers, Ascendance, join Rapita Systems Trailblazer Partnership Program
Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification
How to certify multicore processors - what is everyone asking?
Data Coupling Basics in DO-178C
Control Coupling Basics in DO-178C
Components in Data Coupling and Control Coupling
DO-278A Guidance: Introduction to RTCA DO-278 approval
ISO 26262
Data Coupling & Control Coupling
Verifying additional code for DO-178C
XPONENTIAL 2025
Avionics and Testing Innovations 2025
DASC 2025
DO-178C Multicore In-person Training (Fort Worth, TX)
Introduction to ISO 26262
ISO 26262 is a standard for implementing functional safety measures for electric systems in an automotive vehicle. The first version of ISO 26262 was released in 2011. This version only covered functional safety for passenger cars. A later edition of the standard, released in 2018, extended the scope to include all road vehicles except for mopeds.
ISO 26262 describes the automotive lifecycle (Figure 1) and activities that must be carried out in each stage of it to meet functional safety requirements. One of the distinguishing features of ISO 26262 is that appropriate safety measures are implemented based on the level of risk should software fail.
Automotive Safety Integrity Level
The Automotive Safety Integrity Level (ASIL) is a classification system used in ISO 26262. Each component of an automotive system is assigned an ASIL based on the level of risk should the component fail, and this determines the verification activities required to demonstrate functional safety for the component. A risk can be assigned one of five ASIL ratings:
- A (lowest integrity) to D (highest integrity), which define the level of risk in the event of failure. Failure at ASIL D could be potential for loss of life and require stricter compliance requirements compared to ASIL A.
- QM (Quality Management), which assumes that the risk will be mitigated sufficiently by Quality Assurance activities.
The ASIL rating is calculated based on the following factors (see Table 1):
- Severity of injuries afflicted to the passengers
- Probability of exposure
- Controllability of the hazard (probability that the passenger will avoid the harm)
| SeverityClass | ProbabilityClass | ControllabilityClass | ||
|---|---|---|---|---|
| C1 (Simple) | C2 (Normal) | C3 (Difficult) | ||
| S1 (Light injuries) | E1 (Very Low) | QM | QM | QM |
| E2 (Low) | QM | QM | QM | |
| E3 (Medium) | QM | QM | A | |
| E4 (High) | QM | A | B | |
| S2 (Severe injuries) | E1 (Very Low) | QM | QM | QM |
| E2 (Low) | QM | QM | A | |
| E3 (Medium) | QM | A | B | |
| E4 (High) | A | B | C | |
| S3 (Fatal injuries) | E1 (Very Low) | QM | QM | A |
| E2 (Low) | QM | A | B | |
| E3 (Medium) | A | B | C | |
| E4 (High) | B | C | D | |
■ Quality Management ■ ASIL A ■ ASIL B ■ ASIL C ■ ASIL D
Software Verification for ISO 26262 projects
ISO 26262 requires you to plan all software development activities, including the software verification activities you will use to demonstrate functional safety. The standard states the following:
- Hardware and software development will need to verify the interference specification, and
- Demonstrate that the software safety requirements are compliant with the technical safety requirements, system design and hardware safety requirements.
The above can be achieved by implementing appropriate verification as dictated by the ASIL of your project. Verification tools can improve the efficiency of verification activities by automating key parts in the process.
Functional Testing
ISO 26262 requires that functional testing is carried out to demonstrate software robustness and functionality, and that sufficient hardware resources are available for the system’s operation, based on specifications for the software’s functionality (REQ 9.4.2). Different types of testing are expected based on the software’s ASIL (Table 2).
| Methods | ASIL | |||
|---|---|---|---|---|
| A | B | C | D | |
| Requirements-based test | ++ | ++ | ++ | ++ |
| Interference test | ++ | ++ | ++ | ++ |
| Fault injection test | + | + | + | ++ |
| Resource usage test | + | + | + | ++ |
| Back-to-back test between model and code, if applicable | + | + | ++ | ++ |
Software tools such as RapiTest enable you to effectively test critical automotive software for functional behavior including on-target testing (i.e. testing on the final hardware or vehicle), which is an important part of the validation process, and Worst-Case Execution Time (WCET) analysis which is fully automated within the test environment.
'Back-to-back' model-based testing is also supported and is the optimal testing method for model-based developers. Using this method, it is only necessary to write your tests once, and then the same tests can be used all the way from initial model-based analysis to the final target hardware environment.
Requirements-based functional testing tools can streamline the unit testing process by automating test harness generation, execution, and results collection, thereby improving verification efficiency and reducing time to market.
Structural Coverage
ISO 26262 requires the completeness of testing to be demonstrated by measuring the structural code coverage achieved during functional testing (REQ 9.4.4). The coverage metrics that must be analyzed depend on the software ASIL (Table 3). This can include statement, branch and modified condition/decision coverage (MC/DC) data.
| Methods | ASIL | |||
|---|---|---|---|---|
| A | B | C | D | |
| Requirements-based test | ++ | ++ | ++ | ++ |
| Interference test | ++ | ++ | ++ | ++ |
| Fault injection test | + | + | + | ++ |
| Resource usage test | + | + | + | ++ |
| Back-to-back test between model and code, if applicable | + | + | ++ | ++ |
Code coverage analysis can be supported by using software tools, which can automate the collection of coverage data during testing. Tools such as RapiCover enable you to collect coverage measurements from software tests run on host computers, simulators, and embedded targets. Some tools may have specific features to improve verification efficiency such as integrations with continuous build software and the ability to merge results collected from different tests.
Freedom from interference
ISO 26262 requires appropriate steps to be taken to ensure freedom from interference (FFI) being implemented on the system (REQ 7.4.11). ISO 26262 defines FFI as “absence of cascading failures between two or more elements (both hardware and software components) that could lead to the violation of a safety requirement”.
RTOS scheduling visualization tools (such as RapiTask) can assist with the collection of task-level scheduling behavior during software tests. The metrics it collects, including response time and periodicity, can be used to determine if the software has appropriate scheduling properties.
