3. SIPOC structure of the PTF
SIPOC stands for Supplier Input Process Output Customer
Supplier
Definition: Suppliers are the responsible parties who feed input data, documents, or knowledge into the PTF. They provide verified information that serves as the basis for process, technology, and function.
Quality criteria:
Unambiguous, verifiable, deterministic
Versioned, released, documented
Standards-compliant (ISO, CE, MVO 2027)
SIPOC – “Supplier” in the Selmo-PTF
1) Definition
Supplier is the responsible role/organization, the provides binding inputs to the PTF process. These inputs are technically correct, complete, verifiable and versioned – and form the basis for process, technology and function definition as well as the later formal verification in the Selmo model.
Mnemonic: Supplier ≠ “who shouts the loudest”, but who is content-responsible, who owns data sources and who can bear the consequences technically.
2) Principles for identifying a Supplier
A stakeholder is a supplier if they…
…Original source are the original source for an input (e.g. process knowledge, standard requirements, I/O data, interfaces).
…Change authority has authority over this input (may decide technically).
…Delivery obligation commits regarding format, timing, maturity.
…, follow the same basic principles: ensures (limits, tolerances, measurement points, test cases).
…Traceability ensures (version, reason for change, responsible party).
3) Typical Supplier roles in the PTF (with delivered inputs)
Process owner / Industrial Engineering Delivers: process target & takt, value stream, state/process description, stop criteria, process parameters (times, tolerances), quality characteristics.
Process engineer (technologist) Delivers: detailed work sequences, resources, auxiliary materials, inspection plans, measurement points, safety assumptions (PLr/SIL need).
Mechanical design Delivers: kinematics/layouts, bill of materials, media (compressed air, vacuum), safety distances, end positions; mechanical interfaces.
Electrical/control (E-Plan/hardware) Delivers: wiring diagram, I/O list, protection circuits, safety architecture, terminal diagrams, terminal labels.
Automation/Selmo modeling (software) (as supplier for F-inputs) Delivers: Function sheets (e.g. adders), triggers/feedback, limits, error reactions, CMZ/MXIC requirements.
IT/OT & data systems (MES/ERP/SCADA/Cloud) Delivers: Interface description (protocol, topics/tags, payload, QoS), data fields, latency/availability, security requirements.
External technology suppliers (robotics, vision, drives, sensors) Delivers: data sheets, interface/command set, cycle times, accuracy, diagnostics/alarms.
Safety/CE/standards Delivers: applicable standards, risk assessment, PLr/SIL evidence, protective measures.
Quality Delivers: test concept, SPC rules, release criteria, traceability requirements.
Operations/maintenance Delivers: maintenance requirements, HMI operation concept, response times, spare part standards.
Utilities/facility Delivers: media availability (power, air, cooling), limits, connection points.
4) Artifacts/deliverables per Supplier (PTF labeling proposal)
PTF-PROC – Process description (SIPOC, state logic, parameter list)
PTF-TECH – Technology matrix (sensors/actuators, manufacturer, lifecycle data)
PTF-IO – I/O list (address, signal name, zone, CMZ level)
PTF-IF – Interface specification (protocol, topics/tags, field definitions)
PTF-FUNC – Function sheet (e.g. adder): inputs/outputs, domains, limits, error cases, test cases
PTF-SAFE – Safety evidence (PLr/SIL, protective circuits, MXIC/interlocks)
PTF-HMI – HMI texts, operation concept, diagnostic messages
PTF-Q – Quality/acceptance plan (DoE, SPC, limit patterns)
5) Quality & maturity criteria for supplier inputs (Definition of Ready)
Each input must:
Be unambiguous & deterministic (no interpretation gaps, clear states/transitions).
Define domains/limits (min/max, tolerances, units, default values).
Describe error & diagnostic behavior (detection, reaction, return conditions).
Be verifiable (measurement points, test cases, acceptance criteria).
Be versioned & traceable (ID, date, responsible party, reason for change).
Be formally correct (presented using templates/structure as above).
6) RACI framework (typical)
Responsible (R): the respective supplier role per input
Accountable (A): PTF lead / Project management
Consulted (C): adjacent disciplines (e.g. safety, quality)
Informed (I): stakeholders (operations, purchasing, PMO)
7) Supplier checklist (for quick assignment)
Who is Original source the information?
Who decides in case of conflicting goals?
Who signs the input (technical release)?
In which Format is it delivered (PTF artifact)?
By when (due date/milestone)?
How is the , follow the same basic principles: proven (test cases, measurement points)?
8) Entry template (for your process document)
Supplier record
Role/organization: ______________________________
Responsible (name/contact): ___________________
Delivers (artifacts): _____________________________
PTF IDs: ________________________________________
Format/standards: ________________________________
Maturity (draft/review/released): _______________
Due date/milestone: ____________________________
Dependencies: _________________________________
Acceptance criteria/tests: _____________________________
Released by (A): ______________________________9) Mini-examples
Supplier: process engineer (R) Delivers PTF-PROC with takt 18 s, state chain, parameters (press time, temperature), stop criteria; test cases for setpoint/actual comparison. A: PTF lead; C: quality, safety.
Supplier: IT/MES (R) Delivers PTF-IF (REST/MQTT, field list “OrderId, Variant, Result, TraceId”, retry/timeout), data quality rules. A: PTF lead; C: Automation.
Input
Definition: Inputs are the formal information provided by the suppliers. They describe what is analyzed, checked and transferred into the Selmo structure in the PTF process.
SIPOC – “Input” in the Selmo-PTF
1) Definition
Input denotes all binding information, documents, data or models, that are delivered by the identified suppliers to execute the PTF process (process – technology – function) These inputs form the basis for:
the modeling in the Selmo Studio,
the formal verification (determinism, completeness, traceability),
the automated documentation and
the risk and quality assessment.
An input is only validwhen it:
is complete, unambiguous and consistent,
is in the correct format,
is assigned a version and source,
and has been released by the PTF lead or project manager .
2) Goal of the input step
Availability of all technically verified information before the start of modeling
Reduction of interpretation leeway
Formal handover between disciplines (mechanical, electrical, software, IT)
Standardized formats for easy integration into the Selmo system
3) Main categories of inputs in the PTF
Each input belongs to one of the three PTF levels:
P – Process
process description
Describes the logical and physical sequence.
Process diagram, sequence of steps, state matrix
Parameter list
Process parameters, limits, time specifications
Cycle time, temperature, pressure, positions
Quality characteristics
Measured values, acceptance criteria, limit patterns
Test pressure, dimensional tolerances
T – Technology
Technology matrix
Overview of all used technologies, devices, systems
Sensors, actuators, robots, PLCs, buses
I/O list
Assignment of signals to zones, addresses, CMZ level
Inputs/outputs, symbolism, signal names
Interface description
Definition of communication paths to subsystems
MES, ERP, SCADA, robotics, safety
F – Function
Function sheets
Documentation of logical functions
Adders, PID controller, HMI message
Diagnosis/error logic
Description of monitoring and reactions
Limit violation → stop + alarm
Test/verification cases
Test steps, expected outputs
Input A+B=Result, timeout test, interlock check
4) Standardized formats & templates (Selmo proposal)
PTF-PROC (process description)
MS Excel or Selmo template (CSV/XML)
Contains process steps, states, conditions, parameters
Standard template with SIPOC header
PTF-PARAM (parameter list)
Excel / CSV
Key parameters (name, unit, min/max, default, description)
Automatically importable into Selmo Studio
PTF-TECH (technology matrix)
Excel / Selmo template
Listing of all system components (type, ID, interface, manufacturer)
Basis for zone structure
PTF-IO (I/O list)
Excel / EPLAN export (CSV/XML)
Signal name, address, zone type, CMZ level
Import into Selmo zone structure
PTF-IF (interface description)
PDF / JSON / YAML
Communication interfaces (protocol, tags, data types, direction)
For MES, robotics, cloud etc.
PTF-FUNC (function sheet)
Selmo function document (Word/PDF/XML)
Inputs, outputs, triggers, monitors, test cases
Function standardization
PTF-SAFE (safety description)
PDF / Excel
Interlock, CMZ, PLr/SIL, shutdown matrix
Basis for risk assessment
PTF-HMI (HMI texts and operation concept)
Excel / JSON
Texts, colors, states, diagnostics
Automatically generable
PTF-Q (quality plan)
PDF / Excel
Inspection plans, limit values, SPC rules, measurement cycles
Traceability and audit evidence
5) Requirements for form and quality (Definition of Ready)
An input is ready for PTF usewhen it:
Unambiguous
No ambiguity in terms or states
"Cylinder extends" instead of "cylinder active"
Complete
All relevant parameters, states, interfaces defined
All process steps mapped
Be verifiable
Measurable, verifiable, testable
Test case “A+B=Result” with limit values
Deterministic
No undefined transitions or states
No "waiting for an undefined signal"
Traceable
Clear assignment to source, version, date
"PTF-PROC v1.2, created by M. Müller"
Released
Formally confirmed by the responsible party
"Released" status in the PTF register
6) Version and data management
All inputs receive a unique PTF ID (e.g. PTF-PROC-001).
Changes are made according to the change process (change log) with release.
Format specification:
Textual data:
.docx,.pdf,.mdTabular data:
.xlsx,.csvStructured data:
.xml,.json
All data are stored versioned in the project directory "/PTF/Input" .
7) Temporal classification
Inputs must before the start of modeling be complete. Recommended milestones:
Kick-off → Design freeze (0–20%)
Process description (PTF-PROC), parameter list
Process basis clear
Design freeze → technology planning (20–40%)
Technology matrix, I/O, safety
Hardware aligned
Before commissioning (40–70%)
Functions, interfaces
Software definition complete
Before release (70–100%)
HMI, quality plan, tests
Complete verification
8) Example of a complete input dataset
9) Responsibilities (RACI for inputs)
Process engineer
X
Quality, safety
Project management
Mechanics / Electrical
X
Automation
Project management
Software / automation
X
process
Project management
PTF lead
X
all
PMO
Quality / Safety
X
all
10) Conclusion
One Input in the PTF process it is not “a document”, but a technically verified data state, which describes the behavior, the technology and the function of a machine. Only through clear formats, releases and verifiability is the basis created for:
deterministic modeling,
error-free implementation,
and formal traceability throughout the lifecycle.
Process
Definition: The PTF process describes the sequence from requirement to release.
Phases:
Initiation & scope
Process description (P)
Technology analysis (T)
Function definition (F)
Review & risk
Release & handover
Customer → provides requirements PTF lead → structures process, technology, function Mechanical / electrical → define systems and interfaces Software → models the behavior in the Selmo Studio Quality / safety → checks standards and risks Management → approves and manages budget
→ Result: A complete, deterministic project flow without interpretation gaps.
Objective: A Selmo-compliant, deterministic machine model with documented risks, deviations and releases.
SIPOC – Process in the Selmo-PTF
1) Definition
The PTF process describes the formal sequence from capturing requirements to the release of the complete, Selmo-compliant process model. It is binding for all projects that are built according to the Selmo Method and ensures that each machine is deterministic, verifiable and documented is created.
The process follows the three PTF dimensions:
P – Process → What happens?
T – Technology → With what does it happen?
F – Function → How does it work?
2) Goal of the process
Produce a complete, Selmo-compliant process definition
Separation of process, technology and function responsibility
Create the basis for the Selmo process model (sequence, zones, bit control)
Detect, document and assess non-conformities or risks
Formal traceability and risk transparency throughout the lifecycle
Guiding principle: Anything that is not described, documented and assessed in the PTF must not be implemented in the Selmo model.
3) Process overview (top-level)
The PTF process is divided into six phases with clearly defined handover points and responsibilities.
1. Initiation & scope
Define project scope and system boundaries
PTF scope document
2. Process capture & description (P)
Define physical and logical sequence
PTF-PROC, parameter list
3. Technology analysis (T)
Determine technologies, interfaces and system components
PTF-TECH, PTF-IO, PTF-IF
4. Function definition (F)
Specify and document functions
PTF-FUNC, PTF-SAFE
5. Review & risk assessment
Check Selmo compliance, assess deviations
PTF-RISK, review protocol
6. Release & handover
Formally release PTF, create basis for modeling
PTF release, handover protocol
4) Detailed procedure
Phase 1 – Initiation & scope
Objective: Define project and system boundaries clearly. Responsibility: Project management / PTF lead Steps:
Description of the machine/plant to be modeled
Define the scope of consideration (plant, hardware zones, sequences)
Define delivery boundaries between disciplines
Set up the PTF artifact structure (directories, templates)
Name the suppliers and responsible parties
Result:
PTF scope document
Roles & responsibility matrix
PTF directory structure (input/process/output)
Phase 2 – Process capture & description (P)
Objective: Describe the complete process flow – physical and logical. Responsibility: Process owner / Industrial Engineering
Steps:
Survey the real or planned process flow (value stream, steps, transitions)
Define states, triggers, conditions and stop criteria
Identify all process parameters (times, temperatures, forces, paths etc.)
Documentation in the PTF-PROC (process description)
Creation of a parameter list (PTF-PARAM)
Dependencies:
Requires input from mechanical and electrical (layout, sensors)
Provides the basis for technology and function definition
Result:
Complete process description (states, transitions, goals)
Parameter and quality definition
Phase 3 – Technology analysis (T)
Objective: Describe all technologies, devices and interfaces and check for Selmo compliance. Responsibility: Technology responsible (electrical/mechanical/automation)
Steps:
Creation of the technology matrix (PTF-TECH) – sensors, actuators, interfaces, media, controls
Creation of the I/O list (PTF-IO) – assignment to zones, signal types, CMZ level
Definition of the System and data interfaces (PTF-IF) – MES, robots, safety, cloud, etc.
Assessment of Selmo compliance:
deterministic signals?
unique states?
feedback available?
synchronizable?
Documentation of non-conformities in the PTF-RISK
Result:
Complete technology matrix
Interface overview
Assessment of Selmo suitability
Phase 4 – Function definition (F)
Objective: Document, standardize and verify all functions used in the process. Responsibility: Function owner (Software / Automation)
Steps:
Creation of function sheets (PTF-FUNC) for all logical functions
Definition of inputs, outputs, triggers, limits, monitors
Assignment to process and technology elements
Creation of the Safety and monitoring functions (PTF-SAFE)
Definition of test cases / verification points
Dependencies:
Requires complete process (Phase 2) and technology (Phase 3)
Results flow into Selmo standard functions (e.g., adder, interlock, timer)
Result:
Documented, verifiable function library
Defined monitors (CMZ, MXIC, pair-check etc.)
Phase 5 – Review & risk assessment
Objective: Assess PTF completeness, Selmo compliance and risks. Responsibility: PTF lead / quality / safety
Steps:
Review of all PTF artifacts (PROC, TECH, FUNC)
Identification of non-Selmo-compliant requirements
Assessment of these items in Risk management (PTF-RISK) – Classification: critical / moderate / acceptable – Measures: adaptation, simplification, standardization
Release recommendation or revision
Result:
PTF review protocol
Risk list with responsibilities and measures
Note: Risks from non-Selmo conformity are not ignoredNon-conforming requirements or technologies are documented transparently. This keeps the model consistent, and all deviations are conscious, traceable and actionable.
Phase 6 – Release & handover
Objective: Officially release PTF and hand over as the basis for Selmo modeling. Responsibility: Project management / PTF lead
Steps:
Final review with all disciplines
Formal release of all PTF artifacts (release status)
Handover to Selmo modeling (Sequence, Zone, Bit Control)
Archiving the PTF status
Start of Selmo modeling
Result:
Released PTF
Official basis for the Selmo model
Traceability down to code level ensured
5) Process responsibility (RACI)
Initiation
Project management
Project management
PTF lead
all stakeholders
Process capture (P)
Process owner
PTF lead
Technology, quality
Project management
Technology analysis (T)
Technology owner
PTF lead
Process, Safety
Project management
Function definition (F)
Software owner
PTF lead
Technology, process
Project management
Review & risk
PTF lead, quality
Project management
all
Management
Release & handover
Project management
Project management
PTF lead
Team, customer
6) Interfaces & dependencies
Process data (P) → basis for technology and function definition
Technology (T) → defines physical feasibility and signal structure
Function (F) → describes logical behavior and monitoring
Risk management (RISK) → evaluates all deviations and feeds them back
Each phase may only be released, when its upstream phase is completed and validated is. → This ensures that no model is based on uncertain assumptions.
7) Quality and review criteria
A PTF is considered process-wise complete, when:
All PTF artifacts are available, consistent and released
All supplier inputs are validated
All interfaces are defined
All risks are documented and assessed
The deterministic sequence can be modeled in a traceable way
Implementation in Selmo is technically feasible
8) Result and significance
The PTF process provides the fully verified, formal foundation for modeling in the Selmo Studio. It separates:
What (Process)
With what (Technology)
How (Function)
… and brings them together in a verifiable, deterministic framework.
Thus, the PTF becomes the bridge between engineering and automation – and makes every machine created according to Selmo transparent, traceable and safe.
9) Core message for the kick-off
The PTF process is not an add-on, but the foundation. It defines what is built before anything is programmed. When all requirements, technologies and functions are clearly described, verified and released, the PTF automatically yields a Selmo-compliant process model – deterministic, documented and verifiable. And if something is not Selmo-compliant, we know it, document it, assess it and can work on it in a targeted manner.
Output
Definition: The output is the released, documented result of the PTF process – technically, organizationally and normatively.
Technical outputs:
Structured Selmo hierarchy: Plant → HWZ → Sequence → Zones
Bit control matrix, parameters, CMZ, MXIC
Function sheets and test cases
PTF model file (XML / PLCopen)
Organizational outputs:
Risk assessment (PTF-RISK)
Deviation list
Standards and CE evidence
Commercial assessment
Completion criterion: “The system is PTF-complete, Selmo-compatible and released.”
SIPOC – Output in the Selmo PTF
1) Definition
The Output of the PTF process is the fully verified, released and documented overall model of a machine or plant in the Selmo structure. It forms the binding basis for programming, control code, HMI, diagnostics and safety logic.
The output includes both:
Technical results (models, documents, data),
as well as non-technical assessments (risks, deviations, standards compliance, commercial assessment).
2) Objective of the output
Provision of a fully definable process model, which can be implemented in the Selmo Studio
Ensuring that every function is deterministic, verifiable and compliant with standards is
Documentation of Deviations, residual risks and evaluation results
Provision of a formal handover between engineering and software development
Target state: The output of the PTF is so complete that a Selmo model can be generated automatically, without room for interpretation.
3) Technical outputs in detail
3.1. Structured machine setup (Selmo structure)
The PTF is mapped in the hierarchical Selmo structure Each level is documented in the PTF and can be transferred to the Selmo Studio:
PLANT
Entire machine or plant
Plant data sheet, interface overview, safety zones, total CMZ
Hardware zones (HWZ)
Function blocks within the plant (e.g., stations, line segments)
HWZ description, operating modes, safety logic, power supply
Sequences (SEQ)
Logical sequence modules within the HWZ (e.g., clamping, testing, machining)
Flowcharts, states, transition conditions
Zones (Input, Output, In-Out, Mem)
Assignment of physical signals to logical states
Signal definition, CMZ level, HMI texts, interlocks
Bit control (system layer)
Link between state and zone behavior (0, i, S)
Bit control matrix, status definition
CMZ (Constantly Monitoring Zone)
Permanent safety monitoring (sequence, HWZ, plant level)
CMZ table, error reactions
MXIC (Manual Cross Interlock)
Manual operation conditions and release behavior
MXIC matrix, diagnostic conditions
parameter layer
Process parameters and adjustable values
Parameter table with units, limits, default values
This turns the PTF output into a complete digital machine image, which directly serves as the basis for:
the Selmo Sequence Editor,
the Zone logic,
the HMI generation,
and the PLC generation serves.
3.2. Documented function library
All defined functions (e.g., “adder,” “move to position,” “move cylinder,” “open valve”) are provided in a standardized form provided:
Function name and purpose
Unique identification and description
Inputs / outputs
Data types, units, limits
Trigger conditions
Triggers, start/stop logic
Monitors
Error detection, feedback, limit violation
Test cases
Verification, target/actual comparison
HMI integration
Display, message, diagnostics
Safety behavior
CMZ, interlock, MXIC conditions
This makes every function verifiable, reusable and documented. These function sheets are PTF-FUNC stored in the PTF and form the standard toolbox of software development.
3.3. Standards and regulatory evidence
In the PTF documentation, the consideration of relevant standards and regulations is explicitly included:
Machine safety
2006/42/EC (Machinery Directive), ISO 12100, ISO 13849, IEC 62061
Software quality
IEC 61131-3, ISO 9001, ISO/IEC 25010
Risk management
ISO 31000, ISO 14971 (for risk analysis and assessment)
Traceability & documentation
EN 82079, ISO/IEC/IEEE 15288
Data & communication
OPC UA, MQTT, REST, IEC 62443 (IT security)
Objective: Every technology, function or software component used meets or addresses the applicable standard requirements. Deviations are documented and transferred to the risk management section (PTF-RISK) included.
4) Evaluation and risk management as part of the output
The PTF output mandatorily contains the following assessments and evidence:
Technical risk assessment
Assessment of process, technology and function risks
Traceable decision on which risks are accepted or mitigated
Deviation list
Documentation of all items that are not Selmo-compliant or not deterministic
Transparent basis for later improvements
Non-technical risk assessment
Organizational, economic, scheduling or communication risks
Holistic view, no “technical tunnel vision”
Commercial assessment
Effort, benefit, complexity, cost-effectiveness
Justified prioritization for measures and changes
Standards compliance assessment
Degree of fulfillment of relevant standards
Evidence for audits, CE documentation, quality management
These assessments are not optional – they constitute the documented state of responsibility. The result is not a “perfect” state, but a consciously assessed and controllable.
5) Form of outputs (deliverables & formats)
PTF report
PDF / DOCX
Overall report with process, technology and function overview
PTF-RISK
Excel / JSON
Risk list with assessment and measures
PTF-MODEL
XML / PLCopen
Structured machine definition (Plant, HWZ, SEQ, zones, parameters)
PTF-FUNC
XML / PDF
Function sheets and test records
PTF-NORM
Standards and regulatory evidence
PTF-RELEASE
Signed document
Official release for modeling
PTF-HMI
JSON / CSV
Texts, messages, colors, operating procedures
PTF-Q
Excel / PDF
Quality plan, checkpoints, SPC limits
6) Responsibilities (RACI)
Technical PTF report
PTF lead
Project management
Process, technology, software
Quality
Function library
Software / automation
PTF lead
technology
Project management
Risk assessment
PTF lead, quality
Project management
all
Management
Deviation list
PTF lead
Project management
Process, technology
Quality
Standards assessment
Safety / quality
Project management
technology
Management
Approval / release
Project management
Management
PTF lead
all
7) Handover to Selmo modeling
After release, the PTF output is:
handed over as a package to the Selmo Studio,
imported into the modeling structure (Plant → HWZ → SEQ → zones),
automatically implemented in bit control and HMI,
and linked to the PTF version (traceability).
→ Each zone, each signal, each CMZ or MXIC condition can later be traced directly back to the associated PTF entry.
8) Quality and completion criteria
A PTF output is considered complete and released, when:
All technical artifacts are created, reviewed and released
All risks and deviations are documented and assessed
The Selmo structure can be fully mapped
Evidence of standards and guidelines is included
The commercial assessment is completed
The release document is signed
Closing formula: “The system is PTF-complete, Selmo-compatible and released for modeling.”
9) Benefits and significance
The PTF output is the binding, verifiable bridge between engineering and software. It ensures:
Determinism in behavior and control,
Transparency in responsibility and risk,
Reusability through standardization,
Traceability over the entire lifecycle.
This makes the PTF not only the technical specification, but the organizational safety line in the project.
10) Short form for presentations / kick-off
The output of the PTF is the digital twin of the machine – before it is built.
It contains all the information to generate the Selmo process model, all functions to control deterministically, and all assessments to manage risks consciously.
→ What is not Selmo-compliant becomes visible. → What is documented becomes verifiable. → What is released becomes deterministic.
Customer
Definition: Customers are all roles that actively use the PTF output to fulfill their tasks.
Main groups & benefits:
Project Management: Planning, release, transparency
Process owner: Traceable sequence
Mechanical / electrical: Safe signal definition, interfaces
Software / automation: Basis for Selmo modeling
Quality / safety: Evidence & risk assessment
Management: Economic decision basis
Customer / Operator: Documentation, trust, CE evidence
Core benefit: Every stakeholder receives verifiable, traceable information for their responsibility.
SIPOC – Customer in the Selmo PTF
1) Definition
Customer in the PTF context are all roles or organizational units, that use the released PTF use, to
carry out their own tasks,
reduce risks,
make decisions, or
safely manage the lifecycle of a machine.
The PTF is therefore not only input for software development, but a central management and evidence document for the entire project team – from engineering to management.
2) Objective
Create clarity, who gains what benefit from the PTF
Responsibilities and Dependencies define
Establish transparency over risks, interfaces and releases establish
Ensure traceability over the entire machine lifecycle ensure
The PTF makes every role visible – and gives each role a tool to exercise its responsibility based on facts.
3) Overview: All stakeholders of a Selmo project
Project control
Project management, PTF lead
PM, PTF manager
Coordination, schedule, quality, release
Process & product
Process owner, industrial engineer
Process owner
Process definition, target states, parameters
Engineering (mechanical)
Designer, plant planner
ME / head of design
Mechanical implementation, safety, layout
Engineering (electrical)
Hardware planner, E-plan
EE / electrical planning
I/O, sensors, actuators, wiring
Automation
Software developer, Selmo modeler
Automation engineer
Implementation in sequence, zones, bit control
Quality & safety
CE, safety, QM
Safety officer / QMB
Standards review, risk assessment, evidence
IT / OT / data
MES, ERP, SCADA, cloud
Data engineer / OT architect
Interfaces, data flow, IT security
Operation / Maintenance
Production, service
Operator / maintenance
Operation, diagnostics, maintenance
Management & controlling
Executive management, purchasing
Management, controller
Cost-effectiveness, traceability
Customer / end user
Operator, auditor
OEM / end customer
Availability, evidence, safety
4) Customer groups and benefits from the PTF
4.1 Project management / PTF lead
Why they need the PTF: To control the project methodically, risk-based and transparently .
What they get:
Complete overview of process, technology, function and risk
Clear release points and milestones
Documented interfaces and responsibilities
Assessed risks and residual risks
Benefit:
Planability, quality assurance, reduction of rework
Evidence of engineering processes (audit capability)
Project responsibility secured legally and organizationally
4.2 Process owner / industrial engineering
Why: They are responsible for the actual process flow and its efficiency.
What they get:
Transparent description of all process steps and states
Parameter lists with tolerances and limits
Traceable linkage between physical process and control logic
Benefit:
Clear handover to technology and automation
Early risk detection for process changes
Evidence of process quality and stability
4.3 Mechanical and electrical design
Why: Their designs must be integrated deterministically into the control process.
What they get:
Link between physical component (e.g., cylinder, sensor) and logical state
I/O list with zone and CMZ assignment
Feedback on non-Selmo-compliant signals
Benefit:
Early detection of inconsistencies between mechanics, electrical and software
Ensuring feasibility and compliance
Evidence of safety-related functions
4.4 Automation / Software Development
Why: You generate the Selmo model and thus the code from the PTF.
What they get:
Complete, released process definition
Structured Selmo architecture (Plant, HWZ, SEQ, zones, parameters, bit control)
Function sheets and test cases
Benefit:
Unambiguous, interpretation-free implementation
Formally verifiable code
Minimized implementation and debugging time
Direct traceability between model and PTF
4.5 Quality / Safety / CE
Why: You must demonstrate compliance with standards, functional safety and risk minimization.
What they get:
PTF risk assessment (PTF-RISK)
Documentation of protective measures, CMZ, MXIC, interlocks
Deviation list (technical & organizational)
Benefit:
Complete audit evidence
Clear assignment of risks and responsibilities
Minimization of legal liability risks
CE documentation derivable directly from the PTF
4.6 IT / OT / Data Systems
Why: Because they provide interfaces and data flows that must be secure and deterministic.
What they get:
Interface description (PTF-IF)
Communication definitions (protocols, topics, payloads)
Requirements for data quality and security
Benefit:
Reproducible data flows
Traceable coupling between production and IT
Standards compliance according to IEC 62443
4.7 Operations / Maintenance
Why: You use the system in everyday life and are responsible for safety and availability.
What they get:
HMI structure with states, colors, messages (PTF-HMI)
Diagnostics and manual operation logic (MXIC, CMZ, interlocks)
Documented process and error responses
Benefit:
Transparent operation and troubleshooting
Reduction of downtime
Proof of safe operation
4.8 Management / Controlling
Why: Because they must assess investment security, process maturity and reusability.
What they get:
Overall overview of project status and maturity level
Cost/benefit consideration from PTF assessments
Transparent risk situation
Benefit:
Predictability and economic efficiency
Reduction of hidden efforts
Evidence for governance, compliance and quality
4.9 Customer / Operator / End User
Why: Because they will operate, audit or accept the machine later.
What they get:
Documented, traceable process description
Proof of deterministic and safe control
Complete traceability from requirements to code
PTF as part of the CE documentation
Benefit:
Confidence in function, safety and quality
Clear traceability for changes and service
Simplified maintenance and training
5) Summary: Who uses the PTF for what?
Project management
Control, release, proof
Control, transparency
process
Definition, parameters, efficiency
Process quality
Mechanics / Electrical
Integration, signal definition
technical feasibility
Software / automation
Modeling, code
deterministic control
Quality / Safety
Assessment, evidence
Risk and standards compliance
IT / OT
Interfaces, data exchange
secure communication
Maintenance
Operation, diagnostics
Operational safety
Management
Economic efficiency, responsibility
Basis for decisions
Customer / Operator
Operation, audit
Trust and transparency
6) Impact on the overall project
The PTF creates for all stakeholders:
trust through traceability,
Efficiency through clear handovers,
safety through documented risks,
Standardization through reusability,
Economic efficiency through avoidance of frictional losses,
Compliance through formal conformity to standards and guidelines.
7) Conclusion for the kick-off
Every stakeholder benefits from the PTF – the process engineer through clarity, the programmer through structure, the quality manager through evidence, management through security.
The PTF is therefore not just a technical document, but the responsibility model of a project. It translates process knowledge into deterministic control – and makes every machine safe, verifiable and explainable.
Last updated
Was this helpful?