> 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-as-a-process/selmo-prozessmodellierung/sipoc-prozessmodellierung.md). # SIPOC Prozessmodellierung **Zweck:**\ Erklärung, warum die Prozessmodellierung ein eigenständiger, formaler und notwendiger Bestandteil des Projekts ist. **Kernaussagen:** * Die Prozessmodellierung folgt dem PTF und setzt ihn technisch um. * Sie erzeugt deterministische, dokumentierte und prüfbare Abläufe. * Sie ist gleichwertig mit CAD (Mechanik) und EPLAN (Elektro). * Das Modell ersetzt keine Fachdisziplin, sondern integriert sie. * Ziel: Ein formales, vollständig nachvollziehbares Maschinenverhalten. ## Einbettung der Prozessmodellierung in den gesamten Projektverlauf. **Kernpunkte:** * Nach PTF-Freigabe beginnt die formale Umsetzung. * Prozessmodellierung ersetzt unstrukturierte Programmierung. * Verbindung zu Mechanik & Elektro (wie Zeichnung/Schaltplan). * Vorbereitung auf Digital Twin und Inbetriebnahme. * Frühzeitige Simulation (SoftFAT) möglich. * Nutzen: Früh erkennbare Fehler, reduzierte Inbetriebnahmezeiten. **Grafischer Ablauf:**\ PTF → Modellierung → Simulation → Codegenerierung → Inbetriebnahme → Betrieb
🧩 SIPOC – Prozessmodellierung in Selmo Supplier #### **S – Supplier (Lieferanten der Prozessmodellierung)** **Definition:**\ Supplier im Prozessmodellierungs-Prozess sind alle Personen, Rollen oder Systeme,\ die **Informationen, Daten, Modelle oder Entscheidungen** bereitstellen,\ um das **formale Selmo-Prozessmodell** zu erstellen. Sie liefern die inhaltliche, technische und organisatorische Grundlage,\ damit das Modell vollständig, deterministisch und Selmo-konform aufgebaut werden kann. *** #### **1. Haupt-Supplier der Prozessmodellierung** | Kategorie | Rolle / Funktion | Liefert | Beschreibung / Bedeutung | | ------------------------------------------------------- | ---------------------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **1. PTF-Lead / Projektleitung** | Verantwortlicher für die PTF-Ergebnisse | Vollständigen PTF-Datensatz (Process, Technology, Function, Risk) | Liefert das freigegebene Fundament – der PTF ist der *Startpunkt* der Modellierung | | **2. Prozessverantwortlicher (Industrial Engineering)** | Prozesswissen & Parameterdefinition | Prozessbeschreibung (Zustände, Takt, Parameter) | Definiert den realen Prozessablauf, der im Modell nachgebildet wird | | **3. Mechanik / Konstruktion** | Layout, Kinematik, Endlagen, Komponenten | Strukturinformationen (Zonen, Hardware-Zuordnung) | Liefert die logische Abbildung der physischen Maschine | | **4. Elektro / Steuerung (E-Plan)** | Sensoren, Aktoren, Adressierung | Signalstruktur (Inputs, Outputs, CMZ-Level) | Grundlage für die Erstellung der Zonen und deren Bit-Control | | **5. Automation / Software (Selmo-Modellierer)** | Modellierer des Prozessverhaltens | Modelllogik, Zustände, Verknüpfungen | Erstellt das deterministische Prozessmodell aus PTF und Hardwarestruktur | | **6. IT / OT / MES / ERP** | Schnittstellen- und Datenflüsse | Kommunikationsdefinition (Tags, Topics, Payloads) | Sicherstellt, dass das Modell mit Systemen kommuniziert | | **7. Qualität / Sicherheit / CE** | Normen, Sicherheitsanforderungen, Prüfregeln | CMZ-, MXIC-, Interlock-Anforderungen | Definiert sicherheitsrelevante Logik für Sequence- und Hardware-Zonen | | **8. Kunde / Betreiber** | Prozessziel, Funktionsanforderung, Bedienlogik | Funktionsbeschreibung & HMI-Anforderungen | Liefert Anforderungen an Verhalten und Bedienerführung | *** #### **2. Unterstützende / sekundäre Supplier** | Rolle | Liefert | Zweck | | ---------------------------------- | ---------------------------------- | -------------------------------------------- | | **Datenmanagement / IT** | Versionsverwaltung, Strukturierung | Verwaltung der Modellstände | | **Projektmanagement** | Terminplanung, Reviewzyklen | Koordination des Modellierungsprozesses | | **Simulation / Digital Twin Team** | Simulationsmodell (für SoftFAT) | Validierung der Prozesslogik vor Realbetrieb | | **Instandhaltung / Betrieb** | Bedien- und Diagnoseanforderungen | Rückmeldungen für HMI und Funktionsanzeigen | *** #### **3. Artefakte, die Supplier bereitstellen müssen** | Artefakt | Beschreibung | Quelle (Supplier) | | ------------------------------------------------ | --------------------------------------------------------------------------------- | ---------------------- | | **PTF-XML / JSON** | Vollständige, freigegebene Datengrundlage aus PTF (Process, Technology, Function) | PTF-Lead | | **I/O-Liste (CSV / EPLAN)** | Adressierung und Signalstruktur | Elektro | | **Technologiematrix (Excel / PDF)** | Übersicht der eingesetzten Geräte und Schnittstellen | Mechanik / Elektro | | **Funktionsblätter (XML / PDF)** | Funktionsdefinitionen, Trigger, Testfälle | Automation | | **Parameterliste (CSV)** | Prozessparameter mit Grenzwerten | Prozess / Qualität | | **Risikobewertung (Excel / PDF)** | Dokumentierte Nicht-Selmo-Konformitäten | Qualität | | **Sicherheitskonzept (CMZ / MXIC / Interlocks)** | Struktur und Sicherheitslogik | CE / Sicherheit | | **Schnittstellenbeschreibung (JSON / YAML)** | MES-, ERP-, Cloud- oder Roboterverbindungen | IT / OT | | **HMI-Template (CSV)** | Texte, Farben, Diagnosen | Betreiber / Automation | *** #### **4. Qualitätskriterien für Supplier-Daten** Jede Supplier-Lieferung für die Modellierung muss: * **formell freigegeben** sein (Status: *Released* im PTF) * **vollständig** sein (keine offenen Parameter, Adressen oder Zustände) * **konsistent** sein (Prozesszustände ↔ Hardware ↔ Funktionen) * **deterministisch** definiert sein (keine Mehrdeutigkeit in Logik oder Signalverhalten) * **normenkonform** sein (ISO 12100, IEC 62061, MVO 2027) * **maschinenlesbar** vorliegen (z. B. XML, JSON, CSV) *** #### **5. Prüffragen für die Supplier-Freigabe** Vor Beginn der Prozessmodellierung muss der PTF-Lead sicherstellen: * [ ] Liegt der **freigegebene PTF-Report** vor? * [ ] Sind alle **Funktionen mathematisch oder logisch beschrieben**? * [ ] Ist die **I/O-Liste vollständig und eindeutig** adressiert? * [ ] Wurden **Sicherheitsfunktionen (CMZ, MXIC, Interlocks)** dokumentiert? * [ ] Sind **Schnittstellen (MES, ERP, Robotik)** technisch spezifiziert? * [ ] Sind alle **Prozessparameter und Zustände** mit Grenzwerten versehen? * [ ] Gibt es **keine offenen Risikopunkte** ohne Maßnahmenplan? * [ ] Wurde der **Import-Test in Selmo-Studio** erfolgreich validiert (Daten lesbar)? *** #### **6. Fazit – Rolle der Supplier in der Prozessmodellierung** Die Supplier stellen die **gesamte Informationsbasis** für die Modellierung bereit.\ Der Modellierer (Automation) **erstellt keine eigenen Annahmen**,\ sondern arbeitet ausschließlich mit **formalen, freigegebenen Daten aus dem PTF und Engineering**. > Der PTF ist der Bauplan,\ > die Supplier sind die Materiallieferanten,\ > und der Selmo-Modellierer baut daraus das funktionierende, deterministische System.
🧩 SIPOC – Prozessmodellierung in Selmo Input #### **I – Input (Eingaben für die Prozessmodellierung)** *** #### **1. Definition** **Input** bezeichnet alle **technischen, logischen und dokumentierten Informationen**,\ die benötigt werden, um im Selmo Studio ein **vollständiges, deterministisches Prozessmodell** zu erstellen. Jeder Input ist ein **Element der Modellstruktur**, das direkt oder indirekt aus dem **freigegebenen PTF** stammt.\ Die Inputs bilden die Grundlage für: * Aufbau der logischen Struktur (Plant / HWZ / SEQ / Zone), * Definition der Zustände, Parameter und Signale, * automatische Generierung von Steuerungscode, HMI und Diagnosefunktionen. *** #### **2. Haupt-Inputs für die Prozessmodellierung** | Kategorie | Beschreibung | Quelle (aus PTF / Supplier) | Verwendung im Modell | | ----------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------- | | **1. Strukturdefinition** | Hierarchie der Maschine (Plant → Hardware-Zonen → Sequences → Zonen) | PTF-SCOPE, PTF-TECH, Mechanik / Projektleitung | Legt die Projektstruktur, Verantwortlichkeiten und Systemgrenzen fest | | **2. Signaldefinition (I/O-Liste)** | Liste aller Ein-, Aus- und InOut-Signale mit CMZ-Level | PTF-IO, Elektro / Steuerung | Erzeugt Zonen, Signaltypen und Überwachungsregeln im System-Layer | | **3. Bit-Control-Zuordnung** | Logische Beziehung zwischen Zustand und Signal | PTF-FUNC, Automation / Software | Steuer- und Überwachungstabellen im System-Layer (0, i, S) | | **4. CMZ-Konfiguration** | Constantly Monitoring Zones für Plant, HWZ, SEQ | PTF-SAFE, Qualität / Sicherheit | Definiert permanente Signalüberwachung und Sicherheitslogik | | **5. MXIC-Konfiguration** | Manual Cross Interlock – Verriegelungsbedingungen im Handbetrieb | PTF-SAFE, Sicherheit / Automation | Sicherheit im Handbetrieb: erlaubt / blockiert manuelle Aktionen | | **6. Parameterdefinition** | Prozessparameter mit Einheiten, Grenzen und Defaultwerten | PTF-PARAM, Prozess / Qualität | Ergänzt den Parameter-Layer in jeder Sequence | | **7. HMI-Daten** | Texte, Farben, Diagnosen, Meldungen für Zustände und Zonen | PTF-HMI, Instandhaltung / Automation | Anzeigeebene im HMI-Generator (automatisch aus Modell generiert) | | **8. Funktionsdefinition** | Mathematische / logische Funktionen für Aktionen oder Überwachung | PTF-FUNC, Automation / Software | Verknüpft Ablauflogik mit konkretem Verhalten (z. B. Addierer, Timer) | | **9. Schnittstellenbeschreibung** | MES/ERP/Robotik/Cloud-Verbindungen, Variablen und Datentypen | PTF-IF, IT / OT | Integration von Datenebene, übergeordnete Kommunikation | | **10. Risikobewertung / Normen** | Abweichungen, Normanforderungen, PLr/SIL-Nachweise | PTF-RISK, PTF-NORM, Qualität / CE | Dokumentation von Einschränkungen, Warnungen, Maßnahmen im Modell | *** #### **3. Struktur-Input im Detail (Rückwärts aus dem Selmo Studio)** **Plant (Anlagenebene)** * Definition: gesamte Maschine / Linie * Enthält: * Plant-Name, Identifikation, Version * CMZ-Definition (Total Safety Watch) * übergreifende Schnittstellen (MES, ERP, SCADA) * Gesamtparameter (z. B. Taktzeit, Hauptsteuerung, Energieversorgung) * Quelle: PTF-SCOPE, PTF-SAFE, PTF-IF **Hardware-Zone (HWZ)** * Definition: physischer Anlagenteil, eigenständig steuerbar * Enthält: * Betriebsarten (Hand / Automatik) * Safety-Logik (zonenbezogene CMZs) * Start- / Stop-Logik * Zonenstruktur (Sequences, Sensorik, Aktorik) * Quelle: PTF-TECH, PTF-IO, PTF-SAFE **Sequence (SEQ)** * Definition: logischer Ablauf eines Prozesses (z. B. „Einlegen“, „Spannen“, „Bearbeiten“) * Enthält: * Zustände (State, Timer-State, Decision, Jump etc.) * Verknüpfungen (Transitionen) * System-Layer (Bit-Control) * Parameter-Layer (Zeiten, Werte) * CMZ- / MXIC-Einstellungen * Zonen- und Signalzuordnung * Quelle: PTF-PROC, PTF-FUNC, PTF-SAFE, PTF-HMI **Zone** * Definition: kleinste Einheit – mechatronische Funktion (Sensor, Aktor, InOut oder Speicherzone) * Enthält: * Signalname, Typ (Input, Output, InOut, Mem) * Zonen-ID, Zonentext (HMI) * CMZ-Level, Interlock-Zuordnung * Operanten (0, i, S) für jedes State in Bit-Control * Quelle: PTF-IO, PTF-FUNC, Elektro *** #### **4. Layer-bezogene Inputs** | Layer | Inhalt | Datenquelle | Beschreibung | | ------------------------------ | -------------------------------------------- | ----------------- | --------------------------------------------------- | | **Logic-Layer** | Zustände, Übergänge, logische Entscheidungen | PTF-PROC | bildet den logischen Ablauf | | **System-Layer (Bit-Control)** | Signalverhalten je Zustand (0, i, S) | PTF-FUNC / PTF-IO | beschreibt das Verhalten im Automatikmodus | | **Parameter-Layer** | Prozessparameter, Einstellwerte | PTF-PARAM | ergänzt modellierte Abläufe mit Variablen | | **HMI-Layer** | Texte, Farben, Meldungen | PTF-HMI | für Bedienerführung und Diagnose | | **Safety-Layer (CMZ / MXIC)** | Sicherheitslogik | PTF-SAFE | sorgt für sicheres Verhalten in allen Betriebsarten | *** #### **5. Strukturrelevante Inputs für das Projektmanagement** Die Modellstruktur ist nicht nur ein technisches Element,\ sondern dient auch als **Projektstrukturplan (PSP)** für Aufgaben, Verantwortungen und Fortschritte: | Struktur-Ebene | Bedeutung im Projektmanagement | Nutzen | | -------------- | ------------------------------ | -------------------------------------- | | **Plant** | Projekt oder Gesamtanlage | Top-Level Struktur, Gesamtstatus | | **HWZ** | Arbeitspaket oder Station | Fortschritts- und Statusverfolgung | | **SEQ** | Teilprozess / Funktionsmodul | Planbare Implementierungseinheit | | **Zone** | Komponente / Signalebene | Verantwortungszuweisung, Detailprüfung | So kann jede **Sequence** als **eigenständiges Projektobjekt** behandelt werden –\ mit klar definierten Inputs, Outputs, Verantwortlichen und Testfällen.\ Das erleichtert **Ressourcenplanung, Fortschrittsverfolgung und SoftFAT-Organisation.** *** #### **6. Technische Input-Formate (Empfehlung)** | Typ | Format | Nutzung | | ------------------------------- | ------------------ | -------------------------------- | | **Struktur- und Modelldaten** | XML / JSON | Import in Selmo Studio | | **I/O-Daten** | CSV / EPLAN-Export | Signal-Import und Zonenaufbau | | **Parameterdaten** | CSV / Excel | Parameter-Layer und Defaultwerte | | **Funktionsdefinitionen** | XML / PDF | Funktionslogik und Überwachung | | **Sicherheitsdaten (CMZ/MXIC)** | Excel / JSON | Sicherheits-Layer | | **HMI-Texte** | CSV / JSON | HMI-Generator | | **Normen / Risiko** | PDF / Excel | Dokumentation & Audittrail | *** #### **7. Prüf- und Qualitätskriterien für Inputs** Vor Beginn der Modellierung muss der PTF-Lead bestätigen: * [ ] Strukturdefinition vollständig (Plant, HWZ, SEQ, Zone) * [ ] I/O-Liste vollständig und eindeutig (keine Duplikate) * [ ] CMZ- und MXIC-Definition vorhanden * [ ] Parameter vollständig (Einheit, Grenze, Defaultwert) * [ ] Funktionsblätter vollständig (Trigger, Testfälle, Überwachung) * [ ] HMI-Texte korrekt zugeordnet (Zone/State) * [ ] Schnittstellen zu MES/ERP dokumentiert * [ ] Risiko- und Normenbewertung abgeschlossen * [ ] Alle Daten maschinenlesbar und versioniert * [ ] Import-Test in Selmo Studio erfolgreich (keine Datenfehler) *** #### **8. Fazit** Der **Input** für die Prozessmodellierung ist kein unstrukturierter Datenpool,\ sondern ein **klar definierter, hierarchisch aufgebauter Informationssatz**,\ der sich direkt in das **Selmo Studio** übertragen lässt. Er enthält alles, was notwendig ist, um: * die Maschine logisch zu beschreiben, * deterministisch zu steuern, * und automatisch zu dokumentieren. > **Ohne saubere Inputs kein deterministisches Modell.**\ > Der Input ist die Übersetzung des PTF in formale, modellierbare Daten –\ > strukturiert, nachvollziehbar und prüfbar.
🧩 SIPOC – Prozessmodellierung in Selmo Process #### **P – Process (Ablauf der Modellierung)** *** #### **1. Ziel des Modellierungsprozesses** Der Modellierungsprozess dient der **Erstellung des vollständigen, deterministischen Prozessmodells** auf Basis des freigegebenen PTF.\ Er definiert die Maschine in ihrer Struktur, Logik, Sicherheit und Bedienung so präzise,\ dass daraus automatisch **fehlerfreier Steuerungscode, HMI und Diagnose** erzeugt werden können. Das Modell ist **die formale Beschreibung des Maschinenverhaltens** —\ gleichwertig zur technischen Zeichnung oder zum Schaltplan in Mechanik und Elektro. *** #### **2. Grundprinzipien der Selmo-Modellierung** * **Modularität:** Jede Sequence (SEQ) ist ein in sich geschlossener Funktionsblock. * **Determinismus:** Jeder Zustand und jedes Signal sind eindeutig definiert. * **Hierarchie:** Die Struktur folgt der realen Maschine (Plant → HWZ → SEQ → Zone). * **Vollständigkeit:** Jeder Signalzustand ist in jedem Zustand definiert (0, i, S oder M). * **Trennung von Hand- und Automatikbetrieb:** * **System- und Logic-Layer** → Automatik * **MXIC** → Handbetrieb * **Nachvollziehbarkeit:** Alle Zonen, Signale, Parameter und Sicherheitsfunktionen sind dokumentiert. * **Automatisierbarkeit:** Das Modell erzeugt direkt lauffähigen Code und HMI. *** #### **3. Phasen des Modellierungsprozesses** | Phase | Ziel | Ergebnis | | ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------- | | **1. Strukturaufbau** | Grundstruktur (Plant, HWZ, SEQ, Zone) anlegen | Maschinenhierarchie vollständig definiert | | **2. System-Layer definieren** | Zonen und Signale den Zuständen zuordnen (Bit-Control) | Logische Signalverhalten definiert | | **3. Logik-Layer aufbauen** | Ablauf der Sequence modellieren (States, Transitions) | Vollständiger Prozessfluss mit Zustandsdefinition | | **4. Parameter-Layer ergänzen** | Nicht-binäre Prozessgrößen definieren (Zeiten, Werte, Toleranzen) | Parametrierbarer Ablauf | | **5. CMZ definieren** | Permanent überwachte Signale (Plant, HWZ, SEQ) | Sicherheitslogik aktiv | | **6. MXIC anlegen** | Handbetriebsverriegelungen festlegen | Sicherer manueller Betrieb | | **7. SEQCross modellieren** | Synchronisation und Abhängigkeiten zwischen Sequenzen definieren | Koordinierte Abläufe | | **8. Test & Simulation** | Logik-, System- und Sicherheitsfunktionen prüfen | Verifiziertes Prozessmodell | | **9. Output generieren** | PLC-Code, HMI und Dokumentation erzeugen | Freigegebener Modell-Output | *** #### **4. Schritt-für-Schritt Ablauf** **Schritt 1 – Strukturaufbau** * Im Selmo Studio wird das Projekt angelegt. * Aufbau der Hierarchie: * **Plant** (gesamte Anlage) * **Hardware-Zonen (HWZ)** (Stationen, Module) * **Sequences (SEQ)** (Funktionsabläufe) * **Zonen** (Sensoren, Aktoren, InOuts, Mems) * Jede SEQ erhält: * eindeutige ID und Beschreibung * zugewiesene Zonen (Signale) * definierten CMZ-Level ➡️ Ergebnis: **Struktur vollständig und abbildbar** (Plant → HWZ → SEQ → Zone) *** **Schritt 2 – System-Layer definieren** * Erstellung der **Bit-Control-Tabelle**: * Zuordnung von Zonen zu Zuständen mit den Operanten: * `0` → Don’t care / keine Aktion * `i` → Interlock (Überwachung) * `S` → Sequence-Check (erwartete Aktion oder Rückmeldung) * `M` → Mem / Speicherbit / Hilfsstatus * Alle Signale aus der I/O-Liste werden den Zonen zugeordnet. * Für jede Zone werden CMZ-Level und Typ (Input, Output, InOut, Mem) festgelegt. * Damit ist das **Verhalten der Anlage im Automatikbetrieb** formal beschrieben. ➡️ Ergebnis: **vollständiger System-Layer mit Bit-Control-Logik** *** **Schritt 3 – Logik-Layer aufbauen** * Definition der logischen Zustände (States): * Start, Timer-State, Decision, Jump, SequenceCross, Repeater * Abbildung des Prozessablaufs durch Zustandsübergänge (Transitions). * Verknüpfung mit System-Layer über Bit-Control. * Modellierung des Standardverhaltens: Start → Ablauf → Ende → Wiederholungen / Abbrüche. * Sicherstellen, dass jeder Zustand: * eindeutige Aktivitätsbedingungen hat, * Übergangsbedingungen erfüllt sind, * Abbruch- und Fehlerpfade definiert sind. ➡️ Ergebnis: **vollständiger deterministischer Ablauf pro Sequence** *** **Schritt 4 – Parameter-Layer ergänzen** * Parameter aus PTF-PARAM importieren. * Definition von Eingabe-, Anzeige- und Ausgangsparametern: * Zeiten, Geschwindigkeiten, Kräfte, Wege, Wiederholungen. * Parameter werden logisch den Sequenzen oder Zuständen zugeordnet. * Optional: Grenzüberwachung mit CMZ oder SEQ-Check. ➡️ Ergebnis: **parametrierbarer Ablauf mit klaren Grenzen und Variablen** *** **Schritt 5 – CMZ definieren (Constantly Monitoring Zone)** * Auswahl der Signale, die permanent überwacht werden müssen: * Plant-CMZ → Gesamtanlage (z. B. Hauptdruck, Energieversorgung) * HWZ-CMZ → Stationssicherheit (z. B. Schutztür, Verriegelung) * SEQ-CMZ → Prozessüberwachung (z. B. Sensorstatus, Not-OK-Bit) * CMZ-Fehler führt zu automatischer Deaktivierung der betroffenen Einheit. * Manuelle Bewegung ist während aktivem CMZ-Fehler gesperrt. ➡️ Ergebnis: **übergreifende Sicherheitsüberwachung aktiv** *** **Schritt 6 – MXIC anlegen (Manual Cross Interlock)** * Nach Abschluss des System-Layers: * Zonen-Tasten im Handbetrieb (MXIC-Tabelle) definieren * Bedingungen, unter denen manuelle Aktionen erlaubt sind, festlegen * MXIC prüft im Handbetrieb: * ob Sicherheitsbedingungen erfüllt sind * ob andere Bewegungen verriegelt sind * Bei Regelverletzung: Bewegung gesperrt, Diagnosemeldung aktiv. ➡️ Ergebnis: **sicherer, nachvollziehbarer Handbetrieb** *** **Schritt 7 – SEQCross modellieren** * Definiert **Synchronisation und Abhängigkeiten zwischen Sequenzen**. * Beispiel: * „Greifer schließen“ (SEQ 1) startet erst, wenn „Teileposition erreicht“ (SEQ 2) aktiv ist. * SEQCross sorgt für: * parallele oder abhängige Abläufe, * kontrollierte Übergaben, * modularen Systemaufbau. * Alle SEQCross-Logiken sind formal und deterministisch modelliert. ➡️ Ergebnis: **mehrere SEQs arbeiten sicher synchronisiert** *** **Schritt 8 – Test & Simulation** * Modellprüfung im Selmo Studio (Modell-Validator): * Zustände, Übergänge, Bit-Control-Konsistenz * CMZ/MXIC-Prüfung * logische Vollständigkeit * Verknüpfung mit Digital Twin (falls vorhanden): * SoftFAT / Simulation der Signalreaktionen * Integrationstests mit MES / ERP * Ausgabe der Prüflogs (OK / Fehler / Warnung). ➡️ Ergebnis: **verifiziertes, simulationsfähiges Modell** *** **Schritt 9 – Output generieren** * Automatische Generierung: * **PLC-Code** (IEC 61131-3, strukturierter Text) * **HMI-Daten** (Texte, Meldungen, Zustände) * **Diagnose- und Sicherheitslogik** * **Dokumentation** (Prozessablauf, Signalverhalten, CMZ/MXIC-Tabellen) * Alle Artefakte sind versioniert und rückverfolgbar zum Modellstand. ➡️ Ergebnis: **freigegebener, dokumentierter Modell-Output – bereit für Inbetriebnahme** *** #### **5. Qualitäts- und Reviewkriterien je Phase** Vor Übergang zur nächsten Phase gilt jeweils: * [ ] Alle relevanten Layer vollständig (Logic, System, Parameter, Safety, HMI) * [ ] Keine offenen CMZ/MXIC-Definitionen * [ ] SEQCross logisch korrekt und getestet * [ ] Automatik- und Handbetrieb geprüft * [ ] Import in Digital Twin erfolgreich (wenn vorhanden) * [ ] Modellexport erzeugt keine Fehler * [ ] Review-Dokumentation freigegeben *** #### **6. Ergebnis des Prozesses** Ein vollständiges **Selmo-Prozessmodell**, das: * alle Abläufe, Zustände, Parameter und Sicherheitslogiken enthält, * aus validierten PTF-Daten generiert wurde, * deterministisch, prüfbar und dokumentiert ist, * lauffähigen Code, HMI und Diagnose erzeugt, * und direkt in eine Simulation oder Inbetriebnahme überführt werden kann. > **Mit Logic, System und Bit-Control ist die Automatik definiert.**\ > **Mit MXIC und CMZ ist die Sicherheit gewährleistet.**\ > **Mit SEQCross wird die Maschine zum System.**
🧩 SIPOC – Prozessmodellierung in Selmo Output #### **O – Output (Ergebnisse der Modellierung)** *** #### **1. Ziel der Outputs** Die Outputs der Prozessmodellierung sind das **vollständige, deterministische Abbild der Maschine** –\ formal, nachvollziehbar, dokumentiert und ausführbar. Jeder Output ist **prüfbar**, **versioniert** und **rückverfolgbar** auf die Anforderungen aus dem PTF.\ Sie bilden die Grundlage für: * Code-Generierung, * Bedienung (HMI), * Inbetriebnahme, * Diagnose, * Service, * und Audits. *** #### **2. Übersicht der Outputs** | Nr. | Output | Beschreibung | Format / Medium | Hauptnutzer | | ------ | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------- | ---------------------------- | | **1** | **PLC-Code** | Automatisch generierter Steuerungscode aus dem Modell (IEC 61131-3, ST) | `.ST`, `.PLCopenXML` | SPS / Automation | | **2** | **HMI-Projekt** | Automatisch erzeugte Bedienoberfläche – basierend auf Selmo-Struktur (Plant, HWZ, SEQ, Zonen, Parameter) | `.JSON`, `.CSV`, `.XML` (für HMI-Generator) | Bediener, Instandhaltung | | **3** | **Dokumentation (Model Report)** | Vollständige Dokumentation des Prozessmodells inkl. Logik, System, Parameter, Safety | `.PDF` / `.HTML` | Qualität, Audit, CE | | **4** | **Modellstruktur (Selmo Model File)** | Vollständiges, versioniertes Modell (Plant → HWZ → SEQ → Zone → Bit-Control) | `.SEL`, `.XML`, `.JSON` | Entwicklung, Simulation | | **5** | **Funktionsbibliothek (Selmo Function Set)** | Dokumentierte, standardisierte Funktionsbausteine (z. B. Addierer, Timer, Prüfer) | `.XML` / `.PDF` | Automation, Wiederverwendung | | **6** | **Technologiedokumentation** | Übersicht aller verwendeten Komponenten, Schnittstellen, Zonen, CMZ, MXIC | `.PDF` / `.CSV` | Mechanik, Elektro, Betrieb | | **7** | **Safety-Dokumentation (CMZ/MXIC)** | Alle Sicherheitsdefinitionen und -verknüpfungen aus dem Modell | `.PDF` / `.CSV` | CE, Qualität, Audit | | **8** | **Diagnose- und Fehlerlisten (HMI/Log)** | Liste aller automatisch generierten Meldungen, Zustände, Abweichungen | `.CSV` / `.JSON` | Service, Instandhaltung | | **9** | **Parameter-Dateien** | Prozessparameter, Grenzwerte, Defaultwerte, Änderungsgrenzen | `.CSV` / `.JSON` | Bediener, QS, MES | | **10** | **Digital Twin Export** | Strukturierter Datensatz zur Verbindung mit Simulationssystemen | `.JSON`, `.FMU`, `.XML` | Simulation / SoftFAT | | **11** | **Normen- und Nachweisdokumentation** | Zusammenstellung der Normen, Sicherheits- und Prozessnachweise | `.PDF` | Audit, Qualität, Kunde | *** #### **3. Beschreibung der wichtigsten Outputs** **1️⃣ PLC-Code** * Automatisch generierter Steuerungscode aus dem Modell. * Vollständig deterministisch (jede Logik und jeder Zustand ist formal definiert). * Keine manuelle Nachbearbeitung notwendig. * Lauffähig auf allen SPS-Systemen, die IEC 61131-3 unterstützen. * Anpassung nur über Selmo-Parameter oder Funktionsschnittstellen. **Nutzen:** * Formal korrekter, normenkonformer Code ohne Interpretationsfehler. * Zeitersparnis und Qualitätssicherung im Engineering. *** **2️⃣ HMI-Projekt** * HMI-Struktur folgt exakt dem Modell: * Plant → HWZ → SEQ → Zone. * Anzeigen für Zustände, Parameter, Diagnosen und Bedienbefehle. * Hintergrundfarben, Meldetexte und Symbole automatisch generiert. * Einheitliche Diagnosephilosophie: * **Blau** = aktive Aktion (S), * **Rot** = Abweichung (i), * **Grau** = inaktiv (0). **Nutzen:** * Einheitliche, nachvollziehbare Bedienlogik. * Reduzierter HMI-Engineering-Aufwand. * Direkte Rückverfolgbarkeit zur Zonenlogik. *** **3️⃣ Modelldokumentation** * Automatisch erzeugter Bericht mit: * Modellstruktur (Plant → HWZ → SEQ → Zone) * Zustandsdiagrammen (Logic-Layer) * Bit-Control-Tabellen (System-Layer) * CMZ- / MXIC-Zuordnungen (Safety-Layer) * Parametertabellen * HMI-Textreferenzen * Normen- und Risikoverweise * Vergleichbar mit einem **Schaltplan oder mechanischer Zeichnung**. **Nutzen:** * Vollständige technische Nachvollziehbarkeit. * CE-konforme Dokumentation. * Grundlage für Audit und Wartung. *** **4️⃣ Selmo-Modelldatei (.SEL / .XML / .JSON)** * Enthält alle Layer des Modells: * Logic, System, Parameter, Safety, HMI. * Versioniert mit Änderungsverlauf (Modellstand, Datum, Autor). * Dient als Schnittstelle für: * Code-Generator * HMI-Generator * Digital Twin * Dokumentationssystem **Nutzen:** * Einheitliches, maschinenlesbares Format. * Integration in Toolchains (Versionierung, Simulation, Code). *** **5️⃣ Funktionsbibliothek** * Jede Funktion ist formal beschrieben: * Eingänge, Ausgänge, Verhalten, Grenzbedingungen. * Wiederverwendbar für künftige Projekte. * Alle Funktionen sind getestet und dokumentiert. **Nutzen:** * Standardisierung und Reduktion von Engineering-Aufwand. * Klare Funktionsnachweise für Audit und Sicherheit. *** **6️⃣ Technologiedokumentation** * Übersicht aller physischen und logischen Elemente: * Sensoren, Aktoren, Zonen, CMZ, MXIC, Funktionsverknüpfungen. * Automatisch aus PTF und Modell generiert. **Nutzen:** * Übersichtliche Anlagenstruktur. * Transparenz für Betrieb, Instandhaltung und Audit. *** **7️⃣ Safety-Dokumentation** * Alle CMZ-, Interlock- und MXIC-Regeln sind dokumentiert. * Darstellung der Zustände, Verriegelungen und Abbruchlogiken. * Verweis auf PTF-RISK und PTF-SAFE. **Nutzen:** * Vollständiger CE-Nachweis. * Sicherheit nachvollziehbar und prüfbar. *** **8️⃣ Diagnose / HMI-Meldungen** * Automatisch generierte Fehlermeldungen, Statusanzeigen und Texte. * Jede Zone → eigener Diagnosepunkt. * Standardisierte Meldungen: * *„Zone zeigt Abweichung“*, * *„Taste drücken“*, * *„Signal fehlt“*. **Nutzen:** * Einheitliche Bedienphilosophie. * Schnellere Fehlerlokalisierung. * Schulungsfreundliche, logische Struktur. *** **9️⃣ Digital Twin Export** * Abbild des Modells in standardisiertem Format (JSON / FMU). * Ermöglicht Emulation oder Simulation (SoftFAT). * Verbindung von Steuerungscode und virtueller Hardware. **Nutzen:** * Frühzeitige Testmöglichkeiten. * Sicherere Inbetriebnahme. * Basis für lernende Modelle. *** #### **4. Qualitätskriterien für Outputs** Alle Outputs müssen: * [ ] aus freigegebenen PTF-Daten erzeugt sein * [ ] fehlerfrei generiert werden (Modellvalidator = OK) * [ ] versioniert sein (z. B. Model\_v1.3, Code\_v1.3) * [ ] formale Vollständigkeit nachweisen (alle Layer enthalten) * [ ] Prüflog / Validierungsbericht besitzen * [ ] für Audit und Service dokumentiert und archiviert sein *** #### **5. Zusammenfassung – Outputziele** | Kategorie | Ziel | Nutzen | | ---------------------------- | ------------------------------------------------- | ---------------------------------- | | **Code** | Automatisierte, normkonforme Steuerung | Determinismus, Sicherheit | | **HMI** | Strukturierte Bedienung, gleiche Logik wie Modell | Konsistenz, Reduktion Bedienfehler | | **Dokumentation** | Formale Nachvollziehbarkeit | Auditfähigkeit | | **Modellstruktur** | Einheitliche Datenbasis | Integration, Versionierung | | **Funktionen / Technologie** | Wiederverwendung & Standardisierung | Effizienz | | **Safety & Diagnose** | Transparente Sicherheitslogik | CE-Konformität, Betriebssicherheit | | **Digital Twin Export** | Frühe Simulation & SoftFAT | Qualität & Zeitgewinn | *** #### **6. Fazit** > Der Output der Selmo-Modellierung ist **das digitale Pendant zu Zeichnung, Schaltplan und Funktionsdiagramm** –\ > nur präziser, formaler und automatisch ausführbar. Das Ergebnis ist: * **ein deterministisches Modell**, * **ein sicherer Steuerungscode**, * **eine automatische HMI-Struktur**, * **eine vollständige Dokumentation**, * **eine integrierte Verbindung zur Simulation**, * und **eine wiederverwendbare Funktionsbibliothek.** Damit wird aus der Modellierung nicht nur Code,\ sondern ein **vollständiges, intelligentes Maschinenabbild** –\ technisch korrekt, formell dokumentiert,\ und direkt nutzbar für **Inbetriebnahme, Audit, Service und Lernen**.
🧩 SIPOC – Prozessmodellierung in Selmo Customer #### **C – Customer (Nutzer und Nutzen der Prozessmodelle)** *** #### **1. Definition** **Customer** sind alle Rollen, Organisationen oder Systeme,\ die den Output der Selmo-Prozessmodellierung **verwenden, prüfen, integrieren oder im Betrieb nutzen.** Sie profitieren direkt von: * der **transparente Abbildung der Prozesslogik**, * der **technisch vollständigen und formalen Dokumentation**, * der **Sicherheits- und Nachweiskette**, * und der **Wiederverwendbarkeit und Standardisierung**. *** #### **2. Haupt-Customer und ihr Nutzen** | Nr. | Rolle / Stakeholder | Verwendet / erhält | Zweck / Nutzen | | ------ | ---------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Projektleitung / PTF-Lead** | Vollständige Prozessmodelle, Reports, Prüfprotokolle |

