Digitalization, Industry 4.0 and the Industrial Internet of Things (IIoT) are all trends moving the automation market. Academics and technology advocates will debate the nuances of these themes, but control engineers know they mean one thing: more complexity and technology to deploy and maintain in their applications. The end of the Field Bus Wars ushered in an era of open protocols but the proliferation of available protocols over time has created its own set of burdens. The control engineer of today loses sleep maintaining legacy systems while incorporating new devices and technologies.
It is completely reasonable to see a half dozen unique protocols being utilized by devices on a mature factory floor. Robotic arms centered around EtherNet/IP, a filling machine cell from Germany leveraging PROFINET and energy monitors that feature Modbus. Maybe there is a zombie machine, one that still operates but has programming that can no longer be accessed or altered. Someone popped on a few IO link sensors to monitor this undead member of the manufacturing lineup.
The complexity and costs of maintaining these diverse systems are significant. Troubleshooting these protocols and devices will now only be half the battle to be faced. That is because Industry 4.0 will require these systems to report data from the factory floor to either IT or a cloud-based system, which adds OPC UA and MQTT to the suite of protocols one needs to understand. To complement all the above-listed technologies, security is a growing consideration pushing requirements of all Ethernet-based applications.
This proliferation of technology and the one tool for every job attitude most technology groups have about their protocol make picking the right protocol or device for a job a very challenging proposition. This situation is specifically distressing because, for most control engineers, communications technologies are not core competencies. The ongoing need to invest resources and fund the deployments of communication standards largely inhibits improvements in the base application.
In this paper, we will work to dissect the requirement of Industry 4.0 and help individuals create a road map for more intelligent technology deployments. The complexity of bringing Industry 4.0 to their factory floor is immense but comprehending the practical requirements does not have to be.
There are two distinct network ecosystems the Operations Technology (OT) network and the Information Technology (IT) network. If the goal is to embrace the value of Industry 4.0, then there needs to be a bridge between IT and OT. To do this practically, one must understand the role, players, and unique characteristics of each segment.
OT networks, commonly referred to as control networks, are closed, insecure networks of devices and central controllers. If a control engineer is responsible for deploying and maintaining a device, it is likely part of the OT space. The data transfer in these networks is largely cyclic. Determinism and reliability drive the communications requirements. OT encompasses everything from automation devices and sensors to the controllers and PLCs. If a device has a primary responsibility of determinist data transfer in support of discrete or process automation, it lives in the OT space.
The OT space is defined by turning physical world inputs and effects into data points. A motor is set to run at 60%; a valve reports a closed state; a temperature controller reports a current temperature and set point target. Some refer to this as the third wave of industrial automation or Industry 3.0. The OT space has been working since the late 70s to help the physical manufacturing world go digital. The dominant protocols that support this type of communication are Modbus TCP, EtherNet/IP, Profinet and EtherCAT.
IT networks are arguably the more widely understood network, but these networks have not traditionally been managed by controls people. IT systems focus on securely giving humans and other systems access to information. These systems generally have many more devices on a network and a greater variety of technology with a wide range of purposes. This population makes event, publish/subscribe and push-based data transfers vital to optimize network bandwidth utilization for reporting. From the perception of a control engineer, IT is everything above a PLC.
The IT space can be defined by the transformation of data into information. Value 66 becomes the point of information 66 degrees Fahrenheit. A floating-point value becomes a percentage of tank fill. In the IT space, we need to transform data points from applications or sub-process for digestion by human users or other programs. The more accurately we can contextualize the data into information the better.
When we talk about IT requirements for an automation application, the conversation is focused on how to gain access to the devices’ data while maintaining network security and then how to model the data.
If a person has ever moved data from a PLC to an ERP, MRP or other enterprise application, that person has stepped into the IT space. Historically devices below a PLC moved data to IT networks thru a PLC and arrived in PC via something like OPC DA. Today, however, many devices on the line may natively support protocols like OPC UA or MQTT. For these devices to offer their full benefit, they need access to networks outside the closed OT network confines. There are compelling reasons to allow end devices this access but there are likely more reasons not to. What would an IT person say if asked for a unique pinhole through the firewall for every device in the automation application? To practically support the IT/OT convergence, people can no longer believe that generic IoT connectivity is directly connecting everything to everything
The goal of converging IT and OT is to allow businesses to benefit by gaining value from the data currently locked in OT systems. This could be a benefit as simple as giving business systems access to cycle counts and job reports previously locked in a PLC or SCADA system. It can also be used for monitoring performance with advanced analytics and machine learning. OT networks benefit because IT systems can accurately compile and compare large loads of data. This kind of operation is not practical in a PLC. With IT systems, users can, in time-stamped succession, see relations between common factory floor variables such as energy usage, speed, vibration, and heat of a process. These systems can also quickly compare these local machine variables with similar machines in factories around the globe.
This data can lead to better quality, reduced failures, improved safety and reduced downtime. IT and business systems benefit from improved factory logistics, reduced maintenance costs, improved work-in-progress tracking, better material life cycle tracking and improved visibility to operations performance.
Capturing the benefits of converging IT and OT does not mean that every device on the factory floor needs to talk with every device on the corporate network. Industry 4.0 is not achieved with simplistic IoT ideas. IT and OT are unique application spaces that deliver unique value, and those value propositions can easily become compromised if the networks are not segregated. Industry 4.0 value is created by controlling a curated exchange of data and Information between IT and OT networks.
This paper has discussed the unique attributes of IT and OT communications. It presented a factory littered with different devices that feature many different protocols serving IT or OT objectives. All of this may lead a control engineer or operations manager to ask if there is a practical way to standardize on a single protocol to meet the needs of both. It has been a goal that has been elusive for a long time.
In the mid-to-late-2010s, every communication protocol trade organization claimed their protocol was Industry 4.0 ready. These early claims seemingly revolved around the traditional OT protocols (Modbus TCP, EtherNet/IP and Profinet), claiming that because they operated on standard Ethernet, they could meet the demands of Industry 4.0 or the Industrial Internet of Things (IIoT), a term that seemingly meant the same thing but has fallen out of vogue. These claims were partially true. If people properly set up network routers, they could use Modbus, EtherNet/IP or Profinet to talk between a supervisor in the cloud and a device. However, what does this connectivity offer users? They have an insecure protocol passing data packets that have no context. The pipes work but the payload of the data is all wrong.
In this instance, OPC UA clearly stands out above the rest. For decades, OPC DA had been the de facto method to get PLC data to PCs. The data modeling was rudimentary, but it was also revolutionary. Instead of undefined blocks of IO data or Modbus registers that were either an atomic value or part of full value, they had context. OPC DA provided three things: a value with a defined type, a quality status of that value and time stamp.
OPC UA built on this basic data structure’s success and added meaningful metadata and the ability to model the data in a device or system much more complexly. This is very valuable when analyzing data. When people get meta information, they do not need a control engineer to map or analyze data. A data scientist can discover human-readable attributes of a device. Now a drive on line 2, in building three, can easily be discovered and share its speed in rotations per minute. This was a fantastic enhancement and greatly improved the usability of data, providing information that could be leveraged, understood and shared.
OPC UA also aimed to expand beyond OPC DA’s traditional middleware use case. The standard defined transport options and specified functions that, in theory, would position it well against traditional OT
protocols and IT protocols. It provided advanced information modeling and building blocks for OT and IT data transport. In theory, one protocol (or architecture for true believers) for all data and information needs. By any measure, OPC UA has been very successful. It is prevalent in manufacturing systems and greatly enhances the value proposition of data compared to predecessors and competitors. It has, however, failed to unseat any OT protocols. The author has yet to see an automation facility that standardized on OPC UA for devices below a PLC nor does the author anticipate seeing one.
As the major OT protocols and OPC trade organizations realized that their quest to be the one protocol for Industry 4.0 were dashed by technical or adoption challenges, they did something unusual. They started aggressively partnering with each other. They did this with memorandums of understanding and companion specs that standardized ways for these previously competing standards to work together. Now when a customer says, “But X protocol supports feature Y,” technology evangelists could say, “Sure, but if you follow specification XY, a coordination between our groups, feature Y from protocol X can be achieved within our solution.” This added some value but also equal parts confusion and needless technologic specification. Many of these companion specifications have never left the paper on which they were written.
As users of these technologies, those in the industry need to accept that a suite of protocols will be needed to achieve our Industry 4.0 goals. At a minimum, we need a specific IT and OT protocol. It is likely that technical need or market availability will drive far more than two protocols to our factory floor.
Security is Industry 4.0’s dirty little surprise. People do not get data access without breaking down the tried-and-true closed network mentality of automation systems. Factory floor networks are insecure. It does not matter if it is a brown field or green field system, the network is insecure. There have been security additions to EtherNet/IP and Modbus TCP that have added additional levels of security to the OT space. However, these additions are not available in legacy devices, are protocol specific and the addition of security has tradeoffs.
Generally speaking, OT protocols offer three levels of security. Devices leverage some or all of them.
Each adds complexity to the system. Authentication requires certificates that need to be securely maintained and should be changed regularly. Integrity and encryption both add additional message processing that needs to be completed on each message. This slows the data exchange.
Security in depth is a fancy way of saying that multiple security measures should be taken to secure a network. OT protocols with security could be one measure taken, but this author would argue that OT networks should be treated as closed networks even with these enhancements. Let these networks focus on delivering the reliable and determinist data transfer.
Devices intended for communication with IT systems also need consideration for additional on-board
memory. In OT networks, a missed message is quickly followed by the next message or an error flag set. Missed messages are potentially critical failures and need to be treated as such. Loss of communication of more than a cycle of milliseconds is a significant event. In IT, network reliability is less of a severe requirement. Webpages can be manually refreshed, timeouts can reconnect in human time in seconds and communication is not typically connected to a critical system application. This means that edge devices need to be designed to handle the loss of connectivity to IT systems. These devices should have a mechanism to locally collect information it is producing when connectivity to the IT system is lost and then have the ability to deliver the missed series of time-stamped data when communication is restored. Having complete series data, especially during network events, is critical to maximizing the value of the information devices are delivering to these IT systems.
If the plan is to use devices that communicate to both IT and OT systems, one will want to plan for a dedicated Ethernet network interface for each purpose. Two ports acting as a switch will not do. This situation requires two independent ports segregating the IT and OT network traffic. An attack on the IT side could still crimple a device, but the attack would not proliferate onto the OT network and no OT data has the potential of being compromised. This is not an impenetrable plan but a very reasonable step to protect against denial of service and spam attacks and prevent causal browsing of critical networks.
Shelter the OT network behind a firewall and avoid pinholes whenever possible.
This author estimates that 99.9% of ROI from Industry 4.0 will come from energy savings, downtime reduction, more intelligent system maintenance and improved product quality. Improvements in those areas can likely be achieved with a relatively small set of data points. Do not get fooled into believing big data set analytics are going to render miracle results. Most of the benefits gained in industry 4.0 will be intuitive but are today unachievable because we lack simple data access.
There is tangible value buried in the discrete automation systems on the factory floor. However, to grant equal value to every bit and byte passed on a factory floor would be foolish. No process needs 100% data visibility. It is not unreasonable to argue that 95% of the data available in automation systems can rightly stay ignored. A Modbus register table for a device featuring hundreds of data points is something to behold. Control engineers will know that most applications would leverage a fraction of the data points available from devices. Analytic systems might want different data points than a control system, but it is still a subset of all the available data.
There are some incredible case studies from large manufacturers that have found surprising value in vast oceans of data. This author does not question these awesome stories, but they are not going to be practical for the vast majority of manufacturers. Every piece of data pushed to an analytics tool, especially if it is cloud-based, will have a cost. To find exotic relationships in the data, one would need to hire data scientists to create models. This is, all after, the significant upfront investment in equipment and integration. That is not practical for many manufacturers. Most manufacturers will put their existing control engineers to the task. That is not a bad idea, as these are the very people most likely to understand where value can be found.
Find the low-hanging fruit first. Get practical value from an Industry 4.0 initiative instead of a statement piece. Like any system enhancement, this is going to be a challenging journey that impacts a lot of users at your company. Are you ready for operators to revolt when bathroom breaks are to blame for their parts per minute average dropping below newly monitored expectations? Can you simplify the data enough to interest the C-suite? How will your new Industry 4.0 system integrate with the 12 other silos of information spread across your business?
Focus on driving value, not praying that new technology will inherently deliver it. Data access tools can greatly enhance the value proposition of manufacturing, but they are just tools. Use them to create ROI and evolve with them over time for higher ROI.
Industry 4.0 will create significant challenges to overcome, but in exchange, it will improve output and reduce waste. For the first time, those values will be realized beyond the operation space and be directly appreciated by business teams. The unsung control engineers and operation professionals will now have a vast set of tools and data to better illustrate the enhancements they are making to the business. With a proper understanding of the IT and OT communication needs, along with a measured approach to technology deployment, factory floor staff can cut through the market fluff and deploy Industry 4.0 ideas in their plants that will deliver real value.
Working through the all the noise of protocol supperiority that is out there in the industrial automation world and every year communication standards evolve. New features and performance standards are enhanced. This can make it difficult to find what the best solutions are for your organization. An expert partner that can maintain the protocol IP and offer expert consultation on topics like data modeling and navigating conformance is imperative to success. Real Time Automation is backed by a team singularly focused on simplifying the communication protocol experience.
Drew Baryenbruch, President – Real Time Automation® (RTA) in Pewaukee WI. A 17-year veteran of the Industrial and Building Automation industry. He has worked on thousands of applications helping bridge the gap between the legacy Fieldbus technology and Ethernet based technology. He has also helped device manufacturers bring hundreds of automation devices to market. He is passionate about automation and growing American manufacturing.
Real Time Automation, Inc.