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 device manufacturers know they mean one thing: more complexity and technology needs to be added to their devices. 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 for device manufacturers. The issue is no longer getting access to a proprietary protocol, it’s now finding ways to cost-effectively add the multitude of protocols available in the market.

It’s completely reasonable to see a half dozen unique protocols on a requirement for new product development. A simple drive could reasonably require EtherNet/IP, Profinet and Modbus TCP to meet a majority of communication requirements in a market segment. EtherCAT and PowerLink may be requirements for niches you’re looking to exploit in Industrial Automation and BACnet/IP would be required for building automation penetration. The complexity and cost of deploying these protocols are significant and these protocols are only solving the control communication requirements. Then there is a need 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 required protocols. To complement all of the above-listed technologies, security is a growing consideration pushing requirements of all Ethernet based communication.

This proliferation of technology is making the cost and complexity of bringing a product to market unobtainable for many vendors. This is specifically distressing because for most vendors these technologies are not core competencies. The ongoing need to invest resources and fund the deployments of communication standards inhibits improvements in the base product.

In this paper, we will work to dissect the requirement of Industry 4.0 and help you create a road map for more intelligent technology deployments. The complexity of bringing a device to market is immense but comprehending the practical requirements doesn’t have to be.

Embrace the Differences of IT & OT

For device manufacturers on the factory floor, there are still two distinct network ecosystems your devices will need to operate in. Their primary function is to align with the needs of the Operations Technology (OT) network and then be able to bridge to the needs of the Information Technology (IT) Network.

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 and it encompasses everything from automation devices and sensors to the controllers and PLCs. If a device has a prime responsibility of determinist data transfer in support of discrete or process automation it lives in the OT space. The dominant protocols that support this type of communication are Modbus TCP, EtherNet/IP, Profinet and EtherCAT. The market demands your device support one or many of these protocols.

IT networks are arguably the more widely understood network, but the application and communication requirements for automation devices to these networks are not as clear. When we talk IT requirements for an automation device, the conversation is focused on how these protocols add security and support information modeling for business systems to leverage. There are generally many more devices on these networks that make event, publish/subscribe and push-based data transfers important to optimize network band-width utilization. From the perception of an automation device manufacturer, IT is everything above a PLC. If you are moving data from a PLC to an ERP, MRP or other enterprise /cloud-based application you have stepped into the IT space. Historically devices below a PLC moved data to IT networks thru a PLC and something like OPC DA. Today, however, there are more compelling reasons to add the ability for an end device to natively communicate to IT based monitoring, recording and analytic systems. If you wanted your device to communicate directly with IT systems you should consider OPC UA, MQTT, or HTTPS as mechanisms that would also secure the transport of information with noncyclic transfers.

The goal of converging IT and OT is to allow businesses to benefit and leverage 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 complete and compare large loads of data. This allows users to, in time-stamped succession see relations between common factory floor variables such as energy usage, speed, vibration, and heat of a process. This data can lead to better quality, reduce failures, safety and a reduction in downtime. IT and business systems benefit from improved factory logistics, reduce maintenance costs, improve work-in-progress tracking, product and material life cycle tracking, and improved visibility to operations performance.

While there are protocol suites that can support the automation device requirements for both OT and IT applications the market space still draws distinctive lines. Exploring communication technologies and how they serve each segment is required to support the needs of the customer. If you supply a simple device like a low-end sensor or actuator you may choose to focus only on the communication for the OT space. However, if you are creating a higher-end drive or energy monitoring appliance that creates a significant amount of data you should consider adding solutions for both the IT and OT market segments.

Considerations for the deployment of Communication Technology on your Device

Now that we have discussed the value IT and OT communications can bring to automation devices, we can now focus on the technical costs those benefits require. Here again, the concept of IT and OT are valuable differentiators when it comes to technical requirements.

OT devices must meet the ever more demanding requirements of industrial automation communication protocols like EtherNet/IP and Profinet. These protocols were designed to move data deterministically and reliably. They are also both standards that require device certification and certification that focuses on performance. A device will need to reliably process messages, perform through network load tests, and respond to requests within tight tolerances of up to single-digit milliseconds. If you embed these technologies onto an existing device processor that is already laden with the demands of your device’s core function, you may not be able to reliably meet the performance requirements of these technologies. This is why dedicating a processor core or entire processor to the task of communications might be a wise choice.

