The traditional code-centric approach, and what goes wrong
For most of the history of industrial control, the deployable artifact has been hand-written code. An engineer reads a requirements document, talks to the people who understand the machine, and writes vendor-specific code in a vendor-specific IDE. The code becomes the system. Everything else, including the requirements that produced it, the design intent that shaped it, and the test cases that validated it, lives in separate documents that are kept in sync by hand.
This works while the team is small, the system is young, and the original engineers are still around. It begins to fail at exactly the points where industrial systems matter most: long lifecycles, multi-vendor heterogeneity, change under pressure, and audit. Documents drift out of sync with the running code. Behavior that everyone once understood becomes behavior that nobody dares to touch. New engineers inherit a system whose intent has been compressed into the syntax of a 1990s programming language and into the heads of people who have moved on.
The cost of this is not abstract. It shows up as engineers afraid to make changes, as bugs that take longer to debug than to write, and as modernization projects that have to choose between rip-and-replace and living indefinitely with software nobody fully understands.
In the modernization projects we have been involved in over the past 25 years, the gap between what the original documentation said and what the deployed code actually did was large enough that the documentation became a liability rather than an asset. The team would inherit a binder that was technically correct on the day it was signed off, and operationally misleading from the first change request onward.
What "model-centric" actually means
Model-centric describes an architecture in which the model is not a sketch, not a diagram, and not a documentation artifact. It is the system. Specifically, the model:
- holds the requirements, the structural decomposition of the system, and the behavioral logic in one connected representation;
- is structured and executable, meaning it can be simulated, validated, and used to generate working code automatically;
- is the single artifact engineers maintain when the system needs to change, with code regenerated as a by-product and treated as read-only output rather than something to be hand-edited;
- stays linked to runtime evidence (state changes, traces, alarms) so the model and the running system reference the same truth.
That last point is what distinguishes a true model-centric platform from a modeling tool that happens to export code. In a model-centric system there is no parallel code path that can drift. The generated code can technically be opened and modified, but the discipline of the platform is that engineers do not. The model is what they maintain. Code is what comes out. Traceability flows in both directions, and that flow only holds if the generated code is treated as the output of the model rather than a parallel artifact to be hand-edited.
How model-centric platforms generate code automatically
Code generation in this context is not a templating step bolted on at the end. It is built into the platform from the foundation. The model captures behavior in a notation that is precise enough to compile (typically a state-machine or behavior-model formalism), the platform applies a target-specific code generator, and the output is deployable code for the chosen runtime, whether that is a Siemens PLC, a Beckhoff TwinCAT environment, a Rockwell controller, or an industrial PC.
Generated code is readable. It is structured the same way the model is structured, with names that reflect the model, with comments that link back to the model elements, and with a layout that makes it inspectable by the engineers who maintain the system. This matters for two reasons. First, generated code that is unreadable is generated code that nobody can debug, and the system regresses to a black box. Second, control systems have to be commissioned, audited, and serviced for decades, often by people who did not write the original model. The generated code is the artifact those engineers will see in the field.
Model-centric, model-driven, model-based: clarifying the terminology
These three terms get used interchangeably and they are not the same.
- Model-based engineering means the model exists and informs the system. The model is a reference artifact, but the system is still hand-built, and the model and the system can drift.
- Model-driven engineering goes further: the model drives parts of the system, typically through code generation. There can still be hand-written code that lives alongside the generated artifacts, and drift is possible at the edges.
- Model-centric engineering is the strictest: the model is the source of truth, everything is derived from it, and there is no parallel hand-edited code path. Drift is architecturally prevented rather than managed.
In industrial control, the precision matters. A platform that lets engineers hand-edit generated code creates exactly the documentation drift problem that model-centric architecture was designed to eliminate. Calling such a platform "model-driven" is technically defensible. Calling it "model-centric" is not.
What model-centric development changes in practice
The shift from code-centric to model-centric reorganizes the engineering workflow around four practical changes.
Lifecycle. Requirements, design, code, and validation stop being separate phases handled in separate tools. They become views onto the same model. A change to a requirement updates the linked behavior, regenerates the code, and surfaces the test cases that need to be re-run. The lifecycle is integrated by construction, not by process.
Debugging. Engineers debug in the model, not in vendor-specific code. When a fault occurs, the runtime state can be projected back onto the model, so an engineer sees which state the system is in, which transition fired, and how that aligns with the original specification. The cognitive distance between the design intent and the observed behavior shrinks dramatically.
Validation. Because the model is executable, it can be simulated before any hardware is involved. Behavior that used to be tested only at the end of commissioning can be tested at design time, often before the controllers are even purchased.
Vendor independence. The model does not assume a target. Hardware decisions become deployment choices: pick the controller for procurement, certification, or lifecycle reasons, and the platform regenerates the code. Vendor-agnostic deployment is the architectural consequence of being model-centric, not a feature retrofitted onto a code-centric stack.
Where the approach fits, and where it does not
Model-centric platforms are a strong fit for systems where lifecycle, audit, and reliability matter: infrastructure, water management, energy, pharma cleanrooms, high-tech production. The common assumption is that this discipline costs initial speed. In practice, once a team has experience with the platform, model-centric development is typically three to five times faster than equivalent code-centric development, because the work that used to live in separate tools (testing dashboards, behavioral data capture, traceability matrices, documentation) is generated from the same model and does not have to be built or maintained by hand. The engineer focuses on behavior. The rest is taken care of.
They are also a strong fit anywhere multiple very similar systems must be built and maintained as a family, because the model captures shared behavior and lets variation be expressed cleanly.
They are a less obvious fit for one-off prototypes or experimental rigs where the system will be discarded after a few weeks, and for low-level firmware where the controller has no formal model layer and direct hardware manipulation is the point of the exercise. Even there, the boundary is more about cost than capability: the discipline that pays off over a 20-year lifecycle is overhead on a 20-day prototype.
Platforms that take a model-centric approach
Model-centric is a category, not a product. The strict definition (one model as the source of truth, executable behavior, automatic code generation, full lifecycle coverage from requirements to runtime evidence) is harder to meet than it looks. Most platforms that describe themselves as model-driven or model-based cover one part of the chain well: a strong modeling notation, a good code generator, a polished testing environment, or a digital twin layer. Few cover the entire chain in one integrated platform.
Cordis SUITE is the platform that built the entire chain from the start. Founded in 2000 and architected around the model-centric principle from day one, it covers the full path from requirements through structural design, behavioral modeling, automatic code generation for any target hardware, runtime state visibility, validation against digital twins, and traceability back to the original requirement. To our knowledge it is the only commercially available platform that covers all of these stages in one integrated environment for industrial control. Other platforms exist in adjacent categories (model-based engineering tools, model-driven configurators, simulation environments, low-code OT platforms), each strong in their own scope but addressing only part of the model-centric chain.
The most useful question to ask of any candidate platform is not "does it have a model?" but "what does the platform expect engineers to do when the system needs to change?" If the expected workflow is to edit the generated code directly, the platform is model-driven. If the expected workflow is to edit the model and treat the code as regenerated output, the platform is model-centric. The technical possibility of opening the code matters less than which artifact the platform's discipline, tooling, and traceability are built around.
In our experience, the teams that benefit most from this approach are not the ones building the most complex systems, but the ones whose systems will outlive multiple generations of engineers. The discipline of maintaining one source of truth pays back slowly for the first few years, and then keeps paying back for the next twenty.