From the process to the runnable system

This chapter describes, how a conceptual model becomes a real running system – and why this path in Selmo directed, consistent and traceable is.

It is not about implementation details, but about the logical chain of cause and effect.

---

The basic idea

In classic projects many artifacts arise in parallel:

• Code

• HMI

• diagnosis

• Documentation

These artifacts:

• have different sources

• develop at different speeds

• lose their consistency over time

Selmo follows a different approach:

There is one source of truth: the model.

Everything else is a derivation from it.

---

From the model to the PLC

The Selmo model describes:

• States

• Expectations

• monitoring

• Reactions

This model is:

• complete

• deterministically

• formally described

From this model the PLC code is derived:

• not as a creative translation

• but as a consistent implementation

• without additional logical assumptions

The code contains:

• no implicit states

• no hidden transitions

• no unmodeled special cases

The code implements the model – it does not extend it.

---

From the model to the HMI

The HMI is created in Selmo not as an independent concept.

It is a visualization of the model:

• active sequences

• current states

• relevant zones

• expectations and deviations

The HMI:

• decides nothing

• interprets nothing

• does not compensate for logic

It shows:

What the model currently says.

Thus the HMI is:

• consistent with the process

• understandable across projects

• independent of individual design

---

From the model to diagnostics

Because behavior is explicitly modeled, diagnostics arise automatically.

A diagnosis results from:

• active state

• associated zone

• expected condition

• actual signal state

There are:

• no manually maintained error messages

• no aggregate faults

• no interpretation by the programmer

Diagnosis is the formal deviation from the model.

---

From the model to documentation

The model already contains:

• Process description

• State definitions

• Safety assumptions

• Monitoring logic

• Reaction behavior

From this one can derive:

• technical documentation

• process descriptions

• safety arguments

• audit evidence

Documentation is therefore:

• always up to date

• consistent with the system

• not maintained by hand

The model is the documentation.

Model ↓ PLC ↓ HMI ↓ Diagnostics ↓ Documentation

This chain is:

• directed

• lossless

• traceable

There is no feedback, where logic is created in the code or in the HMI.

---

Meaning for operation and responsibility

Because of this structure it is always clear:

• why the machine behaves that way

• where a message comes from

• which assumptions apply

• which response is intended

This is crucial for:

• Commissioning

• Operation

• Changes

• Safety

• liability

What is produced from a model, can also be traced back to the model.

---

Classification

This chapter describes the flow, not the details of the individual steps.

The following chapters explain:

• how the model is structured

• how behavior is described

• how operation and safety work

Selmo does not replace systems – it organizes them.

---

The end-to-end chain

In summary, a clear chain emerges: