With the increasing desire and necessity to deploy the Internet everywhere, the need for Industrial Ethernet is on the rise. RS-232 and RS-485 data transmission no longer satisfy industrial customers. Rather, these customers demand the benefits of Ethernet connectivity.
The dual advantages of treating every data-acquisition node as an IP address or Web page, along with its extended reach and data rate, make Ethernet an ideal communication platform for industrial customers. Ethernet is the most widely deployed network available today; it simply makes sense for tomorrow's industrial network to include more of it.
Ethernet's only weakness in industrial communications is that it was never designed to handle real-time data transfer, which is essential for automation and motion control. Therefore, the challenge is to provide real-time capability while taking advantage of Ethernet's cost and simplicity. But just like Fieldbus, a battle for supremacy has led to multiple standards instead of one common standard. All of these standards, though, have adopted Ethernet as the physical layer (PHY).
Ethernet isn't strictly a protocol in itself, as it only defines the Layer 1 (physical) and Layer 2 (data link) of a network topology. The seven-layer Open Systems Interconnection (OSI) network model requires the upper transport Layers 3 and 4 (for example, TCP/IP) and application layers to specify the complete protocol (Fig. 1). Each standard for Ethernet in an industrial environment differentiates itself in its unique approach to handling the network protocol's higher application layers.
Network standards such as PROFInet, EtherCAT, EtherNet/IP, Modbus, and Powerlink have evolved to address predictable data delivery using Layers 3 and up in the OSI network model. Ethernet can be considered a means of deployment for most of these standards, with the end application determining the best protocol.
Generally, designers implement real-time performance by time-multiplexing the communication on the network between the different nodes. Critical isochronous data transfer is performed at the start of the cycle, followed by non-critical TCP/IP traffic. Such methods guarantee the real-time performance of the network while allowing compatibility to "office" TCP/IP networks.
When Ethernet is introduced into an industrial setting, an existing Ethernet switch or hub often is used to distribute Ethernet in a star configuration from a multiport switch to many destinations. Customers sometimes need more nodes than that available on a multiport switch. Or, they need to locate distributed data-acquisition nodes at distances greater than the 100-m limit from the switch specified for Ethernet over copper (10BaseT, 100BaseTX). Sometimes, 100BaseFX over optical fiber is used to address greater distances, and it typically can extend the reach to 2 km.
However, designers also can "daisy-chain" copper networks to extend Ethernet's reach without going to the expense of installing a fiber-based system (Fig. 2). But, daisy-chaining creates two problems: variable latency of data through multiple switches, and the management of redundant network loops.
Addressing Variable Latency
To reduce latency jitter in the network, the Ethernet Powerlink Group (EPL) recommends using 100BaseTX/FX Ethernet Repeater Hubs. Real-time performance isn't possible using today's switches that employ Store and Forward architecture, which depends on packet size. This results in a possible latency deviation of up to 167 µs.
On the other hand, repeater hubs offer far lower latency. Yet repeater hubs have a major limitation — they're scarce, if not obsolete, compared to the more popular switches. This scarcity leads to an FPGA-based implementation with external Ethernet PHYs. Such an approach conflicts with the strategy to benefit from the falling prices of standard Ethernet devices. It also increases time-to-market and risk.
Some new devices, such as Micrel's KSZ8893 3-Port switch and KSZ8842 2-Port Ethernet Controller families with 8/16/32-bit generic bus or 32-bit PCI interface, offer a unique low-latency repeater mode. This repeater mode provides a maximum port-to-port latency of 310 ns and total deviation of a mere 40 ns, making it ideal for real-time critical applications.
Another approach to deterministic packet delivery uses higher-level protocols such as IEEE 1588. IEEE 1588 uses User Datagram Protocol (UDP) packets over Internet Protocol (IP) on the Ethernet network to supply network synchronization down to a microsecond. Such performance fulfills the stringent real-time requirements for motion-control applications. ProfiNet, EtherNet/IP, and the EtherCAT groups all adopted this standard for network synchronization. Figure 3 shows a typical hardware implementation of the IEEE 1588 functionality using an FPGA.
To achieve synchronization with the rest of the network, each node must determine which clocking source it should use — GPS or a local oscillator. All nodes perform what is known as the Best Master Clock algorithm to select timing. If the node is to be a master to many of the nodes in the ring, a high-precision source, such as the GPS device shown in Figure 3, is employed. If the node isn't designated as a master, it will extract timing from the network using the IEEE 1588 protocol. Failure to extract timing from the network will result in use of the on-board local oscillator.
The master is responsible for providing all of its slaves in the network with a notice of its position. If the slave doesn't receive any notice from the master, it will designate itself as the master. To synchronize the master and slaves, IEEE 1588 operates Precise Time Protocol (PTP) based on IP multicasting. A hardware implementation requires the FPGA and Switch Core to identify PTP packets. The FPGA will add a timestamp to the ingress and egress PTP packets. In the ingress direction, the switch will forward the incoming PTP packets directly to the CPU port. The timestamp point occurs after the Start of Frame (SOF), at the first bit of the Destination Address (DA).
The synchronization process divides into two phases. First, the offset time between the master and slave is calculated and corrected. To perform this function, the master continuously transmits a unique message to the slave at defined intervals, usually every two seconds. The second phase of the synchronization process is the delay measurement. The slave will send a Delay Request to the master, which is returned, and the round-trip delay is calculated using the timestamps. The assumption here is that the delay between master and slave is always symmetrical. Figures 4a and 4b show an example of the Offset and Delay phases of the PTP synchronization process.