> 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-documentation/4-struktur-der-maschine-statisch/zone.md). # Zone **Ziel:** Verbindung zur realen Technik\ **Inhalt:** * Zonentypen (Input, Output, In-Out, Mem) * Signalzuordnung * HMI-Texte * Diagnosefähigkeit ### 1. Warum gibt es Zonen? In klassischen Steuerungsprojekten werden Signale direkt im Code verwendet.\ Ihre Bedeutung entsteht implizit durch Logik, Kommentare oder Erfahrung. Das führt zu typischen Problemen: * Signale sind kontextlos * Bedeutung ändert sich je nach Stelle im Code * Diagnose ist unscharf oder manuell * Sicherheits- und Ablaufaspekte vermischen sich **Die Zone existiert, um Signalen Bedeutung, Verantwortung und Kontext zu geben.** *** ### 2. Was ist eine Zone? Eine **Zone** ist die **formale Repräsentation eines technischen Sachverhalts** innerhalb einer Sequence. Eine Zone: * kapselt ein oder mehrere Signale * verleiht ihnen **funktionale Bedeutung** * ist im Kontext **einer konkreten Sequence** definiert * ist eindeutig diagnostizierbar > **Alles, was in einer Sequence verwendet wird, muss eine Zone sein.** Eine Zone ist **nicht**: * nur ein Eingang * nur ein Ausgang * nur ein Speicherbit Sie ist **Bedeutung + Verhalten + Diagnose**. *** ### 3. Einordnung im Selmo-Gesamtmodell Die Zone ist das Bindeglied zwischen Logik und realer Technik: * **Sequence** – beschreibt *was* passieren soll * **Zone** – beschreibt *womit* es passiert * **Signal** – ist die physikalische Umsetzung Zonen existieren **nicht global**, sondern immer: * innerhalb einer Sequence * mit klarer funktionaler Rolle *** ### 4. Zonentypen Selmo unterscheidet vier grundlegende Zonentypen: #### Input-Zone * repräsentiert reine Rückmeldungen * z. B. Sensoren, Taster, Statussignale * keine aktive Beeinflussung *** #### Output-Zone * repräsentiert reine Aktionen * z. B. Ventile, Lampen, Motorfreigaben * keine Rückmeldung im Modell *** #### In-Out-Zone * kombiniert Aktion und Rückmeldung * z. B. Zylinder, Achsen, Greifer * typische Quelle für Ablaufüberwachung *** #### Mem-Zone * rein logischer Speicher * keine physikalische Entsprechung * speichert Zustands- oder Ablaufinformationen > Der Zonentyp definiert **Struktur**, nicht Verhalten. *** ### 5. Zone und Signalzuordnung Eine Zone wird mit realen Signalen verknüpft: * Eingänge * Ausgänge * oder beides Dabei gilt: * eine Zone kann mehrere Signale enthalten * eine Zone ist **keine SPS-Adresse** * Signale können ausgetauscht werden, ohne das Modell zu ändern **Die Zone ist stabil – die Technik ist austauschbar.** *** ### 6. Zone im System-Layer (Bit-Control-Kontext) Das Verhalten einer Zone wird **nicht im Code**, sondern im **System-Layer** festgelegt. Für jeden Zustand der Sequence wird definiert: * ob die Zone relevant ist * welches Verhalten erwartet wird * welche Abweichungen erlaubt sind Dies geschieht über Bit-Control-Operanden (`0`, `S`, `i`). > **Zone + Zustand + Operand = Verhaltensvertrag** Die vollständige Bedeutung der Operanden ist im Kapitel **Bit-Control** beschrieben. *** ### 7. Verhalten einer Zone im Betrieb Eine Zone ist zu jedem Zeitpunkt: * bewertbar * überwachbar * diagnostizierbar Abhängig vom gesetzten Operanden: * `S` → erwartetes Verhalten / Führung * `i` → zwingende Bedingung / Schutz * `0` → keine Bedeutung im aktuellen Zustand Eine Zone kennt keinen „Debug-Zustand“ und keinen Sondermodus. *** ### 8. Zone im Handbetrieb Im Handbetrieb zeigt die Zone unmittelbar ihren Zustand: * **blau** → Zone erfüllt die Erwartung des aktuellen Zustands * **rot** → Zone weicht vom erwarteten Verhalten ab Der Bediener erkennt: * welche Zone relevant ist * warum ein Zustand nicht erfüllt ist * wo gezielt eingegriffen werden muss > Der Bediener arbeitet **nicht an Aktoren**,\ > sondern an der **Erfüllung von Zonenbedingungen**. *** ### 9. Sicherheitsfunktionen auf Zonenebene Zonen sind Träger von Sicherheits- und Überwachungsfunktionen: * **Interlock (`i`)**\ zustandsabhängige Ablaufüberwachung * **CMZ (Constantly Monitoring Zone)**\ zustandsunabhängige, permanente Überwachung * **Pair-Check**\ Überwachung widersprüchlicher Signalzustände * weitere Plausibilitätsprüfungen (z. B. Bear-Check) > Sicherheit ist eine **Eigenschaft der Zone**, nicht des Codes. *** ### 10. Zone und Diagnose Jede Zone besitzt: * einen klaren HMI-Text * eine eindeutige Bedeutung * einen definierbaren Diagnosegrund Diagnose entsteht automatisch: * aus dem aktuellen Zustand * aus dem erwarteten Verhalten * aus der tatsächlichen Signalrückmeldung Es gibt **keine Diagnose ohne Zonenursache**. *** ### 11. Abgrenzung zu anderen Elementen Zur Klarstellung: * Eine **Zone** ist **keine Sequence**\ → sie beschreibt keinen Ablauf * Eine **Zone** ist **kein Signal**\ → sie verleiht Signalen Bedeutung * Eine **Zone** ist **keine Hardware-Zone**\ → sie kapselt keine Betriebsarten * Eine **Zone** ist **keine Sicherheitssteuerung**\ → sie modelliert Überwachung, ersetzt aber keine Hardware-Sicherheit *** ### 12. Typische Modellierungsfehler bei Zonen Häufige Fehler sind: * Signale ohne Zone * Sammelzonen ohne klare Bedeutung * technische statt funktionale Zonen * Sicherheitslogik außerhalb der Zone * gleiche Zone für unterschiedliche Aufgaben Eine gute Faustregel: > **Wenn eine Zone nicht erklärbar ist, ist sie falsch modelliert.** *** ### 13. Zusammenfassung Eine Zone ist: * die kleinste bedeutungstragende Einheit in Selmo * die Verbindung zwischen Logik und Technik * vollständig überwachbar und diagnostizierbar * Grundlage für sicheren Betrieb und klare Bedienung > **Ohne Zonen gibt es keine erklärbare Maschine.** --- # 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-documentation/4-struktur-der-maschine-statisch/zone.md?ask=&goal= ``` `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.