Telemetry, data acquisition, SCADA — What do they mean, and how do they become part of IoT? Let’s try to sort it out.
What is telemetry?
Telemetry — the gathering of data from remote places for analysis and other purposes — is at the heart of industrial IoT (IIoT). But telemetry predates the Internet of Things by many years; many of us can remember talk of telemetry in the space program in the 1960s, all done by radio. In industry, telemetry was all wired, but the spread of low-power wireless devices that could form themselves into mesh networks made it ubiquitous.
What about data acquisition?
It is possible to connect devices (sensors) directly to the hardware, using anything from a cable plugged into a USB port to direct connection to a circuit board using GPIO, I2C, SPI or an on-board UART. This is how a data acquisition (DAQ) system works, and DAQs have been a laboratory mainstay for a very long time.
A DAQ may also transmit its results via a longer-range — often wireless — connection. This has been standard practice in auto racing for a long time.
A DAQ accepts input from sensors, processes that input, then either stores or transmits the result. But these days it’s possible (and increasingly economical) to do much of the signal processing and other chores right at the sensor itself, using perhaps a single-board controller or microcontroller like a Raspberry Pi or Arduino. Different DAQ channels then become independent of each other and may communicate individually with the user, via IoT. A 2016 blog explained (including sample code) how to set up IoT communications with a series of embedded sensing devices using the Raspberry Pi Zero and the Sflow protocol.
What is SCADA?
If you look at such a system and replace the networked Raspberry Pi and Arduino modules with programmable logic controllers (PLCs) or remote terminal units (RTUs) that connect to the field sensors and actuators you end up with a fair description of a supervisory control and data acquisition (SCADA) system. Of course, like DAQs, SCADA systems have been around since the mid 20th century, when they communicated via telephone lines, and are still used by industries with widely-distributed assets, like pipelines, water and wastewater, electrical distribution and others.
What’s the difference?
One difference between a DAQ and a SCADA system is distance: A data acquisition system can be located very close to both the user and the variables being monitored (often in the same room or even the same cabinet), while the variables being monitored and controlled by a SCADA system can be miles form the central control point, and are connected to remote terminal units (RTUs) that handle communications.
The other difference between data acquisition and SCADA comes from the second letter of the acronym, Control. In many ways, a SCADA system is a form of a distributed control system (DCS). Communication goes in both directions; data comes into the central hub and commands go out to field devices — actuators — to cause something to happen. A good example is pipeline control, where data like flow rates, pressures, pump status and more travel to HQ, and commands are sent back out to start and stop pumps, adjust control valves, and so on.
Too much data at once? That’s where IoT comes in
The data rate from individual field devices may be fairly low; many sensors in wireless mesh networks, foe example, send data only every few minutes. This is done partly to conserve battery power, but also because high data rates are often not needed: the temperature in a 10,000-gallon tank does to need to be reported 100 times a second; one reading a minute may be more appropriate.
But what if there are 10,000 field devices? How about 100,000? The total flow can move into the realm of big data and must be handled as such. That’s where we move into IoT territory, with big data. Packages to do this are available from multiple vendors, large and small.
Telefonica offers a wireless system called Tank Telemetry that feeds such data as tank levels or temperature from remote areas using cellular communications, with the remote devices powered either by battery or solar panels.
Similarly, 360 Telemetry provides complete IoT telemetry packages, from communication devices (generally cellular) to software to cloud services.
Valarm offers a full set of services and engineering assistance for measuring remote variable as disparate as tank levels, wildfire risk, water well levels, and more.
Microsoft, which seems to have a finger in every pie, also offers connected vehicle services to gather and analyze data from cars, trucks and the like. But the folks in Redmond do a lot more.
Microsoft recently upgraded its Azure cloud platform suite to make it more suitable for telemetry applications. Many Azure IoT users, it seems, use it as simply a way to transmit field data to the cloud, which Microsoft calls “device to cloud telemetry.” To facilitate that, the company has introduced a somewhat simpler version called the Azure IoT Hub basic tier, which provides device-to-cloud telemetry and associated services as a way to get started in Azure-based IoT. Eventually, says Microsoft, many users will decide to make the data flow bidirectionally: to be able to send messages and commands from the cloud to the devices, as well as perform device management and, in effect, create a SCADA system or even a DCS. At that point, they can migrate to Azure IoT Hub standard tier, which adds cloud-to-device messaging, device management and IoT edge support.
Summary
Just as the definition of IoT keeps evolving, so do the meanings of telemetry, data acquisition, SCADA and distributed control. But they all aim to do related things: gather data, analyze it, store it as needed, and in many cases use it for control purposes. You just have to decide what you want to call it.
