> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/onboarding/selmo-in-10-minutes.md).

# Selmo in 10 minutes

This onboarding gives you in **10 minutes** a resilient mental model of Selmo. Not complete – but **correct**.

If you read on after this, you'll know:

* what Selmo is
* how it thinks
* where you need to deepen

***

### Minute 1 – The basic problem

Classic machine logic is stuck in the code. The code works – but it explains nothing.

Questions like:

* *Why is the machine stopped?*
* *What is currently being expected?*
* *What is allowed to happen here?*

can often only be answered with experience.

> **Selmo exists to make machine behavior explainable.**

***

### Minute 2 – Model before code

Selmo starts **not** with PLC code.

Selmo starts with a **formal model**, which describes:

* states
* expectations
* monitoring
* reactions

From this model arise:

* Code
* HMI
* Diagnosis
* documentation

> **The model is the truth.**\
> **Code is only an implementation.**

***

### Minute 3 – The central idea: states

A machine is at any time in **exactly one state**.

A state describes:

* a situation
* no action
* no instruction

Example:

* "Workpiece clamped"
* not: "Cylinder extend"

> **Selmo thinks in situations, not in commands.**

***

### Minute 4 – Sequence: one task, one model

A **Sequence** is a deterministic state machine for **a functional task**.

Examples:

* Clamp
* Machine
* Inspect
* Release

A sequence:

* knows its current state
* knows what is expected next
* always reacts the same

> **One task → one sequence.**

***

### Minute 5 – Zone: meaning for engineering

Signals alone mean nothing.

A **Zone**:

* gives signals meaning
* connects logic with engineering
* is uniquely diagnosable

Example:

* not: `I0.3`
* but: *"Cylinder clamped"*

> **Zones make engineering explainable.**

***

### Minute 6 – Bit-Control: explicit behavior

Bit-Control determines **what a zone may or must do in a state**.

Three possibilities:

* `0` → doesn't matter
* `S` → behavior is expected
* `i` → condition must be fulfilled

This applies:

* in every state
* for every zone

> **No implicit behavior.**\
> **Everything is explicit.**

***

### Minute 7 – Operation: manual and automatic

Manual and automatic operation are **not two logics**.

Both operate:

* in the same state space
* with the same monitoring
* with the same rules

Difference:

* Automatic → system drives the sequence
* Manual → operator influences zones

> **Operation does not change the logic,**\
> **only the source of influence.**

***

### Minute 8 – CMZ: what must always be correct

Some things must be **always** correct:

* Doors
* Power
* basic releases

This is handled by the **CMZ (Constantly Monitoring Zone)**.

A CMZ:

* is always active
* regardless of the state
* stops any movement on deviation

> **CMZ protects system integrity.**

***

### Minute 9 – Diagnosis & HMI

Because behavior is modeled, diagnosis arises automatically.

A diagnosis knows:

* where in the sequence
* which zone
* which expectation is violated

The HMI:

* shows the model
* decides nothing
* interprets nothing

> **The HMI is a window into the model.**

***

### Minute 10 – What Selmo really is

Selmo is:

* not a tool
* not a framework
* not a shortcut

Selmo is:

* a formal thinking model
* a common language
* a basis for responsibility

> **If you understand the model,**\
> **you understand the machine.**

***

### What happens next

If you want to dive deeper:

* Sequences → **Sequence**
* Engineering → **Zone**
* Monitoring → **Bit-Control**
* Operation → **Manual & automatic operation**
* Safety → **CMZ**
* Traceability → **Diagnosis, HMI & Documentation**

And if you're unsure: → **Glossary**

> **Do not read Selmo quickly.**\
> **Read Selmo precisely.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/onboarding/selmo-in-10-minutes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.