> 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/einbettung-des-selmo-ptf-in-den-gesamtprojektablauf.md). # Einbettung des Selmo-PTF in den Gesamtprojektablauf ### **1. Grundgedanke** Der **Selmo-PTF (Process – Technology – Function)** ist die **erste und verbindliche Phase** eines jeden Maschinen- oder Anlagenprojekts, da wo das Pflichenheft erstellt wird oder das Konzept.\ Er wird **vor** Mechanik-, Elektro- und Softwarekonstruktion durchgeführt und definiert: * **das Problem (was soll erreicht werden?)** * **den Prozess (wie läuft der Ablauf physikalisch und logisch ab?)** * **die Technologie (welche Mittel, Komponenten, Schnittstellen werden eingesetzt?)** * **die Funktionen (wie wird das Verhalten formal abgebildet und überprüft?)** Der PTF ist somit die **formale Problembeschreibung und Lösungsdefinition**, aus der **alle weiteren Engineering-Disziplinen** ihre Arbeit ableiten.\ Er steht auf derselben Ebene wie **Mechanik-Zeichnung** und **Elektro-Schaltplan**, bildet aber die **digitale Verhaltensbeschreibung** – das **Prozessmodell**. *** ### **2. Position im Projektlebenszyklus** ``` Kundenanfrage ↓ Anforderungsanalyse (Requirements) ↓ → PTF-Prozess (Process – Technology – Function) ↓ Mechanik- & Elektrokonstruktion ↓ Softwareentwicklung (Selmo-Modellierung) ↓ Integration & Inbetriebnahme ↓ Validierung & CE-Dokumentation ↓ Übergabe an Betrieb & Service ``` #### 🔹 Einordnung: * Der **PTF** bildet die **Übergangsphase zwischen Kunde und Engineering**. * Alle Anforderungen (funktional, sicherheitstechnisch, wirtschaftlich) werden **hier verifiziert**, bevor etwas konstruiert oder programmiert wird. * Änderungen sind **in dieser Phase am kostengünstigsten und risikolosesten**. > **Prinzip:**\ > Fehler, die im PTF erkannt werden, kosten Stunden.\ > Fehler, die erst im Code auftreten, kosten Wochen. *** ### **3. Zielsetzung der frühen PTF-Phase** 1. **Problem verstehen, bevor Lösungen entstehen.**\ – Fokus auf Prozessverständnis und Kundennutzen. 2. **Engineering-Konformität herstellen.**\ – Abstimmung aller Disziplinen auf gemeinsame Standards. 3. **Selmo-Konformität sicherstellen.**\ – Nur deterministische, prüfbare Prozessmodelle werden akzeptiert. 4. **Risiken identifizieren und bewerten.**\ – Frühzeitige Risikobewertung (technisch, organisatorisch, wirtschaftlich). 5. **Nachvollziehbarkeit schaffen.**\ – Lückenlose Dokumentation vom Requirement bis zum Code. *** ### **4. Integration in den Engineering-Prozess** | Engineering-Phase | Rolle des PTF | Ergebnis / Nutzen | | ------------------------------ | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | **Pre-Sales / Angebot** | Klärt mit dem Kunden das Prozessziel, liefert belastbare Daten für Angebot & Aufwandsschätzung | Bessere Kalkulation, klare Erwartungshaltung | | **Requirements Engineering** | Formuliert Problemstellung in PTF-Struktur (Prozess, Technologie, Funktion) | Eindeutige, prüfbare Anforderungen | | **Mechanik / Elektro-Design** | Nutzt PTF zur Festlegung der benötigten Komponenten & Signalstruktur | Vermeidung von Fehlkonstruktionen | | **Software / Automatisierung** | Erstellt Selmo-Prozessmodell direkt aus PTF-Output | Vollständige Traceability, kein Interpretationsspielraum | | **Qualität / Sicherheit / CE** | Bewertet PTF-Risiken & Normenkonformität | Nachweisbare Sicherheit & Dokumentation | | **Betrieb / Service** | Nutzt PTF-Dokumentation für Schulung & Diagnose | Transparente Bedienung & Wartung | *** ### **5. Frühzeitige Prüfbarkeit und Änderungsfähigkeit** Da der PTF **vor der Konstruktion** erstellt wird, können: * **Prozessabläufe noch verändert** werden, bevor sie teuer umgesetzt sind, * **Nicht-Selmo-konforme Technologien erkannt** und **angepasst** werden, * **Funktionen standardisiert** und wiederverwendbar gestaltet werden, * **Kosten und Komplexitäten** reduziert werden, * und **Risiken proaktiv bewertet** statt reaktiv behandelt werden. → Damit wird der PTF zum **strategischen Filter**:\ Nur was methodisch, normativ und technisch konsistent ist, darf in die Umsetzung. *** ### **6. PTF als formale Beschreibungssprache des digitalen Engineerings** Mit der Selmo-Methode gilt:\ **Wie die Zeichnung die Mechanik beschreibt, beschreibt der PTF den Code.** | Disziplin | Formale Sprache | Nachweis | Ziel | | ------------------------- | ----------------------------- | ------------------------------------ | ----------------------- | | **Mechanik** | CAD / technische Zeichnung | Stückliste, Maße, Toleranzen | Form und Funktion | | **Elektro** | Schaltplan / E-Plan | Verdrahtung, Stromlauf, Schutzkreise | Energie und Signalfluss | | **Automation / Software** | **Selmo-PTF / Prozessmodell** | Prozess, Logik, Überwachung | Verhalten und Steuerung | → Alle drei Disziplinen sind **gleichwertig**, folgen denselben Grundprinzipien: * Dokumentation * Nachvollziehbarkeit * Prüfbarkeit * formale Korrektheit Damit erfüllt Selmo die Forderungen der **MVO 2027** und anderer Vorschriften nach\ \&#xNAN;**„vollständiger Dokumentation, formaler Prüfbarkeit und deterministischem Verhalten“.** *** ### **7. Umgang mit Abweichungen und Risiken** Während des PTF: * **Nicht-konforme Anforderungen oder Technologien** werden **nicht verworfen**, sondern **transparent dokumentiert und bewertet**. * Jede Abweichung erhält: * eine **Risikoeinstufung** (kritisch / moderat / akzeptabel) * einen **Verantwortlichen** * einen **geplanten Maßnahmenpfad** → So entsteht eine **kontrollierte Risikolandschaft**, die aktiv gemanagt werden kann.\ → Änderungen im PTF sind nachvollziehbar und prüfbar – kein „Stille-Post-Wissen“ im Projekt. *** ### **8. Nutzen der frühen Integration** | Dimension | Nutzen | | ------------------------ | ---------------------------------------------------------------------------- | | **Technisch** | Frühzeitige Erkennung von Konflikten zwischen Mechanik, Elektro und Software | | **Organisatorisch** | Einheitliche Sprache, klare Verantwortlichkeiten | | **Wirtschaftlich** | Geringere Änderungs- und Inbetriebnahmekosten | | **Qualitativ** | Höhere Stabilität, geringere Ausfallrisiken | | **Rechtlich / Normativ** | Nachweisbare Konformität (MVO 2027, CE, ISO 12100 etc.) | | | | Der PTF-Prozess dient dazu: * Das Problem des Kunden exakt zu verstehen, * Den Prozess vollständig zu beschreiben, * Die verwendeten Technologien auf Selmo-Konformität zu prüfen, * Die Funktionen dokumentiert und prüfbar zu definieren, * Risiken, Abweichungen und Normanforderungen frühzeitig zu erkennen. → Ergebnis: Ein vollständiges, prüfbares Maschinenmodell – als Grundlage für Mechanik, Elektro und Software. ### **9. Fazit** > Der **Selmo-PTF** ist der neue Startpunkt jedes Projekts.\ > Er ersetzt unvollständige Lastenhefte durch eine **formale, prüfbare und deterministische Beschreibung**. > > Noch bevor Mechanik gezeichnet oder Schaltpläne erstellt werden,\ > ist klar, **was die Maschine tun soll, womit sie es tut und wie sie sich verhält.** > > Damit wird der PTF zum **Engineering-Standard** –\ > zur **digitalen Zeichnung des Maschinenverhaltens**,\ > normkonform, nachvollziehbar und risikobewusst. --- # 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/einbettung-des-selmo-ptf-in-den-gesamtprojektablauf.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.