Ethernet's popularity in industrial applications stems from its ability to exchange information, in real time, between processing equipment and Ethernet-based management systems.
Multiple factors drive its acceptance, including:
- speed advantages over lower baud rate protocols, such as Modbus RTU via RS-485
- number of tools available for troubleshooting and optimizing a network
- broad base of competitive vendor support and products
- large pool of trained personnel who are familiar with the technology
In addition, the ability to bridge existing proprietary communications schemes allows plant engineers to phase in the use of Ethernet rather than having to replace everything at once.
When asked, engineers most frequently respond that they expect to use Ethernet to integrate control systems in the future. But a follow-up question inquiring which Ethernet protocols they plan to use—such as Ethernet/IP, Modbus/TCP, and EtherCAT—is often met with confusion because some engineers do not realize that there are many application-layer networking protocols that are compatible with, and can coexist on, Ethernet networks. An industrial network will generally be set up separately from the office network for security and reliability reasons, and more care is required to choose which protocols will be used.
In attempting to navigate this sea of protocols, it is natural to look first to familiar ones that offer the functionality we are used to using on office networks, at home, and on the Internet. These protocols allow us to extend access to our network to remote users through Web browsers and email. When an engineer's task is to automate a process, the challenge is to connect devices to other devices to integrate automatic functions. For example, a temperature controller may need to get its set point from a programmable logic controller (PLC).
Protocols such as HTTP (which enables Web browsers to display Web pages) and SMTP (used to transmit email messages) are ill suited to automation. They are designed to transmit information over Ethernet, but the information is in a form that requires human interpretation. One purpose of automation is to relieve humans of the tedious task of monitoring and adjusting a process based on feedback from sources such as pressure gauges and mercury thermometers that require human interpretation. Another purpose of automation is, of course, to improve process results by removing variations in these human interpretations and avoiding the occasional misinterpretations.
Automation requires protocols that transmit information structured to allow automation devices to interpret it, rather than protocols that transmit messages intended for human interpretation. Let's look at an example of a control automation problem to illustrate this.
Control Automation in Action
An engineer who plans to automate a candy packaging machine must consider the sequential functions that (1) fill the open bag with candy, (2) close the bag, (3) drop the sealed bag into a box, and (4) manage the critical temperature control of the sealing bar that ensures the candy stays safe, secure, and fresh in its sealed package. The reliability and ease-of-use of the process are additional considerations.
Although a PLC may be ideal for the sequential functions, accurately controlling temperature is also important. The system can use the PLC to perform temperature control directly or employ stand-alone temperature controllers used in conjunction with the PLC.
Performing temperature control in a PLC presents numerous challenges. Programming can be difficult, requiring expertise that may not be available. Control algorithms can interfere with other program functions by consuming processing bandwidth, or you may end up needing a more expensive PLC than would otherwise be required. Further, if a simple ON/OFF control algorithm is used (the easiest control scheme to program in a PLC), control may be suboptimal.
In contrast, commercially available temperature controllers include advanced control algorithms and automatic tuning, so little expertise is required. The calculations and I/O updates associated with temperature control are performed by the PID controller's processor, freeing the PLC's processing bandwidth for other tasks. In the past, due to differences in the supported protocols, getting stand-alone temperature controllers and PLCs to communicate was time consuming, costly, and difficult. If the PLC and temperature controller do not communicate, it's up to the operator to integrate these functions.
To return to our example, if the candy packaging machine uses a PLC to move the product and a separate temperature controller to heat-seal the package, when the demand for candy increases and the production line speeds up, the sealing operation must occur more rapidly, which may require a higher temperature set point. If the PLC and temperature controller are not coordinated by the automation system—if they do not communicate—someone has to manually change the temperature setting on the controller. Without the communications link, it's more likely that the temperature setting will not be correct and the candy will not be properly sealed in the package.
Engineers often prefer to use stand-alone temperature controllers where performance of control loops is important and where incorporation of the temperature controller could negatively impact the PLC application. Traditionally, the major barriers to integrating a temperature controller were cost and difficulty. Now, many PLCs and a growing number of temperature controllers support Ethernet-based protocols intended for industrial applications and this barrier is diminishing (see sidebar "Ethernet-Enabled Devices").
Industrial Ethernet
One such protocol is EtherNet/IP. According to the Open DeviceNet Vendors Association (ODVA), the agency that sponsors both DeviceNet and EtherNet/IP, EtherNet/IP is a member of a family of networking technologies that implement the Common Industrial Protocol (CIP) at its upper layers. CIP encompasses a group of messages and services for manufacturing automation applications including control, safety, synchronization, motion, configuration, and information. EtherNet/IP provides users with the network tools to use standard Ethernet technology for manufacturing applications while enabling Internet and enterprise connectivity.
Using EtherNet/IP specifically yields the advantages of an Ethernet network, as well as the advantages of CIP designed for device-to-device communications. Those advantages include:
- Explicit messaging—allows devices to be configured via the network. A device can be detected and configured automatically in the event that a piece of hardware is replaced
- Implicit messaging—allows efficient communication of data and instructions from one device to another or from one device to many consumers of data on the network. This minimizes network traffic and allows full use of Ethernet's speed advantage
- Assurance of interoperability—all devices are tested by ODVA. Users can expect fewer problems when putting devices from multiple vendors together on a network
- Integration with other EtherNet/IP compliant devices—e.g., programmable logic controllers (PLCs) or touch screen human machine interfaces (HMI)
EtherNet/IP allows engineers to combine various components such as PLCs and temperature controllers to achieve effective and efficient control schemes (Figure 1).
 Figure 1. Controllers, PLCs, and HMIs can be connected via Ethernet/IP to form an integrated control system. The red lines represent Ethernet connections while the yellow lines show analog connections to the loads controlled by the controllers (Click image for larger version) |
