Unlocking the Secrets of ISO 26262 Verification Methods
![](https://lorit-consultancy.com/wp-content/uploads/2024/05/Verification_1_adobe-scaled.jpg)
In today’s blog we discuss the verification methods defined in the ISO 26262 standard. More specifically, we delve into the process of defining verification methods within a project and how to derive specific test cases.
The verification methods according to ISO 26262 are specific techniques and processes used to ensure that the safety-related functions of a vehicle meet the necessary safety requirements.
Let’s first take a look at the part 6 of ISO 26262 – Product development at the software level. Integrated on the right side of the V-model, the verification process includes the following activities among others:
The following ISO 26262 parts define the verification requirements and activities and shall be considered:
The integration and verification process starts with the deriving of test cases, where different combination of methods to derive test cases for integration testing, considering the integration level, are defined.
Table 3. Methods for deriving test cases for integration testing | ASIL A | ASIL B | ASIL C | ASIL D | |
---|---|---|---|---|---|
1a | Analysis of requirements | ++ | ++ | ++ | ++ |
1b | Analysis of external and internal interfaces | + | ++ | ++ | ++ |
1c | Generation and analysis of equivalence classes for hardware-software integration | + | + | ++ | ++ |
1d | Analysis of boundary values | + | + | ++ | ++ |
1e | Error guessing based on knowledge or experience | + | + | ++ | ++ |
1f | Analysis of functional dependencies | + | + | ++ | ++ |
1g | Analysis of common limit conditions, sequences, and sources of dependent failures, see ISO 26262-9:2018 | + | + | ++ | ++ |
1h | Analysis of environmental conditions and operational use cases | + | ++ | ++ | ++ |
1i | Analysis of field experience | + | ++ | ++ | ++ |
Analysis of requirements is the crucial method to derive and specify the verification & test cases. In order to perform the analysis of requirements, following topics/questions shall be addressed to guide you through the evaluation:
Dijaz Maric, Quality Management & Reliability Engineering Consultant
Do you want to learn more about the implementation of ISO 26262, IATF 16949, or other standard in the Automotive sector? We provide remote support and training to enhance your functional safety related projects. Please contact us at info@lorit-consultancy.com for bespoke consultancy or join one of our upcoming online courses.
Erfahre mehrTo reduce the test effort, the test input data/values are obtained by selecting equivalence classes required to execute the function. These test-methods are then based on the equivalence relation of the inputs. Test cases are selected covering the classes previously specified, at least one test case from each equivalence class.
Equivalence classes can be derived from the specification and analysis of requirements or derived from the architecture (equal blocks or functions) or internal structure of the software (set of values executes the same path).
Equivalence classes can be derived at different level. Here are few examples:
There are two basic possibilities for input partitioning – equivalence classes derived from the specification:
Equivalence Class Partitioning can also be used to test output values. For example, if a software application is supposed to return a specific set of outputs for certain input values, the expected output values can be partitioned into equivalent classes and only one value from each class can be tested.
One of the testing methods typically used on system is the black-box testing:
→ Black Box testing doesn’t consider the internal structure, design is to be tested.
→ The internal functioning is not crucial as input for testing.
→ It only evaluates the external behaviour of the system.
→ The inputs implied at the system and the outputs or responses are tested.
The input data range is subdivided into specific input value ranges considering the specification and by analysing the requirements. Test cases are then formed from the:
Another test method is the white-box testing:
→ Test of the internal structures, used data structures, internal design, code structure, and the working of the software.
→ Code coverage analysis helps to analyse the code coverage of an application.
→ White-box testing method is used in SW Unit testing phase but can also occur in SW integration testing to verify the SW design is implemented in accordance with the requirements.
Related to the software, it verifies:
On hardware level:
The advantage of the white-box testing method is that hidden errors, e.g in the code, can be successfully identified. On the downside this method often proves to be highly complex and time-consuming.
I’d like to wrap up with an introduction of the second part of this blog series. In the next instalment of the “Verification in ISO 26262” blog we’ll discuss other methods used for deriving test cases, such as boundary value analysis and error guessing. Additionally, we will examine various examples of their application, while also taking closer look at some examples of generation of equivalence classes in different applications. Stay tuned!
By Dijaz Maric, Quality Management & Reliability Engineering Consultant
If you are looking for functional safety support either through consultancy or training courses, please feel free to contact us via contact form or at info@lorit-consultancy.com.