> 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-solution/selmo-solution-en/selmo-structure-and-standard/selmo-technical-standard-and-structure/selmo-method-in-practice/difference-between-process-description-and-function-description.md). # 🔍 Difference between process description and function description ## **Why the logical sequence (process) is the basis for functions, code, safety and documentation** ### 🧠 What is a *process* in the machine context? A process is **the logical sequence of states**, that a product or a machine goes through – from start to finish. It’s about the **question: *****When does what happen – and under which conditions?***\ This sequence is **deterministic** and describes **state transitions, sequences, dependencies and decision logic**. **Example:**\ At an assembly station the process is: 1. insert part 2. clamp 3. machine 4. unclamp 5. remove part These steps take place **in a defined order and under defined conditions**.\ → This is the *process* – regardless of *how* how the machine implements it technically. *** ### ⚙️ What is a *Function*? A function describes **the technical implementation of a task** by machine components:\ Example: “Cylinder extends”, “Motor starts”, “Valve switches” etc. Functions are based on: * actuators, sensors, controls * rule-based logic (e.g. IF-THEN in code) * signal evaluation and actuator control → Functions are **reactive, technical, rule-based** – but they do not know **process logic**. They do not know *when* they are due – the process governs that. *** ### 🔄 Difference in practice | Characteristic | **Process (logic, sequence)** | **Function (technology, code)** | | ----------------- | --------------------------------------------- | ----------------------------------------- | | **Goal** | What happens when? | How is something implemented technically? | | **Focus** | states, transitions, conditions | controls, signals, technical execution | | **Example** | After clamping, machining may only take place | “Cylinder extends on command” | | **Structure** | state model, flow diagram, decision logic | function blocks, code logic, rule sets | | **Validation** | Formally verifiable | Technically testable | | **Documentation** | process description | function description | *** ### 🔒 Why is the separation important? #### ✅ 1. **Formal verification** Only a **logical process**, that is described in **states and transitions** can: * **be completely analyzed** (e.g. for deadlocks, concurrency, safety) * **be deterministically validated** be (What always happens *always*? What *never*?) * **be automatically checked** (e.g. by model checkers or simulation runs) **→ Only those who formally describe the process can *****prove*****that their machine works correctly.** *** #### 🧾 2. **Documentation and comprehensibility** A process description: * is **visually and logically comprehensible** (also for non-programmers) * makes the **sequences and states transparent** * forms the **basis for HMI texts, fault diagnosis and training** * shows **what happens where – and why** → Functions or code alone are **not sufficient or too complex for that**. *** #### ⚖️ 3. **Legal certainty and standards compliance** In safety-critical environments (e.g. Machinery Directive, product liability) a manufacturer must be able to demonstrate: * **how the machine reacts in normal operation and in fault conditions** * **that risks are controlled** * **that the behavior is predictable** This is only possible with a **formal process description** – not with function code alone. **Only a documented, traceable process flow is legally robust.** *** ### ✅ Conclusion: “First the process, then the function” The **process description** is the **logical basis** for: * machine functions * control code * safety * diagnosis * evidence/proof * Documentation **No process, no function.**\ → The function is the implementation – the process is the intent and logic behind it. *** ### 📌 For Selmo users: The Selmo method makes exactly that possible: * You model the **process as a deterministic sequence** * From this process model the following is generated automatically: * **bit control** for signal control * **complete HMI diagnosis** * **working control code** * **verifiable safety** → *Model instead of code – process instead of 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-solution/selmo-solution-en/selmo-structure-and-standard/selmo-technical-standard-and-structure/selmo-method-in-practice/difference-between-process-description-and-function-description.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.