Devices in the OT space have traditionally been built on real time operating systems or bare metal deployments. The processing power of a single-threaded application was the most significant consideration. Today the power, cost and availability of Linux and Windows-based platforms, along with the growing functional demands on automation devices, has led many vendors to build products based on higher-level operations systems and multi-core processors. While powerful Linux and Windows operating systems still lack the real-time ability RTOS-based devices had. If you plan to bring a Linux or Windows-based device to market a real-time extension to the operations system may be required.

The source code footprints for even the most bloated commercially available stacks are under 500k, many are well under 250k of code space. The question for many device manufacturers today is how many protocols they can fit into a single deployment. Coexistence is possible. Multiple application layer communication protocols can exist on the same device and could communicate on the same network subnet.

EtherNet/IP and Profinet also both operate on standard Ethernet. If your device supports Ethernet these application layer technologies can relatively easily be added to it. For Profinet you’ll want to make sure you have access to the layer 2 Ethernet packets, the function is still part of every standard Ethernet deployment. As the technologies evolve the base communication standard has changed little, but technology related to the usability and network deployment has advanced greatly. Both technologies are leveraging and starting to make requirements for suites of IT tools like LLDP, SNMP and others. Most commercially available or open-source TCP stacks support these technologies but it’s wise to double-check.

Note: You can bring conformant EtherNet/IP and Profinet devices to market with no network security. Security standards are available for many leading protocols but are not yet pervasive in device deployments. One of the reasons this is palatable to the market is because most OT networks are closed networks that do not have access to external networks.

*For the sake of simplicity, we focused on Profinet and EtherNet/IP because any device that supports EtherNet/IP or Profinet can support Modbus TCP. Conversely a protocol like EtherCAT requires its own specific ASIC so many device considerations become mute.

Beyond Ethernet the only hardware requirements you need to consider are LEDs. To have a good device you need visual indicators and both Ethernet/IP and Profinet have specified LED labeling and behavior.

For a device manufacturer, IT’s primary distinction from OT requirements are security and storage space. Generally speaking, technologies like OPC UA and MQTT will not burden your processor with rigid cyclic data requirements. However, they will need to bridge IT and OT networks which means they need mechanisms to secure the communications. This security operates with three primary goals

  • Integrity: Make data you send unable to be altered or changed on its way to the receiver.
  • Authentication: Make sure that the data you send arrives at the proper recipient.
  • Encryption: Makes data exchanged between end hosts unreadable by others.

OPC UA, MQTT and HTTPS all leverage SSL/TLS technology to meet a combination of the above security goals. Specifically, if you are leveraging an embedded RTOS or bare metal design you will need to find a vendor that provides the underlying SSL and TLS technology.

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 your devices need to be designed to handle loss of connectivity to IT systems. Practically, this means your device 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 your devices are delivering to these IT systems.

Hardware Considerations

We discussed the technical deployment considerations of IT and OT technologies. The differences between these network ecosystems create a few challenges to consider related to hardware. We know multiple application layer communication protocols can operate on the same device, through the same Ethernet port and reside on the same subnet. However, we also know OT networks are insecure and IT networks demand security, this creates a conflict. You do not want your device to inadvertently give IT threats access to closed and insecure OT networks.

If you plan to give your device communication to both IT and OT systems, you will want to plan for a dedicated Ethernet network interface for each purpose. Two ports acting as a switch will not do, you need two independent ports. This will segregate the IT and OT network traffic. An attack on the IT side could still crimple your 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.

If your device is being leveraged in marketplaces that demand higher security hardware, then processor-based security should be a consideration and may be a requirement. Hardware-level security offers the benefit of ensuring the programs and files written on the device are not altered or accessed. This can include secured memory used to house security certificates and keys. It can also encapsulate the entire application from a manufacturer ensuring the program running on the device is the intended program.

Understand the Nuances of Certification

OT protocols like EtherNet/IP and Profinet require certification while most IT protocols have recommended certification but do not require it. Certification costs and constraints should not be overlooked when planning to bring a device to market. The paradigm many device manufacturers miss is that the OT certification standards are relatively static and encompass a combination of both the hardware and software considerations.

