The integration of Ethernet and wireless interfaces into microcontrollers makes networking even easier in industrial automation.
Every line of microcontrollers includes a model with at least one Ethernet interface. That's why it isn't surprising to find Ethernet up and down the industrial control pyramid (Fig. 1).
Ethernet has always been found in the upper reaches where management functions occur. But lately, it's been moving down into the fieldbus realm, which once was dominated by more than half a dozen high-speed serial interfaces like Modbus and Profibus.
Merging this plethora of communications systems into a single Ethernet standard would have been a laudable goal, though there's zero chance that will happen. Still, the list of Ethernet-based, industrial-control implementations is shorter than the list of fieldbus implementations (see the table).
Even the one attempt in 2000 to come up with a consolidated fieldbus standard resulted in the IEC fieldbus standard, 61158. Its multiple protocol sets included Foundation Fieldbus H1, ControlNet, Profibus, P-Net, Foundation Fieldbus HSE (High Speed Ethernet), Interbus, and WorldFIP.
Why are there so many Ethernet options? Reasons range from the need for compatibility and migration options for older technology to tradeoffs between using standard Ethernet implementations, or versions that incorporate extensions to the standard to implement real-time support. Yet cooperation may prevail when it comes to interchange and definition standards.
The Fieldbus Foundation, Profibus, and the OPC Foundation support the International Electrotechnical Commission (IEC) 61804-3 international standard on Electronic Device Description Language (EDDL). The ISA (Instrumentation, Systems, and Automation Society) SP104 committee will republish the IEC standard as an American National Standard Institute (ANSI) standard.
Approaches that extend Ethernet typically require custom Ethernet controllers. Then, however, they won't be suitable for off-the-shelf microcontrollers with on-chip Ethernet interfaces. That's because it's unlikely the real-time extensions could be implemented with anything short of an FPGA or ASIC.
Typical TCP/IP Ethernet implementations have latencies on the order of 1 to 2 ms for 100BaseT. Worse for real-time applications, Ethernet uses CSMA/CD (Carrier Sense Multiple Access with Collision Detection). This means one network node can step on the transmission of another. Ethernet recovers gracefully, but neither transmission succeeds and both must be re-sent.
This could have catastrophic results in a real-time system. Also, it's one reason why Ethernet often is mixed with other fieldbus implementations such as CAN, Modbus, and Profibus, which can provide isochronous, real-time support.
Some Ethernet-related standards tend to go across most of the industrial Ethernet implementations, like the IEEE-1588 time synchronization standard and TCP/IP, of course (see "Keeping Time Ethernet-Style" at www.electronicdesign.com, Drill Deeper 13807). Existing Power over Ethernet (PoE) standards are being employed as well.
Yet PoE doesn't always suit industrial requirements, which are usually more demanding when compared to office environments (see "Industrial Power Over Ethernet," p. 46). Also, 24 V is the industrial standard, while the existing PoE is the 48 V found in most communication systems.
Industrial Ethernet implementations that remain true to the Ethernet standard work with 802.11 Wi-Fi. But real-time enhancements are unlikely to propagate through the air with the desired results.
Complicating wireless industrial controls are new wireless standards such as 802.15.4 and ZigBee (see "Industrial 802.15.4, ZigBee, And Wi-Fi," p. 44). This discussion is best left to another day, but keep in mind that industrial Ethernet likely will be the backbone for wireless sensor and control networks.
The key to industrial Ethernet and Wi-Fi is determinism, especially in process control (see "Ethernet Helps Achieve Real-Time And Determinism In Plant-Floor Control," Drill Deeper 13803).
The major industrial Ethernet architectures include those from the Open Device Vendor Association (ODVA), Modbus-IDA, Foundation Fieldbus, PI International (ProfiNet), Ethernet-Powerlink (EPL), EtherCAT, and SERCOS (SErial Realtime COmmunications System). Each has unique features and reasons for taking a particular approach to deterministic communication and interoperability.
ODVA's approach melds the DeviceNet and ControlNet fieldbus systems with Ethernet (Fig. 2). DeviceNet typically runs on a controller-area network (CAN), while ControlNet has its own platform for providing real-time communication.
Tying this all together is the CIP, the Common Industrial Protocol. CIP provides a consistent messaging infrastructure. Ethernet/IP uses CIP and a standard Ethernet stack. Real-time services, then, typically reside in a DeviceNet or ControlNet subnet, with Ethernet providing the infrastructure backbone.
Modbus-IDA takes a similar approach using the same protocol in Modbus-TCP as the Modbus fieldbus. Modbus messages are encapsulated in an Ethernet packet (Fig. 3). As with ODVA's CIP, Modbus-TCP provides interoperability but not the tight, real-time response. This must be balanced with the speed of Ethernet, which is faster than most fieldbus implementations. Therefore, Ethernet's suitability will depend on the application.
Foundation Fieldbus HSE (high-speed Ethernet) is similar to Modbus-TCP and Ethernet/IP, since standard Ethernet stacks and hardware are employed, which tailors them off-the-shelf Ethernet microcontrollers. But Fieldbus H1—the legacy serial control bus—still is part of the infrastructure, providing control of time-critical devices (Fig. 4). A bridge node links The H1 and HSE subnets. Ethernet/IP, Modbus-TCP, and Fieldbus HSE have a response time on the order of 1 ms, even using standard Ethernet.
REAL-TIME INDUSTRIAL AUTOMATION
Using off-the-shelf parts, such as gateways, routers, and switches, is definitely an advantage. However, standard Ethernet suffers from timing variations that can make it unworkable in a real-time environment.
IEEE 1588 time synchronization can answer some of these problems, but it won't address where data must move between two points in the network at a specific time. Therefore, it's necessary to look at Ethernet modifications, and that's usually at the hardware level.
ProfiNet, EPL, EtherCat, and SERCOSIII take the non-standard Ethernet approach. In many cases, the router or switch used on a subnet can be off-the-shelf. Typically, though, all nodes within a subnet must be compatible with the standard employed.
Likewise, normal Ethernet traffic can be routed on or across these non-standard networks. However, a specialized gateway, router, or switch generally is used at the boundary between standard and non-standard Ethernet subnets.
ProfiNet exploits custom hardware to split Ethernet traffic into cycles that are further split into real-time and non real-time traffic (Fig. 5). The real-time portion is split further into isochronous and soft real-time sections. Each section has an allocated, fixed amount of time that's controlled via a subnet master. The soft real-time section typically is used for asynchronous messages, such as alarms.
All real-time messages fit into a time-critical slot, so that each device on the network must maintain synchronization. The non-real-time section is employed for normal Ethernet traffic where collisions must occur. All packets for this cycle, though, must be transmitted within the specified timeframe. Even retries must be deferred if they can't be completed within the current cycle.
ProfiNet works with the Profibus fieldbus. Both are managed by PI International. As with CIP, Modbus, and Foundation Fieldbus, the Ethernet and fieldbus implementations work together at the upper protocol level so data can be moved across the network as necessary.
Ethernet-Powerlink (EPL) uses a similar approach, but a master manager node handles the synchronization by sending packets at the appropriate time (Fig. 6). Each device checks for these packets and responds accordingly with standard Ethernet traffic occurring during the asynchronous interval. The idle time between cycles is small but similar to that found in other time-critical Ethernet implementations.
EPL's advantage is that it uses standard Ethernet equipment and interfaces, but the protocol stacks must be modified to manage the additional handshaking. It can handle transmission cycles of 200 ms with station synchronicity jitter of 1 ms. For even tighter timing constraints, designers can turn to EtherCAT or SERCOS-III. These are better by an order of magnitude. Keep in mind that they require custom hardware at each node to handle more critical timing issues.
EtherCAT goes one step further by packing multiple messages within a single Ethernet packet (Fig. 7). The packets are forwarded through each node that inserts or extracts information. EtherCAT also uses an FPGA to handle its more sophisticated Ethernet implementation. It's often worth the extra cost, since EtherCAT is the implementation with the fastest response and cycle time.
EtherCAT can handle regular Ethernet traffic as well. EtherCAT routers, gateways, or switches are required for traffic to traverse non-EtherCAT subnets. Time synchronization isn't available on these other subnets, but it's still possible to send EtherCAT packets with multiple data messages across non-EtherCAT subnets, thereby improving overall transmission efficiency.
First-generation SERCOS, which supported 2- and 4-Mbit/s transfer rates, mainly was used in machine tool applications. SERCOS-III follows the other industrial Ethernet implementations with 100-Mbit/s Fast Ethernet support. On the other hand, it diverges from the standard hub architecture of Ethernet and implements a dual, counter-rotating, self-healing ring.
This eliminates the need for off-the-shelf compatibility. It also means custom implementations at the node level. SERCOSIII is designed to provide better performance, as well as compatibility with SERCOS. Moving conventional Ethernet traffic into and out of these loops is possible, but SERCOS-III likely will remain on the industrial floor with a standard Ethernet as a corporate backbone. A linear version of SERCOS-III is possible, but it lacks the redundancy of the dual loop.
NOTHING BUT ETHERNET?
It isn't feasible for many applications to employ only Ethernet. Remember that Ethernet is faster than the legacy fieldbus implementations, so even industrial Ethernet versions that lack heavy duty, real-time performance will be more than adequate to meet many industrial-control tasks.
Yet the performance and capacity of Ethernet-equipped microcontrollers continue to grow, making it possible to easily incorporate both non-standard or extended Ethernet protocol stacks, as well as the higher-level protocols such as CIP. These are often larger than the basic communication protocol stacks, but their size can vary depending on the features that will reside on a node.
Still, Ethernet is likely to remain a complementary network, because many control applications are neither power nor performance restricted. Also, fieldbus interfaces like CAN will be more than sufficient for industrial control needs at the bottom of the pyramid. Ethernet may exist all through the hierarchy, allowing mixtures like CANopen, SERCOS on EPL, or Modbus-TCP.
Of course, the possibility of various standards to coexist must be tempered by the vendor implementations that often add a proprietary twist, which prevents interoperability in a mixed-vendor environment. This prevailed with the legacy fieldbus standards and has occurred at the Ethernet level.
Usually, it leads to a vendor-homogeneous environment—at least at the subnet level, given the critical nature of most industrial control systems. Still, the use of a common standard such as Ethernet has brought vendors significantly closer to each other with respect to standards, simply because of the need for interoperability with other fieldbus protocol standards.
NEED MORE INFORMATION?
ControlNet International Ltd.