The original meaning of low-code
Low-code emerged in the application world. It described platforms that let people build internal tools, business applications, and customer-facing software with visual editors, declarative configuration, and pre-built integrations, instead of writing every line of code by hand. The motivating goal was speed and accessibility: more software, built by more people, faster. Forrester coined the analyst term in 2014, and by the early 2020s low-code had become a standard category in enterprise IT, with platforms like Mendix, OutSystems, and Microsoft Power Apps leading the market. The audience that benefits most is not full-time PLC programmers but the engineers, architects, and domain experts who understand the system itself, and who in a code-centric world had to delegate that understanding to a programmer who did not.
That definition does not transfer cleanly to industrial automation. The applications low-code targets in IT are short-lived (rebuilt every few years), forgiving of latency, deployed onto homogeneous cloud infrastructure, and almost never safety-critical. The control software that runs a chemical plant, a tunnel ventilation system, or a high-tech production line is none of those things.
Why industrial automation is a different problem
The underlying technology may share concepts (visual logic, declarative configuration, code generation) but the operational context changes the problem.
- Determinism. Control software runs on PLCs and industrial controllers with hard real-time constraints. A scan cycle that exceeds its budget can compromise the system. Whatever the engineer designs has to translate into deterministic, predictable execution.
- Hardware integration. The system has to read sensors, drive actuators, and sit on industrial fieldbuses. The visual layer cannot abstract away the hardware; it has to compile down to it.
- Lifecycle. Industrial systems run for 15 to 30 years. The software must remain maintainable, auditable, and modifiable across that span, by people who did not write the original.
- Safety and regulation. Many control systems operate in regulated environments (water, pharma, process safety). Visual configuration that cannot be audited is not deployable in those domains.
These differences do not invalidate low-code in OT. They redefine what "low-code" has to be in order to be credible.
What low-code looks like in OT
In industrial automation, low-code typically takes one of three forms:
Graphical configuration tools. Vendors like Siemens (TIA Portal), Rockwell (Studio 5000), and Beckhoff (TwinCAT) all expose graphical languages such as ladder logic, function block diagrams, and structured text. These are "low-code" in the sense that they reduce the amount of textual coding, but they are still vendor-specific and code-centric in architecture.
Model-based design. Tools like MATLAB Simulink let engineers define behavior as block diagrams and generate target code. They are strong at the device and component level, where the work is signal processing, control loops, and motion algorithms. They are not built to model behavior at the equipment, unit, or plant level, where the work is sequencing, coordination, state management, and lifecycle governance. Different scope, different problem.
Model-centric platforms. Platforms in which the entire control system, including requirements, structure, behavior, validation, and runtime monitoring, is defined in one connected model. The "low-code" benefit (less manual coding, broader accessibility) is a consequence of the architecture, not a primary feature.
AI-assisted code generation in vendor IDEs. Newer tools generate vendor-specific code from natural language prompts or pattern recognition inside the existing vendor environment. They reduce typing for the engineer who already knows what to type. They do not change the architecture: the deployable artifact is still vendor-specific code, the lifecycle is still code-centric, and the model integrity problem is unsolved. AI-assisted typing is faster typing. It is not a different category of system.
What "low-code" actually means, and what it does not
Low-code is often misread as "less code is generated" or "the system is simpler underneath." Neither is true. The deployable code that runs on the controller is just as detailed, just as deterministic, and just as long as it would be if it had been written by hand. Low-code refers to how the engineer expresses intent, not to how much logic ends up in the running system.
The benefit is in accessibility and speed of expression. An engineer who understands the system but is not fluent in vendor-specific PLC syntax can still capture behavior correctly, because the platform handles the translation. The complexity of the underlying task is unchanged. What changes is who can productively work on it.
This matters because "low-code" sometimes gets sold as a shortcut around complex engineering. It is not. A system that controls a lock, a cleanroom, or a treatment plant is complex regardless of the tool used to express it. Low-code makes the expression of that complexity more accessible. It does not reduce the complexity itself.
Which raises the question of what kind of model can credibly hold that complexity in the first place.
Why an executable model has to be formalized
The promise of model-centric low-code (define behavior visually, generate code automatically) only holds if the model is formalized. A free-form drawing tool where engineers can place any element anywhere and connect anything to anything cannot be deterministically translated into deployable code. The code generator needs to know that a state has well-defined transitions, that a transition has a clear trigger and effect, that a hierarchy resolves to a single computable behavior, and so on. Without that structure, the model is a sketch, not a specification.
The trade-off is real. Formalization makes the modeling environment feel stricter than a whiteboard. The engineer cannot draw anything they want; they have to draw things the platform can compile. Some engineers initially experience this as a limitation. In practice it is the opposite: the formalization is what makes the model executable, the code generation reliable, and the lifecycle governable. A platform that lets engineers draw anything cannot guarantee what comes out.
Whiteboards remain the right place to think. A formalized model is the right place to commit. The two are not the same artifact, and platforms that conflate them produce sketches that look like systems and systems that drift like sketches.
The risks of "low-code" framing in industrial control
Calling industrial automation tools "low-code" can be misleading in two ways.
Oversimplification. Industrial control is not application development. A platform that promises "anyone can build it" understates the domain knowledge, the integration discipline, and the validation rigor that real systems require. Low-code in OT lowers the cost of expressing intent; it does not lower the cost of getting the intent right.
Governance gaps. Pure visual programming, where engineers compose blocks without a shared underlying model, can recreate exactly the fragmentation and drift that low-code was supposed to fix. Without a single source of truth, "low-code" in OT becomes "many small pieces of code in proprietary editors," which is a governance regression, not a step forward.
The platforms that get this right keep the underlying value (faster development, less manual coding, broader accessibility for domain experts) while preserving lifecycle governance.
How model-centric platforms deliver the real promise
The promise of low-code in industrial automation, stated honestly, is three things: faster development, less manual coding, and broader accessibility for the people who understand the system. Model-centric platforms deliver these without giving up governance.
Cordis SUITE is one of the platforms built around this combination from the foundation. Engineers define behavior in a formalized, structured model. Code is generated automatically for any target hardware (Siemens, Beckhoff, Rockwell, Mitsubishi, CODESYS, Phoenix Contact, .NET/C# and others). The model remains the single source of truth across the entire lifecycle, from first requirement to runtime evidence. The work feels low-code in practice (visual, fast to express, accessible to engineers who understand the system rather than just engineers who understand vendor syntax) and remains auditable, traceable, and maintainable for decades.
The trade-off that pure visual low-code makes (speed at the expense of governance) is not necessary if the visual layer is backed by a model-centric architecture. The platform absorbs the discipline so the engineer does not have to. Cordis SUITE has been built around this principle since 2000, which is why teams who adopt it report development times three to five times shorter than equivalent code-centric work, with auditability and governance intact.
Where low-code approaches fit and where they do not
Low-code fits in two distinct situations, and they are often confused. The first is where the engineering work is repetitive, the system fits patterns the platform already knows, and the lifecycle is short. Internal HMI dashboards, simple configurators, light-weight integration logic: low-code is a clean fit there because the underlying problem is genuinely small.
The second situation is more important. Low-code also fits where the underlying problem is complex but the people who understand it are not fluent in vendor-specific syntax. A water authority engineer who has spent twenty years understanding pumping behavior should not have to learn ladder logic to capture that knowledge in the system. A cleanroom architect who designs flow patterns should not be limited by what they can express in IEC 61131. Low-code, properly built, lets domain expertise translate directly into deployable systems. The complexity of the system is unchanged. The accessibility of the work is transformed.
It fits less well where the system has to be governed across decades, where regulatory or safety constraints demand traceability, and where vendor independence matters. In those contexts, "low-code" should be understood as a property of the user experience, not as the architecture. The architecture has to be model-centric, single-source-of-truth, and lifecycle-aware. The visual layer is the surface; the model is the substance.
Low-code is a useful word in industrial automation only if it points at the right thing. It is not a category of products. It is not a promise that complexity disappears. It is a description of how engineers express intent, on top of an architecture that decides whether the intent stays governable. The architectures that get this right are model-centric. The ones that do not are visual editors that recreate the same drift problem in a different shape.