There are several methods of talking to instrumentation, but which one is best for my application? I hope this article makes this much clearer and gives you a good indication as to which way to proceed.

Proprietary Protocols

In many cases, the only protocols that are available are the vendor’s proprietary protocols over RS232 or RS485. For some instrument manufacturers, this is as good as it gets if you needed data from your device. To implement this type of protocol, one has a few choices to collect process data. First is to use the vendor’s proprietary software. This is good as long as the vendor has software and it is of a high quality and well written, which in many cases it is not.

The second choice is to create your own software. This choice is the last resort if the vendor’s software is nonexistent or the data has to be collected by an established SCADA (supervisory control and data acquisition) system. This is a painful way to use the communication features in your instruments, and if multiple vendors’ equipment is in the shop, writing and maintaining multiple drivers is a full-time job. One company, seeing all of the confusion with the multiple proprietary protocols on the market, took on the challenge of bringing many of the most common protocols into a single, useful SCADA package. The SpecView Corporation of Gig Harbor, Wash., has taken all of the disorder and made it simple for shop owners to collect data from an instrument and store it in one location. SpecView is a saving grace to many instrument vendors who now have a reasonably priced SCADA package to offer their customers that will work with their existing protocols.

OPC is another tool for getting data from instruments on the shop floor. OPC is a common platform whereby multiple instrument servers can place their data so that OPC-compliant Windows software clients can go to collect it. The primary goal of the specification was to eliminate the need of client application vendors to develop proprietary communication drivers to collect data from various instruments. Many vendors provide OPC-compliant servers for their instruments. By using OPC, connecting any software package and any instrument driver together is simple as long as they are OPC compliant.

“I Want Ethernet Protocol”
One point of confusion with many people is the differentiation between the physical connection and the communications protocol. When specifying the type of communications for your network, both the connection type and protocol have to be addressed. Many protocols will operate over more than one physical layer; the physical layer being the connection the instruments use for communications. For example, the Modbus protocol can operate over the RS485 (Modus RTU) and Ethernet (Modbus TCP/IP) physical layer, while CIP (Communications and Information Protocol) operates over Ethernet (Ethernet/IP) and CANbus (DeviceNET) physical connection.

In simple terms, the differences between the physical connection and the protocol can be seen in something as simple as a telephone call. Both parties must have a telephone to establish a physical connection between the two. This would be representative of RS232, RS485, fiber or Ethernet. Now that a physical connection is established, the protocol would represent the spoken language of each of the speakers. If both speakers are speaking English over the telephone, then information can be exchanged. If one is speaking French and the other Japanese, no data is exchanged. Common industrial protocols are Modbus, CIP, CC-Link and BACnet.

Modbus Protocols
Modbus currently is the most commonly used protocol in industrial applications. This protocol was published in 1979 by Modicon for use with their PLCs but is now administrated by the Modbus Organization. Modbus has been and still is the de facto standard for industrial communication protocols. Almost all instrument vendors are using Modbus communication in one form or another. One of the reasons for this is that Modbus has a fairly simple design and is easy to implement. The protocol is designed to only transmit 16-bit integer data between devices on the same network. This means the data is simple and the messages are short. This simplicity allows for robust and reliable communications.

There are multiple Modbus standards, but two are the most common: Modbus RTU, which travels on RS232/485 physical connections, and Modbus TCP/IP, which uses Ethernet. Instruments using Modbus RTU employ a master-slave technique for communicating between instruments. One device, the Modbus master, acts as the conductor on the network by controlling all the data that travels on the bus. This master will query the devices on the network for information such as the process variable or alarm status. It can also push new data to the slaves such as a new setpoint or a change in operation mode.

This device is typically a PLC, data recorder or software SCADA package that needs the data to complete its core function of logging it, controlling the process or using the data to complete other functions in the system. Slave devices are typically elements such as temperature controllers, power meters or signal conditioners that normally perform their primary functions while waiting for a Modbus query from the master. As far as the master is concerned, the slave has no functions other than to respond to Modbus masters commands. Modbus RTU is great for applications where all the devices are in one small area, a panel or even a small shop. All that is needed to connect the instruments is a cable with a couple of twisted pairs in it. Some shops have wired larger facilities with RS485 cable for Modbus, but there is a better solution if a wide-area network is needed – Modbus TCP/IP.

