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
Hardware 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,” Davis 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.
Pyciak says Cleveland Automation Systems 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.
Get your subscription to Control Design’s daily newsletter.
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.
Pyciak 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.
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.
