> 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/8-diagnose-hmi-and-dokumentation/automatische-diagnose.md). # Automatische Diagnose ### Transparenz durch das Modell Dieses Kapitel beschreibt, **wie Diagnose in Selmo entsteht**\ und warum sie **keine zusätzliche Programmierung** benötigt. Diagnose ist in Selmo: * kein nachträgliches Feature * keine Sammlung von Fehlermeldungen * keine UI-Logik Sondern: > **Die sichtbare Abweichung zwischen modelliertem Soll-Verhalten**\ > **und realem Ist-Zustand.** *** ### Wo Meldungen entstehen Diagnose entsteht **ausschließlich im Modell**. Konkret an der Stelle, an der: * ein **Zustand** aktiv ist * eine **Zone** in diesem Zustand eine Bedeutung hat * eine **Erwartung oder Bedingung** verletzt wird Typische Quellen von Diagnose sind: * `S`-Zonen, deren erwartetes Verhalten nicht erfüllt wird * `i`-Zonen, deren Bedingung verletzt ist * CMZ, deren permanente Bedingung nicht erfüllt ist * Plausibilitätschecks (z. B. Pair-Check) > **Jede Diagnose hat einen klaren Modellursprung.** Es gibt keine Meldungen: * ohne Zone * ohne Zustand * ohne definierte Erwartung *** ### Warum keine extra Programmierung nötig ist In klassischen Systemen wird Diagnose oft: * manuell programmiert * an vielen Stellen dupliziert * vom eigentlichen Ablauf getrennt In Selmo ist das nicht notwendig, weil: * Verhalten explizit modelliert ist * Erwartungen eindeutig beschrieben sind * Überwachung integraler Bestandteil des Modells ist Das Modell enthält bereits: * was erwartet wird * wann es erwartet wird * wie bei Abweichung reagiert wird > **Wenn das Verhalten beschrieben ist,**\ > **ergibt sich die Diagnose zwangsläufig.** Es gibt daher: * keine zusätzlichen Fehlerabfragen * keine „if error then message“-Logik * keine manuell gepflegten Meldungstexte *** ### Zusammenhang Zone ↔ Meldung Die **Zone** ist die kleinste diagnostizierbare Einheit in Selmo. Jede Zone besitzt: * eine eindeutige Bedeutung * einen klaren Kontext (Sequence & Zustand) * einen definierten HMI-Text Wenn eine Abweichung auftritt: * wird genau diese Zone identifiziert * wird genau dieser Kontext angezeigt * wird genau diese Erwartung benannt Die Meldung beantwortet damit: * **Welche Zone** ist betroffen? * **In welchem Zustand**? * **Welche Bedingung** ist verletzt? > **Die Diagnose erklärt nicht nur *****dass***** etwas falsch ist,**\ > **sondern *****warum***** der Ablauf nicht fortgesetzt werden kann.** *** ### Determinismus der Diagnose Da Diagnose aus dem Modell entsteht, ist sie: * deterministisch * reproduzierbar * nicht interpretationsabhängig Gleiche Situation bedeutet: * gleiche Meldung * gleiche Ursache * gleiche Reaktion Das gilt: * im Automatikbetrieb * im Handbetrieb * während Inbetriebnahme * bei Wiederanlauf *** ### Abgrenzung zu klassischen Fehlermeldungen Zur Klarstellung: * Diagnose ≠ SPS-Fehlerbit * Diagnose ≠ Sammelstörung * Diagnose ≠ UI-Text * Diagnose ≠ Bedienerinterpretation Diagnose ist: > **Modellbasierte Transparenz über Abweichungen.** *** ### Nutzen der automatischen Diagnose Durch automatische Diagnose wird: * Fehlersuche schneller * Inbetriebnahme sicherer * Betrieb nachvollziehbarer * Dokumentation konsistent * Verantwortung begründbar > **Transparenz entsteht nicht durch mehr Meldungen,**\ > **sondern durch richtige Meldungen.** *** ### Zusammenfassung Automatische Diagnose in Selmo: * entsteht direkt aus dem Modell * benötigt keine Zusatzprogrammierung * ist eindeutig Zone und Zustand zugeordnet * bleibt in allen Betriebsarten gleich > **Wenn das Modell stimmt,**\ > **stimmt auch die Diagnose.** --- # 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/8-diagnose-hmi-and-dokumentation/automatische-diagnose.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.