Demonstrator
Mode, sequence and recovery design demonstrator
A representative controls model for separating operating modes, sequence state, permissives, commands, alarms and operator recovery before real-machine commissioning.
Evidence baseline
What is represented
- Simulated PLC sequence with representative devices and motion commands.
- Defined Auto, Manual, Setup, Stop and Faulted responsibilities.
- No claim of deployment on a specific production machine.
Constraints
What shaped the engineering model
- Recovery must not bypass safety or equipment permissives.
- HMI commands and PLC authority must remain distinguishable.
- Physical timing and process behaviour require real-machine verification.
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 |
|---|---|---|---|
| Unambiguous authority | Mode arbiter | Conflicting-command scenarios | Demonstrated in simulated boundary |
| Controlled recovery | Fault/recovery states | Fault-injection scenarios | Demonstrated; physical hazards excluded |
| Operator clarity | Alarm/action mapping | Screen and scenario review | Review method demonstrated |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Defined transitions exercised by scenario
- Faults with explicit detection, operator action and reset criteria
- Commands rejected outside their permitted mode/state
Deliverable manifest
What makes the decision reviewable
- Mode and state model
- Command/permissive matrix
- Alarm and recovery catalogue
- Scenario test set
- Known-model-limitation record
Limitations
What this evidence does not establish
- Simulated devices do not establish physical process capability.
- Functional-safety behaviour remains outside this demonstrator.
Residual risk
What still requires ownership
- Mechanical faults and latency require representative hardware/site tests.
- Operator usability requires review with intended users.
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.