Offline Telemetry: Saved Data Is Not a Delivered Alarm

Download the failure-and-recovery matrix

Download the offline telemetry acceptance matrix. The template separates acquisition, local retention, upload, platform visibility and remote notification for each failure scenario. Fill in the actual architecture, expected behaviour and observed evidence before signing acceptance.

The industrial IoT service provides the system scope, and the power-interruption protection guide considers power continuity. This guide focuses on the evidence and alarm path. The IoT solutions overview connects the field measurement with the wider operating workflow.

Draw the complete path to the recipient

List the field instrument, acquisition device, radio or wired connection, gateway, backhaul, platform, notification provider and recipient device. Identify where a timestamp is assigned and where records are retained. A storage feature at one stage says little about a failure that occurs before a record reaches that stage.

For each component, record its power source and the dependencies that must remain available. A battery-powered sensor and an unpowered gateway create a different condition from an operational gateway with unavailable mobile backhaul. The acceptance matrix should describe the actual supplied arrangement.

Define what the customer means by an alarm. A local relay, on-site display, platform event and message delivered to a remote person are different outputs. State the recipient and destination of each required function so a general claim that alarms continue cannot conceal which path is being discussed.

Separate measurement time from arrival time

Preserve the original acquisition timestamp where the design supports it, together with the platform arrival time. The two values can diverge when data are buffered and uploaded later. A historical temperature excursion arriving after reconnection should remain identifiable as historical evidence.

Specify the clock source and behaviour during loss of synchronisation. The system may need to retain a time-quality flag or identify a reset. A plausible timestamp without known provenance can make a recovered sequence look more precise than the actual device clock supports.

Use explicit units and timezones in exports. During acceptance, compare the local reference, device record and platform representation for the same event. This establishes whether the operator can reconstruct the sequence rather than merely see that some data appeared after the link returned.

Test failures at the point where they occur

These are questions to resolve for the contracted architecture, not universal promises about every device. Record the expected state before the test and the observed result afterwards. Include a safe restoration step and retain any difference as an open acceptance item.

Distinguish loss-of-contact alerts from process alerts

A functioning platform may detect that expected messages have stopped and notify an operator through its own available route. That establishes a communication or reporting absence. It does not establish the process condition at the disconnected site during the missing interval.

Agree the silence interval, expected reporting pattern and escalation owner. A battery device intentionally reporting infrequently requires different treatment from a continuously connected controller. The rule should account for the actual design and the consequence of having no current evidence.

A process alarm requires the relevant measurement or locally evaluated condition to reach the point that generates the required response. If that path is unavailable, local action must rely on separately specified local functions and procedures. The operating plan should state what the on-site team does while the remote view is stale.

Specify storage capacity and overflow behaviour

Identify the record size or supported retention basis, acquisition rate and usable capacity at each storage stage. Calculate the intended retention window under the configured operation and confirm it against the supplied device behaviour. A nominal memory size alone does not establish how many useful records will survive.

Agree what happens when storage fills: old records may be overwritten, new records may be rejected or another documented behaviour may apply. The operator needs an indication of the resulting gap. Test the supplied behaviour using a safe method rather than assuming that every buffered record is guaranteed to remain indefinitely.

Include restart and power-loss behaviour. Some temporary state may not survive an abrupt loss even when normal buffered operation works. Retain the result of the actual test and any relevant configuration so the continuity claim describes the delivered system.

Check recovery for duplicates and ordering

After restoring communication, inspect original identifiers, acquisition timestamps and arrival times. Confirm how the platform handles repeated uploads and out-of-order records. A duplicate should not silently become a second production event or an additional unit in a total.

Define how late data affect reports and alarms. A recovered record may complete a historical report, but an operational notification may need to identify the event as delayed. The customer should approve the handling of historical exceptions so a burst of recovery messages does not obscure a current incident.

Compare the reconstructed sequence with an independent test log. Count expected, recovered, duplicated and missing records separately. If the design intentionally aggregates data, define the accepted output and information loss before the test rather than judging it against an unstated expectation of raw-record recovery.

Keep human response within the test boundary

Record notification generation, delivery status where available, acknowledgement, attendance and closure as distinct events. A provider accepting a message and a person acting on it are different stages. The customer's response procedure should assign alternates and the action required when a recipient is unavailable.

Use controlled simulations for disruptive conditions and label the evidence. Do not interrupt a live safety or process function merely to demonstrate a dashboard. The local authorised team approves the test method and verifies restoration of the normal operating arrangement.

The acceptance witness should be able to explain the system state during the interruption, not only after recovery. This includes what was known remotely, what remained available on site and which action was expected from each person.

Write a continuity statement the plant can use

Describe the actual failure scenario, remaining powered components, retained data, expected retention window and available response routes. Attach the test evidence and configuration version. This gives operations a practical statement to use during an incident and maintenance a basis for checking later changes.

The system-boundary and availability considerations in NIST SP 800-82 Revision 3 provide engineering background for evaluating dependencies. This worksheet is a project acceptance tool, not a declaration of conformity to that publication.

Discuss telemetry continuity and acceptance with the required records, response times, power arrangement and site communication options. The proposal should identify how suitable LoRaWAN field links and 4G backhaul behave in the selected design, including the conditions under which each required function is available.

Frequently asked questions