What Selmo consciously does not describe

This page describes consciously the boundaries of Selmo.

Not to exclude something, but to make clear what Selmo is intended for – and what not.

A clear model needs clear boundaries.

---

Selmo does not describe a PLC program

Selmo is:

• not a PLC framework

• not a collection of function blocks

• programming guideline as standard and method

• model for behavior

Selmo describes:

• machine behavior

• not the concrete implementation in code

The generated or derived PLC code:

• is an implementation

• not the truth

• not the reference point

The code follows the model – not the other way around.

---

Selmo does not describe HMI design

Selmo defines:

• what must be displayed

• why it is displayed

• when something counts as a deviation

Selmo defines not:

• layouts

• screen division

• colors in the graphical sense

• operator workflows

The HMI is:

• a view onto the model

• not an independent concept

Selmo describes meaning – not design.

---

Selmo does not describe hardware design

Selmo describes no:

• mechanics

• electrical design

• pneumatic or hydraulic circuits

• sensor placement

• safety hardware

These decisions belong:

• to the mechanical design

• to the risk assessment

• to the machine architecture

Selmo assumes that these fundamentals are technically correct are.

Selmo models behavior, not physics.

---

Selmo does not describe safety hardware

Selmo does not replace no:

• emergency stop chain

• safe shutdown

• safety PLC

• mechanical protective measures

Selmo complements these with:

• explicit state models

• formal monitoring

• traceable reactions

Hardware safety protects physically. Selmo safety protects logically.

---

Selmo does not describe project organization

Selmo is:

• no project management model

• no procedure for scheduling

• no organizational structure

Selmo can support projects, but does not replace:

• role clarification

• assignment of responsibilities

• process organization

Selmo structures machines – not organizations.

---

Selmo does not describe shifting responsibility

Selmo automates:

• logic

• monitoring

• diagnosis

• consistency

Selmo automates not:

• decisions about admissibility

• safety responsibility

• normative assessment

• liability

This responsibility remains:

• with humans

• with the company

• with the operator

Selmo makes responsibility visible – it does not assume it.

---

Why this delimitation is important

This clarity prevents:

• wrong expectations

• overloading the model

• misuse as an "all-purpose solution"

• later disappointment

And it enables:

• clean integration into existing processes

• clear distribution of roles

• robust argumentation

• long-term stability

---

Summary

Selmo consciously describes:

• what a machine is allowed to do

• when it is allowed to do it

• why it reacts that way

Selmo consciously describes not:

• how everything is implemented

• how everything is designed

• how everything is organized

Selmo is not a substitute for engineering. Selmo is its formal foundation.