The use of Ethernet communications in industrial applications is growing because it enables the real-time exchange of information between processing equipment and companies' Ethernet-based management systems. Some of the factors encouraging the use of Ethernet technology include:
- the speed advantages over lower baud rate protocols
- the number of tools available for troubleshooting and optimizing a network,
- the broad base of competitive vendor support and solution options and
- the large pool of trained personnel who are familiar with the technology.
In addition, the ability to bridge existing proprietary communications schemes makes it possible 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, is often met with confusion since some do not realize there are thousands of protocols that are compatible with, and can coexist on, Ethernet networks.
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. Using such protocols, Ethernet can extend access to remote users through web browsers and e-mail. But for an engineer tasked with automating 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).
Ethernet protocols such as HTTP, which allows web browsers to display web pages, and SMTP by which email messages are transmitted, are ill-suited for the purpose of automation. These protocols 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 human interpretations and occasional misinterpretations from the process.
What is needed for automation are not protocols that transmit messages intended for human eyes to interpret, but rather protocols that transmit information structured for automation devices to interpret. An example of a control automation problem can be used to illustrate this need.
An engineer who plans to automate a candy packaging machine must consider not only the sequential functions that fill the open bag with candy, close the bag, and drop the sealed bag into a box, but also the critical temperature control of the sealing bar that insures the candy stays safe, secure, and fresh in the sealed package. The engineer must also consider the reliability of the process and its ease-of-use.
A PLC may be ideal for the sequential functions, but accurately controlling temperature is also important. Here the candy packaging engineer is traditionally faced with a dilemma. The system can use the PLC to perform temperature control directly, or standalone temperature controllers can be 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 require the use of a more expensive PLC than would otherwise be required. Control may be sub-optimal due to the sum of a simple on-off control algorithm, which is the easiest to program in a PLC.
The alternative, using a standalone temperature controller, resolves these issues. 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 (Proportional Integral Derivative) controller's processor, freeing the PLC's processing bandwidth for other tasks. But in the past due to differences in the supported protocols, getting standalone temperature controllers and PLCs to communicate has been time consuming, costly and difficult as well. If the PLC and temperature controller do not communicate, the machine depends on the operator to integrate these functions.
For 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 happen faster. That 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, the chances are greater that the temperature setting will not be correct and the candy will not be properly sealed in the package.
Engineers often prefer to use standalone temperature controllers when performance of control loops is important. They are also used when the PLC application could be negatively impacted by incorporating the temperature controller, but traditionally the cost and difficulty of integrating a temperature controller was a major barrier. Because now many PLCs and a growing number of temperature controllers support Ethernet-based protocols intended for industrial applications, this barrier is eroding.
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 networks that implements 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, which allows devices to be configured via the network. A device can be detected and completely configured automatically in the event a piece of hardware is replaced.
- Implicit messaging, which 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 the speed advantage of Ethernet to be achieved.
- Assurance of interoperability. All devices are tested by ODVA™ and users can expect fewer problems when putting devices from multiple vendors together on a network.
- Integration with other EtherNet/IP™ compliant devices such as programmable logic controllers (PLCs) or touch screen human-machine interfaces (HMI).
EtherNet/IP™ allows engineers to integrate various components such as PLCs and temperature controllers with each other in effective and efficient control schemes.
While there are many options for integrating devices in automation solutions, it is clear that Ethernet will play a significant role in the foreseeable future. There are numerous Ethernet protocol options, some provide more 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 attain the advantages of using Ethernet in industrial applications. The broad support by suppliers 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.