How Should Data Storage Capacity Actually Be Calculated?
From “Preventing Data Loss During Network Outages” to Reliable Data Architecture for Remote Monitoring
In dam, slope, bridge, tunnel, tailings dam, mining, and other infrastructure monitoring projects, one RTU capability is often overlooked:
How much local storage does the RTU actually need?
When selecting an RTU, engineers usually focus on:
- Number of vibrating wire channels
- Measurement accuracy
- 4G connectivity
- RS485
- Modbus
- MQTT
- Power consumption
- Alarm functions
But once the system is deployed in the field, another question becomes critical:
What happens to the monitoring data if the 4G network is unavailable for several hours, a full day, or even several days?
This is where local storage becomes more than an optional feature.
It becomes an important part of the reliability architecture of a remote engineering monitoring system.
1. Why Can’t an RTU Rely Only on Cloud Storage?
Consider a typical monitoring architecture:
Sensors
↓
RTU
↓
4G Network
↓
Cloud Platform
↓
Database
Under normal conditions, everything works well.
The sensor collects data → the RTU processes it → 4G transmits it → the cloud platform stores it.
But engineering monitoring sites are very different from typical IoT environments.
Monitoring points may be located at:
- Dams in mountainous areas
- Slopes
- Mines
- Tunnels
- Reservoirs
- Tailings dams
- Remote bridges
- Sites without grid power
Network connectivity is not necessarily stable.
For example:
08:00 Normal transmission
09:00 Normal transmission
10:15 4G connection lost
11:00 Still offline
12:00 Still offline
13:30 Network restored
If the RTU has no local storage, data collected between 10:15 and 13:30 may never reach the platform.
With local storage, however:
Sensors
↓
RTU
├──→ 4G → Cloud Platform
│
└──→ Local Storage
↓
Network Restored
↓
Historical Data Backfill
When communication is restored, the RTU can transmit the historical data according to its configured backfill mechanism.
This is the basic idea behind:
Store-and-Forward
The VW-4816-4G documentation describes offline retransmission as storing collected data locally when the RTU cannot communicate with the central platform because of network failures, signal blind spots, or similar communication problems, and then retransmitting the historical data after communication is restored.
2. Local Storage Is About More Than Network Outages
It is easy to think of local storage simply as:
“A place to keep data when the network goes down.”
But its role is broader.
Local storage can support at least three important functions.
1. Communication Resilience
The RTU continues recording data even when the communication link is unavailable.
This is the most obvious benefit.
2. Data Traceability
Engineering monitoring often needs to answer a very practical question:
When exactly did the abnormal condition begin?
If all data depends on real-time transmission, a network outage during an abnormal event can create a gap in the time series.
Local historical storage provides a record of what was measured at the site.
The VW-4816-4G documentation describes its Historical Logging function as automatically storing process variables in internal non-volatile memory according to preset time intervals or trigger conditions, independently of real-time communication, for subsequent querying, exporting, or retransmission.
3. A Foundation for Edge Computing
Modern RTUs are increasingly becoming more than simple:
Sensor → 4G → Cloud
devices.
The architecture is evolving toward:
Sensor → Edge RTU → Cloud
The RTU may perform:
- Data acquisition
- Data calculation
- Data evaluation
- Anomaly detection
- Data buffering
- Historical logging
- Data transmission
So:
Local storage provides an important data foundation for edge-based monitoring functions.
3. The Real Question: How Much Storage Do We Need?
This is where engineering projects need a more systematic approach.
Instead of simply asking:
“Is 16 MB enough?”
the better question is:
Given the number of channels, acquisition interval, data format, and monitoring strategy, how long can the RTU retain historical data?
The calculation starts with:
Data Volume × Time
A simple estimation formula is:
Daily Data Volume ≈ Record Size × Records per Day × Number of Channels
Then:
Required Storage ≈ Daily Data Volume × Required Buffer Days × Safety Factor
Where:
- Record Size = storage required for one historical record
- Records per Day = number of acquisition records generated per day
- Number of Channels = number of monitoring points being stored
- Required Buffer Days = how long the RTU should retain data during communication outages
- Safety Factor = additional space for timestamps, indexes, status information, alarms, storage overhead, etc.
4. A Simple Example
Suppose an RTU has:
- 16 vibrating wire channels
- One acquisition every hour
- 100 bytes allocated per channel record for engineering estimation
Then:
Records per day:
24
Daily data volume:
16 × 24 × 100 = 38,400 bytes
Approximately:
37.5 KB/day
For seven days:
37.5 KB × 7 ≈ 262.5 KB
Even after allowing additional space for data structures and overhead, the basic data volume is still relatively small.
This illustrates an important point:
Engineering monitoring data is not necessarily large. Storage requirements are mainly determined by acquisition frequency, channel count, record structure, and retention strategy.
5. Why Can’t We Calculate Storage Based Only on “Number of Data Points”?
Because a real engineering monitoring record is usually more than:
Timestamp + Value
A practical record may contain:
Timestamp
Device ID
Channel ID
Engineering Value
Raw Frequency
Temperature
Status
Alarm Status
Communication Status
Data Quality
Checksum / Validation Information
Therefore:
One measurement point is not necessarily equivalent to one simple numeric value in storage.
This becomes particularly important in vibrating wire monitoring.
A vibrating wire measurement may involve:
- Resonant frequency
- Temperature
- Calculated engineering value
- Timestamp
- Channel information
- Status information
And if raw measurement data also needs to be retained, the storage requirement increases further.
6. Raw Data vs. Engineering Data
This is another important consideration.
For example, a piezometer may initially provide:
Resonant Frequency
The RTU can then convert this into:
Pressure / Water Level
Modern RTUs can perform this conversion locally at the edge.
According to the VW-4816-4G documentation, users can configure the sensor’s base frequency and K-value, allowing the device to convert raw frequency into engineering parameters such as pressure or water level locally.
This creates different storage strategies.
Option A: Store Only Engineering Values
Timestamp
+
Water Level
+
Pressure
+
Status
Advantages:
- Lower data volume
- Easier platform processing
- Suitable for long-term historical records
Option B: Store Raw Frequency + Engineering Values
Timestamp
+
Raw Frequency
+
Temperature
+
Engineering Value
+
Status
Advantages:
- Better traceability
- More flexibility for later analysis
- Easier sensor calibration and troubleshooting
Disadvantage:
- Higher storage requirements
Therefore:
Storage capacity should be designed based on exactly what data the project needs to retain.
7. Acquisition Frequency and Storage Frequency Do Not Have to Be the Same
This is another important concept.
For example:
Acquire every 5 minutes
Upload every 30 minutes
is perfectly possible.
Or:
Acquire every 1 minute
Upload every 10 minutes
The system can operate like this:
Acquire
↓
Store Locally
↓
Continue Acquisition
↓
Batch Upload
This is the concept of:
Multiple Acquisition + Centralized Reporting
The VW-4816-4G documentation specifically supports both “multiple acquisition, centralized reporting” and “acquire-and-send” strategies, allowing different trade-offs between communication power consumption and data timeliness.
This can be particularly useful for low-power remote monitoring systems.
8. Therefore, Storage Capacity Must Start With the Acquisition Strategy
Consider the same 16-channel system.
Case A: One acquisition per hour
16 × 24 = 384 records/day
Case B: One acquisition every 10 minutes
24 × 6 = 144 acquisitions/day
16 × 144
= 2,304 records/day
Case C: One acquisition every minute
24 × 60 = 1,440 acquisitions/day
16 × 1,440
= 23,040 records/day
The difference is substantial.
If acquisition frequency increases from once per hour to once per minute, the number of records can increase by roughly 60 times.
So the question should not simply be:
“Is 16 MB enough?”
It should be:
“Is 16 MB enough for this number of channels, this acquisition interval, this data structure, and this retention period?”
9. A More Practical Engineering Calculation
A useful project calculation can follow these steps.
Step 1: Determine the number of channels
For example:
Vibrating Wire: 16 channels
RS485 Sensors: 4 devices
Step 2: Determine the acquisition interval
For example:
One acquisition every 10 minutes
Then:
Daily acquisitions
= 24 × 60 ÷ 10
= 144
Step 3: Estimate the record size
Suppose, for preliminary engineering estimation:
One record = 80 bytes
For 16 vibrating wire channels:
16 × 144 × 80
= 184,320 bytes/day
Approximately:
180 KB/day
Step 4: Define the maximum expected communication outage
Suppose the project requires:
At least 7 days of local buffering.
Then:
180 KB × 7
≈ 1.26 MB
Step 5: Add engineering headroom
Storage should not normally be designed to operate at 100% utilization.
Additional space may be required for:
- Indexes
- Timestamps
- Status information
- Alarm records
- Retransmission queues
- File-system overhead
- Configuration changes
- Future data-format changes
Therefore, a preliminary engineering estimate might use:
Theoretical storage requirement × 1.5–2
as a practical reference.
This is an engineering estimation approach, not a fixed storage-sizing rule specified by the VW-4816-4G documentation.
10. Why Is “Maximum Offline Duration” Such an Important Parameter?
A project should ask:
What is the maximum realistic communication outage that the monitoring point may experience?
For example:
| Application | Storage Design Consideration |
| Urban bridges | Network is often relatively stable, but short outages still need consideration |
| Reservoirs | Mountainous terrain may create unstable coverage |
| Dams | Some monitoring points may be remote |
| Slopes | Terrain can affect communication conditions |
| Mines | Certain areas may have communication blind spots |
| Tunnels | Communication conditions can vary significantly by location |
| Tailings dams | Monitoring points may be far from communication infrastructure |
Therefore, storage capacity should ideally be based on:
How many days of data should be retained under the worst expected communication conditions?
rather than simply:
“How much storage does the device have?”
11. Another Often-Overlooked Issue: Backfill Speed
Suppose:
RTU offline for 24 hours
During that period, the RTU stores:
24 hours of historical data
When communication is restored, another question appears:
How quickly can the historical data be backfilled?
The system may need to handle:
Real-Time Data
↓
Historical Data Backfill
↓
Complete Platform Timeline
A well-designed system should ideally continue acquiring current data while handling historical backfill according to its communication strategy:
Real-Time Data → Normal Transmission
Historical Data → Chronological Backfill
New Data → Continuous Acquisition
The exact behavior depends on the RTU’s firmware and communication protocol design.
12. Store-and-Forward Is More Than Simply “Saving Data”
A complete mechanism can look like this:
Acquisition
↓
Local Record
↓
Check Network Status
↓
Network Available?
/ \
YES NO
↓ ↓
Transmit Local Buffer
↓
Network Restored
↓
Historical Backfill
↓
Normal Transmission
This creates a complete data-recovery loop.
The goal is not simply:
“Store something locally.”
The goal is:
Maintain continuity of the monitoring data stream despite communication interruptions.
13. Local Storage Also Provides Historical Evidence
Even when the network has never failed, local storage can still be valuable.
Suppose the platform shows:
Water level suddenly decreased
Engineers may want to investigate:
RTU Local History
↓
Raw Frequency
↓
Temperature
↓
Calculated Engineering Value
↓
Time-Series Change
This can help distinguish between:
- A genuine change in the monitored structure
- Sensor abnormalities
- Communication problems
- Platform-side issues
- Parameter configuration problems
In this sense:
Local historical data can become part of the field-level evidence chain for engineering monitoring.
14. Is 16 MB a Lot of Storage?
The VW-4816-4G technical specifications list:
Data Storage: 16M
The product also supports:
- Local historical data logging
- Offline retransmission
- Multi-channel vibrating wire acquisition
- RS485/Modbus integration
- Edge computing
- Alarm functions
- 4G communication
But an important distinction needs to be made:
You cannot determine the number of storage days simply by looking at “16 MB.”
Actual retention time depends on:
Number of Channels
×
Acquisition Frequency
×
Record Size
×
Data Fields Stored
×
Historical Storage Strategy
Therefore:
16 MB is a storage capacity specification — not a fixed number of “offline days.”
15. Five Questions Engineers Should Ask When Selecting an RTU
Instead of simply asking:
“How many megabytes of storage does the RTU have?”
it is often more useful to ask these five questions.
① What exactly is stored locally?
Does the RTU store:
- Raw frequency?
- Engineering values?
- Temperature?
- Status?
- Alarm records?
- All of the above?
② How frequently is data stored?
For example:
1 minute
5 minutes
10 minutes
30 minutes
1 hour
③ How many days of data can be buffered?
This is often more meaningful than the storage size alone.
④ What happens when communication is restored?
For example:
Is historical data automatically retransmitted?
Is it sent chronologically?
Is resume-from-interruption supported?
How are duplicate records handled?
The exact behavior should be verified against the device’s protocol and firmware implementation.
⑤ Does historical backfill interfere with real-time monitoring?
A robust architecture should ideally separate these data flows:
Real-Time Acquisition ─────→ Real-Time Data
│
└──────────────→ Historical Storage
│
↓
Network Restored
│
↓
Historical Backfill
rather than allowing historical retransmission to completely occupy the communication channel and delay current monitoring data.
16. Local Storage Is an Important Step From “Data Logger” to “Intelligent RTU”
Traditional data acquisition devices primarily focus on:
Can we accurately acquire the data?
Modern engineering monitoring RTUs increasingly need to answer:
Can the data remain reliable after acquisition?
Then:
What happens when the network goes down?
Then:
Can abnormal conditions be identified locally?
And eventually:
Can acquisition, calculation, storage, alarms, and communication be handled at the edge?
The architecture is evolving from:
Sensor
↓
Data Logger
↓
Cloud
toward:
Sensor
↓
Intelligent RTU
├── Acquisition
├── Edge Computing
├── Local Storage
├── Alarm Management
├── Logic Control
└── Communication
↓
Cloud / SCADA
This is one of the important architectural changes taking place in modern engineering IoT.
17. Final Thought: Storage Capacity Should Be Calculated, Not Guessed
The storage design of an engineering monitoring RTU can be summarized in one sentence:
Calculate the data first, calculate the retention period second, and add sufficient headroom.
A practical starting point is:
Required Storage
=
Number of Channels
×
Records per Day
×
Record Size
×
Maximum Offline Days
×
Safety Margin
But a complete project design should go further:
Acquisition Frequency
↓
Data Structure
↓
Local Storage
↓
Network Outage
↓
Store-and-Forward
↓
Network Recovery
↓
Historical Backfill
↓
Complete Platform Time Series
So local storage in an engineering monitoring RTU is not simply another “Memory” specification.
Its real purpose is to ensure that:
Field data remains continuous, traceable, and recoverable even when communication is unreliable.
For long-term, unattended monitoring of dams, slopes, bridges, tunnels, mines, tailings dams, and other remote infrastructure, this can be just as important as the number of acquisition channels.
Related Article
Next: What Is the Difference Between RTU Data Buffering and Data Storage? How Should Store-and-Forward Really Be Designed?
The next article can go deeper into ring buffers, FIFO mechanisms, breakpoint recovery, historical-data priority, simultaneous real-time and backfill transmission, and what happens when local storage reaches capacity — topics that are particularly relevant to engineers designing reliable remote monitoring systems.
#EngineeringMonitoring #RTU #VibratingWire #DataLogger #StoreAndForward #LocalStorage #EdgeComputing #RemoteMonitoring #GeotechnicalEngineering #StructuralHealthMonitoring #DamMonitoring #SlopeMonitoring #BridgeMonitoring #TunnelMonitoring #Tailings #InfrastructureMonitoring #IndustrialIoT #SmartInfrastructure
