Unlike the devices we used in industrial applications a few years ago, today’s devices are more complex, more functional, and with the ability to generate a lot of time-series data. Even the “dumb sensors” of the past can now produce multiple data streams, images, and even video. Sampling these streams to gather production system intelligence means capturing time-series data.
Time-series data is nothing more than a succession of data points in successive order. The industrial protocol (EtherNet/IP, Modbus TCP, or PROFINET IO) is irrelevant. In years past, these streams were either discarded or sampled at low, periodic rates. Now, more sophisticated data collection systems are available to capture and aggregate these data streams. These streams can be logged directly into cloud applications, middleware software, or local data loggers right on your production network. As a class, the devices that collect these data streams are known by various names such as historians, archives, and loggers. There are three main classes of what I will call data loggers.
Cloud Data Loggers
The emphasis of many vendors building large-scale time-series data collection certainly seems to be on cloud data collection. It’s no secret what Amazon (AWS), Microsoft (Azure), or Google (GCP) think you should do – their cloud is the answer, and the question is somewhat irrelevant to them. They desperately want to be integrated into your manufacturing operation, and charge you every month for that integration, of course.
The advantage of cloud data loggers is that data is located in one place, and if you’re using a cloud service it has simplified and lower software maintenance cost. It also can operate at scale, meaning it can collect lots of data – literally terabytes worth – from multiple systems in various locations.
The disadvantage is that you’re tied directly to the reliability and availability of that cloud connection unless you have some sort of local network buffer to hold the data should your internet connection fail.
Middleware Data Loggers
Middleware is software that sits between the control system networks and the Enterprise or the internet. It is usually software that is located within the manufacturing system firewall.
Middleware data loggers are typically less functional than the enormous tool resources available in the cloud and more functional than the simple data loggers of the embedded world.
Middleware still has a dependency on communications with the Enterprise and the internet, but the risk is lower. You still need to communicate at least to the Enterprise if not the cloud to get the advantages of using all the data. Users are often responsible for software maintenance, which often makes middleware solutions brittle. I think this is probably the least desirable option.
Embedded Data Loggers
Embedded data loggers are those solutions that are designed to work as part of the control system network with direct access to controllers and actuators in the production network. These loggers provide simple functionality and can serve a number of purposes including tracking downtime, monitoring performance, saving product genealogy, monitoring quality indicators, and troubleshooting process upsets.
For most manufacturers, especially smaller ones, none of this necessitates the cost and complexity of cloud computing. None of it requires complex mathematics, running machine learning applications on terabytes of data storage, or using any of those sophisticated and elaborate cloud applications. What’s needed is a good, local data logger and someone who can use it to extract the required information from the data.
The real advantage of a local data logger is that the data is “local.” It’s under your control and available to you without any additional expense. And local data loggers are especially good at collecting data that is useable and manageable. These local data loggers usually are good at scaling and adding metadata that makes the data more valuable than it is in raw form.
Many manufacturers have come to realize that “the cloud” shouldn’t be the default data collection solution. For many data logging applications, local data logging and storage is a better answer. Using the cloud in some applications is like driving a Shelby GT500 in a soapbox derby!
Local data logging can grab data on demand from any of your AB PLC controllers using EtherNet/IP or not, alarm on it, chart it and send it to MS Excel or your favorite database for more comprehensive analysis. A simple tool that does just that needs to be a tool in your control engineering toolbox.
Monitoring of PLC data in all kinds of AB PLCs is easily accomplished with the RTA Raptor Data Logger, a tool that delivers peace of mind by providing real-time monitoring, logging, charting, and alarming of your data locally and in your favorite database.