The power of mix-and-match: How standardized protocols drive I/O

I recently wrote about network protocols such as Ethernet/IP and Modbus/TCP. One of the benefits of a common “standard” protocol is that hardware from various vendors can mesh and work together.

One of the most common benefactors is supervisory control and data acquisition (SCADA)/human-machine interface (HMI) systems. One graphic display panel or computer can run multiple protocols and therefore grab data from disparate control systems for operator display and interfacing.

With the advent of common communication platforms, new layers of automation devices became available to control systems on the plant floor.

Rich Ryan, who was the vice president of automation—software and hardware in the 1990s—for Rockwell Automation, participated in a future-of-automation track I organized for the ISA conference of the day.

He commented to me, after his session, that automation success will lie at the feet of I/O vendors. The programmable logic controller (PLC) central processing unit (CPU) will still be central, but a mixed bag of I/O devices will prevail on the plant floor.

With a plethora of I/O vendors entering the marketplace, the vendor’s PLC just needs to talk to the connected devices. And those devices can be just about anything.

Power supplies can talk on the network and can become part of the control strategy as an I/O device. Encoders and drives can become I/O to the system for monitoring and control.

There are other I/O networks available such as IO-Link. It is based on the IEC standard 61131-9, so any device conforming to that standard can be connected.

While IO-Link requires a master node, that node can support protocols such as Ethernet/IP. This would expose the connected I/O to the control system.

IO-Link is designed to have installation benefits and configuration tools that can support multiple devices of the same type—change-one-and-change-them-all scenario.

Certain system configurations use electronic data sheets (EDSs) to tell the host system how to interface to the device. Some might use Extensible Markup Language (XML) Device Description (XDD) in order to integrate the device(s) into the control system.

In process analog applications, certain I/O can be stand-alone and connected using a protocol supported by the control system CPU network. Closed-loop control within the PLC, for instance, can control the valve directly over the network. Valve manifolds for discrete solenoid valves can also be used for the discrete part of the control.

Variable-frequency drives (VFDs) have been used on the network for quite some time, which simplifies installation and configuration. Reading and writing data to these connected devices makes system programming easier and presents this data to the SCADA/HMI nodes for control and display.

Get your subscription to Control Design’s daily newsletter.

One area of expansion in practice is the ability to implement safety systems on the same network. The integration of safety systems within the control strategy can make the overall system reliability and understanding of how it works more presentable.

Protocols like CIP Safety and ProfiSafe can be implemented in certain configurations as integrated safety. These protocols interface with safety I/O and have the checks and balances intrinsic to the system to be safety certified.

Wireless network communication has made its way onto the plant floor, which allows for mobile data monitoring. Wireless safety is also making some headway, whereas wireless device implementation has been executed in current systems. Wireless brings to bear various issues such as dropped packets, interference, potential channel hopping, latency, and, of course, network security. In any application that requires timely data for operation it would be suggested to only use wired connections for control. Graphic display can be wireless for mobility, but understand that latency can occur.

I/O systems can be in-cabinet or remote. There is movement toward taking the I/O to the process or machine to reduce field wiring. This is where Rich Ryan’s comment bears fruit. The remote I/O can be from any vendor, even a mix-and-match. Multiple vendors’ products can coexist in the same area or panel, so you can choose the best product for the application.

There is also a move to have in-cabinet I/O networking to ease installation costs and time, as well as panel size. Fewer terminal blocks would be required to reduce the footprint of the installation.

With the availability of the I/O data, as well as system diagnostics, troubleshooting these systems may just have gotten easier. The HMI should alarm on a system or I/O fault resulting in a faster downtime response.

Having a network diagram would be very helpful, along with IP addresses, so network tools like PING can be used to identify any issues. Using protocol-based I/O and I/O systems will ease the pain of creation and support.

Get connected.