> 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-as-a-process/selmo-process-modeling/sipoc-process-modeling.md). # SIPOC process modeling **Purpose:**\ Explanation why process modeling is an independent, formal and necessary component of the project. **Key statements:** * Process modeling follows the PTF and implements it technically. * It generates deterministic, documented and verifiable procedures. * It is equivalent to CAD (mechanics) and EPLAN (electrics). * The model does not replace any discipline, but integrates them. * Goal: A formal, fully traceable machine behavior. ## Embedding process modeling into the entire project life cycle. **Key points:** * After PTF approval the formal implementation begins. * Process modeling replaces unstructured programming. * Connection to mechanics & electrics (like drawing/schematic). * Preparation for Digital Twin and commissioning. * Early simulation (SoftFAT) possible. * Benefit: Early detectable errors, reduced commissioning times. **Graphical process:**\ PTF → Modeling → Simulation → Code generation → Commissioning → Operation
🧩 SIPOC – Process modeling in Selmo Supplier #### **S – Supplier (suppliers of the process modeling)** **Definition:**\ Suppliers in the process modeling process are all persons, roles or systems\ that **provide information, data, models or decisions** to **create the formal Selmo process model** . They deliver the content-related, technical and organizational basis\ so that the model can be built completely, deterministically and Selmo-compliant. *** #### **1. Main suppliers of the process modeling** | Category | Role / Function | Delivers | Description / Significance | | --------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **1. PTF lead / Project management** | Responsible for the PTF results | Complete PTF dataset (Process, Technology, Function, Risk) | Provides the released foundation – the PTF is the *starting point* of the modeling | | **2. Process owner (Industrial Engineering)** | Process knowledge & parameter definition | Process description (states, cycle, parameters) | Defines the real process flow that is replicated in the model | | **3. Mechanics / Design** | Layout, kinematics, end positions, components | Structural information (zones, hardware assignment) | Provides the logical mapping of the physical machine | | **4. Electrics / Control (E-Plan)** | Sensors, actuators, addressing | Signal structure (inputs, outputs, CMZ level) | Basis for creating the zones and their bit-control | | **5. Automation / Software (Selmo modeler)** | Modeler of the process behavior | Model logic, states, linkages | Creates the deterministic process model from PTF and hardware structure | | **6. IT / OT / MES / ERP** | Interfaces and data flows | Communication definition (tags, topics, payloads) | Ensures that the model communicates with systems | | **7. Quality / Safety / CE** | Standards, safety requirements, test rules | CMZ, MXIC, interlock requirements | Defines safety-relevant logic for sequence and hardware zones | | **8. Customer / Operator** | Process goal, functional requirement, operator logic | Function description & HMI requirements | Provides requirements for behavior and operator guidance | *** #### **2. Supporting / secondary suppliers** | Role | Delivers | Purpose | | ---------------------------------- | ------------------------------------ | ----------------------------------------------------- | | **Data management / IT** | Version control, structuring | Management of model versions | | **Project management** | Scheduling, review cycles | Coordination of the modeling process | | **Simulation / Digital Twin team** | Simulation model (for SoftFAT) | Validation of the process logic before real operation | | **Maintenance / operations** | Operator and diagnostic requirements | Feedback for HMI and function displays | *** #### **3. Artifacts that suppliers must provide** | Artifact | Description | Source (supplier) | | -------------------------------------------- | ---------------------------------------------------------------------- | ---------------------- | | **PTF-XML / JSON** | Complete, released data basis from PTF (Process, Technology, Function) | PTF lead | | **I/O list (CSV / EPLAN)** | Addressing and signal structure | Electrical | | **Technology matrix (Excel / PDF)** | Overview of the devices and interfaces used | Mechanics / Electrical | | **Function sheets (XML / PDF)** | Function definitions, triggers, test cases | Automation | | **Parameter list (CSV)** | Process parameters with limit values | Process / Quality | | **Risk assessment (Excel / PDF)** | Documented non-Selmo conformities | Quality | | **Safety concept (CMZ / MXIC / interlocks)** | Structure and safety logic | CE / Safety | | **Interface description (JSON / YAML)** | MES, ERP, cloud or robot connections | IT / OT | | **HMI template (CSV)** | Texts, colors, diagnostics | Operator / Automation | *** #### **4. Quality criteria for supplier data** Every supplier delivery for modeling must: * **be formally released** (status: *Released* in the PTF) * **be complete** (no open parameters, addresses or states) * **be consistent** (process states ↔ hardware ↔ functions) * **deterministic** be defined * **(no ambiguity in logic or signal behavior)** comply with standards * **(be machine-readable, e.g. XML, JSON, CSV)** be available in machine-readable form (e.g. XML, JSON, CSV) *** #### **5. Check questions for supplier approval** Before starting process modeling the PTF lead must ensure: * [ ] Is the **released PTF report** available? * [ ] Are all **functions described mathematically or logically**? * [ ] Is the **I/O list complete and unambiguously** addressed? * [ ] Have **safety functions (CMZ, MXIC, interlocks)** been documented? * [ ] Are **interfaces (MES, ERP, robotics)** technically specified? * [ ] Are all **Are process parameters and states** provided with limit values? * [ ] Are there **no open risk points** without an action plan? * [ ] Has the **import test in Selmo Studio** been successfully validated (data readable)? *** #### **6. Conclusion – role of the suppliers in process modeling** The suppliers provide the **entire information basis** for the modeling.\ The modeler (automation) **does not make their own assumptions**,\ but works exclusively with **formal, released data from the PTF and engineering**. > The PTF is the blueprint,\ > the suppliers are the material providers,\ > and the Selmo modeler builds from them the functioning, deterministic system.
🧩 SIPOC – Process modeling in Selmo Input #### **I – Input (inputs for process modeling)** *** #### **1. Definition** **Input** denotes all **technical, logical and documented information**,\ that are required to create a **complete, deterministic process model in Selmo Studio** . Each input is an **element of the model structure**, which directly or indirectly originates from the **released PTF** The inputs form the basis for: * Building the logical structure (Plant / HWZ / SEQ / Zone), * Definition of states, parameters and signals, * Automatic generation of control code, HMI and diagnostic functions. *** #### **2. Main inputs for process modeling** | Category | Description | Source (from PTF / supplier) | Usage in the model | | ----------------------------------- | --------------------------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------- | | **1. Structure definition** | Hierarchy of the machine (Plant → Hardware Zones → Sequences → Zones) | PTF-SCOPE, PTF-TECH, Mechanics / Project management | Sets the project structure, responsibilities and system boundaries | | **2. Signal definition (I/O list)** | List of all input, output and in/out signals with CMZ level | PTF-IO, Electrics / Control | Generates zones, signal types and monitoring rules in the system layer | | **3. Bit-control assignment** | Logical relationship between state and signal | PTF-FUNC, Automation / Software | Control and monitoring tables in the system layer (0, i, S) | | **4. CMZ configuration** | Constantly Monitoring Zones for Plant, HWZ, SEQ | PTF-SAFE, Quality / Safety | Defines permanent signal monitoring and safety logic | | **5. MXIC configuration** | Manual Cross Interlock – interlock conditions in manual operation | PTF-SAFE, Safety / Automation | Safety in manual operation: allows / blocks manual actions | | **6. Parameter definition** | Process parameters with units, limits and default values | PTF-PARAM, Process / Quality | Completes the parameter layer in each sequence | | **7. HMI data** | Texts, colors, diagnostics, messages for states and zones | PTF-HMI, Maintenance / Automation | Display layer in the HMI generator (automatically generated from the model) | | **8. Function definition** | Mathematical / logical functions for actions or monitoring | PTF-FUNC, Automation / Software | Links sequence logic with concrete behavior (e.g. adder, timer) | | **9. Interface description** | MES/ERP/robotics/cloud connections, variables and data types | PTF-IF, IT / OT | Integration of data layer, higher-level communication | | **10. Risk assessment / standards** | Deviations, standard requirements, PLr/SIL evidence | PTF-RISK, PTF-NORM, Quality / CE | Documentation of restrictions, warnings, measures in the model | *** #### **3. Structure input in detail (backwards from Selmo Studio)** **Plant (plant level)** * Definition: entire machine / line * Includes: * Plant name, identification, version * CMZ definition (Total Safety Watch) * cross-cutting interfaces (MES, ERP, SCADA) * Overall parameters (e.g. cycle time, main controller, power supply) * Source: PTF-SCOPE, PTF-SAFE, PTF-IF **Hardware zone (HWZ)** * Definition: physical part of the plant, independently controllable * Includes: * Operating modes (manual / automatic) * Safety logic (zone-related CMZs) * Start / stop logic * Zone structure (sequences, sensors, actuators) * Source: PTF-TECH, PTF-IO, PTF-SAFE **Sequence (SEQ)** * Definition: logical sequence of a process (e.g. "insert", "clamp", "machine") * Includes: * States (state, timer-state, decision, jump etc.) * Linkages (transitions) * System layer (bit-control) * Parameter layer (times, values) * CMZ / MXIC settings * Zone and signal assignment * Source: PTF-PROC, PTF-FUNC, PTF-SAFE, PTF-HMI **Zone** * Definition: smallest unit – mechatronic function (sensor, actuator, in/out or memory zone) * Includes: * Signal name, type (input, output, in/out, mem) * Zone ID, zone text (HMI) * CMZ level, interlock assignment * Operands (0, i, S) for each state in bit-control * Source: PTF-IO, PTF-FUNC, Electrics *** #### **4. Layer-related inputs** | Layer | Content | Data source | Description | | ------------------------------ | -------------------------------------- | ----------------- | -------------------------------------------- | | **Logic layer** | States, transitions, logical decisions | PTF-PROC | forms the logical flow | | **System layer (bit-control)** | Signal behavior per state (0, i, S) | PTF-FUNC / PTF-IO | describes the behavior in automatic mode | | **parameter layer** | Process parameters, setpoints | PTF-PARAM | supplement modeled procedures with variables | | **HMI layer** | Texts, colors, messages | PTF-HMI | for operator guidance and diagnostics | | **Safety layer (CMZ / MXIC)** | Safety logic | PTF-SAFE | ensures safe behavior in all operating modes | *** #### **5. Structure-relevant inputs for project management** The model structure is not only a technical element\ but also serves as **Work breakdown structure (WBS)** for tasks, responsibilities and progress: | Structure level | Significance in project management | Benefit | | --------------- | ---------------------------------- | --------------------------------------------- | | **Plant** | Project or overall plant | Top-level structure, overall status | | **HWZ** | Work package or station | Progress and status tracking | | **SEQ** | Subprocess / functional module | Plannable implementation unit | | **Zone** | Component / signal level | Assignment of responsibility, detailed review | Thus each **Sequence** as **independent project object** can be handled –\ with clearly defined inputs, outputs, responsible persons and test cases.\ This facilitates **resource planning, progress tracking and SoftFAT organization.** *** #### **6. Recommended technical input formats** | Type | Format | Usage | | ---------------------------- | ------------------ | ----------------------------------- | | **Structure and model data** | XML / JSON | Import into Selmo Studio | | **I/O data** | CSV / EPLAN export | Signal import and zone construction | | **Parameter data** | CSV / Excel | Parameter layer and default values | | **Function definitions** | XML / PDF | Function logic and monitoring | | **Safety data (CMZ/MXIC)** | Excel / JSON | Safety layer | | **HMI texts** | CSV / JSON | HMI generator | | **Standards / risk** | PDF / Excel | Documentation & audit trail | *** #### **7. Test and quality criteria for inputs** Before starting modeling the PTF lead must confirm: * [ ] Structure definition complete (Plant, HWZ, SEQ, Zone) * [ ] I/O list complete and unambiguous (no duplicates) * [ ] CMZ and MXIC definition present * [ ] Parameters complete (unit, limit, default value) * [ ] Function sheets complete (triggers, test cases, monitoring) * [ ] HMI texts correctly assigned (zone/state) * [ ] Interfaces to MES/ERP documented * [ ] Risk and standards assessment completed * [ ] All data machine-readable and versioned * [ ] Import test in Selmo Studio successful (no data errors) *** #### **8. Conclusion** The **Input** For process modeling there is not an unstructured data pool,\ but a **clearly defined, hierarchically structured set of information**,\ that can be transferred directly into the **Selmo Studio** model. It contains everything necessary to: * logically describe the machine, * control it deterministically, * and document it automatically. > **Without clean inputs no deterministic model.**\ > The input is the translation of the PTF into formal, modelable data –\ > structured, traceable and verifiable.
🧩 SIPOC – Process modeling in Selmo Process #### **P – Process (flow of the modeling)** *** #### **1. Goal of the modeling process** The modeling process serves to **create the complete, deterministic process model** based on the released PTF.\ It defines the machine in its structure, logic, safety and operation so precisely\ that from it automatically **error-free control code, HMI and diagnostics** can be generated. The model is **the formal description of the machine behavior** —\ equivalent to the technical drawing or the schematic in mechanics and electrics. *** #### **2. Basic principles of Selmo modeling** * **Modularity:** Each sequence (SEQ) is a self-contained functional block. * **Determinism:** Every state and every signal is unambiguously defined. * **Hierarchy:** The structure follows the real machine (Plant → HWZ → SEQ → Zone). * **Completeness:** Every signal state is defined in every state (0, i, S or M). * **Separation of manual and automatic operation:** * **System and logic layer** → Automatic * **MXIC** → Manual operation * **Traceability:** All zones, signals, parameters and safety functions are documented. * **Automatability:** The model directly generates runnable code and HMI. *** #### **3. Phases of the modeling process** | Phase | Goal | Result | | -------------------------- | --------------------------------------------------------------- | ------------------------------------------- | | **1. Structure creation** | Create base structure (Plant, HWZ, SEQ, Zone) | Machine hierarchy fully defined | | **2. Define system layer** | Assign zones and signals to states (bit-control) | Logical signal behaviors defined | | **3. Build logic layer** | Model the sequence flow (states, transitions) | Complete process flow with state definition | | **4. Add parameter layer** | Define non-binary process variables (times, values, tolerances) | Parameterizable flow | | **5. Define CMZ** | Permanently monitored signals (Plant, HWZ, SEQ) | Safety logic active | | **6. Create MXIC** | Define manual operation interlocks | Safe manual operation | | **7. Model SEQCross** | Define synchronization and dependencies between sequences | Coordinated flows | | **8. Test & simulation** | Check logic, system and safety functions | Verified process model | | **9. Generate output** | Generate PLC code, HMI and documentation | Released model output | *** #### **4. Step-by-step procedure** **Step 1 – Structure creation** * The project is created in Selmo Studio. * Build the hierarchy: * **Plant** (entire plant) * **Hardware zones (HWZ)** (stations, modules) * **Sequences (SEQ)** (functional flows) * **zones** (sensors, actuators, in/outs, mems) * Each SEQ receives: * unique ID and description * assigned zones (signals) * defined CMZ level ➡️ Result: **Structure complete and mappable** (Plant → HWZ → SEQ → Zone) *** **Step 2 – Define system layer** * Creation of the **Bit control table**: * assignment of zones to states with the operands: * `0` → Don’t care / no action * `i` → Interlock (monitoring) * `S` → Sequence check (expected action or feedback) * `M` → Mem / memory bit / auxiliary status * All signals from the I/O list are assigned to the zones. * For each zone CMZ level and type (input, output, in/out, mem) are specified. * This means the **behavior of the plant in automatic operation** is formally described. ➡️ Result: **complete system layer with bit-control logic** *** **Step 3 – Build logic layer** * Definition of the logical states (states): * Start, timer-state, decision, jump, sequence-cross, repeater * Mapping the process flow through state transitions (transitions). * Linking to the system layer via bit-control. * Modeling the standard behavior: start → flow → end → repetitions / aborts. * Ensure that each state: * has unambiguous activation conditions, * meets transition conditions, * has abort and error paths defined. ➡️ Result: **complete deterministic flow per sequence** *** **Step 4 – Add parameter layer** * Import parameters from PTF-PARAM. * Definition of input, display and output parameters: * times, speeds, forces, paths, repetitions. * Parameters are logically assigned to sequences or states. * Optional: limit monitoring with CMZ or SEQ-check. ➡️ Result: **parameterizable sequence with clear boundaries and variables** *** **Step 5 – Define CMZ (Constantly Monitoring Zone)** * Selection of the signals that must be monitored permanently: * Plant CMZ → Entire system (e.g., main pressure, power supply) * HWZ CMZ → Station safety (e.g., safety door, interlock) * SEQ CMZ → Process monitoring (e.g., sensor status, Not-OK bit) * CMZ fault leads to automatic deactivation of the affected unit. * Manual movement is blocked while a CMZ fault is active. ➡️ Result: **cross-system safety monitoring active** *** **Step 6 – Create MXIC (Manual Cross Interlock)** * After completion of the System layer: * Define zone buttons in manual mode (MXIC table) * Define conditions under which manual actions are allowed * In manual mode, MXIC checks: * whether safety conditions are met * whether other movements are interlocked * In case of rule violation: movement blocked, diagnostic message active. ➡️ Result: **safe, traceable manual mode** *** **Step 7 – Model SEQCross** * Defines **synchronization and dependencies between sequences**. * Example: * “Close gripper” (SEQ 1) starts only when “Part position reached” (SEQ 2) is active. * SEQCross ensures: * parallel or dependent sequences, * controlled handovers, * modular system design. * All SEQCross logics are modeled formally and deterministically. ➡️ Result: **multiple SEQs operate safely synchronized** *** **Step 8 – Test & Simulation** * Model verification in Selmo Studio (Model Validator): * states, transitions, bit-control consistency * CMZ/MXIC check * logical completeness * Link to Digital Twin (if available): * SoftFAT / simulation of signal reactions * Integration tests with MES / ERP * Output of test logs (OK / Error / Warning). ➡️ Result: **verified, simulation-capable model** *** **Step 9 – Generate output** * Automatic generation: * **PLC code** (IEC 61131-3, Structured Text) * **HMI data** (texts, messages, states) * **diagnostics and safety logic** * **Documentation** (process flow, signal behavior, CMZ/MXIC tables) * All artifacts are versioned and traceable to the model state. ➡️ Result: **released, documented model output – ready for commissioning** *** #### **5. Quality and review criteria per phase** Before transitioning to the next phase, the following applies: * [ ] All relevant layers complete (Logic, System, Parameters, Safety, HMI) * [ ] No open CMZ/MXIC definitions * [ ] SEQCross logically correct and tested * [ ] Automatic and manual modes verified * [ ] Import into Digital Twin successful (if available) * [ ] Model export produces no errors * [ ] Review documentation approved *** #### **6. Outcome of the process** A complete **Selmo process model**, which: * that includes all sequences, states, parameters, and safety logics, * was generated from validated PTF data, * is deterministic, verifiable, and documented, * generates executable code, HMI, and diagnostics, * and can be directly transferred into a simulation or commissioning. > **With Logic, System, and Bit-Control, automatic mode is defined.**\ > **With MXIC and CMZ, safety is ensured.**\ > **With SEQCross, the machine becomes a system.**
🧩 SIPOC – Process modeling in Selmo Output #### **O – Output (results of the modeling)** *** #### **1. Goal of the outputs** The outputs of the process modeling are the **complete, deterministic image of the machine** – formal, traceable, documented, and executable. Each output is **verifiable**, **versioned** and **traceable** to the requirements from the PTF. They form the basis for: * Code generation, * Operation (HMI), * Commissioning, * diagnostics, * Service, * and audits. *** #### **2. Overview of outputs** | No. | Output | Description | Format / medium | Primary users | | ------ | ----------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------- | --------------------------------- | | **1** | **PLC code** | Automatically generated control code from the model (IEC 61131-3, ST) | `.ST`, `.PLCopenXML` | PLC / Automation | | **2** | **HMI project** | Automatically generated user interface – based on Selmo structure (Plant, HWZ, SEQ, zones, parameters) | `.JSON`, `.CSV`, `.XML` (for HMI generator) | Operators, maintenance | | **3** | **Documentation (Model Report)** | Complete documentation of the process model incl. logic, system, parameters, safety | `.PDF` / `.HTML` | Quality, audit, CE | | **4** | **Model structure (Selmo Model File)** | Complete, versioned model (Plant → HWZ → SEQ → Zone → Bit-Control) | `.SEL`, `.XML`, `.JSON` | Development, simulation | | **5** | **Function library (Selmo Function Set)** | Documented, standardized function blocks (e.g., adder, timer, checker) | `.XML` / `.PDF` | Automation, reuse | | **6** | **Technology documentation** | Overview of all components, interfaces, zones, CMZ, MXIC used | `.PDF` / `.CSV` | Mechanics, electrical, operations | | **7** | **Safety documentation (CMZ/MXIC)** | All safety definitions and linkages from the model | `.PDF` / `.CSV` | CE, quality, audit | | **8** | **Diagnostics and error lists (HMI/Log)** | List of all automatically generated messages, states, deviations | `.CSV` / `.JSON` | Service, maintenance | | **9** | **Parameter files** | Process parameters, limits, default values, change limits | `.CSV` / `.JSON` | Operators, QA, MES | | **10** | **Digital Twin export** | Structured dataset for connecting with simulation systems | `.JSON`, `.FMU`, `.XML` | Simulation / SoftFAT | | **11** | **Standards and proof documentation** | Compilation of standards, safety, and process evidence | `.PDF` | Audit, quality, customer | *** #### **3. Description of the key outputs** **1️⃣ PLC code** * Automatically generated control code from the model. * Fully deterministic (every logic and every state is formally defined). * No manual post-processing required. * Executable on all PLC systems that support IEC 61131-3. * Adjustments only via Selmo parameters or function interfaces. **Benefits:** * Formally correct, standards-compliant code without interpretation errors. * Time savings and quality assurance in engineering. *** **2️⃣ HMI project** * HMI structure follows the model exactly: * Plant → HWZ → SEQ → Zone. * Displays for states, parameters, diagnostics, and operating commands. * Background colors, message texts, and symbols automatically generated. * Uniform diagnostics philosophy: * **Blue** = active action (S), * **Red** = deviation (i), * **Gray** = inactive (0). **Benefits:** * Uniform, traceable operating logic. * Reduced HMI engineering effort. * Direct traceability to the zone logic. *** **3️⃣ Model documentation** * Automatically generated report with: * Model structure (Plant → HWZ → SEQ → Zone) * State diagrams (Logic layer) * Bit-control tables (System layer) * CMZ / MXIC assignments (Safety layer) * Parameter tables * HMI text references * Standards and risk references * Comparable to a **circuit diagram or mechanical drawing**. **Benefits:** * Complete technical traceability. * CE-compliant documentation. * Basis for audit and maintenance. *** **4️⃣ Selmo model file (.SEL / .XML / .JSON)** * Contains all layers of the model: * Logic, System, Parameters, Safety, HMI. * Versioned with change history (model state, date, author). * Serves as an interface for: * code generator * HMI generator * Digital Twin * documentation system **Benefits:** * Uniform, machine-readable format. * Integration into toolchains (versioning, simulation, code). *** **5️⃣ Function library** * Each function is formally described: * inputs, outputs, behavior, boundary conditions. * Reusable for future projects. * All functions are tested and documented. **Benefits:** * Standardization and reduction of engineering effort. * Clear functional evidence for audit and safety. *** **6️⃣ Technology documentation** * Overview of all physical and logical elements: * sensors, actuators, zones, CMZ, MXIC, function linkages. * Automatically generated from PTF and model. **Benefits:** * Clear plant structure. * Transparency for operations, maintenance, and audit. *** **7️⃣ Safety documentation** * All CMZ, interlock, and MXIC rules are documented. * Representation of states, interlocks, and abort logics. * Reference to PTF-RISK and PTF-SAFE. **Benefits:** * Complete CE evidence. * Safety traceable and verifiable. *** **8️⃣ Diagnostics / HMI messages** * Automatically generated error messages, status displays, and texts. * Each zone → its own diagnostic point. * Standardized messages: * *“Zone shows deviation”*, * *“Press button”*, * *“Signal missing”*. **Benefits:** * Uniform operating philosophy. * Faster error localization. * Training-friendly, logical structure. *** **9️⃣ Digital Twin export** * Image of the model in a standardized format (JSON / FMU). * Enables emulation or simulation (SoftFAT). * Connection of control code and virtual hardware. **Benefits:** * Early testing opportunities. * Safer commissioning. * Basis for learning models. *** #### **4. Quality criteria for outputs** All outputs must: * [ ] be generated from approved PTF data * [ ] be generated error-free (Model Validator = OK) * [ ] be versioned (e.g., Model\_v1.3, Code\_v1.3) * [ ] prove formal completeness (all layers included) * [ ] have a test log / validation report * [ ] be documented and archived for audit and service *** #### **5. Summary – Output goals** | Category | Goal | Benefit | | -------------------------- | --------------------------------------------- | ------------------------------------------ | | **Code** | Automated, standards-compliant control | Determinism, safety | | **HMI** | Structured operation, same logic as the model | Consistency, reduction of operating errors | | **Documentation** | Formal traceability | Auditability | | **Model structure** | Uniform data basis | Integration, versioning | | **Functions / Technology** | Reuse & standardization | Efficiency | | **Safety & diagnostics** | Transparent safety logic | CE compliance, operational safety | | **Digital Twin export** | Early simulation & SoftFAT | Quality & time savings | *** #### **6. Conclusion** > The output of Selmo modeling is **the digital counterpart to drawings, circuit diagrams, and function diagrams** – only more precise, formal, and automatically executable. The result is: * **a deterministic model**, * **a safe control code**, * **an automatic HMI structure**, * **complete documentation**, * **an integrated connection to simulation**, * and **a reusable function library.** Thus, modeling yields not just code, but a **complete, intelligent machine image** – technically correct, formally documented, and directly usable for **commissioning, audit, service, and learning**.
🧩 SIPOC – Process modeling in Selmo Customer #### **C – Customer (users and benefits of the process models)** *** #### **1. Definition** **Customer** are all roles, organizations, or systems that **use, review, integrate, or utilize the output of Selmo process modeling in operation.** They benefit directly from: * the **transparent representation of the process logic**, * the **technically complete and formal documentation**, * the **safety and proof chain**, * and the **reusability and standardization**. *** #### **2. Main customers and their benefits** | No. | Role / stakeholder | Uses / receives | Purpose / benefit | | ------ | ------------------------------------------ | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Project management / PTF lead** | Complete process models, reports, test protocols |

