Demonstrator
TwinCAT virtual commissioning harness
A representative harness for coupling PLC code to signal and device models, injecting faults, executing scenarios and retaining results before site commissioning.
Evidence baseline
What is represented
- Representative TwinCAT application boundary with simulated field behaviour.
- Scenario runner, model adapters and evidence capture separated from production logic.
- No physical machine, site acceptance or safety result is represented.
Constraints
What shaped the engineering model
- Model fidelity must match the question being answered.
- Simulation code must not alter the production release path.
- Unmodelled physical behaviour remains visible as a site-test dependency.
Responsibility boundary
Who owns which decision
Named ownership prevents a technical work package from silently expanding into product, site, safety, quality or release authority.
Responsibility 1
Axiotech: the engineering method, scoped technical artefacts and stated verification evidence.
Responsibility 2
Customer/OEM: intended use, site constraints, acceptance authority and information supplied.
Responsibility 3
Other competent parties: safety, mechanical, process, quality or infrastructure decisions outside the stated scope.
Lifecycle proof
Decision gates used by the evidence model
The case does not equate activity with acceptance. Each gate has authority, inputs, evidence and unresolved-item visibility.
- G0Scope authorityOutcome, boundaries, roles, assumptions and commercial basis agreed.
- G1Baseline acceptedKnown installed/source state, dependencies, constraints and unknowns recorded.
- G2Design approvedRequirements, interfaces, risks and acceptance evidence ready for implementation.
- G3Release candidateBuild reviewed, verified, versioned and accompanied by defect disposition.
- G4Site acceptanceCommissioning evidence, deviations and release decision recorded.
- G5Handover acceptedSource, configuration, records, recovery and residual risks transferred.
Requirement-to-evidence assurance matrix
A compact proof structure
Public result statements remain deliberately bounded. Project-specific values require approved evidence.
| Need / requirement | Design control | Evidence | Public result status |
|---|---|---|---|
| Test unavailable faults | Fault injection interface | Scenario results | Demonstrated in model boundary |
| Protect production code | Isolated adapter layer | Build/configuration review | Architecture demonstrated |
| Retain repeatable evidence | Scenario identifiers | Versioned result set | Format demonstrated |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Approved scenarios executed against named software/model versions
- Expected and actual results plus defects retained
- Unmodelled requirements allocated to FAT/SAT or site verification
Deliverable manifest
What makes the decision reviewable
- Simulation intended-use and fidelity record
- Signal/device model contract
- Scenario and expected-result catalogue
- Execution/defect evidence
- Site verification and limitation register
Limitations
What this evidence does not establish
- Model results do not prove safety, physical life, process quality or final cycle performance.
- Coverage is limited to declared scenarios and model behaviour.
Residual risk
What still requires ownership
- Model drift must be assessed as the machine changes.
- Hardware/network timing and physical faults require appropriate real-world evidence.
Apply the method
Start with a bounded assessment or engineering work package.
Project facts, responsibilities and acceptance measures are confirmed before any outcome is promised.