Analytical Insights #1 - Data Acquisition from OT (Operational Technology) Systems

Microsoft Most Valuable Professional Dave Shook, Fusion’s Chief Data Officer, dives into a 9-part educational series discussing various topics for asset-intensive industrial companies who need analytical insights to improve operations. The first part of this series is the topic of Data Acquisition from OT (Operational Technology) Systems.

Located in the picture above, we have some industrial equipment, a pump, a motor, a flow meter, and a flow transmitter controller –that control the flow rate all as part of a distributed control system or industrial control system firewall. Then there is a demilitarized zone or DMZ Network. Then another firewall goes through the corporate business network. Then another firewall goes out to the internet and into Microsoft Azure or a specific cloud. 

Before moving forward, it is critical to first discuss the complexity involved in acquiring this operational technology. The process data, the flow rate, and the actions taken by the controller are collectible from the control system itself. The technology for doing this is pretty mature and is largely, but not entirely, based on a set of protocols called OPC. Most control systems support OPC, or you can get OPC connectors. Usually, what happens is there's something called a historian running in the DMZ that collects these values at some interval and stores them locally.

In addition to those signals and calculations in the control system, it can also detect alarms or other events. This data is structurally different from the data in a historian. It tends to live in an alarm and event database often abbreviated as A&E. This data is quite different from the historian data in terms of the data structures and how it's queried so it tends to live in a different system. Unfortunately, there are additional data pertaining to the operations that do not even make it into the historian of the alarms and events server.

For example, the motor control and things like vibration measurement often don't make it into the control system directly. Instead, there's an auxiliary set of computers either specifically for vibration monitoring or almost certainly for motor control. These systems are sophisticated in their own right and have quite complex computations. But the control system often does not digest the data they produce. So you might get a small, thin subset of the data transmitted to the control system so the operator can detect if something has gone badly wrong or so the operator can start to stop the motor controllers. But a lot of the data in vibration systems and motor control systems tends to be stranded in the control system or even stranded upstream of the control system. To make any meaningful analysis of this equipment, especially in the context of the overall process, you often need to put some sort of auxiliary data acquisition system in place to collect the data from the vibration system or from the motor control systems and get that data out to the cloud.

These days, with intelligent IoT devices and intelligent monitoring devices, sometime systems can communicate all on their own up to the cloud because they're just doing monitoring and they're not capable of affecting the process. They don't have to move through this series of firewalls necessarily, but you still have to acquire that data.

In order to be able to do meaningful analytics in the cloud based on your operating data, you need to acquire the operating data first. With Fusion, what we do and encourage others to put some data acquisition client with your DMZ or even on the auxiliary networks, if possible, that can then transport that data up to Azure. Then can deal with the fact that historian data or OPC data s structurally different from alarms and events. That vibration data is structurally different from simple flow measurements, and so on.