The hardware considerations cover LED behavior, labeling and network capability as mentioned in earlier sections. Those are seemingly intuitive, however, if you view your product as software-based, somewhat agnostic of the hardware it resides on, there are complexities to consider. One could create a Windows- or Linux-based software solution that meets conformance on a specified hardware platform. If you change hardware or sell that software-based tool kit to a customer that deploys it on a different hardware platform you have not maintained conformance. Supply chain issues and the availability of SOM platforms have made creating software flexible enough to reside on multiple targets very attractive. Just know that any software alone cannot be certified and any changes to your target platform require a retest.

Many may not think it, but software has some of the same constraints. Many people now look at software-based solutions and map out development roadmaps for years of enhancements. While it is possible to certify a device and have additional features added, if you plan on changing the data model presented on the network (i.e. adding, changing or removing data points), a retest is required, and retesting is always done to the latest conformance standard. Conformance never breaks backward compatibility, but it does evolve annually to add new features or more stringent performance requirements. If you make changes, you are on the hook to align to the latest standard.

Plan for Maintenance

These annual changes in conformance make planning for protocol maintenance a good choice. While you don’t need to update your device annually you will need to meet any and all additions added to the certification. Most license software vendors offer maintenance plans. If you leverage a third party, the vendor should have an offering available to meet the latest conformance test. And if you have a home-spun solution you should strongly consider allocating resources to maintain and monitor the trajectory of these technologies.

The Pace of Evolution Increases

In all IT and OT communications, standards change and the market’s expectation for features is accelerating. Advances in security and ease of deployment continue to add to the feature set of automation devices. The emergence of robotics and autonomous material handling devices has added demand for protocol safety standards that had previously only been needed in niche use cases. On the IT side of the world, multiple organizations are working to promote standardized device and information models.

On the factory floor, the core data communication will stay the same, but the technology will continue to evolve to improve the deployment and management of networks and its devices. In the IT space, there will be standard device information models that can be leveraged to more easily interpret the information presented by OT devices. One key piece of advice is that investing in partners and/or internal resources to monitor and evaluate the latest enhancements to these communications protocols is more important than ever before.

Not All that Glitters is Gold

Industry 4.0 requires a host of competing and complementary communication protocols. If you immerse yourself in any of these technologies and their trade organizations, you will find that each one will make a claim that it is uniquely suited for Industry 4.0. Many will claim they are the only one suited to support all the requirements of industry 4.0. This is where a discerning and somewhat begrudging attitude can serve you well.

Trade organizations are advancing their technical specification and companion specifications at ever-increasing rates. This is exciting but also risky. As you read this paper there are thousands of pages of technical specifications for protocol features that have not been practically deployed in a network. Moreover, there are an equal number of features that achieved successful proof of concept demonstrations but failed to gain any market acceptance or demand. Deploying these fringe or new features can put a developing company at significant risk for deploying a product without a market in which to operate.

If you are leveraging any of these open protocols for communication with your own device infrastructure, go nuts and leverage all features that improve your solution. If, however, you are looking to bring a device to market with features that will add to its demand it may be wise to prove that demand prior to the technical investment. As always vendors of communications tools are great resources to help identify which features are market ready and are demanded in the market.

Bringing Industry 4.0 Comms to Your Devices

Real Time Automation is extending our offerings with our new RTConnect module. The RTConnect module gives device manufacturers a simple solution to add a full suite of communication protocols to any device. With a simple hardware integration and a single software interface, the RTConnect module can seamlessly add a full suite of presentation protocols to their devices. Leveraging this off-the-shelf solution greatly reduces integration costs, risk and time to market. No longer is the full suite of Industry 4.0 protocols out of reach of device manufacturers.

For detailed information on moving data from a PLC or other network, contact us:

Embrace Industry 4.0

As a manufacturer of automation devices, Industry 4.0 will create significant challenges to overcome but in exchange, it will greatly increase the value your devices can offer. Those values will for the first time be realized beyond the operation space and directly appreciated by business teams. With a proper understanding of the IT and OT communication needs, along with a measured approach to technology deployment, you can cut through the market fluff and start offering the market devices that help make Industry 4.0 ideas a reality for your customers.


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.

Drew Baryenbruch
Real Time Automation, Inc.