1. Choose one operational decision
Start with a person and an action. A technician may need to complete a guided test; an engineer may need to understand an unusual pressure reading. Define what they need to see and what happens next before drawing the dashboard.
- Who uses the result, and in what environment?
- How current must the information be?
- What would make the first release useful without the rest of the roadmap?
2. Write down the offline behaviour
A lost connection should lead to an agreed state. Decide what can continue locally, what must pause, what the operator sees and how stored events are reconciled when the connection returns. Treat power loss and restart as separate scenarios.
- Which actions are allowed without the cloud?
- How will delayed readings be distinguished from current ones?
- What should happen to duplicate commands or conflicting updates?
3. Make the data contract explicit
A reading needs context: units, timestamp, source and quality. Map where the data originates, who owns each interface and how changes are communicated. A live chart should not hide gaps, invalid values or the difference between measured and calculated data.
- Which systems produce and consume each reading?
- Where are units and timestamps normalized?
- How will missing or invalid data appear to the user?
4. Separate a simulator from hardware acceptance
A simulator helps exercise device states and failure paths before the physical equipment is ready. Keep a separate plan for validation on the real instrument, including timing, protocol behaviour and the operating environment.
- Which behaviours can be tested without physical hardware?
- Who supplies representative devices and protocol documentation?
- What must pass on the actual equipment before field use?
5. Plan operation and updates
The brief should cover who provisions devices, manages access, diagnoses failures and approves updates. Define rollback and recovery alongside deployment. These choices influence the software architecture and the effort of supporting a fleet.
- Who owns the devices, accounts and deployment process?
- How will support distinguish a device fault from a data or network problem?
- What is the recovery path if an update fails?
6. Scope a first release that can be evaluated
Bring a representative workflow, sample data, available hardware and known integration constraints to discovery. Agree observable acceptance criteria, then use a prototype to test the important assumptions before extending the rollout.
- What will the operator be able to do at the end of the first release?
- Which assumptions need investigation before estimating?
- Who will review the prototype and accept the result?
See these constraints in real work.
Our oil condition monitoring case study describes guided instrument tests and a connected monitoring platform. The drilling case study describes live browser oversight and private simulator sessions for trainees.
- Oil condition monitoring case study
- Managed pressure drilling case study
- Industrial IoT and edge services
- Oil and gas software in Alberta
