A hydrogen storage unit is an electrolyser, a hydride store and a fuel cell in one cabinet, and each of those degrades differently. LAVO's units were already recording everything a support engineer would want — efficiency curves, tank pressure, stack temperatures, cycle counts — and almost none of it left the site. The company was supporting a growing fleet on phone calls and site visits.
The situation
Units sit behind whatever connection the site already has: domestic broadband at a house, a shared business link at a commercial installation, occasionally a mobile service at a remote one. None of that is a datacentre link, and none of it is under LAVO's control.
The practical consequences showed up in three places. Support could not tell whether a reported fault was the unit or the site. Warranty conversations were arguments about recollection rather than readings. And gradual efficiency loss — the failure mode that actually matters commercially — was invisible until a customer noticed their bills.
- High-resolution telemetry recorded on the unit and rarely retrieved
- Connections owned by the site, not by LAVO, and power-cycled at will
- Degradation detected only when a customer complained
- Field visits dispatched on a description rather than a reading
A residential connection is not a reliable transport and never will be. Anything that assumed connectivity, or assumed the unit would not be switched off at the wall, was going to fail in the field rather than in testing.
What we built
Edge first, cloud second
AWS IoT Greengrass on the unit's gateway, subscribing to the local data store, computing features at the edge and buffering to local storage. Full-resolution data stays on the unit; what crosses the connection is aggregates, state changes and anything anomalous. When the link drops, ingestion continues locally and backfills on reconnect, reconciled against what already arrived.
Two channels, not one
Safety-relevant events and routine telemetry were separated deliberately. Telemetry is aggregated, sampled and allowed to arrive late. Safety-relevant events take a small, guaranteed-delivery path with acknowledgement and retry, and are never batched behind a backlog of efficiency readings.
Combining the two would have been simpler to build and wrong: the first large backfill after an outage would have queued a pressure event behind six hours of routine data.
A fleet view built on an open table format
Telemetry lands on S3 in Apache Iceberg tables through a bronze/silver/gold structure. Iceberg earned its place quickly — the payload schema changed twice during the project as firmware evolved, and neither change required reprocessing history.
Degradation models per component
Not one model for the unit. Electrolyser efficiency, hydride absorption behaviour and fuel cell output degrade on different timescales and for different reasons, so each got its own detector, trained against that component's history and labelled with LAVO's own service records.
Alerts into the existing service workflow
Detections raise a service task in the system field teams already use. A separate dashboard would have been ignored inside a month, which we have watched happen elsewhere.
| Layer | Choice | Why |
|---|---|---|
| Edge | IoT Greengrass with local buffering | Tolerates multi-day outages |
| Transport | IoT Core, split by criticality | Safety events never queue behind telemetry |
| Storage | S3 + Apache Iceberg | Schema changed twice without reprocessing |
| Detection | SageMaker, one model per component | Components degrade differently |
| Action | Task in the existing service system | Adoption, rather than another dashboard |
Deliberately unremarkable choices. The interesting decisions were about failure modes, not services.
The hard part
Two problems, and neither was the modelling.
The first was identity. Units move — a commercial site reconfigures, a unit is swapped under warranty, a gateway is replaced — and early telemetry was keyed to the gateway rather than the unit. That quietly attributed one unit's history to another. We rebuilt the model around a stable unit identity with a separate installation record, and reprocessed the history we had.
The second was labels. Anomaly detection needs no labels; predicting a specific failure needs to know what previous failures looked like, and service records described outcomes rather than precursors. Reconstructing failure timelines from service notes and telemetry took several weeks with LAVO's field engineers. It is the least glamorous part of the project and the reason the detectors are useful.
The model was a few weeks of work. Understanding what a failing stack looks like a month beforehand was several weeks sitting with the people who replace them.
Where it landed
Mean time to detect degradation moved from weeks — effectively, until someone complained — to hours. Roughly a third of field visits that would previously have been dispatched on a description are now either resolved remotely or arrive with the right part already on the vehicle.
Telemetry completeness sits around 96%. The shortfall is connections that stay down longer than the local buffer window, which is a known and accepted limit rather than a defect. Safety-relevant events are the exception: those are delivered, not sampled.
Model unit identity properly in week one. We treated it as a data-modelling detail and it turned into a fortnight of reprocessing.
Equipment in the field generating data you never see?
A single-site pilot proves the connectivity assumptions and the model value in eight to twelve weeks, before you fund a fleet rollout.