Data logger vs RTU vs SCADA: what each one does
Three terms that tender documents use interchangeably, and the different jobs behind them: recording, reporting and controlling, and supervising.
A tender asks for "data loggers with RTU functionality, reporting to a SCADA system". A vendor replies with a box that does none of the three properly. The confusion is understandable, because the words overlap in real products. Still, data logger vs RTU vs SCADA is not a choice between three competing devices. They do different jobs at different places in a monitoring system, and knowing which is which makes specifications, tenders and fault-finding much easier.
The short answer
- A data logger records measurements from sensors, with a time stamp, in its own memory.
- An RTU (remote terminal unit) sits at a remote site, connects to sensors and sometimes to actuators, and communicates with a central system over a wide-area link.
- SCADA (Supervisory Control and Data Acquisition) is the whole system on the centre side: software, servers, screens and communications that collect data from many field sites and let operators monitor and, where needed, control them.
A logger and an RTU are field devices. SCADA is the system they report to. The US National Institute of Standards and Technology (NIST) describes the typical SCADA layout in the same terms: a control server at a control centre, communications equipment, and geographically distributed field sites made up of RTUs and/or PLCs that monitor sensors and control actuators [2].
What does a data logger do?
A data logger reads sensors at a fixed interval, stamps each reading with the time and stores it. In its simplest form that is all it does, and it may never be connected to anything: someone visits the site and copies the file. The World Meteorological Organization (WMO) Guide to Instruments and Methods of Observation (WMO-No. 8) notes that data loggers are sometimes used as the acquisition equipment of an automatic weather station and are considered a part of it. It also lists an industrial data logger, not specific to meteorology, as one of several possible hardware designs, valued for versatility with analogue inputs and counters [1].
What a logger is good at:
- Sampling and storing on a regular schedule, including when no network is available.
- Reading many sensor types: analogue signals, pulse counters and digital buses. One common digital bus in hydrology is SDI-12, a standard for "interfacing data recorders with microprocessor-based sensors" at 1200 baud, with at least 10 sensors on one cable [5]. We cover it, with RS-485, in SDI-12 and RS-485: the two sensor buses hydromet stations rely on.
- Keeping good time, which matters more than it looks; see time stamps you can trust.
What a logger is not designed to do: send alarms, accept commands or run site logic. Modern products often add a modem, and then the line between logger and RTU blurs.
What does an RTU do, and how is it different?
An RTU is a field computer whose purpose is to be the remote end of a supervised system. NIST's glossary defines it as a computer with radio interfacing used in remote situations where communications via wire is unavailable, usually to communicate with remote field equipment [2]. Three things set it apart from a plain logger:
- It talks to a master. An RTU answers a central system, usually using a standard telecontrol protocol. IEC 60870-5-101, for example, is a companion standard for "telecontrol equipment and systems with coded bit serial data transmission" for monitoring and controlling geographically dispersed processes, intended to give interoperability between compatible equipment [3]. Another protocol commonly met on sensors and field devices is Modbus; see Modbus RTU explained.
- It can act. Besides inputs it usually has outputs: open a gate, start a pump, sound a siren.
- It reports on events, not only on a schedule. A level crossing a threshold can be sent at once rather than waiting for the next poll.
In NIST's description, the control server stores and processes the information from RTU inputs and outputs, while the RTU or PLC controls the local process [2].
RTU vs PLC: what is the difference?
An RTU and a PLC (programmable logic controller) overlap, and many products are sold as both. The usual distinction is in their origin and emphasis. A PLC is built to run control logic reliably, such as timing, counting, interlocks and feedback loops. IEC 61131-1 applies to programmable controllers and their associated peripherals [4]. An RTU is built to be remote: low power, tolerant of poor communications links, and fluent in telecontrol protocols.
NIST notes that in SCADA systems PLCs "may provide similar functionality to RTUs", and that PLCs can also be the primary controller in smaller systems that lack a central control server or operator interface [2]. In practice:
| Data logger | RTU | PLC | |
|---|---|---|---|
| Main job | Record measurements | Report to and obey a central system | Run local control logic |
| Talks to a central system | Optional | Always (that is its purpose) | Often, but not its core purpose |
| Controls outputs | Rarely | Yes | Yes, with richer logic |
| Typical site | Rain gauge, river station, borehole | Remote hydromet, pump or gate site | Treatment plant, canal gate control, barrage |
| Needs a link to be useful | No | Yes | No |
The questions "data logger and PLC" or "RTU vs PLC" usually come from the same worry: which one can also record, and which can also control? The answer is that modern devices often do several of these, so write down the functions you need rather than the device name.
What is SCADA, and what is it not?
SCADA is not a device. NIST describes it as integrating data acquisition systems with data transmission systems and operator-interface software to provide a centralised monitoring and control system for many process inputs and outputs; it collects field information, transfers it to a control centre and displays it to the operator in near real time [2]. Control can be automatic or by operator command [2].
The WMO Guide makes the same point for weather and hydrological networks. The collecting of data from field stations and the processing to supervise the network are typical tasks of a SCADA system, and many commercial packages for collecting and monitoring observations are developed by SCADA suppliers. Systems from hydro-meteorological equipment makers may be tied to their own stations rather than being general SCADA software, "but they have the same functionalities" [1].
This is the same idea as a real-time data acquisition system (RTDAS) in India's hydromet programmes. A Maharashtra government page describing its RTDAS lists water level sensors (shaft encoder, radar and bubbler types), climate and precipitation sensors, a data collection platform at each site and a combination of satellite and GSM/GPRS communications [6]. We explain that arrangement in what is an RTDAS and the data's whole path in from sensor to screen.
Worked example: a six-hour network outage
This example is illustrative. A river station records level every 15 minutes and is polled by a central server.
Records per hour = 60 / 15 = 4
Outage of 6 hours = 6 × 4 = 24 records- If the field unit only answers live polls and keeps no history, those 24 readings are gone. The dashboard shows a gap, and any peak during the outage is missing.
- If the field unit logs on board and sends the stored records when the link returns, the server back-fills all 24 points and the hydrograph is complete.
This is why a logger's memory matters even when the system is "online": the link is the weakest part of a remote station. Telemetry options and their failure modes are covered in telemetry link design. The distinction is also why the stored record and the live value should be tagged differently once the data reaches the centre; see data quality control for hydromet time series.
Which do you need at a river or rain station?
| Your requirement | What to ask for |
|---|---|
| Periodic readings, downloaded on site visits | A data logger |
| Near-real-time data to a central dashboard | A logger with a communications link (in effect, an RTU function) and a central collection system |
| Alarms on thresholds, or switching a siren or gate | RTU functions with outputs, and decision rules defined and tested |
| Complex local sequencing, interlocks | PLC functions |
| Many sites, one operator view, alarm handling, history | A SCADA or equivalent platform at the centre |
For flood warning, add one more line: define who authorises actions. A SCADA screen that can trigger a siren is a safety decision, not just a software feature.
Common mistakes in specifications
- Asking for "SCADA" when you need a dashboard. A small network of river stations may only need data collection and display. A full SCADA package adds licences, servers and training.
- Specifying the device, not the functions. Say "records on board for at least N days of 15-minute data, reports on a threshold, accepts SDI-12 and RS-485 sensors" rather than "RTU".
- Forgetting outputs and protocols. If the central system speaks one protocol and the field unit another, you need a gateway or a different unit.
- Ignoring time. A record with a wrong time stamp is worse than a gap.
Key points
- A data logger records; an RTU reports to a central system and can act on outputs; SCADA is the centre-side system that supervises many sites.
- RTUs and PLCs overlap. PLCs emphasise local control logic and RTUs emphasise remote communications, but modern products mix both.
- On-board storage protects the record when the link fails, so an RTU function without logging is a poor design for a river station.
- Specify the functions you need (inputs, storage, alarms, outputs, protocols), not just the device name.
Where ClimMaTech fits
ClimMaTech's monitoring devices, Tarang, PRAVAAH and DoorDrishti, have an integrated data logger that records on board and keeps the record when the network is down, and they report over GSM. In the field they behave as the recording and reporting end of the chain, and Visiflow (Device Cloud) provides the central side: collecting, storing and displaying data from many stations. See our RTDAS and hydromet telemetry solution for how the pieces fit together in a state or district network.
References
- World Meteorological Organization, Guide to Instruments and Methods of Observation (WMO-No. 8), 2024 edition, Volume III, Part II, Chapter 1 "Measurements at automatic weather stations" (the chapter was not changed in the 2024 edition; text read from the 2018 edition). library.wmo.int; 2018 chapter PDF
- K. Stouffer, M. Pease, C. Tang, T. Zimmerman, V. Pillitteri, S. Lightman, A. Hahn, S. Saravia, A. Sherule, M. Thompson, Guide to Operational Technology (OT) Security, NIST Special Publication 800-82 Revision 3, National Institute of Standards and Technology, September 2023. csrc.nist.gov
- International Electrotechnical Commission, IEC 60870-5-101: Telecontrol equipment and systems, Part 5-101: Transmission protocols, Companion standard for basic telecontrol tasks (edition 2.1, consolidated with Amendment 1), 2015. webstore.iec.ch
- International Electrotechnical Commission, IEC 61131-1: Programmable controllers, Part 1: General information (edition 2.0), 2003. webstore.iec.ch
- SDI-12 Support Group, SDI-12: A Serial-Digital Interface Standard for Microprocessor-Based Sensors, Version 1.4, 20 February 2023. sdi-12.org
- Water Resources Department, Government of Maharashtra, RTDAS Equipments (Hydrology Project). mahahp.gov.in
