Chinese
Spanish
Russian
Portuguese
French
German
Indonesian
Thai
Vietnamese
Arabic
Italian
Turkish
Polish
Japanese
Preventing industrial data loss during network outages requires a tested acquisition and storage design. A reconnect indicator cannot establish that history was preserved. Specify which component creates each record, when it becomes durable and how the receiving system reconciles it later. A restored link cannot recover measurements that were never acquired or stored.
Place the buffer before the failure it must cover
A server-side queue cannot store new field readings that never reach the server. If a remote site must keep sampling during an uplink outage, the responsible PLC, RTU or gateway needs an appropriate local logging function. Separately assess a sensor failure or loss of site power: a communications buffer does not solve either by itself.
The METRAVON TG501 RTU lists local storage and retransmission, including 16 MB memory. Treat this as a capability to configure and test, not a guaranteed number of retained days. The usable storage and full-buffer behaviour depend on the actual firmware and record design.
Specify industrial data loss limits as testable requirements
| Decision | Required definition | Acceptance evidence |
|---|---|---|
| Acquisition | Which values and events are sampled, and when. | Compare source activity with locally created records during a controlled outage. |
| Retention | The outage duration and record volume that must be recoverable. | Demonstrate available capacity with the intended format, channels and logging schedule. |
| Full buffer | Whether to stop, overwrite or prioritise specified records. | Verify the selected policy and an observable indication of any lost period. |
| Recovery | Ordering, duplicate handling and acknowledgement rules. | Compare the final destination records with the known source record set. |
| Power loss | Which completed or in-progress writes are expected to survive. | Use the approved test procedure and document the actual recovery limitation. |
Estimate storage from the record rate, encoded record size and required outage duration, with explicit allowance for overhead and reserved space. Use the implementation's actual record representation. An engineering value stored with identity, timestamps and quality needs more space than its numeric value alone.
Separate sampling rate from upload rate. Uploading once per minute may carry many samples or only one, depending on the design. Ask for the locally stored record count rather than assuming the reporting interval determines retention.
Keep measurement time and arrival time distinct
Preserve acquisition timestamps and source identity through backfill. Agree what happens if the local clock is invalid or changes after synchronisation. Arrival time can help diagnose a delayed upload, but substituting it for measurement time can distort a trend or aggregate.
Where a retry can repeat records, use an agreed record identity or another defined reconciliation rule. MQTT QoS or a transport acknowledgement does not automatically prove exactly-once processing in the final database. Define the acceptance point across acquisition, transport and storage instead of relying on a protocol label.
For totals and counters, specify resets and rollover handling. Replaying an older total after a newer value must not create a false process change. Historic alarm events also need a policy: distinguish recording the past event from issuing an inappropriate current command.
Recover history without blocking current information
A large backlog can compete with live reporting. Specify the priorities and permitted recovery load, then test both functions together. Operators should be able to see that the site has current data while older records are still being transferred.
Expose stale, missing and invalid values clearly. Zero is often a legitimate measurement and should not be used as an unexplained substitute for a lost connection. Any displayed last-known value needs its age and appropriate quality indication.
Test beyond a brief cable removal
Create a known sequence of source records and interrupt the intended link during an authorised maintenance test. After reconnection, compare record identities, order, timestamps and values. Repeat a retry during backfill to check duplicate handling, then exercise the specified storage-limit policy.
Power-loss testing needs the supplier's procedure and safeguards for the equipment and data. Record any limitation rather than claiming lossless operation after a short successful trial. Keep the firmware, logging configuration and receiving-system revision with the acceptance results.
Retention questions
Q1. Does additional memory always improve reliability?
It can extend capacity, but it does not correct missing sampling, bad timestamps or unsafe write behaviour. Confirm supported storage hardware, endurance requirements and recovery policy before enlarging the buffer.
Q2. Should old records be used for a current shutdown decision?
Not merely because they arrive after reconnection. Current protective action needs appropriately valid and timely information within the assessed control design. Backfilled data should retain its historical status.
Q3. What should be included in a storage quotation?
Provide channels, record format, sampling and event rates, required outage coverage and reconciliation rules. Specify local storage hardware, firmware functions and destination work separately so both ends of recovery are included.
Summary
Define data retention from acquisition through final acceptance, then test outages, retries and storage limits. Request a METRAVON logging configuration review with the record requirements and permitted data-loss conditions, rather than a memory-size request alone.
