Lesson 16 of 16 · The V, process by process · Automotive SPICE, the vital 20 %
Validation: VAL.1
Every process on the right of the V asks whether the product matches its specification. VAL.1 asks a different question: does the end product do what its users actually need, where they actually use it?
A test checks that two software components exchange data within their specified timing. Which process?
The complete ECU is checked against its temperature-regulation requirement in a climate chamber. Which process?
Verification and validation are different questions
VAL.1's purpose is to provide evidence that "the end product, allowing direct end user interaction, satisfies the intended use expectations in its operational target environment"[PAM §4.5.1, p. 58]. Verification shows the product meets what was specified; validation shows it meets its users' intended use.
The Guidelines' own example is an automatic transmission. Meeting the specified gear-shift times is verification, "given that these can be measured objectively". A good gear-shift feel is validation, "as it requires feedback from end users or their representatives"[Guidelines §3.14.1, p. 163]. Without legal requirements behind them, validation targets may be "exploratory, or even subjective".
Validation does not always mean asking users. In the Guidelines' second example, an automatic side door, the angle at which the powered door movement is triggered "can be objectively measured", so it is verification. How much closing force would harm a user has no legal limit to check against, so it is validation, "such as by means of accident simulations"[p. 163]. The question makes it validation, not the technique: a simulation checked against a specification is still verification.
The dividing line is not whether a requirement exists. The Guidelines warn that being able to write a requirement "does not serve as a distinction criterion": a limit on shift noise can be written down, and judging whether that limit is adequate for users is still validation[p. 164]. Ask instead: can it be settled by objective measurement, or does it take a judgement of what users need?
So validation measures look different from verification measures. The PAM's examples: operational use-case testing under real-life conditions, highly accelerated life testing, simulations under real-life conditions, end-user trials, panel or blind tests, and expert panels[PAM terminology, p. 10].
Who validates
Because VAL.1 is about end users, the Guidelines say it "excludes looking at pure embedded software products, an ECU, or a drive": none of them "provides a direct end user interface"[Guidelines §3.14.1, p. 163].
For Seat-Heat this settles it. Its software, and even the whole seat-heating ECU from lesson 14, has no direct end-user interface. Whether heat setting 2 feels warm enough on a winter morning is a question about the seat in the car, and it belongs to whoever delivers that product. The sources don't say whether that is the seat maker or the vehicle maker. What Seat-Heat delivers is evidenced by verification: SWE.4–SWE.6, and SYS.4–SYS.5 for the ECU.
VAL.1 is a flex process: outside the base and the plug-ins of the recommended VDA Scope, added when the assessment purpose needs it[Guidelines Fig. 1-1, p. 29]. In practice, reading this with the exclusion above, that means an organisation delivering an end product that people use directly (the course's inference).
What VAL.1 asks for
Its five base practices follow lesson 14's pattern, with validation measures in place of verification measures[PAM pp. 58–59]:
- Specify validation measures for the end product, based on the stakeholder requirements, to show it fulfils its intended use in its operational target environment.
- Select them, with criteria including regression, and sufficient coverage for the release scope. Criteria include the release's purpose: test bench, test track, public road, field use by end users.
- Perform the validation of the integrated end product, record the results with pass/fail status, and evaluate them. Deviations go to SUP.9.
- Trace validation measures to the stakeholder requirements they derive from, "if applicable", and results to measures.
- Summarise and communicate the results.
- One-way tracing can be enough. When a validation measure comes from a legal or homologation requirement, bidirectional traceability to that source is not possible, and "unidirectional traceability is sufficient"[VAL.1.BP4 note 8, p. 59].
- Validation feeds requirements back. Results can identify new stakeholder or system requirements, for example from mock-ups or concept studies (BP3 note 5). Where needs are unclear or change often, repeated validation of increments helps refine them (BP1 note 2).
- Its rating rules mirror the verification ones, minus the rule on automated scripts[Guidelines §3.14.2–3.14.3, pp. 164–165].
The whole V, in one table
| Left: what is specified | Right: what checks it |
|---|---|
| Stakeholder requirements (SYS.1) | VAL.1 validation, where the product has end users |
| System requirements (SYS.2) | SYS.5 system verification |
| System architecture (SYS.3) | SYS.4 system integration verification |
| Software requirements (SWE.1) | SWE.6 software verification |
| Software architecture (SWE.2) | SWE.5 component and integration verification |
| Detailed design and units (SWE.3) | SWE.4 unit verification |
The pairs are the course's summary of the processes' purposes. Like the V itself, this is a map of what must be consistent with what, not a sequence of phases: the PAM prescribes no order (lesson 1).
Practice
A. Verification or validation?
The seat reaches 35 °C within 4 minutes at −20 °C, measured in a climate chamber.
A panel of drivers rates whether the heat-up feels fast enough on a cold morning.
A test confirms that heating switches off after 60 minutes, as the requirement specifies.
Test drivers use the heated seats through a winter and report how the heat levels feel on long trips.
B. Scope and traceability
Should Seat-Heat's assessment of its ECU include VAL.1?
A validation measure is derived from a homologation requirement. Is a one-way trace to that requirement enough?
Trials show occupants want heat setting 1 to be warmer. Where does that finding go next?
C. From memory
In one sentence each: what does verification check, and what does validation check?
Verification is what objective measurement can settle, such as a work product checked against its specification. Validation takes a judgement of what users need, made by end users or their representatives or approximated, for instance by accident simulations, and shows that the end product meets their intended-use expectations in its real operating environment. Whether a requirement is written down does not decide which one it is.
Why does an ECU supplier usually not perform VAL.1?
VAL.1 is about intended use by end users, and the Guidelines exclude pure embedded software, ECUs and drives because none has a direct end-user interface. The supplier's evidence is verification; validation belongs to whoever delivers the end product.
Your win: you can walk the whole V, say what each process asks for and what checks it, and tell verification from validation. If you came here after lesson 4, continue with lesson 5.
To keep it: import this lesson's Anki deck (how).
Read next
VAL.1 in the PAM, pp. 58–60, and its chapter in the Guidelines §3.14, pp. 163–165, with the side-door example.
Not sure whether your product has end users in VAL.1's sense? Ask your teacher in the chat.