The V-Model is the structural backbone of IEC 61508. It defines the sequence in which safety activities happen, the artifacts that each phase produces, and — critically — the relationship between what you design on the left side of the V and what you verify on the right.
The V-Model is not a methodology unique to safety engineering. It has been the standard development lifecycle in safety-critical domains since the 1980s. What IEC 61508 does is define it precisely: nine stages, specific inputs and outputs at each stage, and explicit traceability requirements between corresponding stages on each side of the V.
If you’re working on any system governed by IEC 61508 — robotics, automotive, industrial automation, process control — understanding the V-Model is understanding the framework your safety program operates within.
| V-Model stage | Left side (design) | Right side (verification) |
|---|---|---|
| 1/9 | Concept and scope definition | Safety case |
| 2/8 | Hazard and risk analysis | Overall installation, commissioning, and validation |
| 3/7 | Overall safety requirements | Overall safety validation |
| 4/6 | Safety requirements allocation | Overall safety requirements verification |
| 5 | System design | — (center of the V) |
| Element level | Element design → realization | Element testing |
| Subsystem level | Subsystem design → realization | Subsystem testing |
| System level | System design → realization | System testing |
Why the sequence matters
The V-Model is sequential by design. Each left-side phase produces artifacts that define the scope and criteria for the corresponding right-side verification. You can’t meaningfully verify a safety function without first having specified what that function must do, at what integrity level, under what conditions.
This seems obvious until you consider what most teams actually do: build the system, then write the safety documentation. The end-of-process approach systematically inverts the V. Hazard analysis written after the design is done can’t drive design decisions. Requirements written after the architecture is selected can’t shape the architecture. Testing executed against requirements written to match what was already built isn’t verifying the requirements — it’s confirming the implementation.
Teams that follow the V-Model as designed — safety activities in parallel with development activities, each left-side phase completed before the corresponding right-side verification — produce safety cases where the argument is coherent. Teams that invert it produce safety cases where the argument is reverse-engineered, and assessors find the gaps.
The left side: design phases
Phase 1: Concept and scope definition
Define the system boundary, intended use, and foreseeable misuse scenarios. This phase establishes what the safety lifecycle will cover. Getting the boundary wrong here means getting the hazard analysis wrong, which means getting everything downstream wrong.
For robotics systems, this means: operational modes, environmental range, human interaction scenarios, payload limits, communication interfaces, and all predictable ways the system might be used outside its intended design.
Phase 2: Hazard and Risk Analysis
Systematic identification of hazards, assessment of severity and probability, determination of required risk reduction. This is where Safety Integrity Levels or Performance Levels are derived. The HARA is the foundation — every safety requirement, every safety function, every reliability target traces back to it.
ISO 12100 provides the general methodology. IEC 61508 provides the risk graph for deriving SIL targets. Both are used in robotics and automation programs.
Phase 3: Overall safety requirements
The overall safety requirements specify what the system must do to achieve the required risk reduction derived from the HARA. They include: which safety functions are required, what each function must do, and what integrity level each must achieve. These requirements are technology-neutral — they specify the “what,” not the “how.”
Phase 4: Safety requirements allocation
Safety requirements are allocated to subsystems: the electrical and electronic safety system, the programmable electronic safety system, and other risk reduction measures (physical guards, procedural controls, warning systems). Allocation defines which requirements each subsystem is responsible for meeting.
This phase also establishes the SIL target for each subsystem’s safety functions — the point at which architectural decisions begin to be constrained by integrity requirements.
Phase 5 and below: System design through element realization
The system design phase defines the architecture that will implement the safety requirements: hardware platforms, software architecture, communication interfaces, redundancy and diversity structures, and the interfaces between safety-related and non-safety-related systems.
Below system level, the V narrows into subsystem and element design: detailed hardware design, software design, and ultimately the actual implementation in hardware and firmware. At each level, the design produces artifacts (hardware schematics, software specifications, test cases) that correspond to verification activities on the right side.
The right side: verification phases
The right side of the V verifies, level by level, that what was built on the left side meets the requirements defined at the corresponding level. This structure is what makes V-Model traceability explicit.
Element testing
Individual hardware and software elements are tested against their element-level specifications. Software unit tests. Hardware component verification. The evidence generated here is what supports the traceability chain at the element level.
Subsystem testing
Subsystems are integrated and tested against their subsystem-level requirements. Integration testing. Functional testing of safety functions at the subsystem level. This phase often reveals interface issues that element-level testing can’t catch.
System testing
The integrated system is tested against the system-level safety requirements. This includes functional safety testing: confirming that each safety function performs correctly under fault conditions, meets its specified response time, and achieves its required deceleration or safe state.
System testing also includes testing under fault injection: deliberately introducing component failures to verify that the safety architecture responds correctly.
Safety validation through safety case
The top of the right side is the overall safety validation and the safety case. The safety case is the documented argument that the system is sufficiently safe, backed by the complete body of evidence generated on the right side of the V.
A complete safety case links every verification result back to the requirement it satisfies, every requirement back to the hazard that generated it. The V-Model’s structure makes this traceability natural when the lifecycle is followed. It makes it extremely difficult to reconstruct when it wasn’t.
What the V-Model looks like in practice with ASAP
The V-Model prescribes a rigorous structure. The implementation challenge is maintaining that structure across a team, across months of development, with a design that keeps changing.
ASAP implements the V-Model as a guided workflow. Each phase of the lifecycle has a corresponding structured activity: the HARA with live risk assessment, requirements management with linked traceability, reliability modeling, test case management with evidence linking. As the left side progresses, the right side verification criteria are defined. When the right-side activities run, the links back to the left-side artifacts exist because they were built in as the work proceeded.
The resulting safety case isn’t assembled at the end. It’s generated from the connected artifacts produced throughout the lifecycle. That’s why ASAP can generate a 500-page assessment-ready technical file with one click — the file is a view into a linked data structure, not a document assembled from separate sources.
Amazon’s teams built and refined this methodology over five years protecting more than 1 million robots. The measured result: 26 weeks faster to market, $30M+ saved across programs. That’s the compounding return on building the V-Model into the workflow rather than treating it as a documentation exercise.
FAQ: V-Model Safety Engineering
What is the V-Model in functional safety?
The V-Model is the lifecycle framework defined in IEC 61508 for functional safety engineering. It organizes safety activities into nine stages: from concept and hazard analysis on the left (design) side, through system design and implementation at the bottom, to testing and validation on the right (verification) side. Each right-side verification stage corresponds to a specific left-side design stage, creating explicit traceability between requirements and evidence.
Why is the V-Model called a V?
The shape reflects the flow of work. The left side descends from high-level requirements (hazard analysis, safety requirements) to detailed implementation. The right side ascends from detailed element testing back to system-level validation. At corresponding levels, the design artifacts from the left define the verification criteria for the right. The connection between each left-right pair is the traceability chain that makes the safety case coherent.
What are the phases of the V-Model in IEC 61508?
IEC 61508 defines: concept, overall scope definition, hazard and risk analysis, overall safety requirements, safety requirements allocation, and system design on the left side. On the right side: element testing, subsystem integration testing, system testing, overall installation and commissioning, and overall safety validation. The safety case sits at the top, integrating evidence from all right-side phases into a documented argument.
What is the most common V-Model mistake in functional safety programs?
Inverting the sequence — writing requirements to match the system that was already designed rather than designing the system to meet independently derived requirements. Requirements written after the architecture is selected can’t constrain the architecture. When this happens, the safety case argument runs backward: the evidence was designed to confirm decisions that were already made rather than to verify requirements that were set by the risk analysis. Assessors recognize this pattern.
How does ASAP implement the V-Model?
ASAP implements the V-Model as a guided workflow where each phase has a corresponding structured activity linked to the phases before and after it. The hazard analysis generates the safety requirements. The safety requirements drive the reliability targets. The test cases link back to the requirements they verify. The safety case is generated from the connected artifact set rather than assembled from separate documents. This is how the V-Model is supposed to work — ASAP makes it practical to execute that way at scale.
This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.
ASAP implements the full V-Model lifecycle in a guided, connected workflow. The hazard analysis drives requirements. Requirements drive the safety design. Testing links back to requirements. The safety case is generated from the connected record, not assembled from separate documents. See the platform.