1 Why Selmo?

Problem & attitude

An executive summary

Modern machines are powerful, networked and highly automated. At the same time, their behavior is becoming increasingly difficult to explain.

The code works – but it no longer answers central questions:

• Why is the machine stopped?

• What is currently being expected?

• What is allowed to happen here – and why?

• Who is responsible for what?

Selmo exists to answer exactly these questions formally.

---

The core problem of today’s automation

In classic automation projects, machine logic is:

• implicitly distributed in the code

• mixed with operation and safety

• hard to trace

• hardly verifiable

Code describes what happens, but not why it is allowed to happen.

As a result:

• diagnosis is vague

• documentation inconsistent

• responsibility diffuse

• liability hard to argue

---

What Selmo does differently

Selmo shifts the focus:

from code → to the model

Instead of commands, Selmo describes:

• states

• expectations

• monitoring

• reactions

Machine behavior becomes:

• explicit

• complete

• deterministically

• traceable

The model becomes the truth. Code is only an implementation.

---

What Selmo delivers concretely

With Selmo, a formal behavior modelis created, from which can be derived:

• PLC code

• HMI structures

• Diagnosis

• documentation

Not separate. Not afterwards. But from the same source.

The result:

• consistent behavior

• automatic, correct diagnosis

• unambiguous state management

• stable documentation

---

Why this is decisive

Selmo makes machines:

• explainable → States, expectations and deviations are unambiguous

• verifiable → Behavior is formally described, not interpreted

• accountable → Decisions, reactions and safety assumptions can be justified

• scalable → Complexity is structured, not distributed

---

Safety, operation and responsibility

Selmo cleanly separates:

• sequence (Sequence)

• technology (Zone)

• behavior (Bit-Control)

• operation (Hardware-Zone)

• integrity (CMZ)

Manual and automatic operation are:

• no special logics

• no exceptions

• no bypasses

Safety is:

• modeled

• permanently active

• hierarchically effective

---

Relevance for standards and the future

Through the formal model it is always traceable:

• which state was active

• which conditions applied

• why a reaction occurred

This is crucial for:

• functional safety

• standards argumentation

• auditability

• liability

• use of AI in programming

What is modeled is explainable. What is explainable is accountable.

---

What Selmo consciously is not

Selmo is:

• not a low-code system

• not a PLC framework

• not a UI concept

• not a replacement for safety hardware

• not a shortcut for complexity

Selmo does not replace responsibility. Selmo makes it visible.

---

The central statement

Selmo is a formal model for explainable machines.

No more. But also no less.

If you understand the model, you understand the machine.