A Comprehensive Guide to Industrial Networks

Perry Sink Marshall

Part 1: Why Use an Embedded Network or Fieldbus, and What Are the Most Popular Standards?

Silicon and software now make it possible to put network capability on a chip small enough to drop into a sensor. This guide explains why you’d want to do that and demystifies the confusing array of network protocols from which to choose.

The Internet has grown from a bleeding-edge curiosity to a ubiquitous force that is redefining how we live and work. Every imaginable kind of device will eventually be networked, but pervasive connectivity of sensors will materialize in the industrial world before it happens in the consumer arena. This will transform sensors from information devices into communication devices.

But the sensor world is more diverse than the PC world. In most cases, it’s more expensive to network a sensor with embedded intelligence than it is to connect a PC, and there are more ways of doing it. The plethora of network standards and the inherent difficulties in supporting more than one protocol have stopped many an engineer cold.

This three-part series discusses adding network capability to sensors via embedded devices. The remaining parts of the series will answer the following questions.

Part 2: What are the basic hardware and software components needed to build networking capability into a sensor?

Part 3: What are the prepackaged and off-the-shelf alternatives to designing network capability from scratch?

Why Add Network Capability to a Sensor?

Photo 1. On the left is a control panel for a point-to-point wired automation system. On the right is a system that’s wired with DeviceNet. Notice the dramatic reduction of wires and the physical simplification of the system. Network-based systems have a higher component cost, but they save on wiring, labor, and wiring errors and can report diagnostic data unavailable with point-to-point wiring. (Photo courtesy of ODVA.)

The first and most obvious reason is to save wiring when interconnecting multiple devices. Large factory automation and process control applications use industrial networks (fieldbuses) extensively. The elimination of large, unwieldy bundles of cables and the associated mess is an obvious advantage (see Photo 1). Networking allows you to connect hundreds of devices to a single trunk line instead of using hundreds of individual wires. As systems grow past the threshold of 100 I/O points, the added expense of network hardware is offset by savings in wiring time.  These benefits grow exponentially with the size of the system.

Figure 1. Cost savings grow exponentially with the size of a system. Generally, systems with 100 or more devices are likely to be less expensive if you use a network. Networked systems can be reconfigured in software, rather than physically changed. The modularity brings interesting possibilities to machine design.

The modularity of a networked system is another major advantage (see Figure 1). Connectivity is achieved through software, so taking a large system apart, putting it on a truck, and reassembling it somewhere else is much easier.

In addition to the wiring savings and modularity, there are three major reasons to add network capability to a sensor:

Diagnostics. A networked device often can tell you if it is malfunctioning, or if something’s about to go wrong. This information can be of great help. It’s even more valuable if the information can be accessed remotely via the Internet.

Self-Configuration. Machine controllers can automatically detect which modular components are connected to the network and determine what software configuration to load. This can cut hours or even days off the delivery and setup time of a large system.

Enterprisewide Information Systems. Initiatives to interconnect every system in a company””from accounting to purchasing to manufacturing to payroll and sales””may extend down to individual devices. Even the most mundane information can add money to the bottom line if used appropriately.

Redefining a Sensor via Networking

It’s one thing to connect hundreds of solenoid valves and proximity switches via a network to save wiring time or to make the system modular. It’s quite another to use the network to gather more information than you could get from a hard-wired device.

Photo 2. The 6950/6960 mass flow controller series from Brooks Instrument, Hatfield, PA, comes in two versions: a hard-wired analog version, which has seven connections, and a DeviceNet-enabled version, which has a single connector and the ability to handle many additional variables. The DeviceNet version exchanges more than 100 additional data types, making it more valuable to customers in the semiconductor industry.

For example, Brooks Instrument Division, Emerson Electric (215-362-3500), makes mass flow controllers (MFCs) for semiconductor fabrication machines. These devices precisely monitor and regulate the flow of gases in a process (see Photo 2). Network the MFCs, and you’ve greatly enhanced the device. In addition to the seven control variables available through the hard-wired version, the network-enabled unit gives you access to hundreds of variables from 39 categories of variables and functions, which relate to the complexity of regulating and monitoring gas flow in real time (see the sidebar “Information Access: Hard Wire vs. Network”). This rich array of information provides insight into the process that otherwise would be unavailable. The information lets you identify the source of problems, and the manufacturer can determine whether the problem originated in its MFC or elsewhere.

Commercially, a manufacturer can sell its sensor based on the added value of the specialized information that its unit provides, rather than on the commodity value of an xyz category sensor. For this product, semiconductor processes that create millions of dollars of product per hour can be optimized in ways that were only dreamed of when hard-wired devices were used.

Who Uses Sensor Networks?

The larger the company, the larger the installation, and the more sophisticated the application, the more likely it is that a network will be used. General Motors and Chrysler use DeviceNet and Profibus extensively to link factory-floor devices, and Ethernet is everywhere, not only connecting the enterprise but linking controllers and PLCs to each other and to the IT department.

Networks like Bacnet and LonWorks link devices in building HVAC systems (see the sidebar “Honorable Mention”). Foundation Fieldbus connects intrinsically safe devices across huge oil refinery and chemical processing campuses.

How Does an Industrial Network Open New Markets?

If a network redefines a sensor, it also redefines who wants to buy it and what it can be used for. If customers have chosen a particular network for a control or data acquisition system (DA), then their choice of sensors is narrowed to those that support the network.

Right now, most sensors don’t have a network capability; only a few can make this claim. So if your sensors are network enabled, you’re in an elite group. You’re competing against fewer people, and your customers are more value driven and less price driven. Customers who focus only on the increased price of a networked system have missed the main point. It’s not about price. It’s about the value of information and what you can do with it””how you can profit from it””once it’s available.

Ethernet

There are a lot of network standards out there. If you’re going to add network capability to your sensor, which one should you support? Well, to start with, it’s best to view networks in terms of their scope. One of the reasons there are so many different network standards is that there are so many different requirements. Table 1 indicates the amount of data that various buses are designed to handle.

One of the most widely accepted standards, Ethernet, is designed to transfer large amounts of data at high speed and to serve the needs of large installations (see Figure 2).

Figure 2. The question of which network to use is largely determined by the amount of data being sent. Ethernet is designed to handle large amounts of data (more than 1000 bytes at a time) and is poorly suited for simple devices. Other networks are more suitable for small amounts of data. This illustration shows the relative quantities of data that various networks are designed to handle.

The networking of millions of PCs in offices and the proliferation of the Internet around the world has made Ethernet a universal networking standard. Today, the standard is gradually working its way to the sensor level in DA and control applications. The hardware and related software have evolved to the point where even inexperienced users can build simple networks and connect computers together. In automation, Ethernet is commonly used with other fieldbuses (see Figure 3).

Figure 3. Typically, three layers of networking make up enterprisewide networks. Ethernet acts as the company’s intranet backbone, and it’s linked to controllers or industrial PCs, which supply strategic data to the enterprise. An industrial network, or fieldbus, links sensors and smart devices. A gateway (not uncommon in a large system with lots of devices) links devices that have only RS-232 or RS-485 ports to the fieldbus system.

Ethernet hardware is dirt cheap and can be purchased from office supply stores, computer stores, and e-commerce sites everywhere. The protocol appears to be a panacea for all those who are overwhelmed by the confusing array of standards vying for market dominance and who believe that the popular fieldbuses are expensive and difficult to use. Furthermore, a study by a Big Three automotive manufacturer showed that Ethernet could potentially serve up to 70% of plant floor networking applications.

On the other hand, Ethernet does have its drawbacks. For example, it has a high overhead-to-message ratio for small amounts of data. Also, Ethernet carries no power on the bus, and its RJ-45 connectors are physically vulnerable and more susceptible to EMI/ RFI than most fieldbuses. And even now, its multiple open and proprietary standards are a source of confusion in the industry.

What’s the Deal with Industrial Ethernet?

Multiple instrumentation protocols””including Modbus/TCP, EtherNet/IP, ProfiNet, and Foundation Fieldbus HSE””have emerged as standards for connecting sensors, discrete and analog I/O, and smart devices to Ethernet. This is a new chapter in the fieldbus wars that have been fought in the industry for the last 10 years, except that TCP/IP allows multiple protocols to exist simultaneously on the same wire.

There are at least three major issues that must be addressed for Ethernet to become a viable, popular, plant-floor fieldbus. First, a common application layer must be established. When your device receives a packet of data, in what format is that data? Is it a string of I/O values, a text document, or a spreadsheet? Is it a series of parameters for a variable frequency drive? How is that data arranged? There are several competing standards.

Photo 3. A panel mount receptacle allows a traditional RJ-45 Ethernet telephone connector to be changed to an 8-pole, euro-style waterproof connector for industry. Connectorization is a major issue in using Ethernet for control and data acquisition in industrial environments. (Photo courtesy of Lumberg, Inc.)