- Evidence of successful implementation of the PTF
- Project release and acceptance
- Documented quality and completeness

| | **2** | **Process owner (Industrial Engineering)** | Logic and system documentation, parameterization |

- Check whether the process is implemented technically exactly as specified
- No black-box code, but a traceable model
- Option to optimize the sequence

| | **3** | **Mechanics / Design** | Model structure (Plant → HWZ → SEQ), technology report |

- Verification that the real mechanics are correctly represented in the process model
- Simple error analysis through signal mapping

| | **4** | **Electrical / Control (E-Plan)** | I/O mapping, bit control, CMZ/MXIC documentation |

- Traceable link between circuit diagram and logic model
- Unambiguous signal linkage to hardware

| | **5** | **Software / automation** | Code, model, function library |

- Standardized, reproducible code generation
- Maintainable and documented software architecture

| | **6** | **Quality / Safety / CE** | Safety documentation, risk assessment, CMZ/MXIC tables |

- Complete CE and standards evidence
- No uncontrolled logic changes
- Verifiability of every safety behavior

| | **7** | **IT / OT / MES / ERP** | Interface description, communication structure |

- Easy integration thanks to formal data model
- Uniform connection between automation and IT systems

| | **8** | **Operation / Maintenance / Service** | HMI, diagnostics, technology documentation |

