> 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-dokumentation-der-logik/ziel-eine-formal-korrekte-sichere-durchgangige-realisierung-der-maschine.md).

# Ziel: Eine formal korrekte, sichere, durchgängige Realisierung der Maschine

Das ist eine entscheidende Frage – und tatsächlich der **Kern jedes professionellen Automatisierungsprojekts**:\
🧩 *Was braucht es – technisch, strukturell und formal –, damit eine Maschine nicht nur funktioniert, sondern auch normgerecht, prüfbar und langfristig wartbar ist?*

***

### ✅ Ziel: Eine **formal korrekte, sichere, durchgängige Realisierung** der Maschine

Dafür müssen **alle Ebenen** – von der Technologie bis zur Softwarestruktur – **aufeinander abgestimmt und modellbasiert beschrieben** sein. Im Kontext von Selmo heißt das:

***

### 🔷 1. **Technologieanforderungen**

(Was ist physisch vorhanden / vorgesehen?)

| Bereich                 | Anforderungen                                                              |
| ----------------------- | -------------------------------------------------------------------------- |
| **Sensorik**            | eindeutige Signalverfügbarkeit, eindeutig platzierbar, schnell auswertbar  |
| **Aktorik**             | schaltbar, rückmeldbar, sicher im Fehlerfall                               |
| **Schnittstellen**      | IO (lokal oder Bus), Safety-IO, HMI, Leitsystem, OPC UA                    |
| **Antriebe / Regelung** | normierter Zugriff (z. B. Drive-Enable, Statusbits), Rückmeldung eindeutig |
| **Safety-Komponenten**  | Verriegelungen, Luftdrucküberwachung, Türkontakte, Not-Halt etc.           |

→ Alles muss **modellierbar als Zone** abbildbar sein

***

### 🔷 2. **Engineeringstruktur / Automatisierungsstruktur**

(Was ist steuerungstechnisch geplant?)

| Ebene                | Anforderungen                                                 |
| -------------------- | ------------------------------------------------------------- |
| **Signalstruktur**   | eindeutige Adressierung (IO-Map), dokumentiert, reversibel    |
| **Steuerungssystem** | IEC 61131-3-fähig, stabile Zykluszeiten, diagnostizierbar     |
| **HMI-System**       | rückführbar auf Modelllogik, kein „freies Skripting“ nötig    |
| **Projektstruktur**  | Plant → HWZ → SEQ → Zone → Parameter → IO, strukturierbar     |
| **Dokumentation**    | automatisch erzeugbar aus Modell (kein manuelles Nachpflegen) |

→ Jede Zone, jeder Zustand, jede Interlock-Bedingung muss abbildbar & exportierbar sein

***

### 🔷 3. **Prozessablauf / Funktionslogik**

(Was soll passieren – logisch und strukturell?)

| Thema                   | Anforderungen                                                 |
| ----------------------- | ------------------------------------------------------------- |
| **Ablaufstruktur**      | in logischen Zuständen beschreibbar                           |
| **Schrittverlauf**      | deterministisch (kein „Springen“, kein „Schieben“)            |
| **Reaktion auf Fehler** | modelliert (Interlock, CMZ), dokumentiert, nicht programmiert |
| **Handbetrieb**         | Tastenbewegung nur mit Freigabe (MXIC)                        |
| **Restartfähigkeit**    | Zustand immer eindeutig, Resetverhalten modellierbar          |

→ Alle Abläufe müssen als **Zustandsautomat mit Zone-Logik** formulierbar sein

***

### 🔷 4. **Systemaufbau / CE-relevante Struktur**

| Bereich                      | Anforderungen                                        |
| ---------------------------- | ---------------------------------------------------- |
| **Betriebsartenumschaltung** | modelliert, abgesichert (Schlüssel, Freigabe)        |
| **Wiederanlauf / Reset**     | nur unter dokumentierten Bedingungen möglich         |
| **Schnittstellenverhalten**  | Signalisiert: Fehler, Status, Freigabe, EOC etc.     |
| **Safety-Zonen / CMZ**       | logisch geprüft, dokumentiert, HMI-geführt           |
| **Parameterführung**         | normierte Datentypen, fest definierte Schnittstellen |

→ Das System muss **prüfbar, durchsimulierbar, rückführbar** auf modellierte Logik sein

***

### 🔷 5. **Qualitätsanforderungen für formale Umsetzung mit Selmo**

| Thema                             | Muss gewährleistet sein                                 |
| --------------------------------- | ------------------------------------------------------- |
| Eindeutige Signalbezeichnung      | `Zone = IO = Klemme = Funktion`                         |
| Vollständige Sensorik             | Jeder Zustand ist prüfbar (kein „Glaube an Bewegungen“) |
| Modulare Funktionsaufteilung      | SEQ für jede logische Teilfunktion                      |
| Technisch überprüfbare Logik      | jeder Zustand + jede Zone muss **validierbar** sein     |
| Rückverfolgbarkeit (Traceability) | vom Modell über Code bis zur Doku                       |

***

### 📦 Ergebnis: Projekt ist **formalisierbar**, **dokumentierbar** und **CE-konform umsetzbar**, wenn:

#### ✅ Die Technologie:

* **ausreichend digitalisiert** ist (Ein-/Ausgänge, sicherheitsbewertet)

#### ✅ Der Engineeringaufbau:

* **modellbasiert abgebildet werden kann** (keine versteckten Seiteneffekte)

#### ✅ Der Prozess:

* **logisch beschreibbar** ist (Zustände, Bedingungen, Sicherheit, Reset)

#### ✅ Die Struktur:

* **klar trennbar und nachvollziehbar** ist (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-dokumentation-der-logik/ziel-eine-formal-korrekte-sichere-durchgangige-realisierung-der-maschine.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.