While there are many options for integrating devices in automation systems, it is clear that Ethernet will play a significant role for the foreseeable future. There are numerous Ethernet protocol options, some of which provide greater functionality for remote access by users and others provide more functionality for integrating devices. The emergence of protocols such as EtherNet/IP enables engineers to use Ethernet, with its attendant advantages, in industrial applications. Suppliers' broad support for these protocols allows an engineer to choose the best device for the job without compromising the ease-of-use that comes with fully integrating the control system.
| Ethernet-Enabled Devices An example of a temperature controller designed for such automation systems is the EZ-ZONE PM controller (Figure 2) from Watlow. This device can be configured as a high-performance, PID, panel mount controller with a high amperage power controller output, an over/under limit controller, or as an integrated controller, combining all these functions. Serial communication choices include EtherNet/IP, Modbus RTU, and Modbus TCP, allowing you to easily connect to a PC, PLC, or HMI to remotely configure, manage, and monitor the system's performance. The controller decreases design and assembly time, requires less panel space, minimizes system complexity, and, best of all, lowers the total cost of ownership.
Watlow's Series PD controller uses embedded Ethernet technology to provide a convenient, economical means for setting up and viewing key process variables. It is suited for a broad range of temperature and process control applications where the operator interface is supported from a remote location. This single- or dual-loop DIN rail mount controller offers up to four control/alarm outputs, up to two digital/current transformer inputs, and a Web server for configuration and operation via a Web browser. The controller can send an email to service personnel to notify operators of alarms and other conditions. In 2005, the SERIES PD became the first temperature controller to offer ODVA Ethernet/IP conformance-tested communications. Watlow's EM gateway offers Ethernet connectivity for existing devices that communicate via Modbus RTU on an RS-485 network. The gateway bridges communications from Modbus RTU on RS-485 to Modbus TCP on Ethernet, adapting controllers to Ethernet connectivity. It also acts as a Web server for supported temperature controllers, allowing users to remotely monitor the process variables and alarms. The user can remotely set the set points for temperature control in an Internet browser and receive email messages when alarms occur in supported controllers. |
