Why Are More and More RTUs Starting to “Calculate at the Edge”?
In traditional engineering monitoring systems, the data flow is usually straightforward:
Sensor → Data Logger → Communication Network → Cloud Platform → Data Processing → Engineering Decision
It works.
But when the monitoring target is a dam, slope, bridge, tunnel, mine, or tailings facility, things become more complicated.
These projects often share several characteristics:
- Remote monitoring locations
- Harsh or changing field conditions
- Unstable cellular or wireless connectivity
- Large numbers of sensors
- Continuous data generation
- The need for rapid response to abnormal conditions
- Long-term unattended operation
This raises an important question:
Why do we always have to send all the data to the cloud before processing it?
Why not perform some of the processing directly at the monitoring site?
This is where Edge Computing comes in.
And it is becoming an increasingly important capability that distinguishes a modern engineering monitoring RTU from a traditional data logger.
1. What Does “Edge Computing” Actually Mean?
The concept is simpler than it sounds.
In engineering monitoring, edge computing means:
Instead of sending all raw sensor data directly to the cloud, the RTU first performs data processing, conversion, calculation, and event detection locally at the field site.
Traditional approach
Sensor
↓
Data Logger
↓
4G / Network
↓
Cloud Platform
↓
Data Processing
↓
Alarm / Decision
Edge computing approach
Sensor
↓
RTU
↓
Edge Computing
↓
Engineering Value Conversion
↓
Event / Threshold Detection
↓
Local Storage
↓
4G / Network
↓
Cloud Platform
The biggest difference can be summarized in one sentence:
The processing moves closer to the sensor and the physical infrastructure.
2. Why Does Engineering Monitoring Need Edge Computing?
Because engineering monitoring data is rarely just a number.
For example, a vibrating wire sensor may produce:
1,256 Hz
But what the engineer actually wants to know may be:
1.82 MPa
Or even more importantly:
Is the pore pressure increasing abnormally?
To get from raw sensor data to useful engineering information, several steps are required:
Raw Data
↓
Signal Identification
↓
Calibration Parameters
↓
Engineering Calculation
↓
Engineering Value
↓
Trend Analysis
↓
Abnormality Detection
Traditionally, many of these functions were performed by the monitoring platform.
With edge computing, an increasing number of these tasks can be performed directly by the RTU.
3. The Most Typical Example: Frequency → Engineering Value
Take a vibrating wire piezometer as an example.
The sensor does not directly tell you:
“The current pressure is 1.82 MPa.”
Instead, the acquisition system first obtains a frequency-related measurement from the vibrating wire.
The data processing chain looks like this:
Vibrating Wire Sensor
↓
Frequency Measurement
↓
Frequency Identification
↓
Initial Frequency
+
K Value / Calibration Parameters
↓
Engineering Calculation
↓
Pressure
If the RTU supports edge computing, this calculation can take place directly at the field site.
In other words:
The RTU does not simply “read” the sensor. It converts sensor readings into meaningful engineering data.
The VW-4816-4G series, for example, supports edge calculation using parameters such as initial frequency and K value to convert measurement data into engineering quantities such as pressure and water level.
This is one reason why a modern RTU is becoming much more than a traditional vibrating wire readout.
4. Benefit #1: Less Dependence on Cloud-Side Processing
Imagine a project with:
100 monitoring points.
Each point collects data every five minutes.
A traditional architecture may look like:
100 Sensors
↓
100 Sets of Raw Data
↓
4G
↓
Cloud Platform
↓
Data Processing
With edge computing:
100 Sensors
↓
RTU
↓
Local Processing
↓
Engineering Values
↓
Event / Abnormality Detection
↓
4G
↓
Cloud Platform
The data reaching the cloud already has greater engineering meaning.
This can reduce some of the real-time processing burden on the upper-level platform.
More importantly:
The field node itself becomes capable of processing and interpreting data.
5. Benefit #2: The Field System Can Continue Working When the Network Is Unstable
This is particularly important for engineering monitoring.
In a city:
A network outage for a few minutes may simply mean a webpage cannot be accessed.
But at a remote dam, slope, or mine:
A network outage does not mean the engineering risk has disappeared.
Suppose:
Sensor
↓
RTU
↓
4G ❌
If the RTU can only collect and transmit data, many cloud-based functions may become unavailable when communication is interrupted.
But if the RTU provides:
- Data acquisition
- Engineering calculation
- Local storage
- Threshold detection
- Alarm logic
then:
4G Connection Lost
↓
RTU Continues Acquisition
↓
RTU Continues Processing
↓
RTU Continues Monitoring
↓
Data Stored Locally
When the network returns:
Historical Data
↓
Store-and-Forward
↓
Cloud Platform
Therefore:
Edge computing + local storage + Store-and-Forward can significantly improve the resilience of remote monitoring systems.
6. Benefit #3: Abnormal Conditions Can Be Detected Locally
This is one of the most valuable applications of edge computing.
Imagine a dam pore pressure monitoring point normally operates around:
1.2 MPa
and suddenly rises to:
1.8 MPa
With a simple scheduled reporting system:
Acquire
↓
Wait for Scheduled Upload
↓
Cloud Platform
↓
Analysis
↓
Alarm
The abnormal condition may have to wait for the next reporting cycle.
An RTU with local decision-making can instead work like this:
Acquire
↓
Engineering Calculation
↓
Threshold Detection
↓
Abnormal Condition Detected
↓
High-Priority Report
↓
Monitoring Center
In other words:
Normal data can follow the scheduled reporting strategy, while abnormal events can be handled immediately.
This is the foundation of event-driven monitoring.
7. Why Doesn’t Scheduled Reporting Equal Intelligent Monitoring?
Many monitoring systems are configured to report data:
Every 30 minutes
This is perfectly reasonable for routine monitoring.
But consider:
00:00 Normal
00:30 Normal
01:00 Normal
Then:
01:05 Abnormal Condition
If the next scheduled report is at:
01:30
the monitoring center may not receive the abnormal information immediately.
A more intelligent system would work like this:
Normal
↓
Normal
↓
Normal
↓
Abnormal Event
↓
RTU Detects It
↓
High-Priority Alarm
↓
Monitoring Center
So:
Edge computing transforms an RTU from a scheduled reporting device into a field-level event response node.
8. Benefit #4: Turning Raw Data into Engineering Information
This is particularly important in infrastructure monitoring.
For example:
Frequency = 1,256 Hz
By itself, this number may not mean much to a project manager.
After RTU processing:
Frequency
↓
Calibration Parameters
↓
Engineering Formula
↓
Pressure
↓
Threshold Analysis
The monitoring platform can then display:
Pore Pressure = 1.82 MPa
and potentially:
Normal / Warning / Alarm
This changes the data chain.
Traditional monitoring
Sensor Data → Cloud → Interpretation
Edge-based monitoring
Sensor Data → RTU → Engineering Data → Event → Cloud
The data moves one step closer to engineering decision-making.
9. Benefit #5: Multi-Sensor Correlation
This is likely to become increasingly important.
As discussed in the previous article, an RTU can integrate both Vibrating Wire and RS485/Modbus sensors.
For example, a slope monitoring system may include:
Vibrating Wire
├── Anchor Load
├── Earth Pressure
└── Pore Pressure
RS485
├── Rainfall
├── Water Level
└── Temperature
If all these measurements are available within the same RTU, the system can go beyond simple single-parameter threshold detection.
For example:
Rainfall Increases
↓
Groundwater Level Rises
↓
Pore Pressure Increases
↓
Anchor Load Changes
↓
Edge Logic
↓
Higher Risk Level
This is different from simply saying:
“One sensor exceeded its threshold.”
Instead, the system starts to ask:
“Are multiple monitoring parameters indicating a change in the engineering condition?”
This is one of the most promising directions for edge computing.
10. Edge Computing Does NOT Mean AI
This is an important distinction.
When people hear:
Edge Computing
they often immediately think of:
AI / Machine Learning / Large Language Models
But engineering monitoring edge computing can start with very simple—and highly reliable—logic.
Level 1: Engineering Value Conversion
Frequency → Pressure
Level 2: Threshold Detection
Pressure > Threshold
↓
Alarm
Level 3: Rate-of-Change Detection
ΔPressure / Δt
↓
Rate of Change
↓
Alarm
Level 4: Multi-Parameter Logic
Rainfall ↑
+
Pore Pressure ↑
+
Water Level ↑
↓
Risk Level ↑
Level 5: AI / Machine Learning
Historical Data
+
Real-Time Data
↓
Machine Learning
↓
Prediction
So edge intelligence can evolve step by step:
Calculation → Rule-Based Decision → Multi-Parameter Analysis → Intelligent Prediction
AI does not have to be the starting point.
11. Can Edge Computing Reduce Communication Traffic?
In some applications, yes.
Imagine a monitoring site generating large amounts of raw data.
If everything is transmitted:
Raw Data
Raw Data
Raw Data
Raw Data
Raw Data
↓
4G
↓
Cloud
The RTU can instead perform:
- Data processing
- Engineering calculations
- Data filtering
- Status evaluation
- Event detection
before transmission.
For example:
Normal Data
↓
Scheduled Reporting
Abnormal Data
↓
Immediate Reporting
Historical Data
↓
Local Storage
Network Restored
↓
Store-and-Forward
This can be more efficient than:
“Send everything, all the time.”
Of course, the actual communication savings depend on the project’s sampling frequency, data format, reporting strategy, and platform requirements.
12. What Does Edge Computing Have to Do with Low-Power Monitoring?
Many engineering monitoring sites are located in:
- Mountains
- Reservoirs
- Slopes
- Mining areas
- Tunnels
- Remote infrastructure
Some sites do not have reliable grid power and must rely on:
Solar + Battery
Power consumption therefore becomes a critical design consideration.
A smart RTU can coordinate power management:
RTU Sleep
↓
Wake Up
↓
Power Sensor
↓
Acquire
↓
Calculate
↓
Store
↓
Transmit
↓
Sensor Power OFF
↓
Sleep
This avoids keeping every external sensor continuously powered.
For long-term unattended monitoring stations, this can make a meaningful difference to system autonomy.
13. What Should a Real Edge-Computing RTU Be Able to Do?
From an engineering project perspective, the edge-computing capability of an RTU can be evaluated through several questions.
① Can it convert raw measurements into engineering values?
For example:
Frequency → Pressure / Strain / Water Level
② Can it perform local logic?
For example:
Threshold / Event / Status
③ Can it store data locally?
Data should not disappear simply because the network is unavailable.
④ Can it perform Store-and-Forward?
Historical data should be uploaded automatically after communication is restored.
⑤ Can it integrate multiple sensor types?
For example:
Vibrating Wire + RS485/Modbus
⑥ Can it be configured remotely?
Engineers should not have to travel to a remote monitoring station every time a parameter needs to be changed.
⑦ Can it generate active alarms?
An abnormal condition should not have to wait for the next routine reporting cycle.
When these capabilities are combined, the RTU moves beyond the role of a:
Data Acquisition Device
and becomes an:
Intelligent Edge Monitoring Device
14. Why Does the VW-4816-4G Need Edge Computing?
Take the VW-4816-4G multi-channel vibrating wire hybrid acquisition RTU as an example.
Its role is not simply:
“Measure vibrating wire frequency.”
It integrates functions including:
Vibrating Wire Acquisition + RS485/Modbus + Engineering Calculation + Local Storage + Alarm + 4G Communication
The architecture can be represented as:
Vibrating Wire Sensors
│
↓
┌──────────────────┐
│ VW-4816-4G │
│ RTU │
├──────────────────┤
│ Signal Processing │
│ Edge Computing │
│ Local Storage │
│ Alarm Logic │
│ Power Management │
│ Communication │
└────────┬─────────┘
│
4G / IoT
↓
Cloud / SCADA
The significance of this architecture is simple:
Data gets its first layer of “understanding” as close as possible to the sensors and the physical infrastructure.
15. What Could Future Engineering Monitoring Systems Look Like?
The future of engineering monitoring is unlikely to be:
Sensors collect data, while the cloud does everything.
Instead, we may see an architecture like:
Sensor
↓
Edge Node / RTU
↓
Local Processing
↓
Local Decision
↓
Cloud Platform
↓
AI Analysis
↓
Digital Twin
↓
Decision Support
In other words:
The field handles fast response.
The cloud handles global analysis.
These two layers do not replace each other.
They complement each other.
A simple way to think about it is:
Edge = Fast Response
Cloud = Global Intelligence
This may be a more practical architecture for large-scale infrastructure monitoring in the future.
16. What Is Edge Computing Really Changing?
If we think of edge computing simply as:
“Adding a more powerful CPU to an RTU,”
we are missing the bigger picture.
What is really changing is the way the entire monitoring system works.
Before:
Collect → Upload → Wait for Platform Analysis
Now:
Collect → Calculate → Evaluate → Store → Alarm → Upload
Future:
Collect → Understand → Predict → Decide → Coordinate with Cloud
Therefore:
The real value of edge computing is not simply making an RTU calculate faster. It is giving the monitoring system the ability to understand and respond to field conditions closer to where they actually occur.
Conclusion
Why are more and more RTUs starting to “calculate at the edge”?
Because modern engineering monitoring is no longer satisfied with:
“Send the data back.”
The goal is increasingly:
“Turn the data into meaningful information before it leaves the field.”
Edge computing can provide several important benefits:
① Engineering value conversion
Frequency → Pressure / Strain / Water Level
② Less dependence on cloud-side real-time processing
③ Continued local acquisition and processing during network outages
④ Faster detection of abnormal conditions
⑤ Multi-sensor correlation
⑥ More efficient data transmission
⑦ Support for low-power, unattended monitoring
Ultimately:
Sensors
↓
Data Acquisition
↓
Edge Computing
↓
Engineering Value Conversion
↓
Abnormality Detection
↓
Local Storage
↓
Active Alarm
↓
4G
↓
Cloud / SCADA
↓
AI / Digital Twin
This is an important evolution in engineering monitoring RTUs:
From collecting data to understanding data.
And this may become one of the key foundations of future smart dam, smart slope, smart bridge, smart tunnel, and smart mine monitoring systems.
Next Article
What Happens When a Remote Monitoring System Loses Network Connectivity? Why Is Store-and-Forward So Important?
We will look at a very practical question in remote engineering monitoring:
If the 4G connection at a remote site suddenly goes down for several hours, what should the RTU do? Will the data be lost? And how can historical data be recovered automatically when communication is restored?
#EngineeringMonitoring #RTU #EdgeComputing #VibratingWire #DataLogger #GeotechnicalEngineering #StructuralHealthMonitoring #DamMonitoring #SlopeMonitoring #BridgeMonitoring #TunnelMonitoring #Mining #Tailings #RemoteMonitoring #IoT #InfrastructureMonitoring #SmartInfrastructure
