> 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-digital-twin-process/sipoc-digital-twin-process.md). # SIPOC – Digital Twin process ### **S – Supplier (Suppliers of the Digital Twin)** **Objective:**\ Suppliers provide all data, models and definitions necessary for the virtual representation of the machine. | Supplier | Responsibility | Delivers | Description | | --------------------------------- | --------------------------------------- | ------------------------------------------------- | ------------------------------------------ | | **Selmo modeler / Automation** | Formal machine behavior | Selmo process model (Plant, HWZ, SEQ, Zones) | Logic, system, parameters, safety | | **PTF lead / Project management** | Released PTF data | PTF-XML / PTF report | Process definition, technology, parameters | | **Mechanics / Design** | Physical system model | 3D model (STEP, JT, FBX) or kinematics plan | Drilling station with cylinders, motors | | **Electrical / Control (E-Plan)** | Signal and power information | I/O list, wiring, safety linkage | Inputs, outputs, relay circuits | | **IT / OT / Simulation team** | Simulation platform | Tool setup (e.g. TwinCAT, Siemens NX, Unity, FMI) | Linking logic ↔ simulation | | **Process owner (IE)** | Process parameters, real data | Drilling times, tolerances, workpiece data | Comparison real vs. virtual | | **Quality / Safety** | Boundary conditions & test requirements | Safety parameters, test cases | Evaluates validity & fault behavior | *** ### **I – Input (Inputs for the Digital Twin process)** **Objective:**\ All structured data, models and interfaces required for the simulation. | Input | Description | Source / Format | | ------------------------------ | -------------------------------------------------------------------------------- | -------------------------------------------------- | | **Selmo model export** | Structured model file from Selmo Studio (Plant, HWZ, SEQ, Zone, Bit-Control) | `.SEL`, `.XML`, `.JSON` | | **3D model / kinematics data** | Geometric and mechanical structure (drill spindle, cylinders, workpiece fixture) | `.STEP`, `.FBX` | | **I/O list** | Mapping of digital signals to simulation elements | `.CSV` / `.EPLAN` | | **Parameter data** | Process times, rotational speed, feed rate | `.CSV` / PTF | | **Safety rules (CMZ/MXIC)** | Monitoring signals and manual operation conditions | `.CSV` / `.PDF` | | **Interface definition** | Connection to controller or MES | `.JSON`, OPC UA, FMI | | **Simulation platform** | Digital Twin tool / API / communication setup | e.g. Unity, Siemens NX, TwinCAT Simulation Manager | *** ### **P – Process (Procedure for creating the Digital Twin)** **Objective:**\ Create a virtual representation of the machine, link it with logic, test and validate. | Phase | Activity | Result | | --------------------------------- | --------------------------------------------------------------- | --------------------------------------------------- | | **1. Preparation** | Import of the Selmo model and 3D or kinematics data | Basic structure (Plant, HWZ, SEQ) present virtually | | **2. Signal mapping** | I/O mapping between model (Bit-Control) and simulation elements | Digital signals correctly connected | | **3. Logic linking** | Synchronize logical states ↔ physical movements | Simulation responds to states | | **4. Parameterization** | Insert process parameters (t\_ramp-up, t\_drilling) | Simulation runs with realistic times | | **5. Safety implementation** | Activate CMZ and MXIC behavior | Simulation stops on safety violation | | **6. Test runs (SoftFAT / vIBN)** | Perform virtual commissioning | Automatic cycle runs virtually | | **7. Validation** | Comparison between virtual and real data | Deviations documented | | **8. Review & handover** | Acceptance protocol Digital Twin | Digital Twin released | *** ### **O – Output (Results of the Digital Twin process)** **Objective:**\ Virtual representation, test results, evidence and linkages for operations, quality and learning. | Output | Description | Format / Use | | ------------------------------------------ | ------------------------------------------------------- | ------------------------ | | **Virtual machine model** | Complete 3D or logic model of the drilling station | `.STEP`, `.FMU`, `.JSON` | | **Simulation file (Digital Twin package)** | Combined model file with logic, parameters, safety | `.FMU`, `.ZIP`, `.XML` | | **SoftFAT protocol** | Evidence of virtual commissioning (test cases, results) | `.PDF` | | **Validation report** | Comparison of real process data with simulation data | `.PDF`, `.CSV` | | **Interface configuration** | Definition of communication points to PLC / MES / ERP | `.JSON`, `.YAML` | | **Parameter and log report** | Process times, cycles, fault reactions | `.CSV` / `.PDF` | | **Audit trail Digital Twin** | Versioning, changes, review data | `.XML`, `.PDF` | *** ### **C – Customer (Users and benefits of the Digital Twin)** | Customer | Role / Area | Benefit | | --------------------------------- | ---------------------- | ------------------------------------------------------------ | | **Project management / PTF lead** | Project control | Check whether the model works correctly – basis for approval | | **Automation / Software** | Development & testing | Tests control code and HMI virtually before commissioning | | **Process owner (IE)** | Validation | Checks whether sequence and parameters are realistic | | **Mechanics / Electrical** | Integration | Detects mechanical or signal conflicts early | | **Safety / CE** | Testing | Verifies whether safety logic (CMZ, MXIC) reacts correctly | | **Operations / Service** | Training & maintenance | Simulation serves as a training and diagnostic tool | | **Customer / Operator** | Acceptance / Trust | Can understand machine behavior before it is built | | **IT / OT / MES** | Data integration | Test interfaces and data communication in advance | *** ### **Summary: Goal and benefits** | Problem (classic) | Solution through Selmo Digital Twin | Benefit | | ------------------------------------------------ | ---------------------------------------------------- | ---------------------- | | Logic and mechanics only tested at commissioning | Linking model and simulation already before assembly | Early error detection | | Interface problems only visible in the field | OPC UA / MQTT communication is checked virtually | Smooth integration | | Safety behavior hard to test | CMZ and MXIC behavior simulated | Demonstrable safety | | Lack of training opportunity | Simulation serves as a training platform | Efficient onboarding | | No feedback into engineering | Validation data flows back into the PTF | Continuous improvement | *** ### **Conclusion – Why the Digital Twin is an integral part of the Selmo process** > The Digital Twin is the **virtual commissioning and the reality check** of the PTF and the process model. > > It not only checks whether the code runs,\ > but whether the defined behavior – states, parameters, safety – in reality **is implemented reliably and logically correct** . **In short:** * PTF = definition * Process model = implementation * Digital Twin = validation And all three speak the same **formal language**: the **Selmo structure**. *** Would you like me to create for you in the next step, based on this SIPOC, a **checklist for carrying out the Digital Twin process** (comparable to the modeling checklist with inputs, tests, approval and review)?\ This way we could methodically integrate the “Digital Twin” phase directly into your GitBook and project management. --- # 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-digital-twin-process/sipoc-digital-twin-process.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.