- Transparent operating and error messages
- Fast error localization
- Clear assignment of zone and state

| | **9** | **Management / Controlling** | Project reports, function libraries, risk reduction |

- Planability and budget adherence through clear structure
- Fewer complaints, shorter development times

| | **10** | **Customer / Operator / End user** | Complete process documentation, audit evidence |

- Confidence in function, safety, and traceability
- No “black-box code,” but a formally substantiated process
- Basis for operation, training, and audits

| *** #### **3. Special responsibility: PTF owners and process owners** The **Process owners** (from the PTF) are the **direct recipients and reviewers** of the modeling results. They are: * the **requirements providers** (from the PTF) * the **acceptors** of the process model * and the **guarantors** that the machine **does exactly what was specified.** **Their responsibility:** * Validation of the process model based on the PTF specifications * Review of the sequence and functional logic * Confirmation that the implementation corresponds to the specified process behavior * Documentation of the release (acceptance protocol process model) **Their benefit:** * No more interpretation risk between engineering and software * Complete visibility of machine behavior * Possibility to review processes virtually already * Assurance that standards and safety rules are complied with > The process owner no longer receives a “finished program,” but a **formal, documented, traceable process model –**\ > **that makes visible how the machine thinks and acts.** *** #### **4. Benefits by project phase** | Project phase | Customer | Benefits of the process models | | ---------------------------- | -------------------------------------------------- | -------------------------------------------------------- | | **Planning / engineering** | Project management, process, mechanics, electrical | Transparent structure, defined interfaces, no black box | | **Modeling / software** | Automation, safety | Deterministic implementation, automatic documentation | | **SoftFAT / simulation** | IT / OT, process, quality | Early tests, validation without real hardware | | **Commissioning** | Service, CE, customer | Faster commissioning, fewer errors, clear diagnostics | | **Operations / maintenance** | Operations, maintenance | Transparent operation, standardized HMI, easy adjustment | | **Audit / CE inspection** | Quality, management, customer | Proof of standards compliance and process safety | *** #### **5. Organizational and strategic benefits** **For the company:** * **Fewer development risks:**\ Standardization of logic through modeling instead of individual programming. * **Greater reuse:**\ Functions, zones, sequences can be adopted in other projects. * **Simple training:**\ Formal representation of sequences for training and onboarding. * **Traceability:**\ Every change is versioned, every decision documented. **For the customer / operator:** * **Transparency instead of black box:**\ Every step of the machine is documented and explainable. * **Long-term maintainability:**\ Process models can be understood, extended, and verified – even years later. * **Safety:**\ The formal description guarantees compliance with CE and safety standards. * **Digital twin connectable:**\ Models can be used directly for simulation and optimization. *** #### **6. Communication and release process** 1. **Completion of the model** by Automation 2. **Internal review & simulation** (PTF lead, quality) 3. **Review by process owner** (comparison with PTF) 4. **Release of the process models** (acceptance protocol) 5. **Handover to customer / operator** 6. **Archiving in the project repository** 7. **Use in operation / digital twin / CE documentation** *** #### **7. Conclusion** > With the Selmo process model, the customer does not receive a program, but a **complete, documented, and formally correct process description** – traceable like a circuit diagram, verifiable like a test protocol, and reusable like a standardized function block. **Everyone benefits:** * **Process engineers** – see that their process is implemented exactly. * **Software developers** – have clear structure and logic. * **CE and quality** – have formal evidence. * **Operations and service** – have understandable HMI and diagnostics. * **Customer** – have safety, traceability, and confidence. > **Selmo makes behavior visible.**\ > **And visible means: explainable, verifiable, safe.**
--- # 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-as-a-process/selmo-process-modeling/sipoc-process-modeling.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.