ISO 26262 (SOTIF) Article 10- Verification and validation strategy

Goal:

The goal of verification and validation strategy is to create and justified plan to test and prove system behaves safely even when there is no hardware or software faults, but risk arise from functional limitations or misuse.

a. While defining verification and validation strategy the following are considered:

1. Evaluating potential hazardous scenarios.
2. Ensuring enough coverage of different real-world situations.
3. Necessary evidence (e.g. Analysis results, test reports, dedicated investigations)
4. Procedures to generate evidence.

b. Justify why the chosen methods and targets are suitable to prove the achievement of SOTIF.

Specification of Integration and testing:

Verification and validation strategy covers the Entire system functionality including both E/E functionality and elements of other technologies which are SOTIF relevant. It also includes external resource if it is SOTIF relevant.

Validation targets are specific goals to show that the system is safe and the validation targets are derived from acceptance criteria.

ISO 21448 proposes different methods for deriving the verification and validation activities some of them are given below.

1. Analysis of requirements.
2. Analysis of external and internal interfaces.
3. Generation and analysis of equivalence classes.
4. Analysis of boundary values.
5. Error guessing based on knowledge or experience.
6. Analysis of functional dependencies.
7. Analysis of common limit conditions and sequences. etc…

Some important points to consider:

1. We have Acceptance criteria (These are the rules or conditions we set to decide whether a system is safe enough to be used) to address the risk of known and unknown Scenarios. When we test the system we use validation targets (goals or limits) to test whether the system meets the safety requirements. The validation target will differ for Area 2 and Area 3.
2. To decide how much testing is needed for a potential hazard, we can look at how often it happens, how bad it could be, and whether people can control it. If the situation isn’t too risky, we might be able to reduce the testing effort.
3. Your test strategy should include different versions of risky situations, because real-world conditions can vary a lot.
4. When you make changes to the system’s functions during SOTIF development, you need to check if those changes affect anything else that was already working. If they do, you re-test those existing functions to make sure nothing broke or became unsafe. You don’t always need to test everything again — just the parts that could be affected, as long as you have a good reason for narrowing the scope.
5. Before you release a version of the system for production, you must record all the testing and checking (V&V) you’ve done to make sure everything works correctly. This includes both the parts that haven’t changed and the parts you had to retest because of changes.

If you’re interested in gaining deeper insights into ISO 26262 and ISO 21448, feel free to reach out at jshabarijobs@gmail.com.