Edge computing in field devices: local or cloud?

A river station sits on a bridge in a hill valley. The mobile signal comes and goes, every message costs data, and the water is rising. Should the device decide what to do, or should it send everything to a server and wait for an answer? That question is the heart of edge computing in IoT: doing part of the computing on or near the device that produces the data, instead of sending all of it to a distant data centre. This article explains the idea, compares edge computing vs cloud computing, gives edge computing IoT examples from hydromet monitoring, and ends with a test you can apply to any function.

What is edge computing in IoT?

Edge computing means performing computation at the edge of the network, close to the sensors that create the data. One widely cited definition calls the "edge" any computing and network resource along the path between data sources and cloud data centres. A gateway in a smart home is the edge between home things and the cloud, and so is a smartphone between body sensors and the cloud [1].

This is a range, not a single place. The US National Institute of Standards and Technology (NIST) separates fog computing, which places compute nodes in the network between devices and the cloud, from mist computing, a lighter layer that "uses microcomputers and microcontrollers" directly beside the smart end-devices and feeds the fog or cloud above it. NIST also noted that no consensus existed on how to tell fog, mist, cloudlet and edge computing apart [2]. In this article, "edge" means the device in the field itself, and sometimes a gateway beside it.

The idea also sits inside formal IoT architecture. The international reference architecture for IoT, ISO/IEC 30141, describes IoT systems through a foundational view and several further views, using common vocabulary and reusable design patterns. Its second edition was published in August 2024 [3]. Such a reference architecture does not tell you where to put each function. That is a design choice, and the rest of this article is about making it.

Edge computing vs cloud computing

Edge computing vs cloud computing is not a contest in which one wins. Cloud computing centralises storage and computing in large data centres. That gives economies of scale and one place to manage everything [4]. Edge computing moves some work outward. The two work together, as in Figure 1: the device does what must happen on site, and the cloud does what needs the wider view.

Four reasons are usually given for moving work to the edge [1][4]:

• Bandwidth. Some sensors produce more data than a link can carry. One survey gives the example of an aircraft generating about 5 GB every second, far more than its link to the ground can handle [1].
• Response time. A round trip to a distant data centre adds delay. Measurements that the review cites found an average round-trip time of 74 ms from 260 locations worldwide to the best cloud servers, before the wireless first hop is added [4].
• Privacy and policy. The first device that sees the data can enforce rules on what leaves the site [1][4].
• Masking outages. If the cloud or the network fails, a nearby node can keep the service running for a time [4].

For a river station, the second reason matters less than people expect. A river that rises over tens of minutes does not need a decision in 74 ms. The first and fourth reasons, plus the cost of every message, do most of the work.

Edge computing IoT examples from river monitoring

Hydromet stations show the trade-off clearly because they sit in places where links are weak and the cost of a missed event is high.

Data logging and quality checks

Every ClimMaTech monitoring device records on board, so the record is kept when the network is down and can be sent once the link returns. Simple checks can also run on the device: rejecting an impossible jump, flagging a flat line, noting that a reading was interpolated. Doing this at the source means bad values are marked before they travel. Later checks across a network still belong in the cloud; see data quality control for hydromet time series.

Reporting rate and rate-of-rise

A station can report slowly in calm weather and faster when the level rises quickly, so the link is used where information is changing. Deciding "is the level rising fast?" needs only the last few readings, which the device already holds. Waiting for a server to tell it would defeat the purpose. The thinking behind such rules is in rate-of-rise alerts and alarm fatigue.

Images and video

This is where edge computing gives the largest saving. A camera produces far more data than a level sensor. The example below is illustrative, with the arithmetic shown.

No remote station on a mobile data plan should be asked to send the second stream all day. If the device analyses the images itself and sends only results, the cost falls to something like the first row. Camera-based river monitoring is covered in our explainer on image velocimetry. Any such analysis on the device has its own limits, such as glare, rain and camera geometry, so the results still need checking against field measurements.

Alerts when the link is slow

