> 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/11-reference/examples/example-model-start-button-+-cylinder-selmo.md).

# Example model: Start button + cylinder (Selmo)

This example shows the complete transformation of a simple PTF into a Selmo model:

* Start button triggers a cycle
* Cylinder extends until the "extended" end position
* Plausibility (pair check) monitors contradictory end positions
* CMZ protects system-critical conditions
* MXIC allows safe manual movements in manual mode

> Goal: A minimal but complete Selmo core that is deterministic, diagnosable and operable.

***

### 1) Structure (Plant → Hardware Zone → Sequence → Zone)

#### Plant

**PLANT\_01** – Entire plant (minimal for this example)

Plant tasks:

* plant-wide states (optional)
* plant-wide CMZ (optional)

> For this example the plant is deliberately kept lean.

***

#### Hardware Zone

**HWZ\_01 – Station\_01**

Tasks:

* modes of operation (manual / automatic)
* automatic enable
* start coordination (central)
* HW-zone CMZs

***

#### Sequence

**SEQ\_01 – ExtendCylinder**

Task:

* evaluate start button
* extend cylinder
* reach end position "extended"
* complete cycle (ready for next start)

***

### 2) Zones (technique & meaning)

> Every relevant technique is described as a zone.

#### Z\_01 – Start button

* **Type:** Input zone
* **Signal(s):**
  * `I_Start` (start pushbutton)
* **HMI text:** "Press start button"

***

#### Z\_02 – Cylinder (extend)

* **Type:** In-out zone
* **Signal(s):**
  * Output: `Q_Extend` (valve: extend)
  * Input: `I_Extended` (end position extended)
  * Input: `I_Retracted` (end position retracted)
* **HMI text (sequence guidance):**
  * when extending: "Cylinder is extending"
  * Goal reached: "Cylinder extended"

**Pair check (plausibility):**

* Pair: (`I_Extended`, `I_Retracted`)
* Rule: *both TRUE at the same time is physically impossible → diagnosis*

***

#### Z\_03 – AirPressureOK

* **Type:** Input zone
* **Signal(s):**
  * `I_AirOK` (compressed air ok)
* **HMI text:** "Compressed air ok"

> This zone is used as **HW-zone CMZs** (see CMZ).

***

#### Z\_04 – CycleDone (optional)

* **Type:** Mem zone
* **Signal(s):**
  * `M_CycleDone`
* **HMI text:** "Cycle completed"

***

### 3) Logic layer (state model)

> The logic layer describes the sequence as a state machine.

#### States

* **S0 – Idle / WaitStart**\
  Waits for start request
* **S1 – ExtendCommand**\
  Extend cylinder (command + expectation)
* **S2 – Done**\
  Cycle completed, ready for next start (or reset logic as needed)

#### Transitions (simplified)

* S0 → S1, when start request is fulfilled
* S1 → S2, when cylinder is extended
* S2 → S0, when start button is released (or reset/acknowledge, depending on style)

> Note: The *technical fulfillment* is not described in the logic layer, but in the system layer via bit control.

***

### 4) System layer (bit control / cross table)

Operands:

* `0` = Don’t care
* `S` = Sequence check (expectation / guidance)
* `i` = Interlock (mandatory condition, if deviated automatic enable is withdrawn)

#### Bit control matrix

| Zone \ State                | S0 WaitStart | S1 ExtendCommand | S2 Done |
| --------------------------- | -----------: | ---------------: | ------: |
| Z\_01 Start button (input)  |            S |                0 |       0 |
| Z\_02 Cylinder (in-out)     |            0 |                S |       0 |
| Z\_03 AirPressureOK (input) |            i |                i |       i |
| Z\_04 CycleDone (mem)       |            0 |                0 |       S |

**Interpretation:**

* In **S0** is `Z_01` treated as `S` guided: the system expects a start request.
* In **S1** is `Z_02` treated as `S` guided: output is set (`Q_Extend`) and feedback `I_Extended` is expected.
* `Z_03` is in all states `i`: if it fails `I_AirOK` automatic enable is withdrawn and the sequence stops.
* In **S2** is `Z_04` treated as `S` set (optional): the cycle marks itself as completed.

***

### 5) Parameter layer (optional, but clean)

> Parameters change values, not logic.

* `P_ExtendTimeout` (timeout for extending, if needed)
* `P_DoneHoldTime` (display/hold time in Done, optional)

> If you model a "timeout", the logic for it belongs in a timer state – the value comes from the parameter layer.

***

### 6) CMZ (constantly monitoring zone)

#### HW-zone CMZ: `Z_03 AirPressureOK`

* Level: **Hardware Zone**
* Rule: `I_AirOK` must **always** be present correctly
* Effect on error:
  * withdraw automatic enable
  * stop all sequences of the HW zone
  * **no manual movement possible** (CMZ rule)

> This CMZ makes it clear: Without compressed air there is no safe operation – neither automatic nor manual.

***

### 7) Pair check (plausibility)

#### For `Z_02 Cylinder`

* Pair: (`I_Extended`, `I_Retracted`)
* Impossible: both TRUE at the same time
* Reaction:
  * automatic diagnosis "cylinder end positions contradictory"
  * Sequence cannot continue

> The pair check is not a sequence block, but a plausibility monitor with a clear diagnosis.

***

### 8) MXIC (manual cross interlock) – manual operation

Goal:

* Manual movement only when it is **conforming to the model and safe** is
* In case of doubt: **diagnosis instead of movement**

#### Manual actions (buttons)

* `BTN_Extend` → controls zone `Z_02` (extend)
* `BTN_Retract` → controls zone `Z_02` (retract) *(if retracting should be allowed in the example)*

#### MXIC conditions (example rules)

* `BTN_Extend` is allowed when:
  * **no CMZ error** is active (AirPressureOK must be correct)
  * *(optional)* the current state is S0 or S1 (no arbitrary movement in Done)
* `BTN_Retract` is allowed when:
  * **no CMZ error** is active
  * *(optional)* the sequence is not in a critical state

If condition not met:

* movement is prevented
* Diagnosis: "Manual movement not allowed: "

***

### 9) HMI behavior (short, model-based)

* In **S0**:
  * Display `Z_01` with `S` → "Press start button" (guidance)
* In **S1**:
  * Display `Z_02` with `S` → "Cylinder is extending"
  * as soon as `I_Extended` fulfilled → transition to S2
* In case of `i`deviation (`I_AirOK` missing):
  * automatic enable withdrawn, stop, diagnosis on `Z_03`
* In case of pair check error:
  * diagnosis on `Z_02` ("end positions contradictory")

> Basic principle: Messages are generated where the model knows expectation and deviation (state + zone + operand).

***

### 10) Summary: What this model shows

This example is complete because it:

* defines structure (plant/hwz/sequence/zone)
* clearly describes the sequence (logic layer)
* formally specifies behavior (system layer/bit control)
* integrates safety/integrity (CMZ)
* automatically monitors plausibility (pair check)
* safely limits manual operation (MXIC)
* makes diagnosis/HMI derivable from the model

> Thus this example is a minimal "Selmo standard case": small but complete.


---

# 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/11-reference/examples/example-model-start-button-+-cylinder-selmo.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.
