Print this article

Comment

1 May 2002

English, TCP/IP, and language translation

By Perry Marshall

With the help of a skilled translator, four competing industrial Ethernet protocols can work together.

The Oxford English Dictionary says, “English never met a word it didn’t like.” Most English words ultimately come from other languages, and even today, English continues to absorb new words.

For example, the Japanese word for continuous improvement, Kaizen, has become common in management lingo. English has a huge vocabulary: more than 1 million words. Just think of how many words we have for street: road, lane, boulevard, parkway, path, drive, trail, way, avenue. Most of them came from other languages.

If English is the de facto standard for technology and business in the world today, then TCP/IP plays the equivalent role in the world of networking. TCP/IP never met a file or protocol it didn’t like.

Whether streaming video, Word files, Web pages, MP3s, PDFs, e-mail messages, MIDI songs, pictures of the grandkids, and yes, even factory process data in Modbus packets, TCP/IP doesn’t care. It just packs ’em up and sends them on their way.

Spanish often keeps the same words and adopts them as its own—such as telefono. But when the Chinese began to use telephones, they tossed out the English words for these items entirely. Mandarin for telephone is dian hua, which means “electric speech.” It is certainly possible to invent new Ethernet standards from scratch, but TCP/IP is not like Mandarin—it’s more like English and Spanish. It likes other protocols.

ETHERNET AT CENTER STAGE

The fieldbus wars of the 1990s (Interbus vs. ControlNet vs. Foundation fieldbus vs. Profibus vs. . . .) have given way to the industrial Ethernet wars. Drives, programmable logic controllers, and temperature controllers not only must support dedicated networks such as DeviceNet but are also increasingly required to have an Ethernet port, including a standard dialect. I’ve seen the greatest demand for Modbus/TCP and EtherNet/IP, with Profinet as a relative newcomer and Foundation fieldbus high-speed Ethernet (HSE) as a child of the process industry.

Application Layer protocols can coexist on a network. You could possibly have all four of the above protocols on the same wire simultaneously, just like you pass Word documents, hypertext markup language files and .exe files over the same office LAN. However, just like an inner city gang member giving directions to a suburban soccer mom, this is bound to involve confusion and expense.

Greek has three words to describe love. Phileo means ordinary, common, brotherly love; Philadelphia was derived from it. Agape means unconditional love and describes extremely committed and spiritual relationships. Eros means erotic love. It’s easier to make these distinctions in Greek than in English. Likewise, Turkish has dozens of words for tactile sensations of texture for which English has no equivalent.

So despite the enormous flexibility of English—and TCP/IP—sometimes the native language is still best. The entire DeviceNet protocol can be represented on Ethernet, but if you’re trying to hook a few dozen smart sensors, photo eyes, and proximity switches together, real DeviceNet is easier and less expensive than Ethernet.

ENCAPSULATING IN TCP/IP

You can encapsulate a protocol in TCP/IP unless the protocol has a specific timing mechanism that imparts meaning to a message. For example, if a DH485 node has no activity for a few milliseconds, the other nodes will assume the token was lost, and at least one node will try to recreate the token. This behavior can’t directly encapsulate in TCP/IP without some inexact “translation.”

“Industrial Ethernet” implies a standardized format for automation data. Rather than inventing something from scratch, the easiest thing to do is to use existing protocols and map them to TCP/IP.

One could invent any number of new Application Layer protocols, and right now, in fact, there are a myriad of other proprietary standards from various vendors. But there are significant advantages to the existing bus architectures:

• Profiles for many devices have already been defined through laborious, bureaucratic processes that no sane human being would care to repeat. These profiles can be translated to Ethernet with relatively little effort.
• In systems that use, for example, ControlNet as a control-level network and Ethernet/IP at the supervisory level, the relationship between the two networks is relatively transparent. Data can transfer between the upper and lower network fairly easily.
• Many developers and users are familiar with these existing protocols, and this speeds the process of product development and adoption.

FOUR PROTOCOL CONTENDERS