Next, many applications require industrial-grade connectors. Cheap plastic telephone connectors don’t cut it on the plant floor, and the RJ-45 connectors aren’t up to the task. An industrial-strength connector will be a great benefit (see Photo 3). Finally, some applications require determinism. Ethernet, as it is typically used, is not deterministic or repeatable””in other words, throughput rates are not guaranteed. But there are ways of building deterministic Ethernet systems. In reality, most people who think they need determinism really need speed.

Neither Ethernet nor TCP/IP Guarantees Interoperability

Ethernet is just a physical layer standard, in much the same way that an RS-232 link or a telephone line is. Having a physical connection means that messages can be transmitted, but it does not ensure successful communication. Just because you can make a telephone ring in Shanghai doesn’t mean you can speak Mandarin.

There are many transmission protocols that can be used on Ethernet. The most popular””and the one used on the Web””is TCP/IP, which stands for Transmission Control Protocol/Internet Protocol. TCP/IP is just a transport mechanism that ensures that messages get from point A to point B. Even though we all use TCP/IP, we’ve still had the experience of downloading a large file, only to discover that our PC ”cannot find an associated application for this file type.“ So you end up downloading a plug-in, such as Uhockwave, RealAudio, Winamp, or Adobe Acrobat Reader so that you can open the file.

The same problem applies to sensors. You can send any file or piece of process data you want over Ethernet or the Internet, but the receiving end has to know what to do with the data. TCP/IP doesn’t guarantee that you’ll be able to open the file; it just guarantees that it will arrive. Similarly, data can be packaged in an existing fieldbus format and then transported on TCP/IP. This is the direction in which the industry is moving.

Fieldbuses on Ethernet

There’s no need to start from scratch in defining Ethernet protocols for industry. Instead, many vendors are encapsulating existing protocols in TCP/IP. Presently there are four major contenders: Modbus/ TCP (Modbus protocol on TCP/IP), EtherNet/IP (the ControlNet/DeviceNet objects on TCP/IP), Foundation Fieldbus High-Speed Ethernet, and ProfiNet (Profibus on Ethernet).

You could propose an infinite number of application layer protocols. In fact, right now there are (in addition to the above protocols) many proprietary standards from various vendors. But there are several significant advantages to using existing bus architectures:

• Profiles for many devices have already been defined, and they can be transferred to Ethernet with relatively little effort.
• Data can be transferred between the upper and lower network easily. In systems that use, for example, Profibus as an I/O level network and Profibus on Ethernet at the supervisory level, the relationship between the two networks is relatively transparent.
• Many developers and users are familiar with the existing protocols, and this speeds the process of product development and adoption.

To go into the details of Modbus/TCP, EtherNet/IP, Foundation Fieldbus HSE, and ProfiNet is beyond the scope of Part 1 of this series. I’ll provide more information on these protocols in Part 2.

RS-232/-422/-485

RS-232 serial ports are like cassette players in automobiles””nobody brags about them, but almost everybody has one. RS-232 lets one device communicate with another. RS-422 and RS-485 allow multidrop networking on a single wire.

Please note that RS-232 is not a protocol. It’s merely a physical layer with defined pinouts, cable characteristics, and signal levels. ASCII is not a protocol, either: it’s an agreed upon digital representation of characters. For two devices to communicate, they must share the same protocol and physical connection. There are thousands of protocols, mostly proprietary, and a few ¬ommon open protocols. Just because two devices have a serial port doesn’t mean that they can talk to each other. Check out these details carefully when planning a system.

Modbus RTU/ASCII

Modbus Remote Terminal Unit (RTU)/ ASCII is probably the most popular serial protocol in instrumentation, automation, and process control. Today, it provides everything from short serial linkage of smart devices to wide area networking of many devices. Modbus is commonly used with gateways and works well encapsulated in TCP/IP. Developed almost 25 years ago, it’s a simple yet effective way of encapsulating analog and digital I/O and parameters in registers.

Modbus can link as many as 250 devices on an RS-485 cable. Furthermore, you can find many gateway devices that link Modbus and other networks, so if your product has the Modbus protocol on a serial port, you can get from there to almost any network using a black box converter.

The downside, though, is that transmission speed is slow on standard serial media. Also, the protocol lacks sophistication (i.e., it offers no peer-to-peer capabilities, and it is not object oriented).

The Controller Area Network

