What a single source of truth means in industrial control
The phrase "single source of truth" is overloaded across software domains. In industrial control specifically, it has to mean something stronger than "we have a documentation system." It means that one model holds the design intent and that every other artifact (specification document, generated code, test case, runtime trace) either lives inside that model or is generated from it. The truth is in one place. Everything else is a view.
Two consequences follow from that definition. First, drift is eliminated by construction, not by process. Engineers cannot accidentally edit a downstream artifact in a way that contradicts the model, because the downstream artifacts are not edited at all. Second, change has a single entry point. Updating a requirement, a behavior, or an interface happens in the model; the platform takes care of propagating it to the dependent artifacts.
The fragmented reality of traditional development
In traditional control software development, these artifacts live in separate documents and disconnected tools, with no structural link between them. Requirements sit in a Word file or DOORS. Architecture lives in a Visio diagram. Behavior is described informally, often only in the heads of two or three engineers. Code lives in vendor-specific IDEs (TIA Portal, Studio 5000, TwinCAT). HMI lives in yet another tool. Test cases live in spreadsheets tied to the document version, not the code version. Runtime data lives in historians and SCADA systems with no link back to the design. Each of these artifacts can be correct on its own. Together, they drift out of sync within weeks of the project starting.
The team manages consistency across these documents and tools by hand. It works in a small project, with a stable team, on a short timescale. None of those conditions hold for the systems that actually need to be governed: large infrastructure objects, plants with dozens of changes a year, regulated systems that have to be auditable across decades.
Why fragmentation gets more expensive over time
The cost curve is non-linear. In the first year, the gap between the design documents and the running system is small. Engineers remember what was changed and why. In year three, some of those engineers have moved on. In year ten, the relationship between the documents and the system has degraded to the point that the documents are referenced sceptically. By year twenty (which is the middle of a typical industrial asset's life) the running code is the only artifact that can be trusted, and it is also the only artifact that nobody can read with confidence.
This is the lifecycle pattern that drives so many automation modernization projects: the system has to be replaced not because the hardware is unreliable, but because nobody trusts the software anymore.
The technical requirements for a real single source of truth
"We have a documentation system" is not a single source of truth. The architectural requirements are specific:
- One canonical model that holds requirements, structure, behavior, and test cases in linked form.
- Generation, not synchronization. Code, documentation, and test artifacts are derived from the model, not maintained alongside it. Hand-edits to derived artifacts are architecturally prevented or immediately overwritten on regeneration.
- Bidirectional traceability between requirements, behavior, code, tests, and runtime evidence, with traceability data stored in the model rather than reconstructed from a spreadsheet.
- A runtime feedback loop in which observed behavior (state changes, transitions, alarms) can be projected back onto the model element it came from.
Model-centric platforms are the architectural pattern that satisfies these requirements. Cordis SUITE has been built around this pattern since 2000, and the practical consequence is visible in deployed systems: organizations that adopted the platform in the early 2000s are now in their second or third generation of underlying hardware, with the same model still serving as the maintained artifact. The model has outlived multiple PLC generations, multiple integrator teams, and in some cases the original engineers who built the system. That is what a working single source of truth looks like over time. Code generation stays one-way. Runtime traces link back to the originating state in the model. Drift is prevented by construction, not by process discipline.
What changes over the lifecycle of a system
The value of a single source of truth scales with time. In year one, the difference between a fragmented system and a model-centric one is modest. By year ten, it is decisive. Some benefits show up immediately (debugging in the model rather than in vendor code, traceability without spreadsheets, change impact as a query rather than a guess). Others compound across decades.
Year one to three. New requirements arrive. Engineers update the model. The code, the tests, and the documentation regenerate. The cost of change is the cost of the change itself, with no overhead from chasing down inconsistencies in adjacent artifacts.
Year three to ten. Some of the original engineers leave. New engineers inherit the system. They open the model and read it. They see how the requirements connect to the behavior, how the behavior generates the code, how the code is observed at runtime. They do not have to interview the people who left to understand what the system does.
Year ten to twenty. The hardware reaches end-of-life. The platform regenerates the code for the new target. The model does not change. The system continues. The asset owner has not lost the work of the previous decade. Audits become trivially answerable: regulators can trace any decision (a requirement, a behavior, a test) to its current implementation in code and to its current runtime evidence, because the audit trail is the model itself, not a folder of historical documents.
Year twenty and beyond. The original integrator is gone. The original vendor of the controller may be gone. The original team is gone. The model remains the artifact through which the system is understood, audited, and maintained. The single source of truth is what bridges the generations.
Common false-positives
Several systems get described as a "single source of truth" without meeting the architectural test:
- A requirements management tool is a single source of truth for requirements only. The behavior, code, and tests still live elsewhere.
- A configuration database is a single source of truth for parameters, not for behavior.
- A documentation portal is a single source of truth for the latest version of the documents, not for the relationship between the documents and the running system.
- A version-controlled code repository is a single source of truth for the code as written, not for the design intent that produced it.
- A digital twin is a single source of truth for runtime behavior, not for design intent. If the twin is generated from the same model that produces the deployable code, it can serve as part of the architectural single source of truth. If the twin is built separately (a parallel 3D model with its own behavioral approximation), it is a visualization layer, not a source of truth, and it can drift from the actual system in the same way documentation does.
The pattern across all of these is the same. They each contain part of the truth, and each is correctly maintained for the part it covers. The drift happens in the gaps between them.
Each of these is useful and worth having. None of them, alone or in combination, eliminates drift between design intent and running system. That requires a model-centric architecture in which the design intent and the running system reference the same model.
A single source of truth is not a documentation philosophy and not a tool category. It is an architectural choice with consequences that compound over decades. Either the design intent and the running system reference the same model, or they do not. Everything that gets called "single source of truth" without that property is a synchronization regime, and synchronization regimes drift.