Networking that floats all boats

SOMEDAY, industrial networking will be simple. Someday, electronic data packets will move effortlessly and securely from thousands of I/O devices in the field or on production lines, up through the plant floor and control room, and on to enterprise users and beyond. Someday, users will plug-and-play their devices without even having to think about interoperability, configuration, and programming.

Someday—just not today. That’s because despite recent cooperation on electronic device description language (EDDL) technology by three major fieldbus organizations, despite the recent emergence of several other networking protocols and methods, despite multiplying Ethernet flavors, despite evolving wireless standards, and despite new efforts promising even more interoperability, users still don’t have the completely open, interoperable, easy-to-use networks they need.

Selfish, proprietary interests continue to hold uninformed users hostage by subtly feeding their fears about new networking technologies, and then adding unnecessary layers of complexity to fieldbus protocols to confirm those fears. This traditionally is done to “protect users’ investments in their installed base,” which actually means “protecting the market share of suppliers too lazy to truly invest in innovation.” The now-classic example of this was the International Electrotechnical Commission’s (IEC) 61158 standard, which was hijacked years ago, and ended up with eight, non-consensus, ineffectual parts. Though most suppliers and their related trade organizations developed and now promulgate their own Ethernet versions, some proprietary snags are starting to surface in efforts to develop and settle on a wireless networking standard.

Tapping Untapped Interest
However, all is not lost. Surging end-user interest in Ethernet and wireless technologies is stoking interest and adoption of fieldbuses and other networking technologies, rather than replacing them as might be expected. This likely is happening because the sheer volume of users of 4-20 mA and other hardwired networks still is about four or fives times as large as all of those using twisted-pair fieldbuses, industrial Ethernet, and wireless combined.

Many users in this huge, untapped market initially are attracted to Ethernet and wireless, but often settle on fieldbuses, which are perceived to be more reliable and less scary, but still able to generate the wiring and labor savings they’re seeking.  

“Everyone expected Ethernet to supplant other networking methods, and that might happen in 10-20 years,” says Katherine Voss, executive director of ODVA and ControlNet International (CI). “However, at this moment in 2006, it appears that industrial Ethernet actually is causing all our other networking technologies to increase as well. So, while our EtherNet/IP protocol is growing by 30% per year, we’re actually seeing double-digit increased for all our CIP-based protocols, including DeviceNet and ControlNet, and we’re seeing a lot of hybrid networks.”

Voss thinks the ubiquitous adoption of Ethernet and Internet technologies in business and technical applications is the main inspiration for more users exploring and implementing newer networking technologies in control and automation. “For example, the fact that CIP can exist on the same wire and device at the application layer in Ethernet and Internet topologies makes it a very useful way to connect the plant floor to the enterprise, and this makes a good value proposition for all kinds of fieldbus networking.” 

EDDL Expands
In probably the most genuine collaboration effort, Fieldbus Foundation (FF), Profibus Nutzerorganisation e.V. (PNO), HART Communication Foundation (HCF), and the OPC Foundation have been working jointly to extend the text-based Electronic Device Description Language (EDDL) specification and language they use to describe characteristics of networked field devices. EDDL is international standard IEC 61804-2. Proposed extensions to DDL included adding capabilities to describe display characteristics of device parameters, as well as the ability to include algorithmic relationships for complex device parameters, persistent data, and real-time trends. These were approved as IEC 61804-3 earlier this year.

Ron Helson, HART Communication Foundation’s executive director, says the newly enhanced EDDL simplifies and standardizes the presentation of intelligent device information for automation suppliers and users worldwide. “These enhancements allow manufacturers to easily incorporate graphical windows, menus, images, trends and other advanced data visualization features into the DD for display on compliant host application platforms,” he states. “All information to define the window, the presentation of data within the window, and interaction with the device is described entirely within the enhanced DD. The enhancements also support storage of historical data from field devices for troubleshooting and diagnostics.” 

Mike Bryant, executive director of the U.S.-based Profibus Trade Organization, adds, “Once EDDL gets through the configuration and diagnostics phase, everything becomes transparent to the user, and no one needs to care about it anymore, which is what users say they want because it lets them get back to managing their applications.”

The partners also developed EDDL Interoperability Guidelines to help fieldbus developers create EDDLs for multiple protocols, so a description written for an FF valve signature, for example, would also work on Profibus and HART. The guidelines were released as 61804-4 this past March. “So, even though they’re based on different protocols, EDDLs can give different types of devices a common interface with the same look and feel,” says Dave Glanzer, FF’s technology development director.

