Reference architecture
TwinCAT-to-production data contract
A reference pattern for turning PLC states, counts and events into governed OPC UA or message-based information with explicit meaning, time, quality and ownership.
Evidence baseline
What is represented
- Representative TwinCAT machine-state source and downstream production consumer.
- Defined event, count, timestamp, quality and acknowledgement semantics.
- No customer OEE, throughput or production improvement is claimed.
Constraints
What shaped the engineering model
- Machine control remains deterministic when consumers or networks fail.
- Every measure requires an owned definition and source of truth.
- Certificate, identity, buffering and platform operations cross IT/OT ownership.
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 |
|---|---|---|---|
| Comparable downtime | State reason model | State/event reconciliation | Semantic model demonstrated |
| Survive disconnection | Store/forward rules | Disconnect/reconnect tests | Test pattern defined |
| Trusted source | Ownership/data-quality flags | Source-to-consumer examples | No production metric claimed |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- State/event reconciliation across representative timelines
- Message loss, duplication and ordering behaviour under fault
- Data-quality and exception visibility to named consumers
Deliverable manifest
What makes the decision reviewable
- Machine-state and measure dictionary
- Namespace/message and interface specification
- Failure/buffering/security design
- End-to-end reconciliation tests
- Operations and certificate lifecycle runbook
Limitations
What this evidence does not establish
- A data contract does not itself improve OEE or process capability.
- Enterprise platform security and availability depend on customer infrastructure.
Residual risk
What still requires ownership
- Definition governance is required as machines and reporting needs change.
- Time synchronisation and upstream/downstream dependencies require operational monitoring.
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.