Engineering
Connected monitoring: from sensor events to operational visibility
A connected monitoring concept where sensing, embedded control, connectivity, and a dashboard layer had to be defined as one system before any hardware was committed.
- Stage
- In development
- Disclosure
- Anonymised summary
- Last reviewed
Context and constraints
A facilities-focused organisation wanted operational visibility over equipment it already owned. The work was scoped as an engineering definition exercise rather than a product build, because the sensing and data requirements were not yet agreed.
Constraints
- Existing equipment could not be modified or taken out of service for the exercise
- Sensor placement options were limited by the physical layout of the site
- Network availability could not be assumed to be continuous
- The dashboard had to remain useful when updates were delayed
- Confidentiality meant that site identifiers and operational data could not be published
Our role
- Defined the functional requirements and the acceptance criteria for each layer
- Specified the sensing and embedded control approach
- Defined the data flow from device events through to the display layer
- Identified which parts of the concept could not be verified without site access
Delivered by other parties
- Dashboard and interface implementation was carried out by a separate team
- Physical installation and site access were handled by the client
- Hosting and account configuration sat with the client's own providers
Key decisions
| Decision | Consideration | How it was verified |
|---|---|---|
| How to divide responsibility between device and platform | Update behaviour, connectivity interruptions, and data privacy all depended on where state was held. | Scenarios were defined for connectivity loss and restart, and the required behaviour was written into the requirements as testable statements. |
| How device state should be represented | Consistency between devices mattered more than minimising message size at this stage. | A state model was specified with defined behaviour for out-of-order and repeated events. |
| How to record product revisions across hardware and firmware | Maintenance and fault reproduction both depend on being able to identify exactly what was running in the field. | A revision identifier scheme was defined and checked against the maintenance scenarios described by the client. |
Verification evidence
-
Requirements and architecture documentation
Layer-by-layer functional specification with stated assumptions and a list of what remained unverified.
- Scope
- Defined from client-supplied information; not validated on site.
-
State and event model
Written model covering restart, repeated events, and connectivity loss, used as the basis for the test scenarios.
- Scope
- Desk exercise; not exercised against production hardware.
-
Revision identification scheme
Scheme linking hardware revision, firmware revision, and test records.
- Scope
- Defined and reviewed; not yet in operational use.
Stated limitations
- This entry describes an engineering definition exercise, not a deployed or certified system
- No site measurements were taken, so sensing placement and coverage remain unverified
- No operational performance figures are published because no agreed measurement method existed
- Dashboard implementation, installation, and hosting were delivered by other parties
Background
The organisation had equipment it could already operate, but no agreed way to observe it. The first problem was therefore not which sensor to buy, but which questions the system had to answer.
Approach
Requirements were defined layer by layer, from the physical event through embedded control, connectivity, data interpretation, and finally the operational view. Each layer was given acceptance criteria, and each assumption was written down so that it could later be confirmed or discarded.
What remains open
Site-dependent questions — coverage, placement, and interference — could not be resolved without access. Rather than estimate them, they were recorded as unverified and left for a stage where measurement was possible.