Presently, there are four major industrial protocol contenders: Modbus/TCP (Modbus protocol on TCP/IP), EtherNet/IP (the ControlNet/DeviceNet objects on TCP/IP), Foundation fieldbus HSE, and Profinet (Profibus on Ethernet).

MODBUS/TCP
www.modbus.org/

If there is currently a de facto standard for Ethernet on the plant floor, this is it. It takes advantage of the simplicity and availability of Modbus. However, the limitations of Modbus also apply. It has limited ability to transmit complex sets of parameter data among devices.

ETHERNET/IP
www.odva.org/

EtherNet/IP is essentially the ControlNet and DeviceNet objects on TCP/IP and user datagram protocol. This specification has been released, and EtherNet/IP products are starting to appear. Example code and the specification itself are available from the Open DeviceNet Vendors Association, ControlNet International, and the Industrial Ethernet Association.

PROFINET
www.profibus.com/

This specification has just been released, and a few products are now available. It combines a form of the existing Profibus protocol with component object model, distributed component object model, OLE for process control (OPC), and TCP/IP. With the worldwide acceptance of Profibus, it has strong likelihood of commercial success. The relationship between Profibus-DP and Profinet is not as direct as with some other protocols, but I/O data as well as device profiles (i.e., ProfiDrive) remain intact.

Profinet is not simply “Profibus on Ethernet” but is actually an object-oriented, high-level architecture that attempts to bring complete transparency to all automation devices, similar to the way Microsoft networking and file sharing make PCs and their files transparent in your office.

FOUNDATION FIELDBUS HSE
www.fieldbus.org/

HSE puts the Foundation fieldbus H1 protocol on TCP/IP and adds OPC, extensible markup language, and simple object access protocol on TCP/IP. It’s definitely geared toward the process industry and will be a very strong contender there.

SIMILARITIES AMONG DIALECTS

Every language has nouns, verbs, and adjectives. Every control application has outputs to send, inputs to receive, and various parameters to occasionally read and write.

This table shows there are two types of data in a control system: I/O data that is usually updated constantly and messaging data, which is sent only as needed. Most networks have mechanisms for handling both. The terminology for these functions is listed here:

MULTIPROTOCOL PRODUCTS

Some devices may be required to support more than one protocol at a time. A motor drive that supports both Modbus/TCP and EtherNet/IP, for example, could be programmed to recognize which of the two dialects is being spoken and automatically respond in the correct language. Variables for start, stop, velocity, and acceleration must all wind up in the same place, regardless. That implies a common application programming interface (API) for all protocols.

This is not new. The concept can be applied not only to different protocols but to entirely different networks. Many OEMs achieve connectivity by using interchangeable “daughter boards” for various networks—i.e., ControlNet, Profibus, CANopen, etc.—that all use a common API so they can swap networks just by changing cards, without rewriting software. On a PC, this is accomplished on the software level with OPC. Changing dialects doesn’t have to be as difficult as it might sound.

POETRY AND THE TOWER OF BABEL

You may wonder if all these protocols are actually going to work together. For the most part they will. However, when they don’t, it won’t usually be due to a fundamental flaw in the language but to how it’s implemented within a specific product.

Going back to the motor drive example, standard profiles exist for DeviceNet that are now being extended to EtherNet/IP. Most drives have added features that extend beyond the standard profiles. How these are implemented across multiple dialects is a manufacturer-specific decision. Even if protocols are interchangeable, devices are usually not.

Integrating networking equipment skillfully is an art form—a sort of high-tech poetry. Shakespeare’s sonnets can be translated into French without much loss of meaning, but to keep the original message and the poetic form perfectly intact certainly requires the services of a skilled translator.

Convergence of industrial protocols is inevitable. Just as your PC can open PDF files, Web pages, and Word documents, industrial devices will increasingly support multiple data formats on Ethernet as well. The challenge there is twofold: Larger vendors tend to be uninterested in supporting one another’s protocols, and the additional protocol support consumes memory and processor power. Because resources are at a premium in embedded designs, this is costly and will be slow to come.

But make no mistake: Convergence is inevitable and will continue to make connectivity simpler and more complete. IC

Behind the byline