8 Diagnosis, HMI & documentation

1. The fundamental problem of classical diagnosis

In many automation projects diagnosis is created:

• afterwards

• manually

• detached from the process

• inconsistent across projects

Typical symptoms:

• aggregate alarms without cause

• messages without context

• wrong time, wrong place

• high maintenance effort

The core of the problem:

If behavior is not modeled explicitly, diagnosis can only be guessed.

---

2. Basic principle of Selmo diagnosis

In Selmo diagnosis is not an additionbut a consequence of the model.

Diagnosis arises because:

• states are defined explicitly

• zones carry meaning

• expectations are described formally

• monitoring is continuous

Every diagnosis is the deviation between expected and actual states in the model.

There are:

• no heuristic error detection

• no manual "if error then message" logic

---

3. Sources of diagnosis in the model

Diagnosis arises exclusively from modeled elements:

• Zone

  • carries meaning

  • knows its signals

  • has HMI text

• Bit-Control

  • defines expectation (S)

  • defines mandatory conditions (i)

• CMZ

  • monitors continuously

  • acts independently of state

Without a model cause there is no diagnosis.

---

4. Diagnosis in automatic operation

In automatic operation applies:

4.1 Interlock deviation (i)

• immediate withdrawal of automatic release

• stop of the affected sequence

• automatic diagnosis with:

  • zone reference

  • state reference

  • clear cause

4.2 CMZ deviation

• hierarchical stop:

  • Sequence

  • hardware zone

  • or Plant

• no movement possible anymore

• unambiguous, non-aggregated message

The diagnosis knows time, place and cause.

---

5. Diagnosis in manual operation

In manual operation diagnosis is active guidancenot an error message.

Properties:

• zones show their status directly

• deviations are highlighted visually

• the operator recognizes:

  • what is missing

  • where intervention is required

Diagnosis in manual operation does not answer "What is broken?", but "What is missing to satisfy the state?"

---

6. HMI as a model view

The HMI in Selmo is not a logic instance.

The HMI:

• decides nothing

• evaluates nothing

• controls nothing autonomously

It shows:

• active sequences

• current states

• relevant zones

• expectations and deviations

The HMI is a project-specific view of the same model.

---

7. Uniform HMI semantics

From the model automatically results:

• uniform colors

• uniform meanings

• uniform reactions

Examples:

• Blue → state / zone fulfilled

• Red → deviation from expected behavior

This semantics is:

• the same across projects

• independent of UI design

• independent of target systems

---

8. Documentation arises from the model

The Selmo model already contains:

• process (sequences, states)

• technical reference (zones)

• monitoring (bit control, CMZ)

• reactions (stop, release, diagnosis)

Derivable from this are:

• process descriptions

• state diagrams

• safety argumentations

• operation concepts

• diagnosis descriptions

Documentation is not a separate activity, but a view of the model.

---

9. Significance for standards & traceability

Through the formal model it is always traceable:

• which state was active

• which expectations applied

• which deviation occurred

• which reaction followed

This is crucial for:

• functional safety

• auditability

• liability issues

• argumentation for AI-generated code

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

---

10. Delimitation

To clarify:

• Diagnosis ≠ UI logic

• Diagnosis ≠ PLC error bit

• Diagnosis ≠ safety function

• Diagnosis ≠ user interpretation

Diagnosis is model-based state deviation.

---

11. Typical errors in diagnosis & HMI

Common mistakes are:

• aggregate messages without cause

• UI-specific logic

• diagnosis outside the model

• duplicate error logic in code and HMI

• different meanings of the same colors

Rule of thumb:

If a message has to be explained, model information is missing.

---

12. Summary

Diagnosis, HMI and documentation in Selmo are:

• not additional functions

• not separate disciplines

• not project-specific special solutions

They are:

• direct consequences of the model

• consistent, deterministic and traceable

• Basis for safe, explainable machines

Selmo does not document machines – Selmo makes machines explainable.