Operational technology: Data acquisition, data architectures, data analytics

Using Big Data for operational technology (OT) automation and control applications is increasingly important and can be a bewildering journey if the right questions aren’t asked. See four elements of data analytics system architecture.

By Nate Kay, P.E. March 18, 2021


Learning Objectives

  • Users looking to solve an operations technology (OT) automation problem need to know what problem they want to solve. 
  • Following the data and asking questions along the way helps shape the answer. 
  • Once the answer has been found, the system architecture will help make it a reality. 

How data is treated for operational technology (OT) automation and control applications is increasingly important as people talk about Big Data analytics role in meeting enterprise goals. Data design, data architecture and data acquisition profoundly affect data analytics, or, in old-school terms: Garbage in, garbage out. Learn best practices for data gathering so data can be turned into information and value beyond its original purpose.

Consider this scenario: Two travelers are on a journey. The first one says, “We’re lost.” The second replies, “We’re not lost, I know exactly where we are. I just don’t know how to get to our destination.” This highlights three pieces of information are need when trying to reach a destination. Knowledge of the destination, our current location, and a path to get there.

Data collection and analytics is similar. It is easy to “jump in” and start collecting data. However, before it is important to review the three points listed above before doing so:

  1. The destination: What is the problem we want to solve?
  2. The location: What data is available to the solve the problem.
  3. The path: How does the data we have move us toward the solution?

The data analytics destination: Identify a problem, ask a question

The first step in data analytics is to identify a problem and then ask a question. For example, a manufacturing company may have a product with a wide variance in material strength, resulting in poor quality (the problem). The company suspects variations in pressure or temperature during the manufacturing process are the reason. Next, restate the problem in the form of a question, which we will use data to answer. In this case we can ask, “Are variations in pressure or temperature affecting the strength of my product?”

The location: Gather data needed to answer the question.

The next step is to decide what data is needed to answer my question. The available data can be thought of as my current location. A user may say: “On the surface, the data I need to collect is obvious, pressure and temperature. But, to have a complete picture, I also must look at where, when and how the data is gathered.”

For example, the user may have a sensor measuring the temperature of a process tank. However, the sensor may be mounted at the top of the tank and not measure the exact temperature where the reaction is occurring. So, the user may need to add a second sensor to more directly measure the reaction.

The user also will need some form of linking data, which allows them to associate each quality measurement with a corresponding process measurement. In this example, the user will record a common batch number that is associated with both the process data (temperature and pressure) and quality data (material strength).  They’ll also need to generate a batch number, which will be tracked through all steps of the process.

The data analytics path: Look at the relationship between the data and the question.

Analyzing and following the data will lead the user to the destination, which is an answer to the original question. There are a number of paths to choose from. These include analytics methods ranging from regression and classification algorithms to neural networks and supervised learning. However, the user needs to have a good understanding of the relationship between the data and the problem before starting on the path.

For example, they might want to know how variations in pressure and temperature affect my product quality in the form of material strength. It may be tempting to select a model, plug the data in and look for results. But having a good understanding of process will achieve better results. If the user knows a temperature overshoot by 2 degrees will weaken the product, then they can select a model that will help look for this in the data. Also, if it takes an hour of this over-temperature to impact quality, that helps with selecting an appropriate resolution and sampling rate. It may require making some assumptions, but the better the assumptions, the easier it will be to answer the questions.

Four elements of data analytics system architecture

With everything addressed and answered, the user now has a road map to the destination and can embark on the data collection. The vehicle used to get there will be the system architecture. There are common components used to build this architecture. Several of these components, as well as use cases, are listed below.

  1. Edge device: Provides an interface between the devices on the local network (the source of the data) and the public network. They can be used to buffer and format data and perform calculations. Some edge devices have options to configure a firewall, provide cellular access and act as a protocol converter.
  2. Data concentrator: This device, which is often a programmable logic controller (PLC), is used to collect and aggregate data from existing sensors and PLCs. It can be used to buffer data, format data, and perform calculations before uploading to a server computer.
  3. Local server: Server PC, hosted on premise. It is often used to provide monitoring, reporting and data warehousing.
  4. Cloud server: Server PC, hosted in the cloud and accessible over the internet. It can be used to provide dashboards, reporting, notifications, data warehousing and advanced analytics.

The path from data acquisition to solutions can sometimes resemble a long and winding road. However, the extra effort spent identifying the problem, asking questions, and gathering quality data will lead to a more direct route. The system architecture, built on a set of common components, is the vehicle that will take me to my destination. So, enjoy the drive.

Nate Kay is a senior project engineer at MartinCSI. MartinCSI is a CSIA Certified control systems integrator in Central Ohio. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.


Keywords: system integrator, Big Data, data acquisition


See additional system integration stories at www.controleng.com.


How do you design and develop your automation roadmap?

Original content can be found at Control Engineering.

Author Bio: Nate Kay is a senior project engineer at MartinCSI.