Industrial networks are generally no longer locked into a specific hardware or communication protocol choice. The vendor-specific design has likely seen its heyday, and the overwhelming majority supports open communication protocols, largely supported by non-profit industry organizations.
However, complete system interoperability is not always as easy as adding the latest open protocols or hardware, when upgrading an existing production line with established legacy equipment. All the choices about devices, I/O, protocols and software will affect system interoperability and factors like ease of installation or operational maintenance down the line. The application will ultimately dictate what it needs, based on many factors. The convergence of information technology (IT) and operational technology (OT) is the final frontier for industrial networks.
The hardware choice
For most technology, gateways and drivers exist to integrate with almost anything, and this is good and bad for industrial automation, says Larry Grate, director of business development for OT infrastructure & security at EOSys, a Control System Integrators Association (CSIA) member.
“The advantage is you can make almost any two devices talk, if necessary. The disadvantage is that, when you force a fit, the end users must live with that solution for the rest of the time it is installed,” Grate says. “It makes more sense as a machine builder to choose hardware components which fit the control requirements of the machine or the process that you are trying to control.” From an end-user perspective, it’s better for customers to have the same control platform, when possible, to reduce personnel learning curves and overall cost.
“As a system integrator, you are trying to consider the long-term challenges your choices make for your customer,” Grate says. Higher up the Purdue model—L2/L3—it’s easier to select a common human-machine interface (HMI)/ supervisory control and data acquisition (SCADA) platform for the entire site, he explains. “This is where understanding the long-term strategies of the site is important,” he adds. “You want to select a solution that will meet the short-term and long-term needs of the site from a digital-transformation perspective.”
Standardization can be a successful tactic, says Harrison Davis, team lead of mechatronics at Schunk. Standardizing robots, control systems, communication protocols and end-of-arm tooling (EOAT) as much as possible is the simplest way to ensure that a new machine is compatible with existing systems and machines. “While factories may have different lines with varying requirements, using the same robot brands and controllers across as many systems as possible will ease the learning curve for those responsible for maintaining and programming the manufacturing lines,” Harrison says.
However, standardization or finding the easiest solution might not always be possible for many reasons: end user preference, product supply availability, legacy system networks or the machine design.
“We often start with a review of the customer’s existing facility, as well as any standards documents they may have,” says Rylan Pyciak, president of Cleveland Automation Systems, a CSIA member. Then the integrator will want to identify what software packages and versions are in use, communication protocols and spare parts availability. “The last thing you want to do is install a one-off system that requires more monetary spend to have the proper software or additional spare parts,” Pyciak adds.
The machine will still need to fit with the overall plant architecture and existing systems, so proper system integration will also consider factors like electrical standards and compliance and communication compatibility, says Ranjit Maharajan, head of product group, automation solutions, at Andritz Feed and Biofuel.
Andritz prefers to match protocols like EtherNet/IP, Profinet or Modbus with existing machines and other control systems. In choosing hardware components, it also tries to prioritize suppliers with reliable local support. Environmental considerations might also play a role, such as ingress-protection (IP) ratings, temperature or vibration, and cost will be the final decider in most projects, Maharajan says. Consider the project budget but also product lead times and lifecycle.
“Generally, there are different requirements that determine the machine architecture and control design,” says Martin Schütz, product manager of smart sensors at Hottinger Brüel & Kjær (HBK). “From the application perspective it is necessary to take into consideration the needed physical measurands, actuators for motion control and other peripheral systems interfacing with the machine and process. Secondly, the performance requirements for data transmission of the sensors and controllers—real-time requirements—need to be checked.” Other considerations, Schütz says, are the openness of the machine and how it will connect to other devices and equipment.
The IT department on-site also has a role to play or can help understand the data architecture, and the new machine will need to be designed to fit that system. “If sensor readings should be transferred to IT-level applications too, then the question arises at which level the sensor data needs to be transferred. Programmable logic controllers (PLCs) can send data directly into the cloud, but this means all the data needs to be sent to the PLC from sensors and/or amplifiers in the first place,” Schütz says.
Using, for example, IO-Link sensors make it possible to send data to IT-level applications on the IO-Link master level. “If more complex monitoring tasks using higher data rates in parallel to the running PLC process are required, then edge amplifiers using dedicated Ethernet ports for IT-level applications might be considered,” Schütz adds.
Network devices and I/O
Ease of installation is paramount for any application, as downtime equals money, and the choice of network and I/O devices can affect connectivity time and cost. “Ensuring seamless communication between your devices is crucial, especially as manufacturing increasingly relies on electrically based systems,” Davis says. Even with varying production lines, the devices can all speak the same language, essentially. “Effective communication between your robot controller or PLC and your tooling can significantly enhance the ease of integration,” Davis adds.
It's more difficult to integrate devices that all use different native network protocols, so Grate recommends choosing devices with the same native protocol capability, when possible. “Additionally, you must choose I/O devices which can interface directly with the hardware used in the field. Anytime you introduce any type of converter between two devices, whether a network gateway or physical signal converter, you reduce the reliability and increase the complexity of the overall system,” Grate adds.
Pyciak said EOSys prefers remote I/O and I/O over Ethernet communications. “By utilizing I/O via communication protocol, this allows for much simpler and easier integration,” he adds. “We no longer have to run multiconductor cable halfway across a plant facility. We are able to run one Ethernet cable and one power cable, and that's it.”
When connecting sensors at the field level to the PLC or the control system in the automation level, the choice of sensors and electronics can have huge implications on the ease and efficiency of installation, Schütz says.
“Using passive sensors requires adding amplifiers,” Schütz says. “These setups have their own set of advantages but require manual parametrization in order to ensure correct sensor and amplifier pairing. Using smart sensors with integrated amplifiers provides a digital signal at the sensor’s output. Depending on the digital communication protocol used, the system setup is correspondingly easier and more efficient.”
For example, a force, load or torque sensor with an IO-Link interface can behave like any other IO-Link sensor and make integration into the machine and system architectures via standardized methods more efficient. “The sensors directly output the correct physical quantities—N, Nm, kg—without any manual parametrization needed,” Schütz adds.
Industrial communication protocols
For a long time, communication protocols were driven by vendor choice, with many vendor-specific protocols locking end users into a system. But that reality is no longer the case, as even vendors have mostly let go of proprietary protocols, in place of open communication standards. There still may be applications where older protocols are necessary, but they’re quickly being replaced by open standards. But each application still has individual requirements and choices to be made.
“Choosing the right industrial protocol depends on factors such as system architecture, device compatibility and integration with existing infrastructure,” Maharajan says. “In most cases, the choice is influenced by the platform in use or selected architecture, which may limit the flexibility of using proprietary protocols.” He adds that Andritz strongly prefers widely adopted open protocols, which provide simplified integration and interoperability across devices and vendors.
Pyciak says 95% of Cleveland Automation Systems’ projects use EtherNet/IP. “We like to push for the latest and greatest technologies, so often, that is some sort of Ethernet-based communication protocol. We still have customers utilizing RS-232, DeviceNet and ControlNet; however, we try to encourage our customer base to upgrade from these protocols,” he adds. With older protocols, finding readily available parts and hardware can be challenging, and fewer personnel understand these older systems.
“It is interesting when you consider that most of what we consider to be a proprietary protocol, like Profinet or CIP/EtherNet/IP, are managed by non-profit member organizations and therefore considered open protocols or standards. So, whether we realize it or not, in most instances, we are using an open protocol to communicate between devices in ICS,” says Grate. The exception would be I/O networks within the distributed control system (DCS) or similar technologies where you don’t have a choice, he adds.
Communication protocols are not all the same and do not all work for every application. The choice of protocol should consider the need for speed and resilience, Grate says. “Not all protocols are built the same, and as you approach the limits of Ethernet from a speed perspective, there are vendors that modify standard Ethernet resulting, in some cases, in having to use that vendor’s network switch, as well. There have also been issues with vendors not following the standards fully or fully implementing a protocol, which has resulted in challenges when integrating equipment, but this is becoming increasingly rare,” he adds.
In general, Grate says, EOSys will try to choose what is native for the vendor. “When you get to the top of the Purdue model and start communicating with historians or other cloud-based solutions, then protocols like OPC UA, and MQTT/Sparkplug B become preferences for us to work with,” he adds.
Get your subscription to Control Design’s daily newsletter.
Similarly, the choice of communication protocol for the application should also consider the process requirements on time synchronization and the need for real-time loop control. “As soon as highly deterministic communication for loop-control applications is needed the current solutions are typically going to be industrial Ethernet-based fieldbus protocols. A common misconception though is the thought of needing to send all sensor readings to the central controlling unit or PLC and thereby taking up high bandwidth and cycle time requirements on the industrial communication protocol,” Schütz says. “This concept relies on the idea that a central controlling unit performs all the process control and application-specific calculations, which results in more costly PLCs to be installed. The concept of decentralized intelligence is emerging in the domain of sensors and controllers too.”
The application will dictate if open standard protocols like IO-Link can be used for field-level to automation-level communication or if industrial Ethernet communication is needed to connect all the way down to the nodes in the field level, Schütz says.
Legacy technology and obsolescence
Designing a seamless system under all the same communication protocol isn’t always possible when combining new machines with old. “When designing, we take into consideration the architecture that supports both old and new systems. This includes choosing the right protocol converters, I/O gateways and software that supports multiple systems,” says Maharajan.
Obsolescence is a concern for components and systems, he says, and should be considered when integrating new machines into older production lines. “We take a proactive lifecycle management approach in close collaboration with suppliers and vendors to help mitigate this risk during the design phase and through the life of the delivered systems,” he adds.
Backward compatibility or integration into legacy systems is easier today because gateways can make most protocols open, Grate says. However, consideration should be given to update rates for any products and equipment, and converters can unnecessarily complicate designs. “Putting protocol converters in front of motion applications, for example, can often be challenging at a minimum, or at worse make a solution unreliable or completely nonfunctional,” Grate says.
Pyciak of Cleveland Automation Systems says he is already seeing obsolescence become an issue. “Customers have legacy systems in place which have no readily available hardware or other components to keep these systems running. We like to identify the latest technologies currently on the market and implement the solutions wherever possible. We must also identify strong systems and networks that will withstand the test of time,” he adds.
The future of industrial networking
“The clear demand from the customers is for open standard solutions and a higher interoperability between existing control system solutions. The truth is that a full compatibility is hard to achieve with existing solutions, which lead to new initiatives being started,” Schütz says. He points to the many open protocols in existence like IO-Link, MQTT or OPC UA.
The next level and the future of industrial networking for automation is an infrastructure with deterministic OT communication and IT-level communication over a single network. “Solutions making this possible are currently being developed in organizations and working groups pushing for open standard solutions, but we are not there yet,” Schütz says. “For the current solution landscape, we at HBK follow the path of parallel connectivity.”
“The gap between IT and OT is getting closer, leading to a stronger focus on cybersecurity and edge computing, and wireless technology is becoming more prominent,” says Maharajan.
“There are already secure variants of most common industrial protocols, but they are not currently deployed very frequently in most applications. With the EU Cyber Resiliency Act (CRA) and the increasing desire for zero-trust solutions, adoption of these technologies will increase over the coming years,” says Grate. He does not believe that industrial control systems in general and the OT community are ready for the adoption of these standards just yet.
“We will have to evolve to support what is becoming increasing regulatory requirements. On the software side of things, you will also see increasing demand for software bills of materials (SBOMs) to make vulnerability management easier and more reliable,” he adds.
Pyciak also predicts that the future of industrial networking will shift to IT/OT systems in the future. “More and more systems are becoming interconnected, and companies want access to real-time production data, monitoring and statistics,” he adds.
Schütz agrees that industry is pushing for the convergence of OT/IT communication over the same network. New technology like time-sensitive networking will help that become a reality. He recommends watching closely the initiatives supporting communication protocol standards with wide industry support. “From our viewpoint the current proprietary solutions have their justification, and this will be the case for the mid-term future. In the long-term there will be a shift to open standards allowing for OT/IT communication on single networks,” he adds.