Modbus TCP/IP uses a client-server scheme for managing data, which is a bit different than the master-slave. With Modbus RTU, the master device is responsible for managing the flow of all the data on the network. With Modbus TCP/IP, data flow is controlled by the TCP/IP protocols embedded in the routers, switches and servers in the network. The TCP/IP is not another industrial protocol but a set of rules for transmitting packets of data from one computer or device on a network to another. With TCP/IP, a device can take a piece of data, surround it with addressing information called an envelope and push data onto the network. The TCP/IP protocol ensures the data will reach its final destination.

This is similar to addressing a letter and mailing it. The mailing address that is written on the envelope has the final destination of the package. The postal system has the infrastructure to pick up, sort and deliver millions of pieces of mail daily in a process that is almost completely automated. TCP/IP does the same thing but much faster and with much more packet data.

Since dataflow no longer has to be managed by a master device, some things change. Requests for information can come from multiple sources at the same time. Devices requesting data are called clients. Like masters, they can be PLCs, data-acquisition systems or SCADA packages. The previous RTU slaves are now servers in the TCP/IP world basically doing the same thing – responding to queries from the network. One thing that is different in this configuration is that an instrument may be both a client and server at the same time, providing data to other clients and collecting data from other servers. Some vendors, such as Yokogawa, provide instruments and data recorders with this capability. Modbus TCP/IP is great for any application but excels where the installation needs to be quick and simple and an existing Ethernet infrastructure already exists in the facility. Distance is not an issue as most intranets and the Internet use TCP/IP protocol. Client and servers do not have to be in the same building or even the same county but can exchange data effortlessly. This ease of use and flexibility has propelled Modbus TCP/IP into the premier spot of industrial networks.  

Common Industrial Protocol
Common Industrial Protocol (CIP) is a protocol that was developed by Rockwell Automation for use in their PLCs. They have opened the protocol up, and it is now administrated by the ODVA. This protocol is becoming one of the most widely used protocols in U.S. industry today due to a large installed base of Allen Bradley PLCs and the number of instrument vendors that support the protocol. CIP is implemented across various physical connections: a RS485 CAN connection (DeviceNet), Ethernet (Ethernet IP) and Coax (ControlNet).

Unlike the simplicity of Modbus, CIP is much more complex in its operation but offers key capabilities that allow users to determine what information is needed and when. Data can be exchanged between units on multiple CIP networks regardless of the physical connection. CIP uses a comprehensive group of implicit/explicit messages and application objects to group information, configure devices, collect data and diagnose problems. Data can be easily organized so that information needed for manufacturing can be separated from information needed by the front office. When implemented properly, CIP can be a very efficient way to operate a production process.  

CC-Link Protocol
CC-Link is protocol that was developed by Mitsubishi in the late 1990s for use with their PLCs. Soon after, Mitsubishi opened up the protocol and released it to the public. Many equipment vendors have adopted the protocol, but these vendors typically serve the Asian markets. Most applications for this protocol will be found in machine control or process automation in manufacturing facilities. The CC-Link protocol comes in multiple formats in which speed and function differentiate them from one another. The primary physical connections between these protocols is RS485 and Ethernet, which supports their popular CC-Link and CC-Link IE protocols, but their other protocols run on these connections as well. CC-Link is best used when an existing CC-Link network is in place or when using a Mitsubishi PLC.  

BACnet Protocol
BACnet is a protocol used in building automation and control applications. This protocol allows different elements and systems used in a commercial building – such as HVAC, thermostats, motion detectors, lighting, security and smoke detection – to all work together on the same network. Initially, BACnet was implemented on multiple physical layers such as telephone wire, RS232/485 or coaxial cable. Today, it is exclusively implemented over Ethernet. BACnet is typically not a protocol that would be implemented in an industrial process, but you may run into it as your building may be using it or you may be using instrumentation that has the protocol in it.

Conclusion

This is by no means an exhaustive list of protocols available in the market. The selection of a protocol for your particular situation will be based on many factors, including the existing hardware in your facility, the types of data and diagnostics you require, and the technical expertise that is available to you to engineer and implement a communications system. In my opinion, a Modbus TCP/IP is the logical choice with all things being equal. It is supported by most instrument and software suppliers, it’s simple to understand and setup, can use existing an Ethernet infrastructure and it is extremely reliable for collecting basic process information. Many resources are available online explaining this protocol and many instrument vendors such as Yokogawa are willing to help you with your Modbus TCP/IP setup and implementation questions. IH  

For more information: Contact Clayton Wilson, Yokogawa Corporation of America, 2 Dart Rd., Newnan, GA 30265; tel: 678-423-2524; fax: 770-251-6427; e-mail: clayton.wilson@us.yokogawa.com