SCADA Level Data Buffering: Size and Test Outage Storage

SCADA level data buffering needs a defined outage duration, record format and recovery test. Storage capacity must cover the intended measurements without making delayed history appear current. For a remote water station, specify the logging requirement and how the radar, RTU and receiving service will handle missing or recovered records before choosing the telemetry hardware.

Follow the data through the station

One candidate arrangement is an RS485 version of the METRAVON MV-RD12T, a TG501 RTU, a suitable cellular connection and the receiving SCADA service. Confirm the radar's protocol and the RTU's acquisition mode together. The radio connection does not determine whether the serial measurement is valid.

Commission the local measurement before testing remote delivery. Establish the radar reference, units and variable being read, then compare the RTU value with a site reference. A telemetry system can transmit the wrong offset perfectly. The separate RS485 and Modbus commissioning guide covers the wiring and register checks; outage testing starts once that local chain is working.

Keep fresh radar level data in SCADA separate from recovered history

Specify at least the measurement time, reception time, measurement quality and communication state in the receiving system's data model. These fields need not all originate in the radar. The RTU or server may add some of them, but their origin must be documented. If the instrument does not provide its own timestamp, an RTU timestamp normally describes acquisition, not necessarily the instant of the radar's internal measurement.

After reconnection, old samples should retain their original time association and be distinguishable from live data. Otherwise, a historical high level could appear to be a new event or overwrite the current display. The historian may need those samples to complete a trend, while the live control path needs a fresh, valid observation. Define both behaviours explicitly.

Calculate the payload for SCADA level data buffering

The TG501 product information lists 16 MB local storage and data retransmission. That figure is not a guarantee that all memory is available to every logging configuration. Confirm the selected firmware, record format, enabled channels and reserved capacity, together with the behaviour when the allocated buffer fills.

For a procurement estimate, calculate the required payload first. An illustrative record of 64 bytes saved once per minute for 24 hours requires 92,160 bytes before headers, indexes, quality fields or storage overhead. Doubling the number of separately stored records doubles that payload. This calculation specifies a requirement; it does not establish TG501's supported retention for a particular configuration.

When comparing that requirement with a quoted buffer, record whether capacity is shared or allocated per channel and which bytes count towards it. The payload estimate is a lower bound for the chosen record layout. A retention duration cannot be confirmed until record overhead and usable capacity are documented. Include the time needed to clear a backlog while new records continue arriving.

Ask the supplier to identify the supported buffer size and overflow policy in the proposed firmware. Confirm whether records persist after power loss, how acknowledgements work, and whether an interrupted replay resumes without losing or duplicating records. If those behaviours are not documented, include them in a witnessed acceptance test rather than assuming that a storage feature provides them.

Test loss, recovery and a second interruption

Use a test environment or an approved maintenance window with control consequences isolated. Record the configuration, firmware, clock source, sampling interval and starting buffer state. Create an identifiable sequence of safe input changes or test records; a constant level alone makes missing and duplicated samples hard to detect.

1. Interrupt only the external network. Verify whether local acquisition continues and whether the server exposes increasing data age.
2. Restore the connection. Compare the sent and received sequences, timestamps, quality and record counts, not just the final value.
3. Confirm that new observations remain timely while historical records are being recovered. Agree the permissible recovery delay before the test.
4. Interrupt the connection again during recovery. Check the documented resume and duplicate-handling behaviour.
5. Separately test a station restart and an instrument-read failure. Network buffering cannot recover measurements that were never successfully acquired.

Define a maximum outage requirement and a policy for data beyond the supported capacity. If the test cannot cover the required duration, document what was demonstrated and what remains unverified. A short reconnect test should not be reported as proof of multi-day retention.

Agree responsibility before commissioning

The instrument supplier should identify the measurement variable and fault indications. The RTU supplier or integrator should document acquisition, storage and delivery behaviour. The SCADA integrator should implement time interpretation, duplicates, stale-value display and historian insertion rules. The site owner must approve alarm and control behaviour during invalid or absent data.

Do not make a public cellular link the sole basis for an essential local protective action. The required independent protection and failure response must follow the site's risk assessment. A cached high-level record may be valuable for incident analysis without being a valid command to act on the current process.

For an enquiry, provide the site count, sensor interfaces, reporting interval, longest outage to retain, intended server protocol, regional network requirements and enclosure conditions. Include who supplies the SIM, server and commissioning support. Ask METRAVON to review the radar and RTU configuration against those requirements, with storage and recovery behaviour stated as acceptance items.

Questions about outages and recovered records

Q1. Can a connected RTU prove the level reading is current?

No. The network session can remain active while sensor polling fails. Track the last successful instrument acquisition separately from the last server connection. If the device provides measurement-status information, carry that through too rather than reducing all conditions to one online indicator.

Q2. Should recovered high-level samples generate alarms?

They may need historical event records, but they should not silently become new live alarms or control commands. Agree whether the system records the original event time, raises a retrospective notification or only fills the historian. Keep that policy separate from the handling of a fresh high-level observation.

Q3. What if the station clock is wrong after restart?

Preserve the evidence and flag time uncertainty. A reception timestamp can show when the server obtained the record, but it cannot reconstruct the exact measurement time. Confirm the clock source, synchronization behaviour and restart handling, and avoid presenting uncertain historical ordering as a verified sequence.

Summary

Specify outage recovery as an observable sequence: acquire, timestamp, store, reconnect and reconcile. MV-RD12T and TG501 provide a candidate instrument-and-RTU arrangement, not a guarantee of complete history under every interruption. Acceptance should demonstrate which records survive, how current data remains distinguishable and what the operator sees when measurement or communication fails.