The Industrial Edge can be understood through an analogy of the different types and capabilities of a Purdue Reference Model Level 1 device. I’ll use the AWS terminology for this article, and it could be written around Azure and other mature in concept cloud service providers.
The Remote Terminal Unit (RTU)
At it’s simplest, the Edge can be a RTU … but an RTU with security for the communication with the cloud / higher levels. AWS IoT Greengrass provides this RTU capability. It currently supports OPC UA, Modbus/TCP, EtherNetIP and MQTT. It can get data from the ICS and forward it to the cloud service. It can also accept read, write and administrative requests from the cloud and forward those to a device in the ICS.
If your system does not support one of these protocols, there are (at least) two options.
- You deploy a protocol converter that supports a myriad of protocols, such as a Kepware or Matrikon to do the protocol conversion to OPC UA or MQTT, logically between the ICS and the Industrial Edge. OPC can be thought of as the universal translator of ICS, both the original version and now OPC UA. MQTT looks like it will play much the same role in IIoT.
- You deploy the protocol code in the Industrial Edge device, most likely as a container, but possibly as an AWS Lambda function on Greengrass.
Figure 1 – The Industrial Edge as an RTU
Where the Industrial Edge exceeds the RTU is in security. Greengrass creates a mutually authenticated and encrypted session between the Industrial Edge and the Cloud. There are other security benefits, such as automated security updates on the Industrial Edge device, managing secrets at the edge with AWS Secrets Manager, enabling root of trust with a secure element on the Industrial Edge device, and machine learning based anomaly detection. I’ll cover security architecture and security configuration at the Industrial Edge in a subsequent article.
The Programmable Logic Controller (PLC)
The ICS world found value in adding a compute capability to RTU’s that made operations more efficient and faster with decisions made closer to the process. The same is true at the Industrial Edge. Consider the following cases and it should sound familiar to uses of a PLC.
- Sending all the data to the cloud may be inefficient, costly and unnecessary. The Industrial Edge may structurally, algorithmically, time-based, or use some other criteria to determine what data should be sent to the cloud.
- It may be faster, more efficient and less expensive to perform some calculations and run code in the Industrial Edge and send the results to the ICS and the Cloud.
- Latency and Cloud or network availability concerns may dictate that code be run and decisions made in the Industrial Edge and provided back to the ICS rather than done in the Cloud.
In the AWS world the Industrial Edge moves from an RTU to a PLC by either writing this code in Lambda functions in Greengrass or by deploying the code in a container in the Industrial Edge device. The Industrial Edge compute capability can be scaled in the same way most PLC modules offer a family of models based on needs.
Figure 2 – The Industrial Edge as a PLC
It is important to note that the Greengrass security applies here as well.
The PLC With An Industrial Firewall
Closed loop cloud services, where the cloud will send requests to the Industrial Edge, introduce new risks. If the RTU capability is in the Industrial Edge, then legitimate protocol requests could be forwarded that would write (change settings), manage (stop, start, change IP address, etc.), and in some cases modify the logic/program itself.
The closed loop cloud services I’ve encountered often have effectively secured the Cloud / Industrial Edge connection, but they have allowed nearly unrestricted ICS protocol access and capabilities past the Industrial Edge. This necessitated putting in an industrial firewall with ICS protocol deep packet inspection (DPI), such as mGuard, OT-Fuse or Tofino, between the Industrial Edge and Level 1 to limit the impact of a compromised or improperly functioning cloud service. This Industrial Firewall could, and I’d argue should, be a container on the Industrial Edge device.
I have a lot more to say on the Industrial Firewall in the Industrial Edge in a subsequent article. This could resurrect, or at least jump start, that product category. It is likely the biggest potential market until the Industrial Firewall is integrated into the Level 1 device.
Figure 3 – PLC with Embedded Industrial Firewall
One last related thought – why couldn’t or shouldn’t a device similar to the Industrial Edge device connected to universal I/O and properly located in the ICS be the future of the Level 1 device?