Effective Edge Data Collection means consistent, standard mechanisms for accessing OT devices, describing data and its meta-data characteristics, and moving that data securely and reliably.
Some of the more vehement proponents of Industry 4.0 and Smart Manufacturing are urging a radical restructuring of manufacturing control systems, tools and techniques. They are insisting that a new breed of machine controller be adopted. A controller that provides not only basic machine control but one that supports 3rd party software applications, Cloud analytics, autonomous process control and more. A controller that not only supports Industry 4.0 applications but simplifies the communications for moving the data across the factory floor.
Some argue that this won’t happen at all and others are just dubious. What everyone does agree on, is that it certainly won’t happen overnight as today’s legacy machinery and often decrepit control systems won’t be going away quickly. In the meantime, edge data collection devices will be used to harvest data from these legacy machine control systems to make data available to Smart Manufacturing applications running in the Enterprise and the Cloud.
Before using these kinds of edge devices, operations and control engineers must carefully evaluate all the components of the systems they will use before deploying any edge computing or edge data collection device.
There are four areas of concern:
This paper examines each of these areas and identifies a total of ten key recommendations that an operations or control engineer should consider before selecting and implementing edge devices.
Platforms are the software systems for turning your factory floor data into actionable information. Manufaturers have there choice from very basic platforms using common and well-known tools to sophisticated Cloud platforms that can be complicated and expensive. The most popular are:
AWS (Amazon Web Services) created Cloud computing and is the leading provider. AWS provides a wealth of applications that you can use to manage your data, generating insights and creating actionable information. You can find databases, compute engines, analytics, security, storage and many more applications. The applications they provide are useful to every industry. AWS provides the technology to build AWS friendly devices, software to enable current devices for AWS and protocols like MQTT and OPC UA that you can use to send your data into AWS cloud.
Recommendation: AWS is the market leader and the most expensive of the Cloud computing platforms. AWS is the most nimble and arguably provides more services. If you don’t have a significant business relationship with Microsoft, select the market leader.
Azure is Microsoft’s online Cloud computing platform for accessing and managing the application services that process data. Azure offers over 200 services/applications divided into nearly 20 categories to support generating insights from plant floor data. The Azure IoT Hub is the main tool for transferring data from supported IoT devices to Azure Data Explorer. Common ways of ingesting plant floor data include JSON packets, OPC UA and MQTT.
Recommendation: There is much discussion around the benefits of Azure vs AWS. Both are sophisticated platforms with a wealth of tools. Select Microsoft Azure if you company already has a significant business relationship with Microsoft.
Some users dislike putting their data into a more expensive cloud service like AWS or Azure. For these users, there are literally hundreds, if not thousands, of IoT application providers that are anxious to ingest your data, manipulate it and provide fancy online presentations.
Recommendation: This is a crowded market and it is unlikely that all of them will survive. If you engage with one of these IoT companies, carefully check their references to ensure your data is secure and avoid having your data stored in some platform that doesn’t survive.
Much of the processing of manufacturing data is not sophisticated and can be done in Excel and other simple tools. Many do this for proof of concepts before engaging with a Cloud platform. Overall, Excels capability of dat ingestion is lackin and leaving it easier for manufacturers to move information to a database first, then Excel.
Recommendation: It’s always prudent to prototype an edge data collection application before committing to expensive, time-consuming software or hardware integration.
Like it or not, hackers are evading all the fancy IT Cybersecurity tools and invading corporate IT systems all over the world. Ask Chrysler, US Steel, that Florida water utility or the people at Colonial pipeline – the list is long and growing. It’s time manufacturers treat their company network as if it’s compromised. That’s not being paranoid, that’s being realistic. It’s the number one cybersecurity risk to the plant floor.
There are many security strategies and tools that manufacturing people can use to protect plant floor operations. The two effective (and one ineffective) strategies for protecting edge devices as they interact with OT controllers and manufacturing networks are:
A one-way gateway is a device with two network nodes in the same device. One manages OT communications and connects to factory floor equipment. The other manages IT communications and connects to applications in the Cloud or enterprise. The OT communication extracts non-control data (data not in a controller) from the OT network. Data is passed to the IT node over a communication link that contains no communication path for messages to travel from the IT network to the OT network.
Recommendation: A one-way gateway is one of the best ways to secure the factory floor and eliminate risk of corrupting an OT controller or network.
Perimeter security is conceptually pretty simple, you put a box around the resource you want to protect (subnet, machine, cell, etc.) and you restrict traffic to that protected resource through ONE AND ONLY ONE connection to your plant network and the Internet.
You restrict traffic over that connection to only authenticated traffic making authorized requests. You block traffic from unauthorized devices. You can even block traffic from authorized sources making unauthorized requests.
The single biggest mistake that many of us make with OT security is not taking advantage of the fact that every single message between a manufacturing system and the external world is known and unchanging. Closely monitoring traffic through that gate and limiting the traffic to expected messages from known sources provides maximum protection for the manufacturing system.
An easy-to-use, well-defined Plant Floor Perimeter Security Appliance is one of the best ways to secure the factory floor. Unfortunately, there are few devices capable of this doing this effectively. The ICS-Defender (https://www.ics-defender.com/) from Dynics corporation is clearly the leader of the category.
Recommendation: Use the Moat and Drawbridge approach to secure access to your factory floor with an effective perimeter security device.
It’s unfortunate but there are those engineers and operations that choose to just ignore cybersecurity. Sometimes it’s the press of everyday business but usually it’s the confusion generated by overly complicated cybersecurity technology that makes ignoring the issue seem like a good decision.
Recommendation: Don’t ignore cybersecurity aspects of edge device integration.
Ignoring cybersecurity issues doesn’t make them disappear. They make decisions like using high risk, dual NIC devices more likely.
Recommendation: Reject using dual NIC devices that make comprising an OT system from the corporate IT easier.
There are those of us in Industrial Automation that focus on the wire protocol, the merits, features and functions of which are debated endlessly. What many fail to understand is that the most important component of building systems that process manufacturing data (like Industry 4.0 applications) is the data model (a.k.a. Information Model). It is unquestioningly where the value is created and thus, the component of your manufacturing system that deserves significant attention.
An Information Model is the representation of concepts, relationships, constraints, rules, and operations that capture the characteristics of an entity or process. An information model provides a sharable, stable, and organized structure for communicating information about that system or entity. The Information Model is simply a structure that defines the component, devoid of any information on how those characteristics captured by the model can be stored or accessed.
You can get as complex or as straightforward as you’d like with an Information Model. It has infinite flexibility to describe your device or process in whatever way serves you best. When complete, you can document your process using a standard language and symbology that conveys to everyone exactly what each entity is and what relationship exists between those entities.
But if you customize it for your application, it’s yours and only yours. You may have modeled a pump with the characteristics defined as speed and RPM. Someone else might have used a pump model that includes the current flow rate. The RPMs might be an integer value in one system and a float in another. Since you’ve both modeled the pump differently there is no saving in labor or productivity for any of your customers. You may have given them a model using some open standard communications interface (like MQTT, for example) but they still must incorporate your proprietary characterizations of the pump. That leaves us where we’ve always been, repeating the integration again when we use a different pump in the next application.
It’s actually worse than that. We haven’t even begun to talk about common transports, data encoding, and access to the data contained in the Information Model. It’s one thing to define a nice Information Model for your device, your machine or production line but if there isn’t any standardized way for others to know that you are using that model, to know what’s in it, and to easily access it, it doesn’t save anybody any time or money. It creates no value.
And that’s the problem that many of us have faced over the years. The big problem in the past was that a lot of the models were tightly integrated with a specific technology or communication protocol. In other cases, the Information Model was designed specifically to solve problems in one, particular application domain. And when there was a mechanism to create a flexible Information Model, there wasn’t a standardized way to deploy the model in an actual system.
OPC UA is an open technology that best solves this problem. OPC UA is the first technology to provide system architects with a common infrastructure for modeling data and providing the transport, encoding, and security to employ it. Information Modeling in OPC UA provides enhanced organization, flexibility, and scalability. It allows you to customize your view of your information to agree with the way you do business and how you integrate with other enterprise applications, improve asset performance and reliability, and act on your available data with greater agility and confidence.
OPC UA Information Modeling is different than other technologies in several ways:
Figure 1 – The CESMII Building Blocks for Smart Manufacturing (Used with Permission)
One of the leading organizations working to clarify Smart Manufacturing, promote it, educate and unite the manufacturing community and develop the enabling technologies is CESMII1 (https://www.cesmii.org/). CESMII views Smart Manufacturing as the ability to collect data, contextualize, process and model it to make more intelligent decisions about a manufacturing process.
This kind of system offers significant advantages to manufacturers:
Recommendation: Use OPC UA with edge devices in systems that interact with multiple applications or model data using a well-known standard.
Recommendation: Use MQTT with edge devices used for prototype systems and systems that are local and do not require interfacing with applications that also do not require standard data or a common and well-known data model.
There are two good choices for the protocols to use in an edge device, OPC UA and MQTT. OPC UA is clearly more able to easily support data models than MQTT, though MQTT can be massaged to function in this environment.
MQTT is a good a solution for many small, non-closed loop IoT applications. It has a large number of adherents because of its small footprint, simplicity and “push” architecture. Many of the large automation vendors and cloud vendors that support OPC UA also support MQTT. It is a reasonable solution for IoT prototyping and small, in-house applications but may not be the right solution in the era of open, widely available data models for all automation devices.
OPC UA is a good solution for many industry 4.0 systems not requiring massive data transfers to many different Clients. Manufacturers who anticipate a future with downloadable data models will find that OPC UA is the only solution that promises support for all the data model architectures being developed to ease integration in the future. Manufacturers must ensure that their vendors have well-implemented, certified and well-supported OPC UA implementations.
Like all other automation battles we’ve fought over the years, there is not going to be a clear winner. Both technologies will grow and prosper. Developers, integrators and system architects will eventually come to learn where they have the best success with OPC UA and the best success with MQTT. Neither will be the sole solution, and that is a loss for manufacturers who are going to have to understand, support and work with both technologies and figure out which works best for what in which applications.
Real Time Automation is uniquely positioned to support manufacturers in this environment. Our communication gateways support both OPC UA and MQTT. That means that control engineers and operations staff now have the ability to reach into a Siemens S7, an Allen-Bradley Logix controller, an Allen-Bradley PLC5 and other controllers and devices to extract information and publish it to an MQTT broker or present it using our OPC UA Server.
Like all RTA gateways, the unit is extremely configurable. You can pick single tags, User-Defined Tags (AB), Data Space Blocks (Siemens) and other data using any one of the many protocol drivers in the RTA protocol suite. And on the MQTT side, the gateway publishes that data using topics that you define to the brokers you identify.
Our RTCONNECT® factory floor data collection software platform supports both MQTT and OPC UA and collect data from many different factory floor technologies, manipulate it, scale it, normalize it and send it out over OPC UA and MQTT.
John S. Rinaldi is Chief Strategist and Director of WOW! for Real Time Automation (RTA) in Pewaukee, WI. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of over 100 articles on industrial networking and the author of six books including: