> 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/8-diagnosis-hmi-and-documentation.md). # 8 Diagnosis, HMI & documentation ### 1. The fundamental problem of classical diagnosis In many automation projects diagnosis is created: * afterwards * manually * detached from the process * inconsistent across projects Typical symptoms: * aggregate alarms without cause * messages without context * wrong time, wrong place * high maintenance effort The core of the problem: > **If behavior is not modeled explicitly, diagnosis can only be guessed.** *** ### 2. Basic principle of Selmo diagnosis In Selmo diagnosis is **not an addition**but a **consequence of the model**. Diagnosis arises because: * states are defined explicitly * zones carry meaning * expectations are described formally * monitoring is continuous > **Every diagnosis is the deviation between expected and actual states in the model.** There are: * no heuristic error detection * no manual "if error then message" logic *** ### 3. Sources of diagnosis in the model Diagnosis arises exclusively from modeled elements: * **Zone** * carries meaning * knows its signals * has HMI text * **Bit-Control** * defines expectation (`S`) * defines mandatory conditions (`i`) * **CMZ** * monitors continuously * acts independently of state > **Without a model cause there is no diagnosis.** *** ### 4. Diagnosis in automatic operation In automatic operation applies: #### 4.1 Interlock deviation (`i`) * immediate withdrawal of automatic release * stop of the affected sequence * automatic diagnosis with: * zone reference * state reference * clear cause #### 4.2 CMZ deviation * hierarchical stop: * Sequence * hardware zone * or Plant * no movement possible anymore * unambiguous, non-aggregated message > **The diagnosis knows time, place and cause.** *** ### 5. Diagnosis in manual operation In manual operation diagnosis is **active guidance**not an error message. Properties: * zones show their status directly * deviations are highlighted visually * the operator recognizes: * what is missing * where intervention is required > **Diagnosis in manual operation does not answer "What is broken?",**\ > **but "What is missing to satisfy the state?"** *** ### 6. HMI as a model view The HMI in Selmo is **not a logic instance**. The HMI: * decides nothing * evaluates nothing * controls nothing autonomously It shows: * active sequences * current states * relevant zones * expectations and deviations > **The HMI is a project-specific view of the same model.** *** ### 7. Uniform HMI semantics From the model automatically results: * uniform colors * uniform meanings * uniform reactions Examples: * Blue → state / zone fulfilled * Red → deviation from expected behavior This semantics is: * the same across projects * independent of UI design * independent of target systems *** ### 8. Documentation arises from the model The Selmo model already contains: * process (sequences, states) * technical reference (zones) * monitoring (bit control, CMZ) * reactions (stop, release, diagnosis) Derivable from this are: * process descriptions * state diagrams * safety argumentations * operation concepts * diagnosis descriptions > **Documentation is not a separate activity,**\ > **but a view of the model.** *** ### 9. Significance for standards & traceability Through the formal model it is always traceable: * which state was active * which expectations applied * which deviation occurred * which reaction followed This is crucial for: * functional safety * auditability * liability issues * argumentation for AI-generated code > **What is modeled is explainable.**\ > **What is explainable is accountable.** *** ### 10. Delimitation To clarify: * Diagnosis ≠ UI logic * Diagnosis ≠ PLC error bit * Diagnosis ≠ safety function * Diagnosis ≠ user interpretation Diagnosis is **model-based state deviation**. *** ### 11. Typical errors in diagnosis & HMI Common mistakes are: * aggregate messages without cause * UI-specific logic * diagnosis outside the model * duplicate error logic in code and HMI * different meanings of the same colors Rule of thumb: > **If a message has to be explained, model information is missing.** *** ### 12. Summary Diagnosis, HMI and documentation in Selmo are: * not additional functions * not separate disciplines * not project-specific special solutions They are: * direct consequences of the model * consistent, deterministic and traceable * Basis for safe, explainable machines > **Selmo does not document machines –**\ > **Selmo makes machines explainable.** --- # 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/8-diagnosis-hmi-and-documentation.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.