When the starting decision defines success or risk
The starting point of an automation project may appear at first to be a purely technical decision. In reality, however, it lays the foundation for how machine behavior is defined, validated, and controlled across the entire lifecycle of a system.
In modern industrial automation, machine control systems are typically based on PLC systems, sensors, and actuators. However, long-term stability is not determined by PLC programming alone, but by the underlying automation architecture.
In practice, many projects initiate straight with programming, HMI design, or hardware selection. This results in machines that appear to function at first glance, but their actual behavior often only becomes visible during integration, changes, or commissioning.
This is exactly where it is decided whether a system is truly controllable, or whether risks only become visible once they already incur costs. If machine behavior only emerges during implementation, it often leads to complex systems with logic that is difficult to trace and carries increased risk, especially during commissioning.
This raises a central question for projects and organizations: how can machine behavior be structurally defined from the outset?
This article explores:
Selmo Method Brochure
What advantages arise when machine behavior is not created in code, but clearly defined from the outset?
Our brochure shows how behavior can be structurally defined and made controllable before programming begins. With WhiteBox Engineering, Process-First automation, and model-based control architecture.
Download the Selmo Method Brochure
Every automation project begins with a fundamental decision: the entry point. This entry point largely determines how machine behavior emerges, how it is validated, and how it can later be controlled during operation.
Typically, four entry points can be distinguished:
What appears technical at first glance is, in reality, a strategic decision. It has long-term implications for risk, maintainability, and the investment security of a system.
The safest and most long-term efficient entry point is the process.
In Process-First Engineering, machine behavior is first defined as a structured model before implementation begins.
This means:
Technology, control logic, and software then follow this structured behavioral definition.
This approach significantly reduces risk because:
Organizations that apply Process-First Engineering often achieve:
At Selmo, this approach is implemented through Sequence Logic Modeling and the PTF methodology. Machine behavior is thus deterministically described and explicitly defined before implementation.
In practice, many automation projects do not begin with an explicit definition of machine behavior, but directly with technical decisions.
These approaches may work in the short term. In the long term, however, they often lead to implicit machine behavior, increased complexity, and higher operational risk.
The difference between these approaches becomes particularly clear when examining when and how machine behavior is actually defined.
| Approach | Machine Behavior | Validation | System Logic |
Commissioning | Changes | Operational Risk |
|---|---|---|---|---|---|---|
| Process-First Engineering | Defined before implementation | Model verification before implementation | Clear automation architecture | Confirms defined behavior | Verified against the process model | Low – clear structure |
| Code-First | Emerges in code | During integration | Logic distributed across code | Behavior is discovered | Risk of unintended effects | Medium to high |
| Interface-First (HMI) | Emerges through UI logic | Late in the project | Distributed between HMI and code | Align UI and control logic | UI influences logic | Medium |
| Hardware-First | Shaped by hardware | After hardware integration | Driven by hardware structure | Hardware constraints become visible | Often hardware-dependent | Medium |
Process-First Engineering differs fundamentally from the other approaches.
While code-, interface-, or hardware-driven projects allow behavior to emerge implicitly, Process-First Engineering defines machine behavior explicitly before implementation.
This creates a clear separation between:
This separation significantly reduces structural risks. As a result, machine behavior becomes:
This principle forms the foundation of Selmo’s WhiteBox Engineering approach, where machine behavior is formally defined before implementation and remains controlled and traceable throughout the entire lifecycle.