> 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/goal-a-formally-correct-safe-consistent-realization-of-the-machine.md).

# Goal: A formally correct, safe, consistent realization of the machine

This is a crucial question – and indeed the **core of any professional automation project**:\
🧩 *What is required – technically, structurally and formally – so that a machine not only works, but is also compliant with standards, verifiable and maintainable in the long term?*

***

### ✅ Goal: A **formally correct, safe, end-to-end implementation** of the machine

For this, **all levels** – from the technology to the software structure – **must be aligned with each other and described model-based** In the context of Selmo this means:

***

### 🔷 1. **Technology requirements**

(What is physically present / planned?)

| Domain                | Requirements                                                               |
| --------------------- | -------------------------------------------------------------------------- |
| **Sensors**           | clear signal availability, unambiguously placeable, quickly evaluable      |
| **Actuators**         | switchable, feedback-capable, safe in case of faults                       |
| **Interfaces**        | IO (local or bus), Safety-IO, HMI, control system, OPC UA                  |
| **Drives / control**  | standardized access (e.g. Drive-Enable, status bits), feedback unambiguous |
| **Safety components** | interlocks, air pressure monitoring, door contacts, emergency stop, etc.   |

→ Everything must **be modelable as a zone** be representable

***

### 🔷 2. **Engineering structure / automation structure**

(What is planned from a control perspective?)

| Level                 | Requirements                                                    |
| --------------------- | --------------------------------------------------------------- |
| **Signal structure**  | unambiguous addressing (IO map), documented, reversible         |
| **Control system**    | IEC 61131-3-capable, stable cycle times, diagnosable            |
| **HMI system**        | traceable back to model logic, no “free scripting” needed       |
| **Project structure** | Plant → HWZ → SEQ → Zone → Parameter → IO, structurable         |
| **Documentation**     | automatically generable from model (no manual post-maintenance) |

→ Every zone, every state, every interlock condition must be mappable & exportable

***

### 🔷 3. **Process flow / functional logic**

(What should happen – logically and structurally?)

| Topic                  | Requirements                                         |
| ---------------------- | ---------------------------------------------------- |
| **Sequence structure** | describable in logical states                        |
| **Step progression**   | deterministic (no “jumping”, no “shifting”)          |
| **Reaction to errors** | modeled (interlock, CMZ), documented, not programmed |
| **Manual mode**        | Button movement only with release (MXIC)             |
| **Restart capability** | state always unambiguous, reset behavior modelable   |

→ All sequences must be **formulable as a state machine with zone logic** be

***

### 🔷 4. **System architecture / CE-relevant structure**

| Domain                                | Requirements                                         |
| ------------------------------------- | ---------------------------------------------------- |
| **Mode switching of operating modes** | modeled, secured (key, release)                      |
| **Restart / reset**                   | only possible under documented conditions            |
| **Interface behavior**                | signals: error, status, release, EOC etc.            |
| **Safety zones / CMZ**                | logically checked, documented, HMI-guided            |
| **Parameter control**                 | standardized data types, strictly defined interfaces |

→ The system must **be testable, simulatable, traceable** to modeled logic

***

### 🔷 5. **Quality requirements for formal implementation with Selmo**

| Topic                          | Must be ensured                                      |
| ------------------------------ | ---------------------------------------------------- |
| Unambiguous signal designation | `Zone = IO = terminal = function`                    |
| Complete sensing               | Every state is verifiable (no “belief in movements”) |
| Modular functional division    | SEQ for each logical subfunction                     |
| Technically verifiable logic   | every state + every zone must be **verifiable** be   |
| Traceability                   | from the model through code to the documentation     |

***

### 📦 Result: Project is **formalizable**, **documentable** and **implementable in compliance with CE**, when:

#### ✅ The technology:

* **sufficiently digitized** is (inputs/outputs, safety-evaluated)

#### ✅ The engineering setup:

* **can be represented model-based** (no hidden side effects)

#### ✅ The process:

* **logically describable** is (states, conditions, safety, reset)

#### ✅ The structure:

* **clearly separable and comprehensible** is (Plant → HWZ → SEQ → Zone)


---

# 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/goal-a-formally-correct-safe-consistent-realization-of-the-machine.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.