Make the machine understandable.
Start with how the equipment should behave: its operating states, operator actions, recipes and response to faults. A coherent software structure makes those decisions visible and gives future changes a defined place to live.
Scope the right work.
- Machine sequences and operating states
- Operator interfaces and alarm behaviour
- Recipe and configuration requirements
- Interfaces between equipment and higher-level systems
Technical scope
Behaviour before screens.
Describe what the equipment must do before deciding how the interface should look.
| Area | Define together | Example evidence |
|---|---|---|
| Operating states | Define permitted transitions, entry conditions and the information shown to the operator. | A reviewed state diagram and witnessed normal/fault sequences. |
| Configuration | Separate recipes, machine settings and engineering-only parameters; define version ownership. | A configuration register and agreed tests for changes and recovery. |
| Interfaces | List commands, feedback and responsibilities at each equipment boundary. | An interface schedule with timeout and unavailable-system behaviour. |
Useful review artefacts
- Operating-state and sequence definitions
- Screen, recipe and alarm requirements
- Interface and change-control scope
A planning framework, not a confirmed feature or compatibility list. Deliverables and acceptance criteria are agreed for the application.
Questions worth answering early.
- What must continue running if the network is unavailable?
- Which settings can operators change, and which require engineering access?
- How will software changes be reviewed, tested and handed over?
The starting point
A defined controls and software scope, with the responsibilities of the machine, operator and connected systems made explicit.