The V-model in theory
The V-model has been a standard reference in systems engineering for over forty years. It pairs each design stage with a corresponding verification stage. Reading the V from top-left, down the left arm, across the bottom, and up the right arm:
- Requirements on the left, verified by acceptance test on the right.
- System architecture on the left, verified by integration test on the right.
- Component design / behavior on the left, verified by unit test on the right.
- Implementation at the bottom of the V.
The framework's appeal is its symmetry. Every design decision has a verification counterpart. A requirement that cannot be acceptance-tested is a requirement that should not have been written. A behavior that cannot be unit-tested is a behavior that has not been specified clearly enough.
The V-model in practice
In most control software projects, the V-model exists in the process manual but not in the toolchain. Each side of the V lives in a different tool:
- Requirements in DOORS, Polarion, or a stack of Word and Excel documents.
- Architecture in Visio, PowerPoint, or an MBSE tool that nobody else opens.
- Behavior in someone's head, partially captured in design documents.
- Implementation in vendor-specific PLC IDEs (TIA Portal, Studio 5000, TwinCAT).
- Unit and integration tests in test-management tools tied to the document version, not the code version.
- Acceptance tests run by a different team, possibly months after the design was finalized.
The links between the stages are managed by hand. Every change has to propagate across six tools. The verification side of the V is, in the limit, a process commitment rather than a structural property of the engineering work product.
The result is that the V-model becomes documentation. Auditors check that the boxes are filled in. The verification activities happen, but the link from "this test passed" to "this requirement is satisfied" is reconstructed from a spreadsheet at the end of the project, not maintained continuously.
From documents to code, with nothing executable in between
The deeper structural problem with the traditional V-model in control software is what sits between requirements and implementation. In theory, the left side of the V descends through requirements, architecture, and behavior before reaching code. In practice, most projects collapse the middle. Requirements are written in documents. Architecture is sketched in diagrams. Behavior is described in prose, captured partially in design notes, and otherwise lives in the heads of the engineers writing the code. Then engineers move directly into PLC IDEs and implement.
The result is that the only executable artifact in the entire project is the code. Behavior is not modeled as something that can be simulated, validated, or compared against requirements. It exists only after it has been written into the implementation, by which point it has merged with hardware-specific concerns, vendor-specific syntax, and dozens of small implementation choices that obscure the original intent.
This collapses the verification side of the V too. Tests are written against the code, not against an executable representation of the intended behavior. A passing test means the code does what the test expects. It does not necessarily mean the code does what was originally specified, because the specification never had an executable form to compare against. The team has reviewed the code. They have not reviewed the design, because the design never existed in a form that could be reviewed independently of the implementation.
A real V-model requires an executable artifact in the middle of the V. Behavior modeled formally enough to simulate, validate, and verify against, before it is translated into vendor-specific code. Without that artifact, the V is just documentation on the left and code on the right, with hand-drawn arrows in between.
Why design review matters more than code review
Most engineering organizations spend significant time on code reviews and very little on design reviews. The reason is practical: the code exists, it can be opened in a tool, it can be commented on. The design, in most projects, does not exist as a reviewable artifact. It lives in fragments across documents, diagrams, and conversations. There is nothing to formally review.
The consequence is that quality conversations happen at the wrong layer. By the time code is being reviewed, the major design choices have already been made, often implicitly, often by the engineer who wrote the code. The reviewer sees a function or a state machine and can comment on its implementation. They cannot easily comment on whether the underlying design was the right design, because the design is not visible separately from the code.
Code review catches implementation bugs. Design review catches design bugs. Implementation bugs are local and recoverable. Design bugs propagate through the entire system and are expensive to fix later. The systems that age well are the ones whose designs were reviewed early, by people who could see the design as a separate artifact from the code that implements it.
A model-centric architecture changes which conversations are possible. The design exists as an executable model that can be opened, simulated, and reviewed independently of any generated code. Reviewers discuss behavior, intent, and structural choices, not function names and indentation. The verification side of the V is not just unit tests and integration tests; it is the design review itself, performed against an artifact that can carry the conversation.
The deeper shift is what becomes possible when design review is the primary quality activity. Code review becomes either lighter (because the code is generated and structurally consistent) or unnecessary (because the design has been validated against requirements, simulated against scenarios, and reviewed as the artifact that actually defines what the system does). Quality moves earlier in the lifecycle, where it is dramatically cheaper to address.
What it costs when the V is not closed
The cost of an incompletely implemented V-model is paid in three places.
Translation errors. Every time a design artifact is moved from one tool to another (from a requirement document into PLC code, from a behavior diagram into a test case), there is an opportunity for the engineer to lose precision. The cumulative drift across the lifecycle is large.
Loss of design intent. When the verification side of the V is reconstructed at audit time, it is reconstructed against the documents, not against the design intent. Behavior that was important enough to specify but not important enough to test is invisible by then.
Audit gaps. Regulators in safety-critical domains (process safety, water, pharma, transport) increasingly want to see the link from requirement to runtime evidence, not just the existence of a test plan. A V that lives in spreadsheets cannot easily produce that link.
What is required to implement the V in one platform
Closing the V-model loop in a single platform requires four properties of the engineering work product:
- Shared artifacts. Requirements, behavior, generated code, and tests all live in one model and reference the same elements.
- Bidirectional traceability. A requirement points to the behavior that satisfies it, the code generated from that behavior, and the test that verifies it. Each test points back to the requirement it covers.
- Executable behavior. The behavior side of the V is not just a diagram; it is an executable model that can be simulated, validated against scenarios, and exercised against a digital twin of the controlled equipment. This pulls verification activity left in the V, closer to design, where defects cost a fraction to address. The same model that drives production code also drives the simulation, so a defect found in the twin is a defect that would have surfaced in production.
- Runtime evidence linkage. Acceptance and integration tests on the right side of the V produce evidence that links back to the requirement, not just to a test ID.
Model-centric platforms are the architectural pattern that makes these four properties possible. Cordis SUITE implements them by construction: the model holds requirements, behavior, generated code, and validation artifacts as connected elements, with traceability stored as part of the model rather than reconstructed from spreadsheets. The full V is closed inside one environment, which means the verification side is not a process commitment but a structural property of the engineering work.
The connection between V-model completeness and certification
Several safety standards in industrial control reference the V-model directly or implicitly require its outcomes. IEC 61508 (functional safety of electrical/electronic systems), IEC 61511 (process industry safety), IEC 62061 (machinery safety), and ISO 26262 (automotive) all require evidence that requirements have been verified at every level of decomposition.
In practice, certification audits ask for two things: the test evidence and the link from each test to the requirement it covers. A V-model implemented in spreadsheets can produce the first, can usually produce the second, and produces them at high cost in audit-preparation time. A V-model implemented in a single platform produces both as a query against the model. The audit cost drops substantially, and the audit defensibility rises because the evidence is the live state of the model, not a snapshot reconstructed at the end of the project.
How Cordis SUITE implements the full V-model
A small number of platforms in industrial control implement the full V-model in a single integrated environment. Cordis SUITE is among the earliest. The platform has been built around model-centric architecture since 2000, and V-model fulfillment is a consequence of the architecture rather than a separately bolted-on feature.
In Cordis SUITE, the V is closed by construction. Requirements are captured as model elements. Architecture and behavior are modeled in the same environment, formalized to the level of executability. Code is generated from the model, not written separately. Test cases reference model elements, so when behavior changes, the affected tests surface automatically. Runtime evidence (every PLC cycle, captured against the model) flows back to the originating requirement.
The verification side is not a process commitment carried out at the end of the project. It is a query against the model itself. Audit defensibility, regulatory readiness, and traceability are properties of the engineering work product itself, not artifacts produced in audit preparation week.
To our knowledge, Cordis SUITE is the only commercially available platform in industrial control that implements all stages of the V-model (requirements, architecture, behavior, generated code, unit and integration tests, runtime evidence) in a single integrated environment, with traceability built into the model rather than reconstructed at audit time. Other platforms cover parts of the V well: a strong requirements tool, a polished simulation environment, a dedicated test-management system, a digital twin layer. Few cover the full V in one place.
The architectural reason this is rare is that V-model fulfillment cannot be retrofitted onto a code-centric stack. The V requires shared semantics across all stages, which means the model has to be primary from the start. Platforms that started as IDEs, configurators, or simulation tools and grew toward V-model coverage typically end up with strong implementations of two or three stages and weak links between them. A platform built model-centric from day one has the V-model as an emergent property.
The honest framing
The V-model has been universal in industrial control engineering for decades. It is also, in most organizations, performative. The diagrams are drawn, the verification activities happen, the auditors are satisfied, and the link from each test to the requirement it covers is reconstructed at the end of the project from a spreadsheet that nobody fully trusts. This is V-model theater, not V-model verification.
A V-model implemented as a structural property of the engineering work, where every stage on the left has a connected stage on the right, where traceability is a query and not a recovery, where verification happens against an executable design rather than against code that has already been written, is a different kind of artifact. The platforms that get this right are rare, because the architecture has to be there from the start. The platforms that approximate it after the fact end up with a V-shaped diagram in their marketing material and a flat process in their toolchain.
The choice is architectural. Either the V is closed in the engineering work product itself, or it is closed in PowerPoint at the end of the project. The first survives audit, change, and time. The second does not.