The Industrial IoT data flow in a factory

The best way to explain the I-IoT data flow of industrial signals, from their generation at field level in the factory, to when they are processed in the cloud, is to start from the controllers. They perform the following steps cyclically and sequentially:

1. Read the measurements that arrive as input from the sensors
2. Execute the control algorithms that are fed by the last reading of the inputs
3. Write the outcomes of the control algorithms as outputs to the actuators

This cycle is the same for all kinds of controllers (embedded controllers, PLCs, or DCSes, for example) but a cycle's duration varies according to the kind of controllers in use:

• Embedded controllers take a few milliseconds
• PLCs take between 10 and 100 milliseconds
• DCSes take between 200 and 1000 milliseconds

In any case, any controller, in every scan cycle, whatever its duration is, performs a reading of all the sensors and calculates the values for all actuators linked to it. For example, a PLC that controls a gas turbine can manage up to 3,000 readings coming from the sensors or as feedback commands from the actuators. Basically, this means that 3,000 values are read every 100 milliseconds, 30,000 every second, 1,800,000 every minute, 108,000,000 every hour, and 2,592,000,000 each day. This is just for one PLC controlling a single equipment, even if that piece of equipment is quite complex, like a gas turbine.

The values refer to analog signals, such as temperatures, pressures, or Boolean for two-status representation, such as whether a valve is open or closed, or whether a part in a conveyor is present or not. The sampling of these values come as an input to the systems of the upper level, such as SCADA and Historian, as a representation of the related signals. In the industrial world, the digital representation of a signal is named a tag, and its samples are called time-series. A time-series is an ordered sequence of timestamps and values related to a signal in a particular time interval. SCADA systems and Historian gather the data from the controllers, but with a higher scan time. Typically, they collect the time-series using a scan cycle from 500 to 1,000 milliseconds in SCADA applications, and from one second to one minute or more in the Historian systems.

Collector compression applies a smoothing filter to incoming data by ignoring incremental changes in values that fall within a deadband centered around the last reported value. The collector reports any new value that falls outside the deadband to the Historian archive and then centers the deadband around the new value.

In addition, a smoothing filter is applied to the sample of analog signal that is gathered by the SCADA and Historians by ignoring incremental changes in values that fall within a deadband, which is centered around the last reported value. Samples of the Boolean signals are typically collected when their state changes rather than at every scan time. In this way, the amount of the data that SCADA and Historian must deal with is much less compared to that managed by controllers, but it has a lower time resolution. The balance between the amount and the resolution of the data collected is a trade-off, depending mainly on the dynamic of the industrial process and the resources that are available. PLCs and DCSes can also provide other information to the upper levels besides the time-series, such as the following:

• A memory buffer area that temporarily stores the values of the internal variables of the controllers at its scan time in a sliding time window. The memory buffer area can be exported as a binary or text file on an event or a condition.
• Alarms related to measurements or calculations that fall outside the configured high or low limit for that variable.

From SCADA, the most important information flows to the MES system, and vice versa. At this level, the information provided from SCADA can be the total amount of a batch, the timestamp of its start or stop, quality samples, and so on. The information received from the MES might be the recipe to use, a cleaning cycle to be carried out, the kind of product or part to be produced, on which equipment, and so on.

From the data collection perspective, the data sources of the I-IoT are the following:

• The PLCs and DCSes at level 2 of the CIM pyramid
• SCADA systems at level 3 of the CIM pyramid
• Historian systems at level 3 and 4 of the CIM pyramid

Sensors, RTUs, CNCs, single pieces of equipment, or stations that are driven by an embedded controller cannot act autonomously as a data source for the I-IoT gateway. This is because they have too many connections to isolated networks that are managed by legacy protocols. Moreover, their data is mostly collected and made available by the PLCs and DCS, so there is no need to connect directly to them.

PLCs and DCSes in the control network are managed by fieldbus protocols, such as Modbus, Profibus, and ControlNet. Fieldbus protocols are specialized industrial network protocols that ensure determinism in the packet delivery to the devices that are configured as belonging to that network. PLCs and DCS manage all data coming from the sensors and devices of the lower levels according to the resolution of their scan time. Control networks are isolated networks that are protected by a firewall. They have a few well controlled ports that are open to the upper levels by means of the firewalls. 

SCADA and Historian are in the corporate network and are based on Ethernet, so they are not in an isolated and specialized network, and therefore don't need specific network cards or boards to communicate with the other systems. SCADA and Historian do not collect all the data that is made available by the PLCs to which they are connected. Instead, they collect the most important data, and that which has a lower frequency.

In any case, whatever the device that is acting as a data source is, we need to have a software layer to interact with the industrial data source through its own protocol for querying tags and time-series and exposing them by means of a standard interface to the upper levels and external systems. This software layer, which acts as a translator between the controllers and the producers of the industrial data and the consumer systems, is the Open Platform Communications (OPC). The OPC is a standard that is used to abstract PLC or DCS-specific protocols (such as Modbus or Profibus) into a standardized interface. This allows SCADA and other systems to interface with a middle-man which converts generic OPC read or write requests into device-specific requests and vice versa.

Through the OPC, the PLC or the DCS can expose tags, time-series, alarms, events and Sequence of Events (SOE) to any system that implements the OPC interfaces. In the next chapters, we will look at how the OPC standard has changed from its first specification in 1996, when it was called OLE for process control, to the current specification, which is now called OPC. It has overcome various challenges related to security, data modelling, and performances in the manufacturing systems. Since their beginnings, OPC specifications and the related interfaces have enjoyed considerable success, becoming over the course of few years the de facto standard to expose industrial application data and make it available to the external systems.

SCADA and Historian, which were initially developed to be consumers of industrial data, therefore implementing an OPC client interface, themselves became producers of industrial data, therefore so implementing an OPC server interface and playing both roles at same time. The quality and the performance of the OPC technology had various issues and limitations at the beginning. Even so, the adoption and the spread of the OPC in the industrial world was considerable. This was because of the significant need of all the actors involved, which includes vendors, end users, and integrators, to exchange data between applications belonging to the automated production system in a standardized and reusable way. OPC interfaces allow you to query for time-series and data cyclically, both on changes, and through subscriptions with dead bands and a scan time typically from one second. Cyclical data collection is also called in polling or just polling, on-change data collection is often referred as unsolicited, and the publish/subscribe mechanism is also known as subscription.

The OPC standards include two main specifications for OPC interfaces: the so-called OPC Classic and the OPC Unified Architecture (UA). These specifications have no compatibility with each other.