Comparison to classical control development
🔄 Classical way: Open loop with many breaks
In a classic PLC project it typically goes like this:
Requirements are defined
An expert translates them manually into PLC code
The code is tested – does it match the requirement?
Documentation is created separately – usually afterwards
When changes occur:
Adjust code
Update documentation
Re-run tests
Review by a specialist required
Result: An open loop
high effort for review, traceability, maintenance
any deviation in operation requires manual intervention
🧠 Selmo & SDEA: Closed, automated loop
With Selmo it works differently – structured and end-to-end:
Requirements are formulated as a process model (SDEA) formulated
From this are generated automatically:
the control (logic, states, transitions)
the Monitoring (bit control, CMZ, interlock, MXIC)
the Documentation (signal directory, sequence, safety functions)
Code and HMI are generated directly from the model
Changes in the requirement → Update model → everything adapts
In operation:
the model checks the machine in real time
no undefined states
automated fault diagnosis & documentation
🎯 Conclusion: Difference in depth
Requirements
manually translated into code
directly modeled
Code review
by experts
automatically validated
Documentation
retrospective and costly
automatically from model
Changes
error-prone, costly
simple via model change
Real-time behavior
hard to verify
formally monitored by the model
States
often open, implicit
deterministic and visible
CE evidence
manually assembled
structured, directly derivable
With Selmo and the SDEA model a closed, audit-proof loop, in which logic, behavior, safety, operation and documentation are always synchronized – and any deviation is detected immediately is.
📌 Selmo replaces testing effort with model clarity – and makes automation traceable, scalable and safe.
🆕 Chapter: Comparison to the classic PLC – methodology & behavior
What is Selmo (SDEA) compared to the classic PLC?
Criterion
Classic PLC
Selmo (SDEA model)
Sequence logic
via code, jump markers, conditions
via modeled states and transitions
Control logic
distributed in the code
central in the model (logic layer)
Signal behavior
programmed directly (e.g., set/reset)
modeled via bit control (0, S, i)
Safety behavior
manually programmed
modeled (interlock, CMZ, MXIC)
Manual mode
via auxiliary logic and button handling
automatically released/locked by MXIC
Operator diagnosis
created manually
automatically from the model (texts, colors, zone display)
Restart
programmed individually
model-driven with synchronization and reset
Documentation
manually or externally
automatically generated from the model
Advantages of the Selmo approach
Clarity: Model instead of code – everyone sees what is happening
safety: Structured CMZ and MXIC logic
Maintainability: every change documented traceably
Fault tolerance: Diagnosis comes directly from the model
CE conformity: Operating modes, reset logic, safety reactions representable
With Selmo a consistent behavior is created – from the sensor to the HMI display, documented and testable.
Last updated
Was this helpful?

