> 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/selmo-prozessmodellierung-im-gesamtprojektverlauf.md). # 🧭 Selmo Prozessmodellierung im Gesamtprojektverlauf #### **1. Ausgangspunkt: Das Problem in klassischen Projekten** In herkömmlichen Maschinenprojekten entsteht ein zentrales Problem: * Der Prozess wird verstanden – aber nicht formal beschrieben. * Die Anforderungen werden dokumentiert – aber nicht eindeutig umgesetzt. * Der Code funktioniert – aber ist nicht erklärbar oder prüfbar. Das führt zu: * **Abweichungen zwischen Prozess und Software**, * **Zeit- und Kostensteigerungen** in der Inbetriebnahme, * **Blackbox-Code**, den niemand nachvollziehen kann, * **fehlenden Nachweisen** für Normen, Sicherheit und Qualität. **Selmo löst genau dieses Problem**,\ indem es aus der Prozessbeschreibung ein **formales, deterministisches und dokumentiertes Prozessmodell** erzeugt –\ sichtbar, prüfbar und automatisch ausführbar. *** #### **2. Rolle der Prozessmodellierung im Projektablauf** **Prozessmodellierung ist die Brücke zwischen Definition (PTF) und Umsetzung (Software & Inbetriebnahme).**\ Sie übersetzt Anforderungen in ein lauffähiges, nachvollziehbares und dokumentiertes Maschinenverhalten. ``` Kundenanforderung (Problem) ↓ PTF – Prozess, Technologie, Funktion (Was ist nötig?) ↓ Selmo Prozessmodellierung (Wie funktioniert es?) ↓ Code / HMI / Dokumentation (Wie wird es ausgeführt?) ↓ Digital Twin / Inbetriebnahme (Wie wird es getestet?) ↓ Betrieb / Service (Wie bleibt es nachvollziehbar?) ``` **Zentrale Aussage:** > Der PTF beschreibt, *was* die Maschine tun soll.\ > Die Prozessmodellierung zeigt, *wie* sie es deterministisch tut.\ > Und der Code führt es formal korrekt aus. *** #### **3. Warum die Prozessmodellierung notwendig ist** | Problemstellung | Selmo-Lösung | Nutzen | | ---------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------- | | Unklare Übersetzung von Anforderungen in Software | Formales Modell als Zwischenschicht zwischen PTF und Code | Keine Interpretationsfehler | | Individuell geschriebene Logik, unprüfbar | Modell erzeugt deterministischen, prüfbaren Code | Nachvollziehbarkeit und Prüfbarkeit | | Fehlende Struktur / Abhängigkeiten zwischen Abläufen | Strukturmodell: Plant → HWZ → SEQ → Zone | Transparenz und Wiederverwendbarkeit | | Mangelnde Sicherheit / Normkonformität | CMZ- und MXIC-Regeln als Teil des Modells | Sicherheit formal garantiert | | Keine Dokumentation des Codes | Automatische Dokumentation (System-, Logic-, Safety-Layer) | CE- und Auditfähigkeit | | Späte Fehlererkennung | SoftFAT / Digital Twin-Integration | Frühzeitige Validierung, Zeitersparnis | | Abhängigkeit von einzelnen Programmierern | Standardisierte, formal definierte Modellierung | Unternehmensweite Wiederverwendbarkeit | *** #### **4. Was passiert in der Prozessmodellierung?** Die **Prozessmodellierung** baut auf den Ergebnissen des **PTF** auf und übersetzt diese systematisch in ein formales Maschinenmodell: | Phase | Aktivität | Ergebnis | | ------------------------- | ---------------------------------------------------- | ----------------------------------------- | | **1. Strukturierung** | Anlage (Plant), Zonen (HWZ, SEQ, Zone) anlegen | Logische Maschinenstruktur | | **2. System-Layer** | Signalverhalten (Bit-Control: 0, i, S, M) definieren | Automatikverhalten dokumentiert | | **3. Logic-Layer** | Zustände und Übergänge modellieren | Prozesslogik sichtbar und nachvollziehbar | | **4. Parameter-Layer** | Werte, Zeiten, Toleranzen definieren | Flexibilität durch Einstellbarkeit | | **5. CMZ / MXIC** | Sicherheits- und Handbetriebsverhalten anlegen | CE-konforme Sicherheit | | **6. SEQCross** | Abläufe zwischen Sequenzen synchronisieren | Modulare, skalierbare Struktur | | **7. Validierung / Test** | Simulation oder SoftFAT ausführen | Fehlerfreie, geprüfte Logik | | **8. Output generieren** | Code, HMI, Dokumentation, Safety-Reports | Vollständiger, prüfbarer Maschinenoutput | *** #### **5. Warum die Prozessmodellierung an dieser Stelle des Projekts steht** | Zeitpunkt | Aufgabe | Ergebnis / Ziel | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------- | | **Nach PTF-Freigabe** | Übernahme aller PTF-Daten in das Modell | Sicherstellung der vollständigen, geprüften Anforderungen | | **Vor der SPS-Programmierung** | Erstellung des formalen Prozessmodells | Deterministischer Code kann automatisch generiert werden | | **Vor SoftFAT / Simulation** | Verbindung des Modells mit Digital Twin | Virtuelle Inbetriebnahme möglich | | **Vor Inbetriebnahme (IBN)** | Prüfung des Codes, HMI, Safety | Zeitgewinn, Risikominimierung | | **Im Betrieb / Service** | Nutzung der Dokumentation, HMI, Parameter | Transparente Wartung, Schulung, Optimierung | **Zentrale Bedeutung:** > Die Prozessmodellierung ersetzt den unstrukturierten Programmierprozess\ > durch einen **formalen, dokumentierten und nachvollziehbaren Modellierungsprozess.** *** #### **6. Nutzen im Gesamtprojekt (vom Problem zum Mehrwert)** | Sichtweise | Vor Selmo (Problem) | Mit Selmo Prozessmodellierung (Lösung) | Direkter Nutzen | | --------------------------- | -------------------------------------------- | -------------------------------------------------- | ---------------------------------------- | | **Projektleitung** | Fehlende Transparenz, kaum prüfbare Software | Vollständiges, dokumentiertes Modell | Planbarkeit, Sicherheit, Nachweisbarkeit | | **Prozessverantwortlicher** | Prozess wird nicht exakt umgesetzt | Logik und Verhalten sichtbar modelliert | Nachvollziehbare Umsetzung | | **Mechanik / Elektro** | Mangelnde Abstimmung mit Steuerung | Struktur abbildet reale Maschine | Bessere Koordination | | **Software / Automation** | Individuelle Codebasis, unklarer Status | Standardisierte Modellierung, automatisierter Code | Qualität, Wiederverwendbarkeit | | **Qualität / CE** | Kein Nachweis des Verhaltens | Formale Dokumentation, Safety-Layer | CE- und Auditfähigkeit | | **Betrieb / Service** | Blackbox-Verhalten, keine klare Diagnose | HMI & Logik sind deckungsgleich | Schnelle Fehlerlokalisierung | | **Kunde / Betreiber** | Keine Nachvollziehbarkeit des Verhaltens | Dokumentiertes, geprüftes Maschinenmodell | Vertrauen, Transparenz, Sicherheit | *** #### **7. Das „Warum“ im Kern – der Nutzen aus Kundensicht** * **Warum modellieren statt programmieren?**\ Weil Modelle **prüfbar, erklärbar und wiederverwendbar** sind – Programme allein nicht. * **Warum jetzt, nach dem PTF?**\ Weil hier alle Anforderungen validiert sind, bevor sie technisch umgesetzt werden –\ Änderungen sind noch günstig, Fehler noch reversibel. * **Warum für alle Beteiligten relevant?**\ Weil das Modell alle Disziplinen verbindet:\ Mechanik, Elektro, Prozess, Software, Qualität und Betrieb. > Die Prozessmodellierung macht aus isolierten Fachbereichen ein durchgängiges Systemverständnis.\ > Jeder sieht das Gleiche – in einer formalen, eindeutigen Sprache. *** #### **8. Ergebnis im Gesamtzusammenhang** **Prozessmodellierung = formale Umsetzung der PTF-Ergebnisse**\ → Sie erzeugt den „digitalen Zwilling des Verhaltens“ einer Maschine –\ noch bevor die Hardware real existiert. Damit entsteht: * **Ein Modell statt einer Interpretation**, * **Ein dokumentierter Code statt individueller Logik**, * **Ein sichtbares Verhalten statt einer Blackbox**, * **Ein reproduzierbares Engineering statt Einzelfallwissen.** *** #### **9. Fazit – Warum & Was** **Warum:**\ Weil jedes Projekt klare, formale und überprüfbare Logik braucht.\ Selmo sichert die technische und normative Richtigkeit von der Definition bis zur Ausführung. **Was:**\ Ein vollständiges, formales, dokumentiertes Maschinenverhalten –\ logisch, sicher, deterministisch und prüfbar. **Wie:**\ Durch den standardisierten Prozess der Selmo-Modellierung –\ vom PTF über Logik, System, Parameter, Safety und HMI bis zum Code. *** > **Mit dem PTF wird Wissen gesammelt –**\ > **mit der Prozessmodellierung wird Wissen angewendet.** > > Sie ist der Moment, in dem aus Anforderungen Realität wird –\ > präzise, sicher und nachvollziehbar. > > Damit wird der gesamte Engineering-Prozess von Selmo\ > **vom Problem aus gedacht** und\ > **auf dokumentierte technische Exzellenz ausgerichtet.** --- # 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/selmo-prozessmodellierung-im-gesamtprojektverlauf.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.