> 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-solution/selmo-solution-en/selmo-as-a-process/selmo-ptf.md). # Selmo PTF ### **1. Introduction** Selmo PTF stands for **Structured Execution Logic for Machine Operation** – a method that completely describes machine behavior, documents it formally and deterministically translates it into control code. For Selmo to unfold its full effect, the development process must be defined as precisely as electrical or mechanical designs.\ The **Selmo PTF process** provides the binding framework for this:\ It describes, **what** is developed (process), **with what** it is realized (technology) and **how** how it works (function). PTF stands for: * **P – Process:** Description of the physical and logical sequence * **T – Technology:** Description of the technologies, components and interfaces used * **F – Function:** Description of the individual functions acting in the process The PTF process is thus the **Clarifies the process goal with the customer, provides reliable data for proposal & effort estimation** of Selmo:\ It defines the requirements that are later formally verified in the model and code. *** ### **2. Objective of the PTF process** The PTF process serves the **clear, verifiable and complete description of a machine or plant**, before it is modeled and programmed.\ Goals are: * **Complete traceability** from requirements to behavior * **Unambiguous separation** of process, technology and function * **Deterministic execution** and **formal verification** of the code * **Reduction of complexity** through standardization and reuse * **Automated documentation** and **verifiable functions** * **Responsibilities and interfaces** clearly defined *** ### **3. The PTF approach at a glance** The PTF process is divided into **three levels** that are worked on sequentially and interconnected: | Level | Description | Result | | -------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | **Process** | Definition of the work or production process – physical, logical, sequential. | Process description with states, conditions, parameters | | **Technology** | Definition of the technologies, components, interfaces and sensing/actuation used. | Technology matrix with all relevant devices and connections | | **Function** | Definition of the generic functions to be executed with inputs, outputs and boundary conditions. | Function library with documented, verifiable functions | *** ### **4. The PTF as a SIPOC process** According to the lean principle (Supplier – Input – Process – Output – Customer) the PTF process is clearly structured: | element | Description | Example | | ----------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------- | | **Supplier** | Who supplies the input? | Process owner, designer, customer | | **Input** | What information is required? | Process description, function requirements, technology overview | | **Process (PTF)** | How are process, technology and function described and verified? | PTF documentation, modeling, review | | **Output** | What is produced? | Complete PTF report (process, technology, function), ready for Selmo modeling | | **Customer** | Who uses the result? | Software developers, commissioning, quality management | *** ### **5. Process flow in the PTF** The PTF process follows a **clearly defined sequence** with assigned tasks and responsibilities: #### **Step 1 – Process definition** * Description of the sequence: steps, states, logical transitions * Definition of process-relevant parameters (inputs, times, tolerances) * Clarification of boundary conditions and abort criteria **Result:** Process description with structure diagram (SIPOC + state logic) *** #### **Step 2 – Technology overview** * Definition of all sensors, actuators, control components used * Definition of interfaces to subsystems (e.g. robots, MES, HMI) * Check for determinism and Selmo compliance\ → Every technology must be testable, standardized and deterministically addressable. **Result:** Technology matrix with signal list and interface description *** #### **Step 3 – Function definition** * Description of all functions (e.g. adder, cylinder control, valve monitoring) * Specification of inputs, outputs, limits, monitoring conditions * Definition of trigger conditions (trigger, start, stop, feedback) * Goal: Each function is **fully documented, verifiable and reusable** **Result:** Function catalog with documented standard functions *** #### **Step 4 – PTF review & approval** * Check for completeness and consistency * Acceptance by project management / quality responsible * Approval for modeling in Selmo Studio **Result:** Approved PTF report as basis for modeling *** ### **6. Responsibilities and interfaces** | Role | Task | Deliverable | | -------------------------------------------- | ------------------------------------------------------ | ----------------------------- | | **Process owner** | Delivers process description, parameters, dependencies | Process document | | **Technology owner (electrical/mechanical)** | Delivers sensors, actuators, interface overview | Technology matrix | | **Function owner / software engineer** | Defines functions, limits, tests | Function catalog | | **Selmo modeler** | Generates sequence and zone model from PTF | Process model in Selmo Studio | | **Quality / project management** | Checks and releases the PTF | Release protocol | The **Interface between PTF and modeling** is unambiguous:\ → The PTF delivers **all verified requirements**,\ → the Selmo model implements them **formally and deterministically** into control code. *** ### **7. Completion criteria of the PTF process** A PTF is considered complete when: 1. **process description** is complete and understandable 2. **Technology list** contains all components and interfaces 3. **functions** are defined, documented and verifiable 4. **Responsibilities** are clear 5. **Review protocol** is available 6. **Approval for modeling** has been granted *** ### **8. Importance for project management** The PTF process ensures that every project: * risk rating **has a clear starting point** with complete requirements, * **no interpretation gaps** arise between disciplines (mechanical, electrical, software), * the **Documentation automatically** remains consistent with the model, * the **Risk assessment** is supported by formal traceability, * and the **result is deterministic and verifiable** is. Selmo thereby becomes the **binding regulation for digital machine description** – equivalent to electrical or mechanical design. *** ### **9. Conclusion – Why Selmo PTF** The Selmo PTF is **more than a documentation standard**.\ It is the **methodical basis**, on which modern, safe and traceable automation is built. It turns requirements into a verifiable system,\ technology into a clearly defined architecture,\ and functions into reusable building blocks\ that are executed deterministically – in every machine, every project, every plant. --- # 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-solution/selmo-solution-en/selmo-as-a-process/selmo-ptf.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.