The same question arises for warnings. A threshold can be evaluated on the device and an alert sent at once, under good network conditions, without waiting for a server to compare the reading to a limit. What happens next, such as who approves a live alert and how a siren sounds, is a separate design decision. The chain is described in how a flood early warning system works and early warning dissemination.

What belongs in the cloud?

Some jobs cannot be done at the edge, because they need information the device does not have:

• Many sites at once. Comparing upstream and downstream gauges, mapping a basin, or combining rainfall from many gauges needs all the data together.
• Long records and archives. A device has limited storage. Trends, reports and open data exports are central tasks. See from sensor to screen.
• Users and dashboards. Engineers, officials and the public need one place to look.
• Heavy models and fleet management. Training a model, forecasting, and monitoring the health of hundreds of devices run centrally. The updated settings or models then go back down to the devices.

ClimMaTech's cloud platform, Visiflow (Device Cloud), plays this central role in our systems; see the Visiflow page.

What does edge computing cost you?

Moving work to the device is not free, and a good design admits it.

• Less raw data to fall back on. If the device keeps only results, a mistake in the local logic cannot be corrected later. Keeping raw data on board for a period, and uploading a sample, reduces this risk.
• Harder updates. A rule on 500 devices in remote places has to be updated over a weak link. The security of that update path matters; see security for field IoT devices.
• Power and processing limits. A solar station has a limited energy budget, and every extra computation uses some of it.
• Divergence. Two devices with different software versions may behave differently. Version tracking becomes part of the job.

A cloud-only design has its own costs: dependence on the link, more data to send, and a blind spot whenever the network is down. The right mix depends on the link, which is why telemetry link design comes first. How the device should send what it has decided to send is covered in MQTT, HTTP or SMS.

How do you decide: a simple test

For each function, ask these questions in order.

1. Must it work with no network? If yes, it runs on the device. Recording and local threshold checks belong here.
2. Is the raw data too large or too costly to send? If yes, process it on the device and send results. Images are the usual case.
3. Does it need data from other sites, or from before the device was installed? If yes, it runs in the cloud.
4. Does it change often or need the latest model? If yes, prefer the cloud, and push only stable results to the device.
5. Would a mistake be hard to see or reverse? If yes, keep a way to review the raw data, and make the device's decision visible in the record.

The table shows tendencies, not rules. A device with a good link and a cheap data plan may send more; a device on a weak link in a deep gorge should decide more.

Key points

• Edge computing in IoT means doing part of the processing on or near the device, instead of sending all data to a distant cloud.
• Edge and cloud work together. The device handles what must work without the link; the cloud handles what needs many sites, long records or many users.
• Bandwidth, link reliability and cost matter more for river stations than millisecond response time.
• Images and video are where processing on the device saves most. A video stream can carry over a hundred thousand times the data of a level message (illustrative arithmetic above).
• Keep raw data for review, plan for secure updates, and check results against field measurements.

Where ClimMaTech fits

Our monitoring devices keep an integrated on-board record, so the data survives a network outage. DoorDrishti combines a radar with an AI camera in one unit and processes the images on the device itself, while PRAVAAH, our non-contact discharge sensor, combines an AWLR (Automatic Water Level Recorder) with an SVR (Surface Velocity Radar). Both send results to the cloud platform for dashboards and wider analysis.

References

1. W. Shi, J. Cao, Q. Zhang, Y. Li, L. Xu, Edge computing: vision and challenges, IEEE Internet of Things Journal 3(5), 637–646, 2016. doi:10.1109/JIOT.2016.2579198
2. M. Iorga, L. Feldman, R. Barton, M. J. Martin, N. Goren, C. Mahmoudi, Fog Computing Conceptual Model, NIST Special Publication 500-325, National Institute of Standards and Technology, 2018. doi:10.6028/NIST.SP.500-325
3. ISO/IEC, ISO/IEC 30141:2024, Internet of things (IoT): Reference architecture, 2nd edition, August 2024 (replaces the 2018 edition). Catalogue record (SFS, national member body)
4. M. Satyanarayanan, The emergence of edge computing, Computer 50(1), 30–39, IEEE, January 2017. doi:10.1109/MC.2017.9