Examples · decision exercise
The server is back. Is the service?
Explore the gap between restoring software and returning a physical service to operation. Try an update regression, power interruption, or cyber incident, then compare preparation and recovery choices.
A fictional pumping service, generated conditions, and no lab connection. Decisions advance model time; nothing runs in the background. Refreshing discards the exercise.
Choose the disruption
A workstation update breaks its HMI communications driver. Local control still runs, but the fictional pumping service is placed on an operational hold because its normal visibility is unavailable.
Changing the scenario starts a new exercise. This deliberately small dependency model is not a real pumping design or a site-specific incident procedure.
0 min
Illustrative objective: 60 min. Actual recovery time is not known until the service is released.
100%
A fictional buffer depletes by 2 percentage points per model minute on hold. This is not a hydraulic or quality model.
In service
A running server alone does not authorize a process restart.
Recovery decisions
Try an order and read the outcome. Missing prerequisites cost two model minutes. Completed tasks are marked; restoring another image invalidates the configuration/functional checks.
Assess the incident
Identify the failure and distinguish visibility loss from loss of local control.
Restore controller configuration
Recover the controller project into a hold state. Not needed when the update left local control running.
Restore HMI from selected copy
A tested pack restores faster in this model. A booting image can still contain the wrong configuration.
Reconcile configuration
Compare the restored project with the approved field-mapping change.
Review field conditions
Represent the operations/engineering review needed before acceptance testing.
Run functional acceptance test
Check data freshness, expected response, commands, and alarms after the dependencies are ready.
Verify historian collection
An optional collection check in this model; some real services require it before release.
Attempt return to service
See whether the evidence supports an operational release, rather than just a server restart.
Dependencies & acceptance
- ○ Pending Cause assessed
- ○ Pending Power and recovery network
- ○ Pending Controller and HMI available
- ○ Pending Trusted, reconciled configuration
- ○ Pending Field conditions reviewed
- ○ Pending End-to-end functional test
These checks belong to this fictional service. A different facility may have a different dependency order and release criteria.
Power → recovery network → controller → HMI → reconciled data → functional test → operational release.
The update scenario leaves the first three available. A controller can run locally without the HMI. The model requires visibility before releasing this particular service.
Decision notebook
Choose an incident and a preparation level, then begin the exercise.
- 0 min · observation
Choose an incident and a preparation level, then begin the exercise.
Teaching assumptions: RTO, RPO, and physical consequences
The 60-minute recovery time objective (RTO) is an illustrative target, not a prediction or standard. Actual downtime includes the decisions taken until release. Backup configuration age is displayed to encourage reconciliation; it is not automatically a recovery point objective (RPO) or a measurement of lost data. RPO describes the acceptable loss of information expressed in time. Different data, configurations, and records can have different recovery needs.
The service buffer is a deliberately simple way to show that time has consequences. It does not model water quality, pressure, supply, redundancy, people, or real equipment. Every scenario begins after fictional operations has placed this service on hold; do not infer that shutting down or disconnecting systems is always the correct response to a real cyber event. This is a decision exercise, not operational guidance.