In Phase II, which includes an assist from OPC’s Unified Architecture (OPC-UA) and installation in a web-services environment, EDDL’s common interface will bring Foundation fieldbus closer than ever to interoperability at its HSE level by similarly enabling common-application software packages (Figure 1). “In this case, HSE will perform a subsystem integration function that the higher levels won’t have to see anymore,” adds Glanzer. “The I/O devices still will have their own sensor-level protocols, but the host client won’t have to know there are different protocols.” 

FF also supports ISA’s SP104 committee, which is drafting a harmonized version IEC 61804-3 standard for EDDL. SP104 plans to republish the IEC standard as an American National Standard Institute (ANSI) standard.

“Many suppliers are devoting major engineering time to revising their instruments to make sure they have EDDL-compliant model numbers in them, so their devices can be accessed by system software conforming with EDDL,” says Dick Caro, CEO and principal consultant at CMC Associates in Acton, Mass.

OPC’s Overall Assist
“The whole goal of EDDL is to have one language that can look for any device for diagnostics, configuration, and run-time operations, and do it independent of the device manufacturer,” says Tom Burke, OPC’s president and executive director. “OPC’s role is to be the unifying transport mechanism for that language, so users can get rid of the traditional translation issues in industrial networking.”

Because users can configure any device in the same way by using its unified architecture as this transport mechanism, OPC was scheduled in late June 2006 to demonstrate its new ability to be scaled down into intelligent and not-so-intelligent devices. Burke explains this involves a uniform way of implementing XML-based web services. “In the old days, we spoke about having different devices talk without a bridge, and this will allow that,” he says. “You still can have the PC platform, but you won’t need it because OPC UA technology will be in the devices via XML web services.”

Burke adds that OPC, EDDL, and the FDT Group also planned to meet at the end of June to explore another technical collaboration project. “We want to have technical integration between all the standards,” he says. “This will allow manufacturers to easily use the technology that makes the most sense for the product they’re building. It’s like stopping the fieldbus wars at the technology level. You can’t stop the political fighting, but you can deal with these problems from a technical perspective, and ignore everything else, which was how EDDL formed in the first place.”

Ethernet Multiplies, Moves
In recent years, Ethernet in industrial networking (IEEE 802.3) has been characterized mostly by the quasi-proprietary icing that many suppliers have spread on top of the basic TCP/IP protocol. Every fieldbus organization and its related suppliers seem to have their own Ethernet version to capitalize on user interest. Some newer players are getting into the act, however, and using Ethernet to enable relatively high-speed, multi-axis, and other motion control-related technologies. Ethernet Powerlink, developed by B&R Industrial Automation and supported by the Ethernet Powerlink Standardization Group (ESPG), and EtherCat, developed by Beckhoff Automation and supported by the EtherCat Technology Group are two possibilities.

However, perhaps the most notable effort in this area comes from the SERCOS Trade Organization, which recently added Ethernet capabilities to its 20-year-old protocol. The organization released its specification for the controller-to-controller (C2C) synchronization and communication profile for interconnecting motion controllers using SERCOS III industrial Ethernet-based standard for motion con­trol. This profile defines mechanisms to interconnect distributed control functions, and synchronizes distributed motion controls in modular machines and systems via SERCOS III, which offers hardware redundancy, hot-plugging, and cross-communication. Typical applications for the profile are in printing, packaging and processing machines, as well as in machine tools with special requirements for control systems and synchronization, such as machines with gantry axes or rotary transfer tables.

Similarly, Profinet comes in real-time, soft-real-time, and hard-real-time versions to address motion-control applications. The soft-real-time version partitions data with time-division-multiplexing, while the hard-real-time version is supported by a dedicated Ethernet chip developed by Siemens to achieve its microsecond-level response times.

Though Ethernet performs well between devices, Caro believes it’s not well-suited for field device control, for example, because its higher-power requirement means it can’t be made intrinsically safe. He adds Ethernet also can’t compete with AS-interface or DeviceNet, which are optimized to serve at the device level, and are designed to work with single-bit transmitters.

Wireless Evolves, Accelerates
For several years, the Institute of Electrical and Electronics Engineers (IEEE) has been drafting its IEEE 802.11 and 802.15-based series of wireless standards. Some of these, such as ZigBee, WiFi, and Bluetooth, have gained their own following and momentum in communications, consumer products, and related applications. Most of the 802.11 group were recently gathered, and again updated in the newly approved 802.11n standard.

