> 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-of-the-logic/selmo-standard-overview.md).

# Selmo standard overview

#### 1.2 The Selmo Standard

The Selmo Standard describes machines in a fixed structure:

```
PLANT(PLC)
└── Hardware zones (HWZ)
    └── Sequences (SEQ)
        └── Zones (Input, Output, In-Out, Mem)
```

Each logical process unit (e.g., stations, robot control, conveyor, etc.) is modeled as its own SEQ – with defined states and linked signals in zones.&#x20;

Each zone contains:

* Signal name
* IO definition
* HMI text
* Behavior per state (via `bit control` defined)

### 🔧 **The Selmo Standard – Overview and core functions**

The **Selmo Standard** defines a consistent structure for **modeling, control, and diagnostics** of machines. It is modular and based on three central principles:

1. **Model instead of program code**
2. **State-based behavior instead of signal sequences**
3. **Automated diagnostics through fixed system behavior**

Each machine is represented in a clear **hierarchy** :

```
Plant → Hardware Zone → Sequence → Zone
```

***

#### 🔹 **Structural elements of the Selmo Standard**

| Level             | Description                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------- |
| **Plant**         | The entire machine or system in one PLC                                                           |
| **Hardware Zone** | A controllable machine part (e.g., station with multiple SEQs, areas) with its own operating mode |
| **Sequence**      | A logical process flow with defined states in a station (e.g., clamping, drilling)                |
| **Zone**          | A technical functional unit (e.g., cylinder, pushbutton, sensor)                                  |

***

#### 🧩 **Core functions of the Selmo Standard**

Below are the most important integrated functions that every Sequence and Zone supports according to the Selmo Standard:

***

**⚙️ 1. Bit Control (System Layer)**

* Defines per state, **how each zone behaves**
* Operands:
  * `0` = **Don’t care** – no relevance
  * `I` = **Interlock** – condition must be fulfilled
  * `S` = **Sequence Check** – action is expected and monitored
  * `M` = Monitoring - like interlock, but without shutdown - documents deviation
* Basis for automatic enable, state transitions, and error diagnostics

***

**🔍 2. Sequence Check**

* Expected action in automatic mode
* Is compared with the actual signal
* In case of deviation: **Diagnosis with blue hint in the HMI as info for the continuation condition per signal**
* Leads to the **release of the next state**, when all S are fulfilled

***

**🛑 3. Interlock Check**

* Monitors critical conditions in every state
* If an `I` is violated: **Automatic mode stops immediately**, **red error message**
* Also visible in manual mode → targeted correction possible
* Monitoring is the same function, but does not shut down

***

**🚨 4. CMZ (Constantly Monitoring Zone)**

* Permanent monitoring of safety-relevant signals
* Faults have **cross-cutting effects** on:
  * **Sequence (SEQ errors only)**
  * **Hardware Zone (all SEQ errors in the HWZ)**
  * **Plant (all HWZ errors)**
* Leads to immediate blocking of automatic mode **and** Manual mode
* Errors are **not overrideable**

***

**✋ 5. MXIC (Manual Cross Interlock Check)**

* Controls in manual mode **whether a manual movement is permitted**
* If not permitted:\
  → **no movement**,\
  → **diagnosis with explanation**, why not
* Safety logic: no manual movement against logical conditions

***

**👁️ 6. HMI linking (automatic)**

* Each zone is **HMI text** linked
* Errors are **automatically localized and color-coded**:
  * **Red** = Interlock error (No automatic mode)
  * **Blue** = Sequence Check active (Automatic possible or active in automatic)
* Operator can always see **what is expected and what is missing**

***

**⏱️ 7. Steptime**

* Time monitoring for certain states possible
* Used e.g. for waiting times, safety sequences, etc.

***

**🔁 8. Sequence Cross**

* Synchronous transitions between multiple sequences
* Enables synchronization e.g. with robot or additional stations
* Modular structure across sequence boundaries

***

**🧠 9. Parameter Layer**

* Enables definition and use of **non-binary values**:
  * Times
  * Speeds
  * Number of repetitions
* Parameters can be written directly from the HMI
* Flexibilization of the process sequence with parameters (positions, lengths, etc.)

***

**📋 10. Automatic diagnostics**

* Errors, warnings, and states are **derived from the model**
* No manual programming of diagnostics necessary
* Errors are **contextual, localized and visually recognizable, bit-precise information**

***

#### ✅ **What the Selmo Standard delivers**

| Benefit             | Description                                              |
| ------------------- | -------------------------------------------------------- |
| **Structure**       | Uniform, reusable control architecture                   |
| **safety**          | Interlocks, CMZ and MXIC as integrated safety mechanisms |
| **Transparency**    | Automatic diagnostics with clear HMI feedback            |
| **Modularity**      | Machines can be divided into and combined from sequences |
| **Maintainability** | Every process is transparently modeled, not programmed   |
| **Determinism**     | Behavior is clearly defined in every state               |


---

# 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-of-the-logic/selmo-standard-overview.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.