- Nachweis der erfolgreichen Umsetzung des PTF
- Projektfreigabe und Abnahme
- Dokumentierte Qualität und Vollständigkeit

| | **2** | **Prozessverantwortlicher (Industrial Engineering)** | Logik- und System-Dokumentation, Parametrierung |

- Prüfen, ob der Prozess technisch exakt wie spezifiziert umgesetzt ist
- Kein Blackbox-Code, sondern nachvollziehbares Modell
- Möglichkeit zur Optimierung des Ablaufs

| | **3** | **Mechanik / Konstruktion** | Modellstruktur (Plant → HWZ → SEQ), Technologiereport |

- Überprüfung, ob die reale Mechanik korrekt im Prozessmodell abgebildet ist
- Einfache Fehleranalyse durch Signalzuordnung

| | **4** | **Elektro / Steuerung (E-Plan)** | I/O-Zuordnung, Bit-Control, CMZ/MXIC-Dokumentation |

- Nachvollziehbare Verbindung von Schaltplan und Logikmodell
- Eindeutige Signalverknüpfung zu Hardware

| | **5** | **Software / Automation** | Code, Modell, Funktionsbibliothek |

- Standardisierte, reproduzierbare Codeerzeugung
- Wartbare und dokumentierte Softwarearchitektur

| | **6** | **Qualität / Sicherheit / CE** | Safety-Dokumentation, Risikobewertung, CMZ/MXIC-Tabellen |

- Vollständige CE- und Normnachweise
- Keine unkontrollierten Logikänderungen
- Prüfbarkeit jedes Sicherheitsverhaltens

| | **7** | **IT / OT / MES / ERP** | Schnittstellenbeschreibung, Kommunikationsstruktur |

- Einfache Integration dank formalem Datenmodell
- Einheitliche Verbindung zwischen Automatisierung und IT-Systemen

| | **8** | **Betrieb / Instandhaltung / Service** | HMI, Diagnose, Technologiedokumentation |

- Transparente Bedien- und Fehlermeldungen
- Schnelle Fehlerlokalisierung
- Eindeutige Zuordnung von Zone und Zustand

| | **9** | **Management / Controlling** | Projektberichte, Funktionsbibliotheken, Risikoreduktion |

- Planbarkeit und Budgettreue durch klare Struktur
- Weniger Reklamationen, kürzere Entwicklungszeiten

| | **10** | **Kunde / Betreiber / Endanwender** | Vollständige Prozessdokumentation, Auditnachweise |

- Vertrauen in Funktion, Sicherheit und Nachvollziehbarkeit
- Kein „Blackbox-Code“, sondern formal belegter Prozess
- Grundlage für Betrieb, Schulung und Audits