Meanwhile, the ISA’s Wireless Systems for Automaton SP100 committee is working to draft a unified wireless standard. To this end, SP100 recently formed two standards working groups. The first, SP100.14, will define wireless connectivity standards optimized for the unique performance and cost needs of a range of industrial monitoring, logging and alerting applications. The second, SP100.11, will define wireless connectivity standards for applications optimized for, but not restricted to, the unique performance needs of control applications ranging from closed-loop regulatory control through open-loop manual control. Both groups say they’ll coordinate their activities to enable SP100 to provide a complete and integrated set of standards for industrial wireless applications.

These two SP100 working groups will define the upcoming wireless standard’s OSI layer, security, and management specifications, including network and device configuration. They’ll also determine specifications for wireless workers, wireless first responders, and wireless automation networks operating in automation and control environments. “The ISA-SP100 standard will allow compliant devices that have relatively low complexity, reasonable cost, and low power consumption to support long battery life where needed,” says Richard Sanders of ExxonMobil, co-chair of the SP100 committee. “The communication data rates must be sufficient to satisfy the range of needs typically associated with these classes.“

Despite these and other efforts, technical changes in this field might be happening too fast for a standard to be possible yet. “The big problem now is that no one wants a standard to restrict innovation, so wireless technologies might not be at a stage where a standard is doable,” says Caro. “It’s undoubtedly needed, but no one wants to deal with the ‘air protocol’ that would define how to modulate the electronic signal going through the air.

So, instead of fixing this air protocol, the standard likely will cover the rest of the frame in the seven-layer OSI model, and rely on software to decode signals coming in via whatever technique and with whatever frequency pattern.”

For example, Caro says the ZigBee wireless standard (IEEE 802.15.4) was developed for industrial/process automation, but it’s becoming obvious that it’s biggest market is home automation, and that’s what is driving that standard now. “ZigBee also was found to be inappropriate for industrial automation because it usually sleeps until an event occurs to extend battery life, and also because it’s optimized to work at 2.4 GHz where there’s a lot of potential interference,” he adds.

Likewise, Caro adds that the Blueooth wireless standard (IEEE 802.15.1) previously was limited by its available speed and distance, but now is being revamped with ultrawideband capabilities. These are expected to give it more power for greater range, as well as faster data processing, which could make it useful in industrial automation in a couple of years.

ASI

• Actuator Sensor Interface (AS-i) is supported by AS-i International
• Claims 12 million nodes installed worldwide via flat, two-wire cable in bus, ring, tree, or star topologies
• 62 slave devices maximum at 100 m maximum distance, or 300 m with repeaters
• Master/slave communication methods with cyclic polling
• Always-on transmission speed, which is the same as 4-20 mA
• Four-bit data packet size and 10 msec cycle time

DEVICENET, CONTROLNET, ETHERNET/IP

• DeviceNet, ControlNet, EtherNet/IP are based on the upper-layer Common Industrial Protocol (CIP), and are supported by ODVA and ControlNet International, which co-manage EtherNet/IP
• Claims 10 million nodes installed worldwide for CIP-based networks, with more than 1 million EtherNet/IP nodes  
• DeviceNet uses linear, trunkline/dropline topology; ControlNet has a linear, tree, star, or combination; and EtherNet/IP has active star with devices connected to an Ethernet switch
• DeviceNet uses twisted-pair physical media for signal and power; ControlNet uses coaxial or fiberoptic cable; EtherNet/IP typically uses 10/100Base T or 1 Gbps with Cat 5E, twisted-pair cable
• DeviceNet allows 64 nodes maximum; ControlNet allows 99 nodes maximum; EtherNet/IP has no practical device limit 
• Maximum distance is 500 m at 125 kbps for DeviceNet, depending on data rate; ControlNet’s maximum distance is 1 km via coax with two nodes, 3 km over fiber with 99 nodes, 30 km over fiber or coax with repeaters up to 99 nodes; EtherNet/IP has no distance limit 
• DeviceNet and ControNet’s communication method is producer/consumer with peer-to-peer and a master/slave option 
• Data Rate is 500 kbps, 250 kbps or 125 kbps for DeviceNet; 5 Mbps for ControlNet; 10/100 Mbps and 1 Gbps for EtherNet/IP 
• Data packet size is 0-8 bytes variable for DeviceNet; 0-510 bytes variable for ControlNet; 0 to 65,511 bytes variable for EtherNet/IP    

