Open Telemetry Architecture for Extreme Environment Suits: Edge, Rig and Cloud Layers

A telemetry system's sensors will be replaced two or three times across the service life of a platform. Its data schema will not. That asymmetry determines which architectural decisions matter and which are temporary.

An open telemetry architecture is one where the data schema, interfaces and processing boundaries are documented and stable enough that sensors, analytics and consuming systems can each be replaced independently.

WHY THREE TIERS

The three-tier structure - edge, rig, cloud - is not an arbitrary software pattern. It follows directly from the physical constraint that connectivity in extreme environments is intermittent and often absent.

Edge: on the operator

The edge tier runs on the suit itself. Its responsibilities are sampling and timestamping, local sensor fusion, on-body anomaly detection, immediate operator alerting, and buffering when the link is down. The defining requirement is that the edge tier must remain fully functional with no connectivity at all. An operator whose safety alerting depends on a radio link has no safety alerting.

This constrains the design considerably. Models running at the edge must fit within the power and compute budget of a wearable device, which usually means lightweight physiological models and threshold logic rather than large learned models. Power budget is frequently the binding constraint, and it interacts with mission duration in ways that are easy to underestimate.

Rig: the local gateway

The rig tier runs at the dive control station, vehicle, command post, airlock or mission vehicle. It aggregates across the team, performs comparative analysis, buffers during upstream outages, and drives supervisor displays.

The comparative function is the one that adds the most operational value. A supervisor does not need to remember thresholds for six operators. They need to know which operator is furthest from nominal, and that is a rig-tier computation.

Cloud or ground: the long horizon

The upper tier handles what neither of the others can: longitudinal analysis across missions and operators, model training and refinement, exposure and health surveillance records, fleet-level equipment condition tracking, and post-mission reconstruction.

Latency requirements here are relaxed, which is why it is the wrong place for anything safety-critical and the right place for everything that improves the system over time.

THE DATA SCHEMA IS THE PRODUCT

If one architectural decision determines long-term value, it is the schema. A well-designed schema for human systems telemetry has several properties that are easy to state and commonly neglected.

• Explicit units and reference frames on every measurement, never implied by field name.

• A single monotonic time base with documented synchronisation method and drift bounds across devices.

• Provenance metadata: which sensor, which calibration record, which firmware version produced each value.

• Quality flags on every sample, distinguishing measured, interpolated, estimated and invalid.

• Separation of raw measurement from derived values, with derivation method recorded.

• Versioning that allows schema evolution without invalidating historical data.

The fourth property is the one that most affects analytics quality later. A dataset where estimated and measured values are indistinguishable cannot be used to train or validate models reliably, and this defect is usually discovered years after the data was collected.

WHY OPEN MATTERS COMMERCIALLY

The argument for open architecture is often made on principle. The practical arguments are stronger.

First, sensor obsolescence. A closed system tied to specific sensor models becomes unsupportable when those models are discontinued. An open interface allows substitution without re-architecting.

Second, cross-system correlation. Organisations accumulate multiple safety and monitoring systems over time. If each holds data in a proprietary format, the analysis that would produce the most value - correlating physiological state with equipment condition and environmental exposure across systems - is impossible.

Third, procurement position. Defence and agency buyers increasingly require data rights and interface documentation as contract terms, having learned expensive lessons from vendor lock-in. A closed architecture is now a competitive disadvantage rather than a moat.

Fourth, multi-domain operation. A joint multi-domain intelligence layer that fuses land, sea, air and space operator state into a single operational picture is only possible when all four domains share a schema. This is the technical prerequisite for the dual-use platform model.

TIME SYNCHRONISATION: THE UNDERESTIMATED PROBLEM

Fusing physiological, environmental and equipment telemetry requires that all three streams be aligned to a common time base with known accuracy. This sounds trivial and is not, particularly when GPS is unavailable underwater or indoors, when devices sleep to conserve power, and when buffered data is transmitted after a link is restored.

Practical approaches include a designated time master on the suit with periodic resynchronisation, timestamping at the sampling point rather than at transmission, explicit recording of clock offset and drift estimates, and treating time uncertainty as a quality flag on the data. Systems that timestamp on receipt rather than on sampling produce data that cannot support any analysis where sequence matters.

DEGRADATION BEHAVIOUR

How the architecture behaves when things fail matters more than how it behaves when they work. A well-designed telemetry system degrades in a defined and communicated sequence.

• Sensor failure: the affected derived values are flagged invalid rather than silently substituted, and the operator display indicates reduced capability.

• Link loss: edge alerting continues unchanged, buffering begins, and the supervisor display explicitly shows stale data with its age rather than freezing the last value.

• Power reduction: sampling rates degrade in a defined priority order, with safety-critical signals preserved longest.

• Compute limitation: derived analytics are shed before raw capture, because raw data can be reprocessed and lost data cannot.

The most dangerous failure mode in any monitoring system is a display that continues showing a plausible value after the underlying measurement has stopped. Explicit staleness indication is not a nicety.

A MINIMUM VIABLE SCHEMA

Organisations frequently delay schema work because it appears to require a complete data model before anything can be built. It does not. A minimum viable schema is small and can be extended without invalidating earlier data if versioning is designed in from the start.

At minimum, every measurement record should carry a device identifier, a channel identifier, a timestamp with an explicit clock source and uncertainty, a value with explicit units, a quality flag, a calibration reference, and a schema version. Seven fields.

Derived values carry the same seven plus a derivation identifier naming the method and version used to produce them, and references to the input channels. This single addition is what makes it possible, years later, to reprocess historical raw data with an improved model and compare results meaningfully.

Everything beyond this is extension. Event records, annotation, mission context and configuration state all matter, but they can be added incrementally. What cannot be added retrospectively is provenance and quality information that was never captured, which is why these seven fields are the ones to get right before the first deployment collects data.

BUILDING IT IN THE RIGHT ORDER

Programmes that succeed with telemetry architecture generally sequence the work as schema first, then edge, then rig, then cloud, with analytics last. The instinct is to reverse this because analytics demonstrate well and schemas do not.

The cost of reversing it is that early data is collected in a format that later analytics cannot use, and the most valuable dataset an organisation will ever have - its first years of operational telemetry - is functionally lost. Architecture decisions made in month three constrain what is possible in year five, and this is the strongest argument for treating the data layer as core infrastructure rather than as a feature of the hardware programme.

FREQUENTLY ASKED QUESTIONS

What is an open telemetry architecture?

One where the data schema, interfaces and processing boundaries are documented and stable enough that sensors, analytics and consuming systems can each be replaced independently. It matters because sensors will be replaced several times over a platform's service life while the data collected must remain usable throughout.

Why is the three-tier edge, rig and cloud structure used?

Because connectivity in extreme environments is intermittent. The edge tier on the suit must handle sampling, fusion and alerting fully offline. The rig or gateway tier aggregates across a team and buffers during outages. The cloud tier handles longitudinal analysis, model training and record keeping where latency is not critical.

What happens if a telemetry system loses a sensor mid-mission?

A well-designed system flags dependent derived values as invalid rather than silently substituting estimates, indicates reduced capability on the operator display, and continues operating with the remaining channels. The most dangerous failure mode in monitoring is a display that keeps showing a plausible value after the underlying measurement has stopped.