Getting Started with Distributed Data Logging

In the first part of this series, I talked about how I see distributed data logging as an evolving trend in the field of general purpose data logging. I discussed what it is, the parts that make up distributed data logging systems, and some of the technology for connecting and communicating between the different pieces of the system and why you might want this type of system. In part II, I would like to talk more nuts and bolts about how you can put together a system with examples from a couple of projects we have worked on.

Getting Started with Distributed Data Logging Systems

One of the first choices you need to make when designing distributed logging systems is the physical connection between the different parts of the system.

The Interconnect Method

From my experience, there are 3 basic interconnect technologies:

1. Serial interfaces
2. Ethernet
3. Wireless communications

Serial is the oldest and probably the most common. Of the 3 standard serial interfaces, RS-232, RS-422, and RS-485, the latter is most appropriate. Unlike RS-232 and RS-422, the RS-485 interface allows multiple devices to be attached to a single 2 or 4 wire communication’s bus. Because RS-485 uses a differential signal, it allows the bus to extend to over 1000 meters depending on communication speed. Note that the RS-485 standard only defines the physical interconnection. There are several different communication protocols such as Modbus and Profibus which define the structure of the messages on the bus.

The use of Ethernet in distributed logging systems is expanding. New and existing manufacturers are introducing new devices, both sensors and data collectors every day. Like the serial interface, Ethernet only defines the physical interconnect and there are several different communications protocols being used that we’ll talk about later.

The third interconnect technology is Wireless and within this category, there are a bunch of variations. One of the most common wireless technologies is WiFi, and there quite a few WiFi data loggers in the market. However, I have not been able to find many sensors with WiFi interfaces that allow connection to another device as part of a distributed system. To me, this would seem to be a good opportunity as it would allow flexible placement of the sensor with the ease of configuration of other common WiFi devices. There also seems to be more new devices in the consumer market like this, but they typically are part of a closed, proprietary system.

Beyond WiFi, there are other wireless technologies like spread spectrum radio modems and proprietary wireless networks. These typically operate on either the 900 MHz or 2.4 GHz industrial, scientific and medical (ISM) frequency bands. For example, we used a half dozen radio modems to collect data from test wells spread around a large landfill that covered hundreds of acres and brought all the data back to a central monitoring point. An interesting hybrid technology is wireless devices like the Novus Airgate that support Modbus communications.

The Communications Protocol

The communications protocol defines the structure of messages that are sent over the physical communications bus. Of all the different protocols that we have used, Modbus is the most common and comes in several different flavors. When using a serial communications network like RS-485, Modbus RTU is very common. This protocol defines a standard way of sending numeric data, both integer and floating-point values.

There are literally dozens of vendors and hundreds of devices that support Modbus RTU and RS-485 communications. We have worked with temperature sensors, electrical power meters, humidity transmitters, weather stations and many general-purpose voltage and current I/O modules that utilize this protocol. When using Modbus RTU, one device is configured as the master and the other devices are slaves. The master initiates all the communications on the bus.

One of the challenges of Modbus RTU is there are small variations between devices from different vendors that often require some experimentation to work through. For example, while the protocol defines a 16-bit integer data format, it does not specify the byte order, so some devices send the most significate byte first, while others send the least significant first.

For devices that use Ethernet for communications, a slightly different version called Modbus TCP can be used for data exchange. Modbus TCP is common in higher-end instruments; there are not nearly as many low-cost sensor/transmitter type devices that have this capability.

A less common serial communication protocol is SDI-12. It is often used in environmental applications with weather stations, and water quality sensors. Similar to RS-485, SDI-12 runs on a 2-wire bus, allows up to 10 devices on a single bus, and supports distances of up to 200 feet per device.

Open Platform Communication (OPC) was created to allow the easy exchange of data between industrial control devices from different manufacturers.  However, the original version of OPC was built around a Microsoft Windows platform. Recently the OPC Unified Architecture (UA) specification has been released which eliminates the requirement for a Windows-based platform.  OPC UA utilizes a client/server architecture that makes it much simpler for the client (data logger) to interrogate the servers (sensors) to find out what types of data and functions they provide.

Putting it All Together

So, you might be asking yourself how does this all fit together? A good example would be a project we just did for a battery manufacturer. They had 20+ manufacturing machines spread around a large facility that they wanted to capture and record data from. These machines provided standard 4-20 mA outputs for the values that needed to be measured. Because of the layout of the facility, hardwiring all the outputs back to a central location was not practical and putting a data logger at each machine was cost prohibitive. Not to mention the hassle of trying to assemble the data from all the different logger.

We found a manufacturer with an 8-channel input module with an Ethernet interface and Modbus TCP support. Then, we used our dataTaker DT82I industrial data logger as the central collection point where each of the I/O modules was assigned a static IP address. Then, the data logger was programmed to make a Modbus read of the register(s) at each IP address. Programming the I/O modules and data logger was a snap using the vendor supplied software – the hardest part of the project was wiring the power supplies and machine output to the modules.

Conclusion

Distributed data logging systems have been enabled by industry standards both for the physical interconnection and software for communication. Using equipment from different vendors, you can easily assemble a system using either serial, Ethernet or wireless connections built around communications protocols like Modbus or OPC UA. As an example, a distributed system with over 20 measurement locations was integrated in just a few hours using Ethernet I/O modules and an industrial data logger.