FOUNDATION FIELDBUS

• Foundation fieldbus H1 and High-Speed Ethernet (HSE) are supported by the Fieldbus Foundation
• Claims an installed base of more than 600,000 nodes in 9,000 systems, and growing by approximately 125,000-150,000 nodes annually
• H1 typically uses twisted-pair wiring in a star or bus topology; HSE uses twisted-pair or fiberoptic media in a star topology
• Maximum devices for H1 is 16 devices per segment, depending on performance needs, and up to 65,000 segments; HSE has no device limit due to IP addressing
• H1’s maximum distance is 1.900 km at 31.25 kbps and 100 m at 100 Mbps on twisted-pair; HSE’s maximum distance is 2 km at 100 Mbps using full-duplex, fiberoptic cable
• H1 and HSE use client/server, publisher/subscriber, event notification communication methods
• Data packet size for H1 is 128 octets, with 256 maximum overhead, but this dimension varies for HSE because it uses TCP/IP
• H1’s cycle time usually is less than 500 msec, depending on individual applications; HSE’s cycle time is less than 100 msec

HART

• HART (highway-addressable, remote transducer) field communications protocol is supported by the HART Communication Foundation
• Claims more than 20 million nodes installed worldwide via 4-20 mA wiring in point-to-point topology for simultaneous analog/digital communication, point-to-point for digital only, multidrop for digital only (up to 32 devices), and intrinsically safe with appropriate barriers
• One device maximum for point-to-point or 16 devices maximum for multi-drop, which is derived by the noise calculation. A network can have more than 16 devices if it meets the specification’s noise calculations, but those that exceed these limits might have degraded communications.
• Maximum distance for twisted-pair is 10,000 ft for one device and 5,000 ft for multiple devices
• Traditional analog, 4-20 mA communications, as well as simultaneous encoded digital, FSK based on the Bell 202 telecomm standard, PSK, high speed HART-ITU (CCITT) V.27
• 1,200 bps transmission speed, and 9,600 bps for high-speed HART
• Data packets include one start bit, eight data bits, one odd-parity bit, one stop bit, as well as two-dimensional error checking with device status in every reply
• Two or three transactions per second cycle time for diagnostic information and non-primary variables; three or four transactions per second in “burst mode,” and instantaneous analog transmission of primary variables

MODBUS

• Modbus Serial (RTU/ASCII), Modbus Plus (proprietary to Schneider Electric), and Modbus TCP/IP were developed by Modicon and Schneider, and are supported by Modbus-IDA
• Uses twisted-pair, RS-232, and RS-485 wiring in linear, line, star, and tree topologies with segments
• Modbus Serial can address a maximum of 247 devices; Modbus TCP/IP allows unlimited addressing
• Maximum distance is 100 m between switches for Modbus TCP/IP via Cat5 copper wiring
• Modbus uses a master/slave or client/server communication methods
• Transmission properties include 1 Mbps for Modbus Plus; 300 bps-38.4 kbps for RTU/ASCII; 100 Mbps for TCP/IP
• Data packet size is variable for Modbus Plus; 0-254 bytes for RTU/ASCII; 1,500 bytes for TCP/IP

PROFIBUS

• Profibus-PA, Profibus-DP, Profinet, Profinet for Motion Control, and ProfiSafe were developed by Siemens AG and are supported by the Profibus Nutzerorganisation e.V. and the Profibus Trade Organization
• Claims 17 million nodes in installed base
• Uses twisted-pair or fiberoptic cabling in line, star, ring, or bus topologies
• Maximum devices are generally 127 nodes in four segments with three repeaters, plus three masters; Profibus-PA is limited by current restrictions to 15 devices per segment; Profinet allows unlimited devices; and Profisafe has application-specific limits
• Maximum distance is typically 100 m between segments at 12 Mbps, or 12 km with fiber
• Master/slave, peer-to-peer communication methods
• Transmission properties include 1.5 or 12, Mbps for Profibus DP; 31.25 kbps for Profibus PA; 100 Mbps for Profinet
• 256-byte data packets, including 244 bytes of content data
• Configuration-dependent cycle times of less than 2 msec, as well as 1 and 10 msec for Profinet versions