Reference architecture
TwinCAT requirement-to-release evidence model
A tool-neutral architecture showing how a machine requirement remains connected to Structured Text modules, configuration, review, tests and an approved release baseline.
Evidence baseline
What is represented
- Representative TwinCAT 3 project structure and versioned library baseline.
- Defined operating modes, module responsibilities, EtherCAT/I/O interfaces and release roles.
- No customer machine, production outcome or commissioned site is represented.
Constraints
What shaped the engineering model
- Traceability must remain usable by controls engineers rather than becoming a parallel quality-only record.
- Generated reports cannot replace competent review of requirement meaning or code behaviour.
- Runtime, library, boot project and repository references must identify the same release.
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 |
|---|---|---|---|
| Machine-state behaviour | State/module contract | Scenario and transition tests | Coverage model demonstrated; no site result claimed |
| Repeatable build | Version/dependency baseline | Build and boot-project comparison | Evidence format demonstrated |
| Recoverable release | Backup/rollback design | Recovery drill record | Acceptance criterion defined |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Approved requirements with linked design and test evidence
- Unresolved defects/deviations by release decision
- Successful baseline reconstruction and recovery procedure execution
Deliverable manifest
What makes the decision reviewable
- Requirement and software-item identification scheme
- Architecture/module/interface record
- Version and configuration baseline
- Review and test evidence model
- Release note and residual-risk register
Limitations
What this evidence does not establish
- Reference structure only; project tools and document depth depend on customer procedure and risk.
- Does not demonstrate physical machine performance, safety validation or regulatory acceptance.
Residual risk
What still requires ownership
- Human review quality and source discipline remain critical controls.
- Third-party library and platform changes require lifecycle assessment.
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.