automation devices

Introduction

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.

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.

Bringing Industry 4.0 Comms to Your Devices

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.