| *** #### **3. Besondere Verantwortung: PTF-Verantwortliche und Prozess-Owner** Die **Prozessverantwortlichen** (aus dem PTF) sind die **direkten Empfänger und Prüfer** der Modellierungsergebnisse.\ Sie sind: * die **Anforderungsgeber** (aus dem PTF) * die **Abnehmer** des Prozessmodells * und die **Garant** dafür, dass die Maschine **genau das tut, was spezifiziert wurde.** **Ihre Verantwortung:** * Validierung des Prozessmodells anhand der PTF-Vorgaben * Prüfung der Ablauf- und Funktionslogik * Bestätigung, dass die Umsetzung dem spezifizierten Prozessverhalten entspricht * Dokumentation der Freigabe (Abnahmeprotokoll Prozessmodell) **Ihr Nutzen:** * Kein Interpretationsrisiko mehr zwischen Engineering und Software * Vollständige Sichtbarkeit des Maschinenverhaltens * Möglichkeit, Prozesse bereits virtuell zu prüfen * Sicherheit, dass Normen und Sicherheitsregeln eingehalten sind > Der Prozessverantwortliche erhält kein „fertiges Programm“ mehr,\ > sondern ein **formales, dokumentiertes, nachvollziehbares Prozessmodell –**\ > **das sichtbar macht, wie die Maschine denkt und handelt.** *** #### **4. Nutzen nach Projektphase** | Projektphase | Customer | Nutzen der Prozessmodelle | | --------------------------- | ------------------------------------------ | ---------------------------------------------------------------- | | **Planung / Engineering** | Projektleitung, Prozess, Mechanik, Elektro | Transparente Struktur, definierte Schnittstellen, keine Blackbox | | **Modellierung / Software** | Automation, Sicherheit | Deterministische Umsetzung, automatische Dokumentation | | **SoftFAT / Simulation** | IT / OT, Prozess, Qualität | Frühe Tests, Validierung ohne reale Hardware | | **Inbetriebnahme** | Service, CE, Kunde | Schnellere IBN, weniger Fehler, klare Diagnose | | **Betrieb / Wartung** | Betrieb, Instandhaltung | Transparente Bedienung, standardisierte HMI, einfache Anpassung | | **Audit / CE-Prüfung** | Qualität, Management, Kunde | Nachweis der Normenkonformität und Prozesssicherheit | *** #### **5. Organisatorischer und strategischer Nutzen** **Für das Unternehmen:** * **Weniger Entwicklungsrisiken:**\ Standardisierung der Logik durch Modellierung statt individueller Programmierung. * **Höhere Wiederverwendung:**\ Funktionen, Zonen, Sequences können in anderen Projekten übernommen werden. * **Einfache Schulung:**\ Formale Darstellung der Abläufe für Training und Einarbeitung. * **Nachvollziehbarkeit:**\ Jede Änderung ist versioniert, jede Entscheidung dokumentiert. **Für den Kunden / Betreiber:** * **Transparenz statt Blackbox:**\ Jeder Schritt der Maschine ist dokumentiert und erklärbar. * **Langfristige Wartbarkeit:**\ Prozessmodelle können verstanden, erweitert und geprüft werden – auch nach Jahren. * **Sicherheit:**\ Die formale Beschreibung garantiert die Einhaltung der CE- und Sicherheitsnormen. * **Digitaler Zwilling anschließbar:**\ Modelle können direkt für Simulation und Optimierung genutzt werden. *** #### **6. Kommunikations- und Freigabeprozess** 1. **Fertigstellung des Modells** durch Automation 2. **Interne Prüfung & Simulation** (PTF-Lead, Qualität) 3. **Review durch Prozessverantwortlichen** (Abgleich mit PTF) 4. **Freigabe der Prozessmodelle** (Abnahmeprotokoll) 5. **Übergabe an Kunde / Betreiber** 6. **Archivierung im Projekt-Repository** 7. **Verwendung im Betrieb / Digital Twin / CE-Dokumentation** *** #### **7. Fazit** > Mit dem Selmo-Prozessmodell bekommt der Kunde kein Programm,\ > sondern eine **vollständige, dokumentierte und formal korrekte Prozessbeschreibung** –\ > nachvollziehbar wie ein Schaltplan, überprüfbar wie ein Prüfprotokoll,\ > und wiederverwendbar wie ein standardisierter Funktionsbaustein. **Jeder profitiert:** * **Prozessingenieure** – sehen, dass ihr Prozess exakt umgesetzt ist. * **Softwareentwickler** – haben klare Struktur und Logik. * **CE und Qualität** – haben formale Nachweise. * **Betrieb und Service** – haben verständliche HMI und Diagnose. * **Kunde** – hat Sicherheit, Nachvollziehbarkeit und Vertrauen. > **Selmo macht Verhalten sichtbar.**\ > **Und sichtbar heißt: erklärbar, prüfbar, sicher.**
--- # 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-as-a-process/selmo-prozessmodellierung/sipoc-prozessmodellierung.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.