In the previous post (Blog post 6), we explored about acquiring data using derived measurements. In this post, we will examine in detail about acquiring data from industrial control systems.
PLC (Programmable Logic Controllers), PAC (Programmable Automation Controllers), CNC (Computerized Numerical Controllers), DCS (Distributed Control Systems), Motion controllers, and SCADA systems (Supervisory Control And Data Acquisition systems) are some of the the most commonly used Industrial control systems.
These industrial control systems perform some of the most complex and real time control and automation of complex processes, machinery, and systems. Considering the critical nature of the tasks that these systems perform, these industrial control systems were kept as isolated systems that were not connected to any external systems or networks. However, with Industrial IoT, more and more industrial control systems are getting connected and becoming a part of a larger IIoT ecosystem. Integrating and acquiring data from Industrial control systems into an IIoT system is also known as IT – OT integration [1].
There are many ways of of integrating and acquiring data from Industrial control systems. OPC-UA, EthernetIP, Profinet, Modbus, Serial interfaces are some of the commonly used interfaces for acquiring data from industrial control systems. While interfaces like OPC-UA EthernetIP, Profinet are used in the newer versions of Industrial control systems, older legacy systems still use serial interfaces and Modbus.
Let us explore and understand data acquisition from industrial control systems with an application example.
Application Example: Let us consider a metal working shop where hydraulic punching machines are used for punching holes in metal sheets. These punching machines are controlled by legacy Industrial PLCs installed in every punching machine. There are a total of 10 punching machines in the workshop. These punching machines are the most vital equipment in the workshop.
Operations management team of the workshop have embarked on an initiative to improve availability of these punching machines by performing condition based maintenance [2]. In order to do this, the required operational and machine condition parameters need to be acquired from these punching machines.
Equipment : Hydraulic punching machines
Data Source : Legacy PLC systems
Interface : Modbus on RS-485 [3] Parameters to be acquired : No.of punching operations, Power consumption parameters, Equipment condition parameters
Solution Overview: Given below (Fig 1) is an overview of one of the possible solutions.
Fig 1 - Acquiring data from hydraulic punching machines using Modbus
Shown above is the overview of a possible solution for extracting the required data from the punching machines. As we are aware, each punching machine is controlled by a legacy PLC system. All these PLC systems act as modbus slaves and a data aggregator PLC acts as the modbus master. Data from all the slave PLCs are acquired through modbus RTU on RS-485 and aggregated in this central data aggregator PLC.
The aggregated data is then sent to a data diode through Modbus TCP (More on data diode as you scroll down the blog post), and data from the data diode is sent to the edge device (IoT gateway). From the IoT gateway, the aggregated data is then sent to the IoT platform. Let us elaborate further on two key parts of this solution, namely the modbus system and the data diode.
Modbus system:
In this example, the Modbus system comprises the following components
Modbus master (Data aggregator PLC)
Modbus slaves (Individual Punching machine PLCs)
Cabling and required repeaters
For this modbus system to work, certain configurations and application programming needs to be done. Details are as below :
Configuration: Given below are the minimum parameters that need to be configured both in the master and slave PLCs for the Modbus system to function.
ID : Master – 1 (Data aggregator PLC), Slaves - 10 to 20 (Punching machine PLCs)
Baud rate : 57.6 Kbps
Data bits : 8
Stop bits : 1
Parity : None
Mode : RTU
Address mapping: Modbus provides standard address ranges for mapping data in the slave devices.
Discrete outputs or Coils (Binary): Address range - 1 to 9999, Read / Write
Discrete inputs (Binary): Address range - 10001 to 19999, Read only
Input registers (Size: 16 Bytes): Address range - 30001 to 39999, Read only
Holding registers (Size: 16 Bytes): Address range - 40001 to 49999, Read / Write
For our example, we will use the below address range in the slave devices for extracting the required data (Production data, power consumption, condition data)
30001 – Punching count
30010 – R Phase voltage
30011 – Y Phase voltage
30012 – B Phase voltage
30013 – R Phase current
30014 – Y Phase current
30015 – B Phase current
30016 – KWH LSB
30017 – KWH MSB
30018 – R Phase peak current
30019 – Y Phase peak current
30020 – B Phase peak current
30030 – Hydraulic oil pressure
30031 – Hydraulic oil temperature
30032 – Hydraulic oil flow in the hydraulic system
30033 - Moisture in the hydraulic oil system
30034 - Vibration (X-axis)
30035 - Vibration (Y-axis)
30036 - Vibration (Z-axis)
30037 - Fault code
Function codes: To facilitate data exchange between master and slave devices, modbus provides certain commands known as function codes. Listed below are these function codes:
16# 01 – Query the state of coils of a slave device
16# 02 – Query the state of discrete inputs of a slave device
16# 03 – Query the state of holding registers of a slave device
16# 04 – Query the state of input registers of a slave device
16# 05 – Write single coil of a slave device
16# 06 – Write single holding register of a slave device
16# 0F – Write multiple coils of a slave device
16# 10 – Write multiple holding registers of a slave device
Request - Response: Modbus works by request response (i.e.) the master sends a request and a slave responds to the request. Let us consider the case where we need to read the Punching count data from Slave 10.
Fig 2 - Modbus request response
In this case the master sends a request “0A 04 75 31 01 Checksum” to the slave. “0A” is the slave id in Hexadecimal, “04” is the function code for reading input registers from the slave, “7531” is the starting address of the data in Hexadecimal, and “01” is the number of registers that need to be read. Checksum is automatically computed.
If the communication between the master and the slave works, then the slave responds with “0A 75 31 02 00 25 Checksum”. “0A” is the slave id, and “7531” is the starting address of the data. “02” corresponds to number of bytes of data, and “0025” is the data (Punching count) in hexadecimal.
Exception codes: If the slave is unable to respond to the master, the modbus system sends a exception response to the master. Given below are the list of modbus exception response codes.
“01” – Illegal function code
“02” – Illegal data address
“03” – Invalid data value
“04” – Slave device failure
“05” – Slave is processing the function code
“06” – Slave is busy
Data extraction sequence: Now that we have an understanding of the modbus system, let us look at extracting the required data from the punching machines in the workshop. Shown below is a sequence of activities needed for extracting the data.
Fig 3 - Data extraction sequence
The master starts the Request – Response cycle with slave 1, waits for 100 milli seconds after completing the Request – Response cycle with slave1, and subsequently proceeds to slave 2. The same sequence is repeated with every slave as shown in the above drawing. This polling sequence is done in an endless loop to facilitate continuous data extraction from all the slaves. Please note that this continuous polling is one of the methods of extracting data from a set of slaves. Another method could be event based data extraction from the slave devices.
The data aggregator PLC (Modbus master) acquires the data from all the slave PLCs and stores the data in specific memory locations. This data is then sent to the IoT gateway through a data diode. All of this data extraction sequence can be written as an application program in the modbus master. In our example, the application program will be written in the Data aggregator PLC.
Data Diode:
Till now, we have seen how the data aggregator PLC acquires the required data from the slave PLCs that control the punching machines. Now this data has to be sent to the IoT platform for further analysis and decision making. This exposes the PLCs to the external network, and most of the times this external network is the Internet.
Now that we are exposing the PLCs (OT network) to the internet, we should make sure that cyber-attacks from the internet are prevented to the best possible extent. Now we are stepping into the complicated world of of IoT security. While the topic of IoT security is inherently complex involving multiple layers, methods and systems, in this example we will explore about one IoT security building block (data diode) that provides credible hardware level deterrence against cyber-attacks.
As shown in Fig 1 , the data from the aggregator PLC is sent to the data diode and then to the IoT gateway and subsequently to the IoT platform. What is this “Data Diode” and how does it work? Shown below (Fig 4) are the building blocks of a data diode.
Fig 4 - Data diode
As the name suggests, the data diode is a device that permits only unidirectional flow of data. In our case, the data diode should permit data flow only from the aggregator PLC to the IoT gateway. Fig 4 provides an overview of the different components of the Data diode, namely, the “Transmission module”, “Reception module”, and “Optical Isolation”
In the Transmission module, the aggregated data is received from the data aggregator PLC through Modbus TCP. Only the payload information is extracted from this data. After this, the payload information is converted to protocol known as Asynchronous transfer mode [4] also known as ATM. Subsequently, this data is transmitted optically to the reception module through a light emitting diode and a fiber optic cable.
Optical isolation between the transmission module and the reception module is achieved through a combination of LED, optic fiber cable, and a photo detector. This enables unidirectional information flow and effectively prevents any reverse information flow or unwanted access originating from the internet.
In the Reception module, the photo detector receives the optical data and converts into electrical data in ATM format. This ATM data is converted back into Modbus TCP to be sent to the IoT gateway.
Reception and transmission sides of the data diode are completely isolated, and even the configuration of routing information needs to be done separately for the transmission side and the reception side. With these features, the data diode effectively isolates the OT network (Punching machine PLCs) from the internet acts as a credible deterrent to cyber-attacks that originate from the internet.
In this blog post, we have delved deep into acquiring data from PLCs through modbus protocol, and also looked at one type of an IoT security building block (data diode) that can offer a credible deterrence at a hardware level to cyber-attacks. Please note that IoT security is a very complex topic and data diode is one example that is relevant to the application discussed in this blog post. IoT security will be covered in great detail in subsequent blog posts.
Through blog posts 5,6,7 we have explored three types of data acquisition, namely: Direct sensor data acquisition, Derived measurements, and Acquiring data from Industrial control systems.
Check out my next post on Edge computing ...
[1] Information Technology – Operational Technology integration
[2] Condition based maintenance, also known as CBM is a maintenance methodology where the decision of "when the maintenance should be done?" and "what type of maintenance is to be done?" is decided based on monitoring and analyzing the actual condition and performance of the equipment. When compared to planned maintenance, where maintenance is performed based upon predefined scheduled intervals, condition-based maintenance is performed on an as-needed basis decided by the actual condition of the equipment.
[3] Modbus is a master-slave protocol developed by Modicon in the year 1979. Modbus is used for data exchange among industrial control systems like PLCs, input modules, output modules, SCADA systems, and HMI systems. Modbus is an application layer protocol that can operate either on serial interfaces (Modbus RTU / ASCII) or Ethernet (Modbus TCP). In a Modbus system there can be one Modbus master and a maximum of 247 slaves. Master and slaves can communicate bidirectionally in a request response mode.
[4] Asynchronous Transfer Mode, also known as ATM was developed by the telecommunications industry for the high speed, low latency requirements of one-way, real-time voice communications. It encodes data into fixed-size packets for consistent, reliable data transfer, without the need for receive-side confirmation. Also note that while converting Modbus TCP to ATM only the payload information is extracted. This provides an additional layer of defense by removing any routing and IP information. In the reception module, the routing information is added while converting ATM to Modbus TCP. Please not that administration and configuration of the Transmission module and Reception module are done separately.
Comments