This paper presents an overview of Ethernet/IP™ (EIP), a high-level industrial application layer protocol for industrial automation applications.
Built on the standard TCP/IP protocol suite, EIP uses all the traditional Ethernet hardware and software to define an application layer protocol that structures the task of configuring, accessing and controlling industrial automation devices. Ethernet/IP classifies Ethernet nodes as predefined device types with specific behaviors. The set of device types and the EIP application layer protocol is based on the Control and Information Protocol (CIP) layer used in both Devicenet™ and Controlnet™. Building on these widely used protocol suites, Ethernet/IP for the first time provides a seamlessly integrated system from the sensor-actuator network to the controller and enterprise networks.
Most people who work in an office associate the term “Ethernet” with the physical cable behind their desk. This cable connects their office PC to the printers and servers of the local network and the infinite websites on the Internet. This cable is only the physical part of Ethernet, the media carrying Ethernet messages to your PC. On this wire is a whole series of communication protocols such as IP, the Internet Protocol; TCP, the Transport Control Protocol; and various Microsoft protocols such as NetBEUI. This suite of protocols works well for the office environment; allowing users to share files, access printers, send email, search the Internet and perform all the other communications used in the office environment.
The needs of the factory floor are much different with some very special requirements. Instead of accessing files and printers, factory floor controllers must access data embedded in drive systems, operator workstations, and I/O devices. Instead of letting a user wait while a task is being performed, factory floor data communications needs are real-time or very close to real time. Terminating the fill operation on a bottle requires much more time-precise communications than accessing the next page of an Internet site.
Traditionally, Ethernet had only limited acceptance in Industrial Automation. Until recently, the expense, lack of intelligent switches and routers, and the domination of large vendors with proprietary protocols prevented the wide acceptance of Ethernet on the factory floor. Now, with prices falling, PCs with inherent Ethernet capability moving in droves onto the factory floor, and intelligent switches and routers, Ethernet is gaining acceptance. Only the lack of a widely accepted, flexible application layer targeted to Industrial Automation has prevented its complete acceptance.
EtherNet/IP is the application layer protocol that can meet this challenge. EIP provides wide-ranging, comprehensive, certifiable standard suitable to a wide variety of automation services:
EIP Uses Tools and Technologies of Traditional Ethernet
EtherNet/IP uses all the transport and control protocols used in traditional Ethernet, including the Transport Control Protocol (TCP), the Internet Protocol (IP), and the media access and signaling technologies found in off-the-shelf Ethernet interface cards. Building on these standard PC technologies means that EIP works transparently with all the standard off-the-shelf Ethernet devices found in today’s marketplace. It also means that EIP is easily supported on standard PCs and all their derivatives. Even more importantly, basing EIP on a standard technology platform ensures that EIP will move forward as the base technologies evolve.
Ethernet/IP is a Certifiable Standard
The groups supporting EIP plan to ensure a comprehensive, consistent standard by careful, multi-vendor attention to the specification and through certified test labs as has been done with DeviceNet and ControlNet. Certification programs modeled after the programs for DeviceNet and ControlNet will ensure the consistency and quality of field devices.
EIP is Built on a Widely Accepted Protocol Layer
EIP is constructed from a very widely implemented standard used in DeviceNet and ControlNet called the Control and Information Protocol (CIP). This standard organizes networked devices as a collection of objects. It defines the access, object behavior and extensions which allow widely disparate devices to be accessed using a common mechanism. Over 300 vendors now support the CIP protocol in present-day products. Using this technology in EIP means it is based on a widely understood and implemented standard that does not require a new technology shakedown period.
The Communications and Information Protocol (CIP) is a communications protocol for transferring automation data between two devices. In the CIP Protocol, every network device represents itself as a series of objects. Each object is simply a grouping of the related data values in a device. For example, every CIP device is required to make an Identity object available to the network. The identity object contains related identity data values called attributes. Attributes for the identity object include the vendor ID, date of manufacture, device serial number, and other identity data. CIP does not specify at all how this object data is implemented, only what data values or attributes must be supported and that these attributes must be available to other CIP devices.
The Identity object is an example of a required object. There are three types of objects defined by the CIP protocol.
Required objects are required by the specification to be included in every CIP device. These objects include the Identity object, a Message Router object and a Network object.
The identity object contains related identity data values called attributes. Attributes for the identity object include the vendor ID, date of manufacturer, device serial number, and other identity data.
The Message Router object is an object which routes explicit request messages from object to object in a device.
A Network object contains the physical connection data for the object. For a CIP device on DeviceNet, the network object contains the MacID and other data describing the interface to the CAN network. For EIP devices, the network object contains the IP address and other data describing the interface to the Ethernet port on the device.
Application objects are the objects that define the data encapsulated by the device. These objects are specific to the device type and function. For example, a Motor object on a Drive System has attributes describing the frequency, current rating, and motor size. An Analog Input object on an I/O device has attributes that define the type, resolution and current value for the analog input.
These application layer objects are predefined for a large number of common device types. All CIP devices with the same device type (Drive Systems, Motion Control, Valve Transducer…etc.) must contain the identical series of application objects. The series of application objects for a particular device type is known as the device profile. A large number of profiles for many device types have been defined. Supporting a device profile allows a user to easily understand and switch from a vendor of one device type to another vendor with that same device type.
A device vendor can also group Application Layer Objects into assembly objects. These super objects contain attributes of one or more Application Layer Objects. Assembly objects form a convenient package for transporting data between devices. For example, a vendor of a Temperature Controller with multiple temperature loops may define assemblies for each of the temperature loops and an assembly with data from all temperature loops. The user can then pick the assembly that is most suited for the application and how often to access each assembly. For example, one temperature assembly may be configured to report every time it changes state while the second may be configured to report every one-second regardless of a change in state.
The vendor usually predefines assemblies, but CIP also defines a mechanism in which the user can dynamically create an assembly from application layer object attributes.
Objects not found in the profile for a device class are termed Vendor Specific. The vendor includes these objects as additional features of the device. The CIP protocol provides access to these vendor extension objects in the same method as either application or required objects. This data is strictly of the vendor’s choosing and is organized in whatever method makes sense to the device vendor.
In addition to specifying how device data is represented to the network, the CIP protocol specifies the number of different ways in which that data can be accessed such as cyclic, polled and change-of-state.
The advantages of the CIP protocol layer over EIP are numerous. The consistent device access means that a single configuration tool can configure CIP devices on different networks from a single access point without using vendor-specific software. The classification of all devices as objects decreases the training and startup required when new devices are brought online. EIP provides improved response time and greater data throughput than DeviceNet and ControlNet. EIP links devices from the sensor bus level to the control level to the enterprise level with a consistent application layer interface.
There are numerous application layer competitors to EIP including Modbus/TCP from Groupe Schneider, ProfiNet from Siemens, HSE Fieldbus from the Fieldbus Foundation and other vendors. Unfortunately, space prevents a detailed review of each of these products. However, none of these competitors can provide the vendor support, flexibility, and total architecture support offered by the implementation of CIP over Ethernet.
EIP implementation is not without challenges. Two of the most important challenges to the first time user include training and network configuration. One common problem is the lack of trained staff who understand both IT fundamentals and the automation network. A collaborative effort between the IT and Automation staffs is required to implement the first Ethernet/IP system successfully.
A second challenge is the proper network configuration. Planning your Ethernet factory automation infrastructure is essential. Careful identification of all your control loops, choosing the correct routers, switches, and paths and properly documenting your network are requisites for a communications network that meets your production goals and requires little ongoing maintenance.
Detractors of Ethernet applications on the factory floor often cite the lack of inherent determinism in Ethernet communications to keep it out of automation applications. While true in the past, recent developments in intelligent switches have largely eliminated this argument. These switches create separate collision domains that offer the determinism required of almost all but the most demanding of automation applications.
John S. Rinaldi is Chief Strategist and Director of WOW! for Real Time Automation (RTA) in Pewaukee, WI. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of over 100 articles on industrial networking and the author of six books including: