> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-struktur-und-standard/selmo-technischer-standard-und-struktur/selmo-methode-praktisch/unterschied-zwischen-prozessbeschreibung-und-funktionsbeschreibung.md). # 🔍 Unterschied zwischen Prozessbeschreibung und Funktionsbeschreibung ## **Warum der logische Ablauf (Prozess) die Basis für Funktionen, Code, Sicherheit und Dokumentation ist** ### 🧠 Was ist ein *Prozess* im Maschinenkontext? Ein Prozess ist **der logische Ablauf von Zuständen**, die ein Produkt oder eine Maschine durchläuft – von Anfang bis Ende. Dabei geht es um die **Frage: *****Wann passiert was – und unter welchen Bedingungen?***\ Dieser Ablauf ist **deterministisch** und beschreibt **Zustandsübergänge, Abfolgen, Abhängigkeiten und Entscheidungslogik**. **Beispiel:**\ In einer Montagestation lautet der Prozess: 1. Teil einlegen 2. Spannen 3. Bearbeiten 4. Entspannen 5. Teil entnehmen Diese Schritte erfolgen **in einer definierten Reihenfolge und unter definierten Bedingungen**.\ → Das ist der *Prozess* – unabhängig davon, *wie* die Maschine das technisch umsetzt. *** ### ⚙️ Was ist eine *Funktion*? Eine Funktion beschreibt **die technische Umsetzung einer Aufgabe** durch Maschinenkomponenten:\ Beispiel: „Zylinder fährt aus“, „Motor startet“, „Ventil schaltet“ etc. Funktionen basieren auf: * Aktoren, Sensoren, Steuerungen * Regelbasierter Logik (z. B. IF-THEN im Code) * Signalauswertung und Aktorsteuerung → Funktionen sind **reaktiv, technisch, regelbasiert** – aber sie kennen **keine Prozesslogik**. Sie wissen nicht, *wann* sie dran sind – das regelt der Prozess. *** ### 🔄 Unterschied in der Praxis | Merkmal | **Prozess (Logik, Ablauf)** | **Funktion (Technik, Code)** | | ----------------- | -------------------------------------------------- | ------------------------------------------- | | **Ziel** | Was passiert wann? | Wie wird etwas technisch umgesetzt? | | **Fokus** | Zustände, Übergänge, Bedingungen | Steuerungen, Signale, technische Ausführung | | **Beispiel** | Nach dem Spannen darf erst bearbeitet werden | „Zylinder fährt bei Befehl“ | | **Struktur** | Zustandsmodell, Ablaufdiagramm, Entscheidungslogik | Funktionsbausteine, Code-Logik, Regelwerke | | **Validierung** | Formal prüfbar | Technisch testbar | | **Dokumentation** | Prozessbeschreibung | Funktionsbeschreibung | *** ### 🔒 Warum ist die Trennung wichtig? #### ✅ 1. **Formale Verifikation** Nur ein **logischer Prozess**, der in **Zuständen und Übergängen** beschrieben ist, kann: * **vollständig analysiert** werden (z. B. auf Deadlocks, Parallelität, Sicherheit) * **deterministisch validiert** werden (Was passiert *immer*? Was *niemals*?) * **automatisch überprüft** werden (z. B. durch Modellchecker oder Simulationsläufe) **→ Nur wer den Prozess formal beschreibt, kann *****nachweisen*****, dass seine Maschine korrekt funktioniert.** *** #### 🧾 2. **Dokumentation und Verständlichkeit** Eine Prozessbeschreibung: * ist **visuell und logisch nachvollziehbar** (auch für Nicht-Programmierer) * macht die **Abläufe und Zustände transparent** * bildet die **Grundlage für HMI-Texte, Fehlerdiagnosen und Schulung** * zeigt **was wo passiert – und warum** → Funktionen oder Code allein sind dafür **nicht ausreichend oder zu komplex**. *** #### ⚖️ 3. **Rechtssicherheit und Normenkonformität** In sicherheitskritischen Umgebungen (z. B. Maschinenrichtlinie, Produkthaftung) muss ein Hersteller nachweisen können: * **wie die Maschine im Normalfall und im Fehlerfall reagiert** * **dass Risiken beherrscht werden** * **dass das Verhalten vorhersehbar ist** Das ist nur mit einer **formalen Prozessbeschreibung** möglich – nicht mit Funktionscode allein. **Nur ein dokumentierter, nachvollziehbarer Prozessablauf ist rechtlich belastbar.** *** ### ✅ Fazit: „Erst der Prozess, dann die Funktion“ Die **Prozessbeschreibung** ist die **logische Grundlage** für: * Maschinenfunktionen * Steuerungscode * Sicherheit * Diagnose * Nachweisführung * Dokumentation **Ohne Prozess keine Funktion.**\ → Die Funktion ist die Umsetzung – der Prozess ist die Absicht und Logik dahinter. *** ### 📌 Für Selmo-Anwender: Die Selmo-Methode macht genau das möglich: * Sie modellieren den **Prozess als deterministischen Ablauf** * Aus diesem Prozessmodell entsteht automatisch: * **Bit-Control** für Signalsteuerung * **vollständige HMI-Diagnose** * **funktionierender Steuerungscode** * **prüfbare Sicherheit** → *Modell statt Code – Prozess statt Chaos.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://infosys.selmotech.com/selmo-struktur-und-standard/selmo-technischer-standard-und-struktur/selmo-methode-praktisch/unterschied-zwischen-prozessbeschreibung-und-funktionsbeschreibung.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.