3. SIPOC-Struktur des PTF
SIPOC steht für Supplier Input Process Output Customer
Supplier
Definition: Supplier sind die Verantwortlichen, die Input-Daten, Dokumente oder Wissen in den PTF einspeisen. Sie liefern geprüfte Informationen, die als Grundlage für Prozess, Technologie und Funktion dienen.
Qualitätskriterien:
Eindeutig, prüfbar, deterministisch
Versioniert, freigegeben, dokumentiert
Normkonform (ISO, CE, MVO 2027)
SIPOC – „Supplier“ im Selmo-PTF
1) Definition
Supplier (Lieferant) ist die verantwortliche Rolle/Organisation, die verbindliche Eingaben (Inputs) für den PTF-Prozess liefert. Diese Eingaben sind fachlich korrekt, vollständig, prüfbar und versioniert – und bilden die Grundlage für Process-, Technology- und Function-Definition sowie die spätere formale Verifikation im Selmo-Modell.
Merksatz: Supplier ≠ „wer es am lautesten fordert“, sondern wer inhaltlich verantwortet, wer Datenquellen besitzt und die Konsequenzen fachlich tragen kann.
2) Prinzipien zur Identifikation eines Suppliers
Ein Stakeholder ist Supplier, wenn er…
…Originalquelle für einen Input ist (z. B. Prozesswissen, Normvorgaben, I/O-Daten, Schnittstellen).
…Änderungsautorität über diesen Input hat (darf fachlich entscheiden).
…Lieferverpflichtung bzgl. Format, Termin, Reifegrad übernimmt.
…Prüfbarkeit sicherstellt (Grenzen, Toleranzen, Messpunkte, Testfälle).
…Traceability gewährleistet (Version, Änderungsgrund, Verantwortlicher).
3) Typische Supplier-Rollen im PTF (mit gelieferten Inputs)
Prozessverantwortlicher / Industrial Engineering Liefert: Prozessziel & Takt, Wertstrom, Zustands-/Ablaufbeschreibung, Abbruchkriterien, Prozessparameter (Zeiten, Toleranzen), Qualitätsmerkmale.
Prozessingenieur (Technologe) Liefert: Detail-Arbeitsfolgen, Ressourcen, Hilfsstoffe, Prüfpläne, Messstellen, Sicherheitsannahmen (PLr/SIL-Bedarf).
Mechanik-Konstruktion Liefert: Kinematik/Layouts, Stückliste, Medien (Druckluft, Vakuum), Sicherheitsabstände, Endlagen; mechanische Schnittstellen.
Elektro/Steuerung (E-Plan/Hardware) Liefert: Stromlaufplan, I/O-Liste, Schutzkreise, Sicherheitsarchitektur, Klemmpläne, Klemmenbezeichnungen.
Automation/Selmo-Modellierung (Software) (als Supplier für F-Inputs) Liefert: Funktionsblätter (z. B. Addierer), Trigger/Feedback, Grenzwerte, Fehlerreaktionen, CMZ/MXIC-Bedarf.
IT/OT & Datensysteme (MES/ERP/SCADA/Cloud) Liefert: Schnittstellenbeschreibung (Protokoll, Topics/Tags, Payload, QoS), Datenfelder, Latenz/Verfügbarkeit, Security-Vorgaben.
Externe Technologie-Lieferanten (Roboter, Vision, Antriebe, Sensorik) Liefert: Datenblätter, Schnittstellen-/Command-Set, Zykluszeiten, Genauigkeit, Diagnose/Alarme.
Sicherheit/CE/Normen Liefert: Geltende Normen, Risikobeurteilung, PLr/SIL-Nachweise, Schutzmaßnahmen.
Qualität Liefert: Prüfkonzept, SPC-Regeln, Freigabekriterien, Traceability-Anforderungen.
Betrieb/Instandhaltung Liefert: Wartungsanforderungen, HMI-Bedienkonzept, Reaktionszeiten, Ersatzteilstandards.
Utilities/Facility Liefert: Medienverfügbarkeit (Strom, Luft, Kühlung), Grenzwerte, Anschlusspunkte.
4) Artefakte/Deliverables je Supplier (PTF-Kennzeichnungsvorschlag)
PTF-PROC – Prozessbeschreibung (SIPOC, Zustandslogik, Parameterliste)
PTF-TECH – Technologiematrix (Sensoren/Aktoren, Hersteller, Lebensdaten)
PTF-IO – I/O-Liste (Adresse, Signalname, Zone, CMZ-Level)
PTF-IF – Schnittstellen-Spezifikation (Protokoll, Topics/Tags, Felddefinitionen)
PTF-FUNC – Funktionsblatt (z. B. Addierer): Inputs/Outputs, Domänen, Grenzwerte, Fehlerfälle, Testfälle
PTF-SAFE – Sicherheitsnachweise (PLr/SIL, Schutzkreise, MXIC/Interlocks)
PTF-HMI – HMI-Texte, Bedienkonzept, Diagnosemeldungen
PTF-Q – Qualitäts-/Abnahmeplan (DoE, SPC, Grenzmuster)
5) Qualitäts- & Reifegradkriterien für Supplier-Inputs (Definition of Ready)
Jeder Input muss:
Eindeutig & deterministisch sein (keine Interpretationslücken, klare Zustände/Übergänge).
Domänen/Grenzen definieren (Min/Max, Toleranzen, Einheiten, Default-Werte).
Fehler- & Diagnoseverhalten beschreiben (Erkennung, Reaktion, Rückkehrbedingungen).
Verifizierbar sein (Messpunkte, Testfälle, Akzeptanzkriterien).
Versioniert & rückverfolgbar sein (ID, Datum, Verantwortlicher, Änderungsgrund).
Formalgerecht vorliegen (Templates/Struktur wie oben).
6) RACI-Rahmen (typisch)
Responsible (R): jeweilige Supplier-Rolle pro Input
Accountable (A): PTF-Lead / Projektleitung
Consulted (C): angrenzende Disziplinen (z. B. Sicherheit, Qualität)
Informed (I): Stakeholder (Betrieb, Einkauf, PMO)
7) Supplier-Checkliste (zur schnellen Zuordnung)
Wer ist Originalquelle der Information?
Wer entscheidet bei Zielkonflikten?
Wer unterschreibt den Input (fachliche Freigabe)?
In welchem Format wird geliefert (PTF-Artefakt)?
Bis wann (Fälligkeit/Milestone)?
Wie wird die Prüfbarkeit nachgewiesen (Testfälle, Messpunkte)?
8) Eintrag-Template (für dein Prozessdokument)
Supplier-Record
Rolle/Organisation: ______________________________
Verantwortlich (Name/Kontakt): ___________________
Liefert (Artefakte): _____________________________
PTF-IDs: ________________________________________
Format/Standards: ________________________________
Reifegrad (Draft/Review/Released): _______________
Fälligkeit/Milestone: ____________________________
Abhängigkeiten: _________________________________
Prüfkriterien/Tests: _____________________________
Freigabe durch (A): ______________________________9) Mini-Beispiele
Supplier: Prozessingenieur (R) Liefert PTF-PROC mit Takt 18 s, Zustandskette, Parametern (Presszeit, Temperatur), Abbruchkriterien; Testfälle für Soll/Ist-Abgleich. A: PTF-Lead; C: Qualität, Sicherheit.
Supplier: IT/MES (R) Liefert PTF-IF (REST/MQTT, Feldliste „OrderId, Variant, Result, TraceId“, Retry/Timeout), Datenqualitätsregeln. A: PTF-Lead; C: Automation.
Input
Definition: Inputs sind die formalen Informationen, die von den Suppliern geliefert werden. Sie beschreiben, was im PTF-Prozess analysiert, geprüft und in die Selmo-Struktur überführt wird.
SIPOC – „Input“ im Selmo-PTF
1) Definition
Input bezeichnet alle verbindlichen Informationen, Dokumente, Daten oder Modelle, die von den identifizierten Suppliern geliefert werden, um den PTF-Prozess (Process – Technology – Function) auszuführen. Diese Inputs sind die Grundlage für:
die Modellierung im Selmo-Studio,
die formale Verifikation (Determinismus, Vollständigkeit, Nachvollziehbarkeit),
die automatisierte Dokumentation und
die Risiko- und Qualitätsbewertung.
Ein Input ist erst gültig, wenn er:
vollständig, eindeutig und konsistent ist,
im richtigen Format vorliegt,
einer Version und Quelle zugeordnet ist,
und vom PTF-Lead oder Projektleiter freigegeben wurde.
2) Ziel des Input-Schrittes
Verfügbarkeit aller fachlich geprüften Informationen vor Beginn der Modellierung
Reduktion von Interpretationsspielräumen
Formale Übergabe zwischen Disziplinen (Mechanik, Elektro, Software, IT)
Standardisierte Formate zur einfachen Integration in das Selmo-System
3) Hauptkategorien von Inputs im PTF
Jeder Input gehört zu einer der drei PTF-Ebenen:
P – Process
Prozessbeschreibung
Beschreibt den logischen und physikalischen Ablauf.
Prozessdiagramm, Schrittfolge, Zustandsmatrix
Parameterliste
Prozessparameter, Grenzwerte, Zeitvorgaben
Zykluszeit, Temperatur, Druck, Positionen
Qualitätsmerkmale
Messgrößen, Prüfkriterien, Grenzmuster
Prüfdruck, Maßtoleranzen
T – Technology
Technologiematrix
Übersicht aller eingesetzten Technologien, Geräte, Systeme
Sensorik, Aktorik, Roboter, SPS, Busse
I/O-Liste
Zuordnung von Signalen zu Zonen, Adressen, CMZ-Level
Inputs/Outputs, Symbolik, Signalnamen
Schnittstellenbeschreibung
Definition von Kommunikationswegen zu Subsystemen
MES, ERP, SCADA, Robotik, Safety
F – Function
Funktionsblätter
Dokumentation der logischen Funktionen
Addierer, PID-Regler, HMI-Meldung
Diagnose-/Fehlerlogik
Beschreibung von Überwachungen und Reaktionen
Grenzverletzung → Stopp + Alarm
Test-/Verifikationsfälle
Prüfschritte, erwartete Outputs
Input A+B=Result, Timeout-Test, Interlock-Check
4) Standardisierte Formate & Templates (Selmo-Vorschlag)
PTF-PROC (Prozessbeschreibung)
MS Excel oder Selmo Template (CSV/XML)
Enthält Prozessschritte, Zustände, Bedingungen, Parameter
Standardvorlage mit SIPOC-Header
PTF-PARAM (Parameterliste)
Excel / CSV
Schlüssel-Parameter (Name, Einheit, Min/Max, Default, Beschreibung)
Automatisch importierbar ins Selmo-Studio
PTF-TECH (Technologiematrix)
Excel / Selmo Template
Auflistung aller Systemkomponenten (Typ, ID, Schnittstelle, Hersteller)
Grundlage für Zonenaufbau
PTF-IO (I/O-Liste)
Excel / EPLAN-Export (CSV/XML)
Signalname, Adresse, Zonentyp, CMZ-Level
Import in Selmo-Zonenstruktur
PTF-IF (Schnittstellenbeschreibung)
PDF / JSON / YAML
Kommunikationsschnittstellen (Protokoll, Tags, Datentypen, Richtung)
Für MES, Robotik, Cloud etc.
PTF-FUNC (Funktionsblatt)
Selmo Funktionsdokument (Word/PDF/XML)
Inputs, Outputs, Trigger, Überwachungen, Testfälle
Funktionsstandardisierung
PTF-SAFE (Sicherheitsbeschreibung)
PDF / Excel
Interlock, CMZ, PLr/SIL, Abschaltmatrix
Grundlage für Risikobeurteilung
PTF-HMI (HMI-Texte und Bedienkonzept)
Excel / JSON
Texte, Farben, Zustände, Diagnosen
Automatisch generierbar
PTF-Q (Qualitätsplan)
PDF / Excel
Prüfpläne, Grenzwerte, SPC-Regeln, Messzyklen
Traceability und Audit-Nachweis
5) Anforderungen an Form und Qualität (Definition of Ready)
Ein Input ist bereit für die PTF-Verwendung, wenn er:
Eindeutig
Keine Mehrdeutigkeit in Begriffen oder Zuständen
"Zylinder fährt ein" statt "Zylinder aktiv"
Vollständig
Alle relevanten Parameter, Zustände, Schnittstellen definiert
Alle Prozessschritte abgebildet
Verifizierbar
Messbar, prüfbar, testbar
Testfall „A+B=Result“ mit Grenzwerten
Deterministisch
Keine undefinierten Übergänge oder Zustände
Kein "Warten auf unbestimmtes Signal"
Rückverfolgbar
Eindeutige Zuordnung zu Quelle, Version, Datum
„PTF-PROC v1.2, erstellt von M. Müller“
Freigegeben
Formal vom Verantwortlichen bestätigt
„Released“-Status im PTF-Register
6) Versions- und Datenmanagement
Alle Inputs erhalten eine eindeutige PTF-ID (z. B. PTF-PROC-001).
Änderungen erfolgen nach Änderungsprozess (Change Log) mit Freigabe.
Formatvorgabe:
Textuelle Daten:
.docx,.pdf,.mdTabellarische Daten:
.xlsx,.csvStrukturierte Daten:
.xml,.json
Alle Daten werden im Projektverzeichnis „/PTF/Input“ versioniert abgelegt.
7) Zeitliche Einordnung
Inputs müssen vor Beginn der Modellierung vollständig vorliegen. Empfohlene Milestones:
Kick-off → Design-Freeze (0–20%)
Prozessbeschreibung (PTF-PROC), Parameterliste
Prozessbasis klar
Design-Freeze → Technologieplanung (20–40%)
Technologiematrix, I/O, Safety
Hardware abgestimmt
Vor Inbetriebnahme (40–70%)
Funktionen, Schnittstellen
Softwaredefinition komplett
Vor Freigabe (70–100%)
HMI, Qualitätsplan, Tests
Vollständige Verifikation
8) Beispiel eines vollständigen Input-Datensatzes
9) Verantwortlichkeiten (RACI für Inputs)
Prozessingenieur
X
Qualität, Sicherheit
Projektleitung
Mechanik / Elektro
X
Automation
Projektleitung
Software / Automation
X
Prozess
Projektleitung
PTF-Lead
X
alle
PMO
Qualität / Sicherheit
X
alle
10) Fazit
Ein Input im PTF-Prozess ist nicht „ein Dokument“, sondern ein verantwortlich geprüfter Datenstand, der das Verhalten, die Technologie und die Funktion einer Maschine beschreibt. Nur durch klare Formate, Freigaben und Prüfbarkeit entsteht die Basis für:
deterministische Modellierung,
fehlerfreie Umsetzung,
und formale Nachvollziehbarkeit im gesamten Lebenszyklus.
Process
Definition: Der PTF-Prozess beschreibt den Ablauf von der Anforderung bis zur Freigabe.
Phasen:
Initiierung & Scope
Prozessbeschreibung (P)
Technologieanalyse (T)
Funktionsdefinition (F)
Review & Risiko
Freigabe & Übergabe
Kunde → liefert Anforderungen PTF-Lead → strukturiert Prozess, Technologie, Funktion Mechanik / Elektro → definieren Systeme und Schnittstellen Software → modelliert das Verhalten im Selmo-Studio Qualität / Sicherheit → prüft Normen und Risiken Management → gibt frei und steuert Budget
→ Ergebnis: Ein vollständiger, deterministischer Projektfluss ohne Interpretationslücken.
Ziel: Ein Selmo-konformes, deterministisches Maschinenmodell mit dokumentierten Risiken, Abweichungen und Freigaben.
SIPOC – Process im Selmo-PTF
1) Definition
Der PTF-Prozess beschreibt den formalen Ablauf von der Erfassung der Anforderungen bis zur Freigabe des vollständigen, Selmo-konformen Prozessmodells. Er ist verbindlich für alle Projekte, die nach der Selmo-Methode aufgebaut werden, und stellt sicher, dass jede Maschine deterministisch, prüfbar und dokumentiert entsteht.
Der Prozess folgt den drei PTF-Dimensionen:
P – Process → Was passiert?
T – Technology → Womit passiert es?
F – Function → Wie funktioniert es?
2) Ziel des Prozesses
Herstellen einer vollständigen, Selmo-konformen Prozessdefinition
Trennung von Prozess-, Technologie- und Funktionsverantwortung
Schaffen der Basis für das Selmo-Prozessmodell (Sequence, Zonen, Bit-Control)
Erkennen, Dokumentieren und Bewerten von Nicht-Konformitäten oder Risiken
Formale Nachvollziehbarkeit und Risikotransparenz im gesamten Lebenszyklus
Leitsatz: Alles, was nicht im PTF beschrieben, dokumentiert und bewertet ist, darf im Selmo-Modell nicht implementiert werden.
3) Prozessübersicht (Top-Level)
Der PTF-Prozess gliedert sich in sechs Phasen mit klar definierten Übergabepunkten und Verantwortlichkeiten.
1. Initiierung & Scope
Projektumfang und Systemgrenzen festlegen
PTF-Scope-Dokument
2. Prozessaufnahme & Beschreibung (P)
Physikalischen und logischen Ablauf definieren
PTF-PROC, Parameterliste
3. Technologieanalyse (T)
Technologien, Schnittstellen und Systemkomponenten bestimmen
PTF-TECH, PTF-IO, PTF-IF
4. Funktionsdefinition (F)
Funktionen spezifizieren und dokumentieren
PTF-FUNC, PTF-SAFE
5. Review & Risikobewertung
Selmo-Konformität prüfen, Abweichungen bewerten
PTF-RISK, Review-Protokoll
6. Freigabe & Übergabe
PTF formal freigeben, Basis für Modellierung schaffen
PTF-Release, Übergabeprotokoll
4) Detaillierter Ablauf
Phase 1 – Initiierung & Scope
Ziel: Projekt- und Systemgrenzen klar definieren. Verantwortung: Projektleitung / PTF-Lead Schritte:
Beschreibung der zu modellierenden Maschine / Anlage
Festlegen des Betrachtungsumfangs (Plant, Hardware-Zonen, Sequenzen)
Definition der Liefergrenzen zwischen Disziplinen
Einrichtung der PTF-Artefaktstruktur (Verzeichnisse, Templates)
Benennung der Supplier und Verantwortlichen
Ergebnis:
PTF-Scope-Dokument
Rollen- & Verantwortlichkeitsmatrix
PTF-Verzeichnisstruktur (Input/Process/Output)
Phase 2 – Prozessaufnahme & Beschreibung (P)
Ziel: Den vollständigen Prozessablauf beschreiben – physikalisch und logisch. Verantwortung: Prozessverantwortlicher / Industrial Engineering
Schritte:
Erhebung des realen oder geplanten Prozessablaufs (Wertstrom, Schritte, Übergänge)
Definition der Zustände, Auslöser, Bedingungen und Abbruchkriterien
Identifikation aller Prozessparameter (Zeiten, Temperaturen, Kräfte, Wege etc.)
Dokumentation im PTF-PROC (Prozessbeschreibung)
Erstellung einer Parameterliste (PTF-PARAM)
Abhängigkeiten:
Benötigt Input von Mechanik und Elektro (Layout, Sensorik)
Liefert Basis für Technologie- und Funktionsdefinition
Ergebnis:
Vollständige Prozessbeschreibung (Zustände, Übergänge, Ziele)
Parameter- und Qualitätsdefinition
Phase 3 – Technologieanalyse (T)
Ziel: Alle Technologien, Geräte und Schnittstellen beschreiben und auf Selmo-Konformität prüfen. Verantwortung: Technologieverantwortlicher (Elektro/Mechanik/Automation)
Schritte:
Erstellung der Technologiematrix (PTF-TECH) – Sensoren, Aktoren, Schnittstellen, Medien, Steuerungen
Erstellung der I/O-Liste (PTF-IO) – Zuordnung zu Zonen, Signaltypen, CMZ-Level
Definition der System- und Datenschnittstellen (PTF-IF) – MES, Roboter, Safety, Cloud, etc.
Bewertung der Selmo-Konformität:
deterministische Signale?
eindeutige Zustände?
Rückmeldungen vorhanden?
synchronisierbar?
Dokumentation von Nicht-Konformitäten im PTF-RISK
Ergebnis:
Vollständige Technologiematrix
Schnittstellenübersicht
Bewertung der Selmo-Tauglichkeit
Phase 4 – Funktionsdefinition (F)
Ziel: Alle im Prozess verwendeten Funktionen dokumentieren, standardisieren und verifizieren. Verantwortung: Funktionsverantwortlicher (Software / Automation)
Schritte:
Erstellung von Funktionsblättern (PTF-FUNC) für alle logischen Funktionen
Definition von Inputs, Outputs, Triggern, Grenzwerten, Überwachungen
Zuordnung zu Prozess- und Technologieelementen
Erstellung der Sicherheits- und Überwachungsfunktionen (PTF-SAFE)
Definition von Testfällen / Verifikationspunkten
Abhängigkeiten:
Erfordert vollständigen Prozess (Phase 2) und Technologie (Phase 3)
Ergebnisse fließen in Selmo-Standardfunktionen (z. B. Addierer, Interlock, Timer) ein
Ergebnis:
Dokumentierte, prüfbare Funktionsbibliothek
Definierte Überwachungen (CMZ, MXIC, Pair-Check etc.)
Phase 5 – Review & Risikobewertung
Ziel: PTF-Vollständigkeit, Selmo-Konformität und Risiken bewerten. Verantwortung: PTF-Lead / Qualität / Sicherheit
Schritte:
Überprüfung aller PTF-Artefakte (PROC, TECH, FUNC)
Identifikation von Nicht-Selmo-konformen Anforderungen
Bewertung dieser Punkte im Risikomanagement (PTF-RISK) – Einstufung: kritisch / moderat / akzeptabel – Maßnahmen: Anpassung, Vereinfachung, Standardisierung
Freigabeempfehlung oder Überarbeitung
Ergebnis:
PTF-Review-Protokoll
Risikoliste mit Verantwortlichkeiten und Maßnahmen
Hinweis: Risiken aus Nicht-Selmo-Konformität werden nicht ignoriert, sondern transparent dokumentiert. Damit bleibt das Modell konsistent, und alle Abweichungen sind bewusst, nachvollziehbar und bearbeitbar.
Phase 6 – Freigabe & Übergabe
Ziel: PTF offiziell freigeben und als Basis für Selmo-Modellierung übergeben. Verantwortung: Projektleitung / PTF-Lead
Schritte:
Abschlussreview mit allen Disziplinen
Formale Freigabe aller PTF-Artefakte (Release-Status)
Übergabe an Selmo-Modellierung (Sequence, Zone, Bit-Control)
Archivierung des PTF-Stands
Beginn der Selmo-Modellierung
Ergebnis:
Freigegebener PTF
Offizielle Grundlage für das Selmo-Modell
Rückverfolgbarkeit bis zur Codeebene gewährleistet
5) Prozessverantwortung (RACI)
Initiierung
Projektleitung
Projektleitung
PTF-Lead
alle Stakeholder
Prozessaufnahme (P)
Prozessverantwortlicher
PTF-Lead
Technologie, Qualität
Projektleitung
Technologieanalyse (T)
Technologieverantwortlicher
PTF-Lead
Prozess, Sicherheit
Projektleitung
Funktionsdefinition (F)
Softwareverantwortlicher
PTF-Lead
Technologie, Prozess
Projektleitung
Review & Risiko
PTF-Lead, Qualität
Projektleitung
alle
Management
Freigabe & Übergabe
Projektleitung
Projektleitung
PTF-Lead
Team, Kunde
6) Schnittstellen & Abhängigkeiten
Prozessdaten (P) → Grundlage für Technologie- und Funktionsdefinition
Technologie (T) → legt physische Machbarkeit und Signalstruktur fest
Funktion (F) → beschreibt logisches Verhalten und Überwachung
Risikomanagement (RISK) → bewertet alle Abweichungen und speist sie zurück
Jede Phase darf erst freigegeben werden, wenn ihre vorgelagerte Phase abgeschlossen und validiert ist. → So wird sichergestellt, dass kein Modell auf unsicheren Annahmen basiert.
7) Qualitäts- und Reviewkriterien
Ein PTF gilt als prozessseitig abgeschlossen, wenn:
Alle PTF-Artefakte vorhanden, konsistent und freigegeben sind
Alle Supplier-Inputs validiert sind
Alle Schnittstellen definiert sind
Alle Risiken dokumentiert und bewertet sind
Der deterministische Ablauf nachvollziehbar modellierbar ist
Die Umsetzung in Selmo technisch möglich ist
8) Ergebnis und Bedeutung
Der PTF-Prozess liefert das vollständig geprüfte, formale Fundament für die Modellierung im Selmo-Studio. Er trennt:
Was (Prozess)
Womit (Technologie)
Wie (Funktion)
… und führt sie in einem prüfbaren, deterministischen Rahmen zusammen.
So wird der PTF zur Brücke zwischen Engineering und Automatisierung – und macht jede Maschine, die nach Selmo entsteht, transparent, nachvollziehbar und sicher.
9) Kernaussage für den Kick-off
Der PTF-Prozess ist kein Zusatz, sondern das Fundament. Er definiert, was gebaut wird, bevor etwas programmiert wird. Wenn alle Anforderungen, Technologien und Funktionen klar beschrieben, geprüft und freigegeben sind, entsteht aus dem PTF automatisch ein Selmo-konformes Prozessmodell – deterministisch, dokumentiert und überprüfbar. Und wenn etwas nicht Selmo-konform ist, wissen wir es, dokumentieren es, bewerten es und können gezielt daran arbeiten.
Output
Definition: Der Output ist das freigegebene, dokumentierte Ergebnis des PTF-Prozesses – technisch, organisatorisch und normativ.
Technische Outputs:
Strukturierte Selmo-Hierarchie: Plant → HWZ → Sequence → Zonen
Bit-Control-Matrix, Parameter, CMZ, MXIC
Funktionsblätter und Testfälle
PTF-Modelldatei (XML / PLCopen)
Organisatorische Outputs:
Risikobewertung (PTF-RISK)
Abweichungsliste
Normen- und CE-Nachweis
Kaufmännische Bewertung
Abschlusskriterium: „Das System ist PTF-vollständig, Selmo-kompatibel und freigegeben.“
SIPOC – Output im Selmo-PTF
1) Definition
Der Output des PTF-Prozesses ist das vollständig geprüfte, freigegebene und dokumentierte Gesamtmodell einer Maschine oder Anlage in der Selmo-Struktur. Er bildet die verbindliche Grundlage für die Programmierung, den Steuerungscode, das HMI, die Diagnose und die Sicherheitslogik.
Der Output umfasst sowohl:
Technische Ergebnisse (Modelle, Dokumente, Daten),
als auch nicht-technische Bewertungen (Risiken, Abweichungen, Normkonformität, kaufmännische Betrachtung).
2) Ziel des Outputs
Bereitstellung eines vollständig definierbaren Prozessmodells, das im Selmo-Studio umgesetzt werden kann
Sicherstellung, dass jede Funktion deterministisch, überprüfbar und normkonform ist
Dokumentation von Abweichungen, Restrisiken und Bewertungsergebnissen
Bereitstellung einer formalen Übergabe zwischen Engineering und Softwareentwicklung
Zielzustand: Der Output des PTF ist so vollständig, dass daraus automatisch ein Selmo-Modell generiert werden kann, ohne Interpretationsspielraum.
3) Technische Outputs im Detail
3.1. Strukturierter Maschinenaufbau (Selmo-Struktur)
Der PTF wird in der hierarchischen Selmo-Struktur abgebildet. Jede Ebene ist im PTF dokumentiert und kann ins Selmo-Studio überführt werden:
PLANT
Gesamte Maschine oder Anlage
Plant-Datenblatt, Schnittstellenübersicht, Sicherheitszonen, Total-CMZ
Hardware-Zonen (HWZ)
Funktionsblöcke innerhalb der Anlage (z. B. Stationen, Liniensegmente)
HWZ-Beschreibung, Betriebsarten, Sicherheitslogik, Energieversorgung
Sequences (SEQ)
Logische Ablaufmodule innerhalb der HWZ (z. B. Spannen, Prüfen, Bearbeiten)
Ablaufdiagramme, Zustände, Übergangsbedingungen
Zonen (Input, Output, In-Out, Mem)
Zuordnung der physikalischen Signale zu den logischen Zuständen
Signaldefinition, CMZ-Level, HMI-Texte, Interlocks
Bit-Control (System-Layer)
Verknüpfung zwischen Zustand und Zonenverhalten (0, i, S)
Bit-Control-Matrix, Statusdefinition
CMZ (Constantly Monitoring Zone)
Permanente Sicherheitsüberwachung (Sequenz-, HWZ-, Plant-Ebene)
CMZ-Tabelle, Fehlerreaktionen
MXIC (Manual Cross Interlock)
Handbetriebsbedingungen und Freigabeverhalten
MXIC-Matrix, Diagnosebedingungen
Parameter-Layer
Prozessparameter und einstellbare Werte
Parametertabelle mit Einheiten, Grenzen, Defaultwerten
Damit entsteht aus dem PTF-Output ein vollständiges digitales Maschinenabbild, das direkt als Basis für:
den Selmo-Sequence-Editor,
die Zonenlogik,
die HMI-Erzeugung,
und die PLC-Generierung dient.
3.2. Dokumentierte Funktionsbibliothek
Alle definierten Funktionen (z. B. „Addierer“, „Position fahren“, „Zylinder bewegen“, „Ventil öffnen“) werden in einer standardisierten Form bereitgestellt:
Funktionsname & Zweck
Eindeutige Identifikation und Beschreibung
Inputs / Outputs
Datentypen, Einheiten, Grenzen
Triggerbedingungen
Auslöser, Start-/Stop-Logik
Überwachungen
Fehlererkennung, Rückmeldung, Grenzverletzung
Testfälle
Verifikation, Soll-/Ist-Vergleich
HMI-Integration
Anzeige, Meldung, Diagnose
Sicherheitsverhalten
CMZ, Interlock, MXIC-Bedingungen
Damit wird jede Funktion prüfbar, wiederverwendbar und dokumentiert. Diese Funktionsblätter werden im PTF als PTF-FUNC gespeichert und bilden den Standardbaukasten der Softwareentwicklung.
3.3. Normen- und Vorschriftennachweis
In der PTF-Dokumentation ist die Berücksichtigung relevanter Normen und Vorschriften explizit enthalten:
Maschinensicherheit
2006/42/EG (Maschinenrichtlinie), ISO 12100, ISO 13849, IEC 62061
Softwarequalität
IEC 61131-3, ISO 9001, ISO/IEC 25010
Risikomanagement
ISO 31000, ISO 14971 (für Risikoanalyse und -bewertung)
Nachvollziehbarkeit & Dokumentation
EN 82079, ISO/IEC/IEEE 15288
Daten & Kommunikation
OPC UA, MQTT, REST, IEC 62443 (IT-Security)
Ziel: Jede verwendete Technologie, Funktion oder Softwarekomponente erfüllt oder adressiert die geltenden Normanforderungen. Abweichungen werden dokumentiert und in den Risikomanagement-Teil (PTF-RISK) übernommen.
4) Bewertung und Risikomanagement als Teil des Outputs
Der PTF-Output enthält verpflichtend folgende Bewertungen und Nachweise:
Technische Risikobewertung
Bewertung von Prozess-, Technologie- und Funktionsrisiken
Nachvollziehbare Entscheidung, welche Risiken akzeptiert oder mitigiert werden
Abweichungsliste
Dokumentation aller Punkte, die nicht Selmo-konform oder nicht deterministisch sind
Transparente Grundlage für spätere Verbesserungen
Nicht-technische Risikobewertung
Organisatorische, wirtschaftliche, terminliche oder kommunikative Risiken
Ganzheitliche Betrachtung, kein „technischer Tunnelblick“
Kaufmännische Bewertung
Aufwand, Nutzen, Komplexität, Wirtschaftlichkeit
Begründete Priorisierung für Maßnahmen und Änderungen
Normenkonformitätsbewertung
Erfüllungsgrad relevanter Normen
Nachweis für Audits, CE-Dokumentation, Qualitätsmanagement
Diese Bewertungen sind nicht optional – sie bilden den dokumentierten Stand der Verantwortung. Das Ergebnis ist kein „perfekter“ Zustand, sondern ein bewusst bewerteter und kontrollierbarer.
5) Form der Outputs (Deliverables & Formate)
PTF-Report
PDF / DOCX
Gesamtbericht mit Prozess-, Technologie- und Funktionsübersicht
PTF-RISK
Excel / JSON
Risikoliste mit Bewertung und Maßnahmen
PTF-MODEL
XML / PLCopen
Strukturierte Maschinendefinition (Plant, HWZ, SEQ, Zonen, Parameter)
PTF-FUNC
XML / PDF
Funktionsblätter und Prüfprotokolle
PTF-NORM
Normen- und Vorschriftennachweis
PTF-RELEASE
Signiertes Dokument
Offizielle Freigabe für Modellierung
PTF-HMI
JSON / CSV
Texte, Meldungen, Farben, Bedienabläufe
PTF-Q
Excel / PDF
Qualitätsplan, Prüfpunkte, SPC-Grenzen
6) Verantwortlichkeiten (RACI)
Technischer PTF-Report
PTF-Lead
Projektleitung
Prozess, Technologie, Software
Qualität
Funktionsbibliothek
Software / Automation
PTF-Lead
Technologie
Projektleitung
Risikobewertung
PTF-Lead, Qualität
Projektleitung
alle
Management
Abweichungsliste
PTF-Lead
Projektleitung
Prozess, Technologie
Qualität
Normenbewertung
Sicherheit / Qualität
Projektleitung
Technologie
Management
Freigabe / Release
Projektleitung
Management
PTF-Lead
alle
7) Übergabe an die Selmo-Modellierung
Nach Freigabe wird der PTF-Output:
als Paket an das Selmo-Studio übergeben,
in die Modellstruktur importiert (Plant → HWZ → SEQ → Zonen),
automatisch in Bit-Control und HMI umgesetzt,
und mit der PTF-Version verknüpft (Traceability).
→ Jede Zone, jedes Signal, jede CMZ oder MXIC-Bedingung kann später direkt auf den zugehörigen PTF-Eintrag zurückgeführt werden.
8) Qualitäts- und Abschlusskriterien
Ein PTF-Output gilt als vollständig und freigegeben, wenn:
Alle technischen Artefakte erstellt, geprüft und freigegeben sind
Alle Risiken und Abweichungen dokumentiert und bewertet sind
Die Selmo-Struktur vollständig abbildbar ist
Normen- und Richtliniennachweise enthalten sind
Die kaufmännische Bewertung abgeschlossen ist
Das Freigabedokument unterzeichnet ist
Abschlussformel: „Das System ist PTF-vollständig, Selmo-kompatibel und für die Modellierung freigegeben.“
9) Nutzen und Bedeutung
Der PTF-Output ist der verbindliche, nachweisbare Brückenschlag zwischen Engineering und Software. Er sorgt für:
Determinismus in Verhalten und Steuerung,
Transparenz in Verantwortung und Risiko,
Wiederverwendbarkeit durch Standardisierung,
Nachvollziehbarkeit über den gesamten Lebenszyklus.
Damit wird der PTF nicht nur zur technischen Spezifikation, sondern zur organisatorischen Sicherheitslinie im Projekt.
10) Kurzform für Präsentationen / Kick-off
Der Output des PTF ist der digitale Zwilling der Maschine – bevor sie gebaut ist.
Er enthält alle Informationen, um das Selmo-Prozessmodell zu erzeugen, alle Funktionen, um deterministisch zu steuern, und alle Bewertungen, um Risiken bewusst zu managen.
→ Was nicht Selmo-konform ist, wird sichtbar. → Was dokumentiert ist, wird prüfbar. → Was freigegeben ist, wird deterministisch.
Customer
Definition: Customers sind alle Rollen, die den PTF-Output aktiv nutzen, um ihre Aufgaben zu erfüllen.
Hauptgruppen & Nutzen:
Projektleitung: Planung, Freigabe, Transparenz
Prozessverantwortlicher: Nachvollziehbarer Ablauf
Mechanik / Elektro: Sichere Signaldefinition, Schnittstellen
Software / Automation: Grundlage für Selmo-Modellierung
Qualität / Sicherheit: Nachweis & Risikobewertung
Management: Wirtschaftliche Entscheidungsgrundlage
Kunde / Betreiber: Dokumentation, Vertrauen, CE-Nachweis
Kernnutzen: Jeder Stakeholder erhält prüfbare, nachvollziehbare Informationen für seine Verantwortung.
SIPOC – Customer im Selmo-PTF
1) Definition
Customer im PTF-Kontext sind alle Rollen oder Organisationseinheiten, die den freigegebenen PTF nutzen, um
ihre eigenen Aufgaben auszuführen,
Risiken zu reduzieren,
Entscheidungen zu treffen oder
den Lebenszyklus einer Maschine sicher zu steuern.
Der PTF ist also nicht nur Input für die Softwareentwicklung, sondern ein zentrales Führungs- und Nachweisdokument für das gesamte Projektteam – von der Technik bis zum Management.
2) Ziel
Klarheit schaffen, wer welchen Nutzen aus dem PTF zieht
Verantwortlichkeiten und Abhängigkeiten definieren
Transparenz über Risiken, Schnittstellen und Freigaben herstellen
Nachvollziehbarkeit über den gesamten Maschinenlebenszyklus sichern
Der PTF macht jede Rolle sichtbar – und gibt jeder Rolle ein Werkzeug, um ihre Verantwortung faktenbasiert wahrzunehmen.
3) Übersicht: Alle Stakeholder eines Selmo-Projekts
Projektsteuerung
Projektleitung, PTF-Lead
PM, PTF-Manager
Koordination, Termin, Qualität, Freigabe
Prozess & Produkt
Prozessverantwortlicher, Industrial Engineer
Process Owner
Prozessdefinition, Zielzustände, Parameter
Technik (Mechanik)
Konstrukteur, Anlagenplaner
ME / Konstruktionsleiter
Mechanische Umsetzung, Sicherheit, Layout
Technik (Elektro)
Hardwareplaner, E-Plan
EE / Elektroplanung
I/O, Sensorik, Aktorik, Verdrahtung
Automation
Softwareentwickler, Selmo-Modellierer
Automation Engineer
Umsetzung in Sequence, Zonen, Bit-Control
Qualität & Sicherheit
CE, Safety, QM
Safety Officer / QMB
Normenprüfung, Risikobewertung, Nachweise
IT / OT / Daten
MES, ERP, SCADA, Cloud
Data Engineer / OT Architect
Schnittstellen, Datenfluss, IT-Sicherheit
Betrieb / Instandhaltung
Produktion, Service
Operator / Maintenance
Bedienung, Diagnose, Wartung
Management & Controlling
Geschäftsführung, Einkauf
Management, Controller
Wirtschaftlichkeit, Nachvollziehbarkeit
Kunde / Endanwender
Betreiber, Auditor
OEM / End Customer
Verfügbarkeit, Nachweisführung, Sicherheit
4) Customer-Gruppen und Nutzen aus dem PTF
4.1 Projektleitung / PTF-Lead
Warum sie den PTF brauchen: Um das Projekt methodisch, risikobasiert und transparent zu steuern.
Was sie bekommen:
Vollständigen Überblick über Prozess, Technologie, Funktion und Risiko
Klare Freigabepunkte und Meilensteine
Dokumentierte Schnittstellen und Verantwortlichkeiten
Bewertete Risiken und Restrisiken
Nutzen:
Planbarkeit, Qualitätssicherung, Reduktion von Nacharbeiten
Nachweis der Engineering-Prozesse (Auditfähigkeit)
Projektverantwortung rechtlich und organisatorisch abgesichert
4.2 Prozessverantwortlicher / Industrial Engineering
Warum: Er trägt die Verantwortung für den realen Prozessablauf und seine Effizienz.
Was er bekommt:
Transparente Beschreibung aller Prozessschritte und Zustände
Parameterlisten mit Toleranzen und Grenzwerten
Nachvollziehbare Verknüpfung zwischen physikalischem Prozess und Steuerungslogik
Nutzen:
Klare Übergabe an Technologie und Automation
Frühzeitige Risikoerkennung bei Prozessänderungen
Nachweis der Prozessqualität und -stabilität
4.3 Mechanik- und Elektrokonstruktion
Warum: Ihre Konstruktionen müssen deterministisch in den Steuerungsprozess integriert werden.
Was sie bekommen:
Verknüpfung zwischen physischer Komponente (z. B. Zylinder, Sensor) und logischem Zustand
I/O-Liste mit Zonen- und CMZ-Zuordnung
Rückmeldung bei Nicht-Selmo-konformen Signalen
Nutzen:
Früherkennung von Inkonsistenzen zwischen Mechanik, Elektro und Software
Sicherstellung der Umsetzbarkeit und Konformität
Nachweis der sicherheitsgerichteten Funktionen
4.4 Automation / Softwareentwicklung
Warum: Sie erzeugen aus dem PTF das Selmo-Modell und damit den Code.
Was sie bekommen:
Vollständige, freigegebene Prozessdefinition
Strukturierte Selmo-Architektur (Plant, HWZ, SEQ, Zonen, Parameter, Bit-Control)
Funktionsblätter und Testfälle
Nutzen:
Eindeutige, interpretierfreie Umsetzung
Formal verifizierbarer Code
Minimierte Implementierungs- und Debugging-Zeit
Direkte Traceability zwischen Modell und PTF
4.5 Qualität / Sicherheit / CE
Warum: Sie müssen Normenkonformität, Funktionale Sicherheit und Risikominimierung nachweisen.
Was sie bekommen:
PTF-Risikobewertung (PTF-RISK)
Dokumentation der Schutzmaßnahmen, CMZ, MXIC, Interlocks
Abweichungsliste (technisch & organisatorisch)
Nutzen:
Vollständiger Audit-Nachweis
Klare Zuordnung von Risiken und Verantwortlichkeiten
Minimierung rechtlicher Haftungsrisiken
CE-Dokumentation direkt aus dem PTF ableitbar
4.6 IT / OT / Datensysteme
Warum: Weil sie Schnittstellen und Datenflüsse bereitstellen, die sicher und deterministisch sein müssen.
Was sie bekommen:
Schnittstellenbeschreibung (PTF-IF)
Kommunikationsdefinitionen (Protokolle, Topics, Payloads)
Anforderungen an Datenqualität und -sicherheit
Nutzen:
Reproduzierbare Datenflüsse
Nachvollziehbare Kopplung zwischen Produktion und IT
Normenkonformität nach IEC 62443
4.7 Betrieb / Instandhaltung
Warum: Sie nutzen das System im Alltag und sind für Sicherheit und Verfügbarkeit verantwortlich.
Was sie bekommen:
HMI-Struktur mit Zuständen, Farben, Meldungen (PTF-HMI)
Diagnose- und Handbetriebslogik (MXIC, CMZ, Interlocks)
Dokumentierte Prozess- und Fehlerreaktionen
Nutzen:
Transparente Bedienung und Fehlersuche
Reduktion von Stillstandszeiten
Nachweis der sicheren Bedienung
4.8 Management / Controlling
Warum: Weil sie Investitionssicherheit, Prozessreife und Wiederverwendung bewerten müssen.
Was sie bekommen:
Gesamtüberblick über Projektstatus und Reifegrad
Kosten-/Nutzen-Betrachtung aus PTF-Bewertungen
Transparente Risikolage
Nutzen:
Planbarkeit und Wirtschaftlichkeit
Reduktion versteckter Aufwände
Nachweis für Governance, Compliance und Qualität
4.9 Kunde / Betreiber / Endanwender
Warum: Weil er die Maschine später betreibt, auditiert oder abnimmt.
Was er bekommt:
Dokumentierte, nachvollziehbare Prozessbeschreibung
Nachweis der deterministischen und sicheren Steuerung
Vollständige Traceability von Anforderungen bis Code
PTF als Bestandteil der CE-Dokumentation
Nutzen:
Vertrauen in Funktion, Sicherheit und Qualität
Klare Nachvollziehbarkeit bei Änderungen und Service
Vereinfachte Wartung und Schulung
5) Zusammenfassung: Wer nutzt den PTF wofür?
Projektleitung
Steuerung, Freigabe, Nachweis
Kontrolle, Transparenz
Prozess
Definition, Parameter, Effizienz
Prozessqualität
Mechanik / Elektro
Integration, Signaldefinition
technische Umsetzbarkeit
Software / Automation
Modellierung, Code
deterministische Steuerung
Qualität / Sicherheit
Bewertung, Nachweis
Risiko- und Normenkonformität
IT / OT
Schnittstellen, Datenaustausch
sichere Kommunikation
Instandhaltung
Bedienung, Diagnose
Betriebssicherheit
Management
Wirtschaftlichkeit, Verantwortung
Entscheidungsgrundlage
Kunde / Betreiber
Betrieb, Audit
Vertrauen und Transparenz
6) Wirkung im Gesamtprojekt
Der PTF schafft für alle Stakeholder:
Vertrauen durch Nachvollziehbarkeit,
Effizienz durch klare Übergaben,
Sicherheit durch dokumentierte Risiken,
Standardisierung durch Wiederverwendbarkeit,
Wirtschaftlichkeit durch Vermeidung von Reibungsverlusten,
Compliance durch formale Konformität zu Normen und Richtlinien.
7) Fazit für das Kick-off
Jeder Stakeholder profitiert vom PTF – der Prozessingenieur durch Klarheit, der Programmierer durch Struktur, der Qualitätsbeauftragte durch Nachweis, das Management durch Sicherheit.
Der PTF ist damit nicht nur ein technisches Dokument, sondern das Verantwortungsmodell eines Projekts. Er übersetzt Prozesswissen in deterministische Steuerung – und macht jede Maschine sicher, prüfbar und erklärbar.
Zuletzt aktualisiert
War das hilfreich?