Unlocking the Secrets of ISO 26262 Verification Methods

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:

  • Unit tests of methods (mostly automated)
  • Integration & verification of units
  • Interfaces between units and classes
  • Testing of the embedded software
  • Integration/verification of hardware & software at system level

Which parts of ISO 26262 is it?

The following ISO 26262 parts define the verification requirements and activities and shall be considered:

  • Part 4 → System level verification, integration & testing
  • Part 5 → Hardware design verification, HW integration & verification
  • Part 6 → Software unit verification, SW integration & verification
  • Part 11 → Application to semiconductors & verification to comply with part 5

Deriving test cases

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 testingASIL AASIL BASIL CASIL D
1aAnalysis of requirements++++++++
1bAnalysis of external and internal interfaces+++++++
1cGeneration and analysis of equivalence classes for hardware-software integration++++++
1dAnalysis of boundary values++++++
1eError guessing based on knowledge or experience++++++
1fAnalysis of functional dependencies++++++
1gAnalysis of common limit conditions, sequences, and sources of dependent failures, see ISO 26262-9:2018++++++
1hAnalysis of environmental conditions and operational use cases+++++++
1iAnalysis of field experience+++++++

What is confirmed by analysis?

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:

  • Which requirements at which ASIL?
  • Which elements/components have the highest criticality?
  • How will the relevant elements/components be verified?
  • Were some elements/components already verified at certain level?
  • Which functional elements/components or blocks can be verified by the same verification cases?

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.

Learn more

Equivalence classes

To 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).

Verification by equivalence classes

Equivalence classes can be derived at different level. Here are few examples:

  • System with modules: The modules 1….n are identical at system level, the test and operation of the module can cover verification of modules.
  • Hardware: Same type of components, e.g. DMA Controllers can be verified on HW detailed design level conducting tests at one of the two identical components.
  • Software: Identical Software units, which are equivalent to each other, depend on specified equivalence relation and class.
  • Software: The inputs to the DMA1 & DMA2 are processed in the same way and can be partitioned. A group is formed based on the same test object behaviour.
    • Example: the application you are testing accept values in the character limit of 1 – 100 only.
    • 3 partitions: one valid partition and two invalid partitions
Figure 1. Test case with valid & invalid partitions

There are two basic possibilities for input partitioning – equivalence classes derived from the specification:

  • Interpretation of the specification may be either input orientated – the values selected are treated in the same way – or
  • Output oriented – the set of values lead to the same functional result.

Output values

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.

Black-box testing

One of the testing methods typically used on system is the black-box testing:

Figure 2. 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:

  • Data from permissible ranges
  • Data from inadmissible ranges
  • Data from range limits
  • Extreme values
  • or combination of the above cases.

White-box testing

Another test method is the white-box testing:

Figure 3. 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:

  • Structured paths in the coding process
  • Flow of specific paths through the code
  • Loops, decision conditions
  • Function & modules on an individual basis

On hardware level:

  • Test of the internal logic, architectural blocks if applicable
  • Test of safety mechanisms on block/component level
  • Functions & modules

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.

Other methods for evaluation of test cases

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.



We look forward to hearing from you.

    Show privacy policy