In the early 1980s, Bosch developed the Controller Area Network (CAN) so that the ürimary control components in an automobile (e.g., brake lights, airbags, sensors, lights, electric windows, and door locks) could be connected by a single cable instead of a 3-in.-thick bundle of cables. Automotive manufacturers found that if a wiring harness was faulty, it was sometimes cheaper to scrap the entire car than to troubleshoot the wiring harness. With a network, you can wire a control panel virtually in software, rather than physically with a screwdriver and terminal blocks. The added hardware cost of the network is more than paid for by labor savings. The same applies to automated equipment in a factory.

Of course, in a vehicle, communication can mean the difference between life and death. You cannot tolerate network errors, regardless of origin. CAN lives up to these rigorous requirements, with a statistical probability of less than one faulty message per century.

The standard is minimally a three-wire bus, with ground and two opposing signal conductors. Signals consist of a pulse train centered at about 2.5 V, with the high signal rising to about 3.2 V and the low signal falling to about 1.8 V. This creates noise immunity, which is especially important in a vehicle.

CAN is a low-level message arbitration protocol implemented on inexpensive (<$1) chips available from multiple vendors and manufactured by the millions. To have a functional network protocol, an additional software layer must be added.

Higher layer protocols (e.g., DeviceNet and CANopen) can be thought of as a sophisticated set of macros for CAN messages, specifically suited for automation. Another popular standard, J1939, was created by the Society of Automotive Engineers as a CAN application layer used in trucks and buses.

Profibus

Profibus is commonly found in process control, large assembly, and material-handling machines””single-cable wiring of multi-input sensor blocks, pneumatic valves, complex intelligent devices, smaller subnetworks (e.g., AS-I), and operator interfaces. Nearly universal in Europe and popular in North America, South America, and parts of Africa and Asia, Profibus is the most widely accepted international networking standard. It can handle large amounts of data at high speed and serve the needs of large instfllations. The DP, FMS, and PA versions collectively address the majority of automation applications.

Unfortunately, the network comes with a high overhead-to-message ratio for small amounts of data and carries no power on the bus. Profibus also costs slightly more than other buses. The standard’s European and Siemens centricity is occasionally an obstacle for some North American users.

Foundation Fieldbus

Foundation Fieldbus has finally come into its own and is rapidly establishing itself as the future standard for process industry networking. Since its official introduction in 1997, many distributed control system vendors have embraced the protocol, developing and certifying devices that conformed to its specifications. This standard contends with Modbus, HART, and Profibus PA.

The fieldbus is a flexible, sophisticated protocol with many capabilities. It holds great appeal because it’s intrinsically safe and provides an integrated device-level/plant-level approach. Broader adoption of Foundation Fieldbus has been slowed by the protocol’s process-industry-centric nature, the limited availability of compatible devices, and the slow process of standardization. The fieldbus combines a device-level network, H!, and High-Speed Ethernet (see Figure 4).

Figure 4. Foundation Fieldbus, which has become a major technology in the process control industry, has two layers: H1, which is designed for intrinsically safe applications with such devices as pressure sensors and valves (31.25 Kbps), and High-Speed Ethernet (100 Mbps), based on the same protocol.

The standard is typically used in distributed control, continuous process control, batching, and oil and gas processing operations (see Figure 5.)

Figure 5. (A) Ethernet 10Base-T and 100Base-T require a star topology (i.e., only one node at each end of a wire). Multiple devices must be isolated by a hub or switch. Low-speed networks, such as AS-Interface and Foundation Fieldbus H1, can be wired in nearly any configuration, including a star (no hubs or isolation devices necessary), because at low baud rates, signal reflections are not a problem. (B) A trunkline/dropline topology defines a length of cable with “spurs” going out to individual devices. The trunk is normally impedance terminated on each end, and drops are limited in length to keep reflections under control. (C) In a daisy-chain network, the trunkline has no spurs, keeping reflections to an absolute minimum.

Is Network Technology New or State of the Art?

What’s interesting is that the answer is really no. Ethernet and the Internet were developed in the 1970s, CAN in the early 1980s, and these networks are more popular now than ever before. Most of the other technologies mentioned here have been around for 10 years or more, but by no means are they obsolete. These networks have steadily grown as a result of two powerful forces: the falling prices of embedded technology and components and the growing expectations of sophistication and connectivity driven by the Internet.

Ultimately, networking is not a technology issue; the technology is there and is readily available (as will be discussed in the next two installments). The issue is the user who is often just becoming educated about the technologies and the political alliances that promote these protocols. Most network formats are to some degree tilted in favor of one vendor or another, and vendor issues have a significant effect on the choice of one network over another.

In the next installment of this series, the circuitry and some of the protocol/ firmware issues for the most popular embedded/instrumentation networks will be discussed. Stay tuned.

SIDEBARS: