> For the complete documentation index, see [llms.txt](https://selmotech.gitbook.io/selmo-solution/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://selmotech.gitbook.io/selmo-solution/selmo-as-a-process/selmo-ptf/3.-sipoc-struktur-des-ptf.md).

# 3. SIPOC-Struktur des PTF

##

<details>

<summary>Supplier</summary>

</details>

## 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)

<details>

<summary>SIPOC – „Supplier“ im Selmo-PTF</summary>

### 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)

1. Wer ist **Originalquelle** der Information?
2. Wer **entscheidet** bei Zielkonflikten?
3. Wer **unterschreibt** den Input (fachliche Freigabe)?
4. In welchem **Format** wird geliefert (PTF-Artefakt)?
5. Bis wann (**Fälligkeit/Milestone**)?
6. 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.

</details>

## **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.

<details>

<summary>SIPOC – „Input“ im Selmo-PTF</summary>

### 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:

| Ebene              | Input-Typ                  | Beschreibung                                               | Beispiel                                        |
| ------------------ | -------------------------- | ---------------------------------------------------------- | ----------------------------------------------- |
| **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-Input                                 | Empfohlenes Format                     | Beschreibung / Zweck                                                    | Kommentar                                 |
| ----------------------------------------- | -------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------- |
| **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:

| Kriterium           | Beschreibung                                                  | Beispiel                                    |
| ------------------- | ------------------------------------------------------------- | ------------------------------------------- |
| **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`, `.md`
  * **Tabellarische Daten:** `.xlsx`, `.csv`
  * **Strukturierte 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:

| Phase                                           | Input-Fokus                                    | Deliverable                 |
| ----------------------------------------------- | ---------------------------------------------- | --------------------------- |
| **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

```
Input-Record
Bezeichnung: PTF-FUNC-002 „Addierer“
Lieferant (Supplier): Automation
Version: 1.0
Format: Selmo Funktionsblatt (XML)
Kurzbeschreibung: Addiert zwei Real-Werte, überwacht Wertebereich
Input: ValueA, ValueB (REAL)
Output: Sum (REAL)
Grenzwerte: -100.0 ... 100.0
Überwachung: Out of Range → Fehlercode 101
Verifikation: Testfall A=2.0, B=3.0 → Sum=5.0
Freigabe durch: Lead Software Engineering
Status: Released
```

***

### 9) Verantwortlichkeiten (RACI für Inputs)

| Rolle                 | R | A | C                    | I              |
| --------------------- | - | - | -------------------- | -------------- |
| 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.

</details>

## **Process**

**Definition:**\
Der PTF-Prozess beschreibt den Ablauf von der Anforderung bis zur Freigabe.

**Phasen:**

1. Initiierung & Scope
2. Prozessbeschreibung (P)
3. Technologieanalyse (T)
4. Funktionsdefinition (F)
5. Review & Risiko
6. 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.

<details>

<summary>SIPOC – Process im Selmo-PTF</summary>

### 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.

| Phase                                     | Ziel                                                         | Hauptergebnis                  |
| ----------------------------------------- | ------------------------------------------------------------ | ------------------------------ |
| **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:**

1. Beschreibung der zu modellierenden Maschine / Anlage
2. Festlegen des Betrachtungsumfangs (Plant, Hardware-Zonen, Sequenzen)
3. Definition der Liefergrenzen zwischen Disziplinen
4. Einrichtung der PTF-Artefaktstruktur (Verzeichnisse, Templates)
5. 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:**

1. Erhebung des realen oder geplanten Prozessablaufs (Wertstrom, Schritte, Übergänge)
2. Definition der Zustände, Auslöser, Bedingungen und Abbruchkriterien
3. Identifikation aller Prozessparameter (Zeiten, Temperaturen, Kräfte, Wege etc.)
4. Dokumentation im **PTF-PROC** (Prozessbeschreibung)
5. 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:**

1. Erstellung der **Technologiematrix (PTF-TECH)**\
   – Sensoren, Aktoren, Schnittstellen, Medien, Steuerungen
2. Erstellung der **I/O-Liste (PTF-IO)**\
   – Zuordnung zu Zonen, Signaltypen, CMZ-Level
3. Definition der **System- und Datenschnittstellen (PTF-IF)**\
   – MES, Roboter, Safety, Cloud, etc.
4. Bewertung der **Selmo-Konformität:**
   * deterministische Signale?
   * eindeutige Zustände?
   * Rückmeldungen vorhanden?
   * synchronisierbar?
5. 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:**

1. Erstellung von **Funktionsblättern (PTF-FUNC)** für alle logischen Funktionen
2. Definition von Inputs, Outputs, Triggern, Grenzwerten, Überwachungen
3. Zuordnung zu Prozess- und Technologieelementen
4. Erstellung der **Sicherheits- und Überwachungsfunktionen (PTF-SAFE)**
5. 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:**

1. Überprüfung aller PTF-Artefakte (PROC, TECH, FUNC)
2. Identifikation von Nicht-Selmo-konformen Anforderungen
3. Bewertung dieser Punkte im **Risikomanagement (PTF-RISK)**\
   – Einstufung: kritisch / moderat / akzeptabel\
   – Maßnahmen: Anpassung, Vereinfachung, Standardisierung
4. 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:**

1. Abschlussreview mit allen Disziplinen
2. Formale Freigabe aller PTF-Artefakte (Release-Status)
3. Übergabe an Selmo-Modellierung (Sequence, Zone, Bit-Control)
4. Archivierung des PTF-Stands
5. Beginn der Selmo-Modellierung

**Ergebnis:**

* Freigegebener PTF
* Offizielle Grundlage für das Selmo-Modell
* Rückverfolgbarkeit bis zur Codeebene gewährleistet

***

### 5) Prozessverantwortung (RACI)

| Phase                   | R                           | A              | C                     | I                |
| ----------------------- | --------------------------- | -------------- | --------------------- | ---------------- |
| 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.

</details>

## 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.“

<details>

<summary>SIPOC – Output im Selmo-PTF</summary>

### 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:

| Ebene                                  | Beschreibung                                                                | Typische PTF-Daten                                                     |
| -------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **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:

| Element               | Beschreibung                                  |
| --------------------- | --------------------------------------------- |
| 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:

| Bereich                                 | Beispielhafte Normen / Richtlinien                                |
| --------------------------------------- | ----------------------------------------------------------------- |
| **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:

| Kategorie                            | Inhalt                                                                              | Ziel                                                                           |
| ------------------------------------ | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| **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)

| Deliverable     | Format              | Beschreibung / Zweck                                                  |
| --------------- | ------------------- | --------------------------------------------------------------------- |
| **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**    | PDF                 | 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)

| Output                 | R                     | A              | C                              | I              |
| ---------------------- | --------------------- | -------------- | ------------------------------ | -------------- |
| 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:

1. Alle technischen Artefakte erstellt, geprüft und freigegeben sind
2. Alle Risiken und Abweichungen dokumentiert und bewertet sind
3. Die Selmo-Struktur vollständig abbildbar ist
4. Normen- und Richtliniennachweise enthalten sind
5. Die kaufmännische Bewertung abgeschlossen ist
6. 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.

</details>

## 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.

<details>

<summary>SIPOC – Customer im Selmo-PTF</summary>

### 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

| Kategorie                    | Rolle / Funktion                             | Typische Bezeichnung         | Verantwortung im Projekt                   |
| ---------------------------- | -------------------------------------------- | ---------------------------- | ------------------------------------------ |
| **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?

| Rolle                 | Nutzt den PTF für …               | Ziel / Nutzen                 |
| --------------------- | --------------------------------- | ----------------------------- |
| 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.

</details>


---

# 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://selmotech.gitbook.io/selmo-solution/selmo-as-a-process/selmo-ptf/3.-sipoc-struktur-des-ptf.md?ask=<question>&goal=<endgoal>
```

`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.