The missing discipline in industrial control system design

Design above
the code.

There's a layer above the ladder that nobody teaches. It's where states, structure, and change actually live — and it's where control systems are won or lost. WonderLogics Studio is the modelling environment for that layer.

Take the course → Read the methodology
WonderLogics Studio
— The problem nobody names
Scenario 01

"Can we disable Unit 3 from the HMI?"

You go to the code. Unit 3's logic isn't in one place — it's spread across many rungs in different routines, referring to readings and states from across the system. You start cross-referencing. An hour later, you're not sure you've found everything. Two hours later, you're not sure anything is safe to change. You make the change anyway, because there's a deadline and the team is waiting. You hope.

Scenario 02

"A valve is behaving strangely during priming."

You open the project. The valve's opening command is a complex logic, referring to the state of other valves, pumps' status, and pressure conditions. You sit in front of the screen waiting for the bug to happen again, because the code doesn't say what it thinks it's doing.

These aren't bugs. These are symptoms of the absence of design discipline above the code.

The discipline

Five moves that separate control systems you fight with from systems you build on.

01
Hierarchical structure
The system consists of components, which consist of other components, recursively. Each component represents something concrete — a production line, a pumping unit, a pressure transmitter — and delivers its function through the components it contains.
02
Clear interface
Each component defines what it can receive (start command, required pressure) and what it can report (failure, actual pressure). No data passes in or out except through the interface. No globals, no shortcuts.
03
Single responsibility
Each component is responsible for one thing. If it does multiple things, each of them belongs in a sub-component.
04
Explicit states & transitions
Never implicit. If the system is "priming," there is a state called Priming, and you can ask the system whether it is in that state.
05
The model is the source of truth
PLC code must faithfully express the model, but it can't replace it. It's like saying you don't need drawings of a house because you already have the house — until you need to measure the roof to replace it.
About the author

Dror Roth is a control engineer with twenty years of experience designing and rebuilding industrial control systems. The "design above the code" methodology is the result of that work. He develops WonderLogics Studio as the practical environment for it, and now teaches the methodology through a hands-on course.

Design above the code.
Generate the rest.

Take the course → Explore Studio
Get in touch

We'd like to
hear from you.

Questions about the methodology, the course, or the tool? Just want to talk through a control problem? Submit the form or email us directly at info@wonderlogics.com