[3 pages 3096 words] Introduction Real-time electronic distributed control systems are an important development of the technological evolution.

. Electronics are employed to control and monitor the most safety-critical applications from flight decks to hospital operating rooms. As these real-time systems become increasingly prevalent and advanced, so does the demand to physically distribute the control in strict real-time. Thus there is a need for control network protocols that can support the application's stringent real-time requirements. Real-time networks must provide a guarantee of service so that they will consistently operate deterministically and correctly. Ethernet, as defined in IEEE 802.3, is non-deterministic and thus it is unsuitable for hard realtime applications. The media access control protocol, CSMA/CD with its truncated binary exponential backoff algorithm, does not allow the network to support hard real-time communication as it incorporates random delays and allows for the possibility of transmission failure. Decreasing costs and increasing demand for a single network type, from boardroom to plantfloor, have led to the development of Industrial Ethernet. The desire to incorporate a real-time element into this increasingly popular single-network solution has led to the development of different real-time Industrial Ethernet solutions. Fieldbus networking standards have failed to deliver an integrated solution. Typically the emerging real-time Industrial Ethernet solutions complement the fieldbus standards, for example by using common user layers. This course covers an introduction to real-time systems along with a study of Ethernet with emphasis on its suitability as a real-time network. Module 402 provides a study of the real-time Industrial Ethernet solutions available today. Real-Time Introduction Real-Time (RT) systems are becoming increasingly important, as industries focus on distributed computing in automation, see Figure 1. As computing costs decrease, and computing power increases, industry has become more dependent on distributed computers to deliver efficiency and increased yield to the production lines. Real-Time does not automatically mean faster execution but rather that a process is dependent on the progression of time for valid execution.

Figure 1 Distributed Real-Time Processing

RT systems are those whose correct execution depends not solely on the logical validity of data but also on its timeliness. A correct RT system will guarantee the successful operation of a system so far as its timely execution is concerned. RT systems are generally broken into two main sub-categories: hard and soft. Hard Real-Time (HRT) systems are those in which incorrect operation can lead to catastrophic events. Errors in HRT systems can cause accidents or even death. Such systems are typically found in flight control or train control systems, where an error could potentially incur loss of life. Soft Real-Time (SRT) systems, on the other hand, are not as brittle. An error in a SRT system, while not encouraged or appreciated, will not cause loss of property or life. SRT systems are not as safety-critical as HRT systems, and should not be employed in a safety-critical situation. Examples of SRT systems would be online reservation systems, or streaming multimedia applications where slight occasional delays might cause small inconvenience but will not have serious impact. Jobs are the real-time system's building blocks. Each real-time job has certain temporal quantities (Figure 2) associated with them:
1. Release Time, 2. Ready Time, 3. Execution Time, 4. Response Time, 5. Deadline.

Figure 2

The Release Time of a job is when the job becomes available to the system. The Execution Time is the time it takes for a job to be completely processed. The Response Time is the interval between the release time and the completion of the execution. The Ready Time is the earliest time the job can start executing (always greater or equal to the Release Time). The Deadline is the time by which execution must be finished. If execution is not complete by the deadline, the job is late. A job's deadline can be either hard or soft, indicating the job's temporal dependence. As mentioned earlier, a missed hard deadline can have serious consequences for correct system operation. All real time systems have a certain level of jitter. Jitter is a variance on the actual timing of the above times. In a real-time system, jitter should be measurable within a +/ interval so that the system performance can still be guaranteed. For textbook information on real-time systems, refer to [1]. To develop a real-time distributed system, where computers are interconnected, it is vital to employ a network that can provide communication between the various distributed computers in a reliable and timely fashion. Distributed processors running real-time applications must be able to inter-communicate via a real-time protocol, otherwise the temporal quality of their work is lost. Real-Time Communication networks are like any real-time system. They can be hard or soft, depending on the system requirements and their 'jobs' include message transmission, propagation, and reception. There are a number of real-time control networks available and employed in industry, but none have the popularity or bandwidth capabilities of Ethernet. In the following section, we will discuss the demand for a real-time Ethernet solution.
The Demand for Real-Time Ethernet The demand for Ethernet as a real-time control network is increasing (see Figure 3) as manufacturers realise the benefits of employing a single network technology from the boardroom to the plant floor. Decreased product costs coupled with the possibility of overlapping training and maintenance costs for information, field level, control and possibly device networks would greatly reduce the expense to the manufacturers.

Figure 3 Predicted Sales of Industrial Ethernet nodes

Ethernet offers many benefits at the real-time control level over existing solutions. As a control network, 10 Gbps Ethernet offers bandwidth that is almost 1000x faster than today's comparable fieldbus networks

(such as the 12 kbps of PROFIbus) and can also support real-time communication. Distributed applications in control environments require tight synchronisation so that the delivery of control messages can be guaranteed within defined message cycle times. Typical cycle times for control applications are listed in Table 1. Traditional Ethernet and fieldbus systems are not capable of meeting cycle time requirements below a few milliseconds, but the emerging real-time Industrial Ethernet solutions allow cycle times as low as a few microseconds. Typical Cycle Times for Control Applications Control Application Low speed sensors (e.g. temp. pressure) Drive control systems Motion control (e.g. robotics) Precision motion control High speed devices Electronic ranging (e.g. fault detection) Typical Cycle Time Tens of milliseconds Milliseconds Hundreds of microseconds Tens of microseconds Microseconds Hundreds of nanoseconds

Table 1 Along with the increased bandwidth and tight synchronisation, real-time Ethernet gives manufacturers the security of using a physical and data-link layer technology that has been standardised by both the IEEE and the ISO. Ethernet can provide reduced complexity with all the attributes required of a field, control or device network - in operations having up to 30 different networks installed at this level [2]. Furthermore, Ethernet devices can also support TCP/IP stacks so that Ethernet can easily gate to the Internet. This feature is attractive to users since it allows remote diagnostics, control, and observation of their plant network from any Internet-connected device around the world with a license-free web browser. Although Ethernet does introduce overhead through its minimum message data size (46 bytes), which is large in comparison to existing control network standards, its increased bandwidth, standardisation and integration with existing plant technology should generate good reasons to consider Ethernet as a control network solution.

Ethernet and CSMA/CD Ethernet, as defined in IEEE 802.3, is unsuitable for strict real-time industrial applications because its communication is non-deterministic. This is due to the definition of the network's media access control (MAC) protocol, which is based on Carrier Sense Multiple Access/ Collision Detection (CSMA/CD), see Figure 4. The implementation described in the standard uses a truncated binary exponential backoff algorithm.

Figure 4 IEEE 802.3 CSMA/CD with Truncated Binary Exponential Algorithm Flow Chart With CSMA/CD, each node can detect if another node is transmitting on the medium (Carrier Sense). When a node's Carrier Sense is on, it will defer transmission until it determines that the medium is free. If two nodes transmit simultaneously (Multiple Access), the network experiences a collision and all frames are destroyed. Nodes can detect collisions (Collision Detection) by monitoring the collisionDetect signal provided by the physical layer. When a collision occurs, the node transmits a jam sequence. When a node begins transmission on the medium there is a certain time interval, called the Collision Window, during which a collision can occur. This window is large enough to allow the signal to propagate around the entire network/segment. When this time window is over, all (functioning) nodes should have their Carrier Sense on, and so would not attempt to commence transmission. When a collision occurs, the truncated binary exponential backoff algorithm is employed at each 'colliding' node. The algorithm works as follows:

Initially: n:=0, k:=0, r:=0. When a collision occurs, the node enters the algorithm: It increments n, the Transmit Counter, which counts the number of sequential collisions experienced by a node. If n > 16, (16 unsuccessful successive transmission attempts), transmission fails and the higher layers should be informed. If n <= 16, select a number from the set k = min(n, 10) (Truncation). A random number, r, is selected from the set (0,1,2,4...2 k) (Exponential and Binary). The node then waits r x slot_time before recommencing a transmission attempt.

One advantage of this backoff algorithm is that it controls the medium load. If the medium is heavily loaded, the likelihood of collisions increases, and the algorithm increases the interval from which the random delay time is chosen. This should lighten the load and reduce further collisions. Ethernet's CSMA/CD with truncated exponential binary algorithm introduces the possibility of complete transmission failure as well as the possibility of a random transmission time, hence IEEE 802.3's nondeterminism and unsuitability for real-time communications especially on heavily-loaded networks. Redefinition of the media access protocol would solve the problem but would leave the new nodes unable to interoperate with legacy Ethernet nodes. Ethernet is non-deterministic only if collisions can occur. To implement a completely deterministic Ethernet, it is necessary to avoid all collisions. A collision domain is a CSMA/CD segment where simultaneous transmissions can result in a collision. The probability of collision increases with the number of nodes transmitting on a single collision domain. Completely avoiding collisions in the Ethernet network, therefore, gives a network with a relatively large bandwidth and popularity an opportunity to be developed for the real-time domain. The most common way of implementing a collision-free Ethernet is through the use of hardware. A solution where two or more nodes compete for medium access to a network segment is called Shared Ethernet. Full & Half Duplex Ethernet When Ethernet was standardised in 1985, all communication was half duplex. Half duplex communication restricts a node to either transmit or receive at a time but not perform both actions concurrently. Nodes sharing a half duplex connection are operating in the same collision domain. This means that these nodes will compete for bus access, and their frames have the potential to collide with other frames on the network. Unless access to the bus is controlled at a higher level and highly synchronised across all the nodes co-existing on the collision domain, collisions can occur and real-time communication is not guaranteed. Full duplex communication was standardised for Ethernet in the 1998 edition of 802.3 as IEEE 802.3x. With full duplex, a node can transmit and receive simultaneously. A maximum of two nodes can be connected on a single full duplex link. Typically this would be a node-to-switch or switch-to-switch configuration. (The set-up of Figure 5 is for illustration purposes, and unlikely to be implemented in a practical form). Theoretically, employing full duplex links can double the available network bandwidth taking it from 10 Mbps or 100 Mbps to 20 Mbps or 200 Mbps respectively, but in practice it is limited by the internal processing capability of each node. Full duplex communication provides every network node with a unique collision domain. This operation completely avoids collisions and does not even implement the traditional Ethernet CSMA/CD protocol.

Figure 5 Half-Duplex vs. Full-Duplex Since full duplex links can host a maximum of two nodes per link, such technology is not viable as an industrial real-time solution without the use of fast, intelligent switches capable of connecting links/segments as a network with single collision domains for each node i.e. Switched Ethernet. Full Duplex, Switched Ethernet With shared Ethernet, nodes compete for access to the media in their shared collision domains. The use of a destructive non-deterministic bus access scheme, such as CSMA/CD, makes shared Ethernet unviable as a real-time network solution. The most popular method of collision-avoidance, which produces a deterministic Ethernet, is to introduce single collision domains for each node because this guarantees the node exclusive use of the medium, thereby eliminating access contention. This is achieved by implementing full duplex links as well as hardware devices such as switches and bridges. These devices have the ability to isolate collision domains through the segmentation of the network because each device port is configured as a single collision domain, see Figure 6. Although, both switches and bridges can provide this segmentation, switches are more flexible because they can cater for more segments. Switches Switches are data-link layer hardware devices that enable the creation of single-collision domains through network segmentation. While a bridge operates like a switch, it only contains two ports. In contrast, switches contain more than two ports, where each port is connected to a segment (collision domain). Switches can operate in half duplex or full duplex mode. When full duplex switches are used along with full duplex capable nodes, there will be no collisions on any segment. Today's switches are more intelligent and faster than previously and with careful design and implementation could be used to achieve a hard real-time communication network using IEEE 802.3.

Figure 6 Switched Full Duplex vs. Shared Ethernet Although switches are data-link layer devices, today's switches are also capable of performing switching functions based on data from layers 3 and 4. Layer 3 switches can operate on information provided by IP such as IP version, source/destination address or type of service. Layer 4 devices can switch depending on the source/destination port or even information from the higher-level application. Further refinements to the IEEE 802 standards, specifically for switch operations, are 802.1p and 802.1Q. IEEE 802.1p, which was incorporated into the IEEE 802.1D [3] standard brings Quality of Service (QoS) to the MAC level and also defines how these switches should deal with prioritisation priority determination, queue management etc. This is achieved through the introduction of a 3-bit priority field into the MAC header, which gives 8 (07) different priority levels decoded and upheld by switches or hubs. As defined, 802.1p can support priorities on topologies that are compatible with its prioritisation service, but to implement prioritisation on Ethernet, which does not include a prioritisation field in its frame format, it uses 802.1Q. IEEE 802.1Q [4] defines an architecture for virtual bridged LANs, the services provided in virtual bridged LANs, and the protocols and algorithms involved in the provision of those services. 802.1Q allows Ethernet frames to support VLANs (Virtual Local Area Networks) limiting broadcast domains and thereby reducing broadcast traffic on the entire LAN. This is achieved by the insertion of 4 bytes between the source address field and the length/type field in the Ethernet frame's header, which among other identifiers, includes the identifier of the originating VLAN. Also included is a 3-bit prioritisation field required for 802.1p to implement prioritisation on Ethernet, see Figure 7.

Figure 7 Extended Frame Format for IEEE 802.1Q

For a real-time Industrial Ethernet application, an 802.1p/Q implementation has certain advantages: it introduces standardised prioritisation on Ethernet, allowing control engineers to implement up to eight different user-defined priority levels for their traffic. But these standards also have drawbacks including the extra hardware costs associated with the increased Ethernet frame length (1522 bytes), which introduces compatibility issues with legacy Ethernet networks. A real-time implementation using 802.1 p/Q would require full duplex, switched Ethernet. IEEE 802.1p/Q are acceptable for certain applications of real-time Ethernet in industry when switch 'through' time is predictable and an overload situation will not result in hard deadlines being missed. Although switches can certainly provide real-time deterministic communication on Ethernet and are the backbone of the Industrial Ethernet solutions available today, they have drawbacks. They are costly a major influence on cost-conscious industries. They are powered devices capable of failure (an influential major factor for hard real-time control operations). And sometimes the operational predictability is not guaranteed by the manufacturer. A study on switches for real-time applications is available at [5]. TCP/UDP/IP for Real-Time Ethernet With industrial Ethernet, the trend is to define an application layer environment along with the TCP/IP protocol, to realise an industrial automation networking solution. Although some real-time Ethernet solutions e.g. EtherNet/IP perform all their communication, real-time included, through the TCP/UDP/IP stack, most solutions although they provide compatibility with TCP/IP, do not employ this protocol for realtime communication. In a system like EtherNet/IP, TCP is used for initialisation and configuration (explicit) messages while UDP, with its reduced overhead, is used for real-time I/O (implicit messaging). Typically, for real-time Industrial Ethernet applications it is sufficient that the solution be compatible with TCP/IP and the protocol suite is bypassed for all real-time communication. The ability of a real-time Ethernet solution to intercommunicate with an office-based system is paramount to achieve the Ethernettechnology plant of the future. Conclusion This module has covered a broad introduction to Ethernet for real-time. It has described concepts that will be developed upon in the follow-up module: Real-Time Ethernet II. The follow-up module will provide detail on existing real-time Ethernet solutions such as PROFInet V3, ETHERNET Powerlink and EtherNet/IP along with an important supporting technology for clock synchronisation: IEEE 1588.

References [1] Liu, J. Real-time Systems; Prentice Hall Inc., 2000; ISBN: 0130996513. [2] Crockett, N. "Industrial Ethernet is ready to revolutionise the factory Connecting the factory floor", Manufacturing Engineer, Volume: 82, Issue: 3, June 2003, pages 4144. [3] ISO/IEC 15802-3: 1998, ANSI/IEEE Std 802.1D, 1998 Edition. Information technology telecommunications and information exchange between systems local and metropolitan area networks common specifications. Part 3: Media Access Control (MAC) bridges. [4] IEEE Std 802.1Q-1998 IEEE standards for local and metropolitan area networks Virtual bridged local area networks. [5] Georges, J.-P.; Rondeau, E.; Divoux, T "Evaluation of switched Ethernet in an industrial context by using the Network Calculus", Factory Communication Systems, 2002. 4th IEEE International Workshop on 2830 Aug. 2002, pages 1926.

[ 6 pages 3,023 words]

INTRODUCTION In "Real-Time Ethernet I," Module 401, we introduced the basic concepts of Ethernet's capacity to deliver a real-time communication system. "Real-Time Ethernet II," Module 402, introduces some of the real-time solutions available to industry today: EtherNet/IP, PROFInet, EtherCAT and ETHERNET Powerlink. This module also provides an introduction to a single standard, IEEE 1588, that is growing in popularity amongst real-time Ethernet developers to provide sub-microsecond synchronization accuracy of distributed clocks over Ethernet. .

What is Ethernet/IP? EtherNet/IP (EIP, where the IP stands for Industrial Protocol) is an open application-layer protocol developed and maintained by CI (ControlNet International), ODVA (Open DeviceNet Vendors Association) and IEA (Industrial Ethernet Association). It is built on the existing IEEE 802.3 physical/data layers and TCP/UDP/IPgiving it optimal interoperability with most information-level networks. EIP offers a real-time (RT) solution when using strict guidelines, but is not deterministic. It uses the open objectoriented CIP (Control and Information Protocol) as its application layer the same layers 57 as both DeviceNet and ControlNetyielding full interoperability with them (Figure 1).

Figure 1 Ethernet/IP Stack

CIP [1] is a flexible and scalable automation protocol well-suited to distributed systems with properties such as: object-orientation, Electronic Data Sheets and device profiles. EIP with CIP is not an RT protocol. To achieve RT for EIP, CIPSync (a high-speed CIP synchronization solution) is employed. CIPSync is based on IEEE 1588. Using 100 Mbps Switched Ethernet, CIPSync can deliver synchronization accuracy of better than 500 nanoseconds between devices [ 2] although jitter introduced by the protocol stack will still be an issue. EIP uses both TCP and UDP with IP for communication. When a connection-oriented exchange is preferred, e.g. at initialization, TCP is used (Explicit Messaging). Explicit Messaging contains protocol information and service information but does not have strict timing requirements; therefore, it is sufficient to use the slower, yet guaranteed TCP protocol. For RT traffic, EIP uses the unicast and multicast capabilities of UDP to implement the producer/consumer model of communication popular with control applications. Implicit messages contain no commands, only data. The meaning of this data is configured at initialization, reducing run-time processing in the nodes. [PD1] Typical traffic on an EIP network is

cyclic (although CIP also specifies polled, change-of-state and strobed traffic). Network collisions are avoided by switches, and EIP is generally implemented in a star topology. Unlike other RT solutions, EIP uses UDP/IP for RT communication, adding jitter and non-determinism. If this jitter is quantifiable and does not infract on the system model, the system can still be RT but will be unsuitable for fast and hard RT systems like motion control. Specific advice relating to implementing an RT version of EIP is offered in [3], and although EIP with CIP is not an RT protocol, the currently achievable end-to-end response time in an EIP control system of eight producers and one consumer was determined to be 7 mswhen implemented with the recommendations in the following paragraph. One recommendation in [3] introduces VLANs and locates all devices sharing time-critical data in the same VLAN so RT multicast EIP traffic will not need to exit the VLAN. Another recommendation is to use the routing functionality of Layer 3 switches and set the TTL of IP multicasts to 1. This keeps RT EIP traffic in its subnet and keeps normal traffic out. Hence, according to [ 3], it is possible to achieve RT performance between EIP devices (using CIP) if the following guidelines are met: 1. Devices sharing RT information must co-exist in the same subnet. 2. The EIP segment must be isolated from the main network multicast traffic. EIP use of CIP with commercial off-the-shelf components, including TCP/UDP/IP, for all devices will benefit certain customers while an EIP solution using CIPSync will be more beneficial to those requiring sub-microsecond synchronization accuracy. EIP can cater for many RT systems where the device count is limited, device synchronization is in the order of microseconds and determinism is not required.

(No part of this article may be reproduced without the written consent of the Industrial Ethernet University.)

EtherCAT

EtherCAT (Ethernet for Control Automation Technology) is the motion-control RT solution from Beckhoff. It can process 1000 I/Os in 30 s [4], but requires full-duplex. It can use copper or fiber-optic cables. EtherCAT is based on the master/slave principal and can interoperate with normal TCP/IP-based networks and other Ethernet-based solutions such as EIP or PROFInet. It also supports any Ethernet topology, including the bus. The EtherCAT master processes RT data via dedicated hardware and software (Beckhoff currently use their PC-based TwinCAT OS and TwinCAT Y driver). In the future, further variations will be introduced that will also provide the same guarantees. The master prioritizes EtherCAT frames over normal Ethernet traffic, which is transmitted in gaps. The master controls traffic by initiating all transmissions. The telegrams are standard Ethernet, and the data field encapsulates the EtherCAT frame (an EtherCAT header and one or more EtherCAT commands). Each command contains a header, data and Working Counter (WC) field. Each Ethernet telegram can contain many EtherCAT commands realizing a higher bandwidth and more efficient use of the large Ethernet data field size and header (see Figure 2). The standard Ethernet CRC is used to verify message correctness.

Figure 2 EtherCAT Encapsulation The EtherCAT master fully controls its slaves. Its commands only elicit responses; slaves do not initiate transmissions. The two EtherCAT communication methods used are "Ether Type" or UDP/IP encapsulation. The "Ether Type" uses the type field (defined in Ethernet II), which is more commonly known as the length field in IEEE 802.3. The Ether Type implementation does not use IP, thus limiting EtherCAT traffic to the originating subnet. Encapsulating commands using UDP/IP allows EtherCAT frames to traverse subnets, but has drawbacks. The UDP/IP header adds 28 (20: IP, 8: UDP) bytes to the Ethernet frame and undermines RT performance through its non-deterministic stack. EtherCAT slaves range from intelligent nodes to 2-bit I/O modules and are networked via 100Base-TX, fibre optic cable or E-bus (depending on distance requirements). E-bus is an EtherCAT physical layer for Ethernet offering a LVDS (Low Voltage Differential Signal) scheme. Slaves are hot pluggable in any topology of branches or stubs. Multiple "slave rings" can exist on a single network if connected by a switch, (see Figure 3).

Figure 3 Sample EtherCAT Implementation EtherCAT slaves have integrated memory from 2 bits to 64 Kbytes. They appear to the Ethernet as a single device though actually comprising up to 65,535 devices. They are configured in an open-ring topology, with the Ethernet interface at the open end. Masters transmit commands to the MAC address of the first device. When the signal reaches the Ethernet/slave interface, it is converted to E-bus specifications (if E-bus is employed) and forwarded. A slave receives a telegram, processes it (in hardware) then forwards it to the next slave on the ring. This processing delays the telegram by an order of nanoseconds. The last slave returns the completed telegram, via the ring, to the master. On the return route, each slave amplifies and regenerates the signal. Each slave has two Tx & Rx interfaces, so bi- directional communication occurs without contention. In each EtherCAT command, the WC increments when a slave processes a command addressed to it, allowing the master to determine if each addressed slave is exchanging data, although correct data is not guaranteed. The FMMU (Field Memory Management Unit) of each configurable slave converts a logical address to a physical one, and that information is available to the master at initialisation. Thus, each slave needs a special ASIC (Application-Specific Integrated Circuit). On telegram reception, a slave determines if it is addressed, and then passes data to/from the telegram, incurring a delay of some nanoseconds. EtherCAT is also internally synchronized by a distributed clock algorithm (a simplified version of IEEE 1588) although external synchronization is achievable with IEEE 1588. EtherCAT is a fast RT Ethernet solution and deterministic if not used with UDP/IP or intermediate switches or routers between master and slaves.

ETHERNET Powerlink (EPL) EPL is a hard RT protocol based on Fast Ethernet. Like EtherCAT, it uses the Ethernet II Frame type field. EPL devices use standard Ethernet hardware with no special ASICs. EPL can deliver a cycle time of 200 s with jitter under 1 s. Its frame is encapsulated as illustrated in Figure 4.

Figure 4 Powerlink Encapsulation EPL uses cyclic communication with time-slot division and the master/slave model. One master (manager) is allowed per network. The master schedules all transmissions and is the only active station slaves transmitting on request. The four EPL cycle subdivisions are illustrated in Figure 5.

Figure 5 Powerlink Cycle During the Start Period, the EPL master broadcasts the "Start-of-Cyclic" (SoC) frame which synchronizes the slaves. The timing of this frame provides the only time base for the network synchronisation: all other frames are purely event-driven. After transmitting the SoC frame, the Cyclic Period occurs as the manager polls each station with a "Poll Request" frame. Only then does the slave respond with a "Poll Response" frame containing datahence, collisions are avoided. The slave broadcasts its response to all devices thus, inter-slave communication can occur. After successful polling of all slaves, the master broadcasts the "End-of-Cyclic" (EoC) frame, informing each slave that the cyclic traffic progressed correctly. The Asynchronous Period allows non- cyclic data transfers under master control. To transmit during this period, a slave must have informed the master in its "Poll Response" during the Cyclic Period. The master

builds a list of waiting slaves and employs a scheduler to guarantee that no send request will be delayed indefinitely. During the Asynchronous Period, standard IP datagrams can be transferred. Unlike PROFInet, EPL does not employ switches to avoid collisions or to provide the network synchronization; the master controls this. EPL networks can be built with standard hubs, and it is proposed that each device incorporate a hub for ease of bus implementation. Switches, although not prohibited, are not recommended for EPL because they add jitter and reduce determinism. Since the EPL network avoids collisions via time-controlled bus access, up to 10 hubs can be cascaded (an allowable exception to the 5-4-3 Ethernet rule). Currently, EPL devices demanding RT communication cannot co-exist on the same segment as non-RT Ethernet devices. However, EPL devices can operate as normal Ethernet devices. In Protected Mode, the RT segment must be separated from normal traffic by a bridge or router. In Open Mode, RT traffic shares the segment with normal traffic, but RT communication is compromised. In the next Powerlink version (V3), IEEE 1588 will be used to synchronize traffic across multiple RT segments providing a more distributed EPL implementation, but true RT segments will still contain only EPL devices. Unlike PROFInet where normal Ethernet and RT devices can co-exist and not affect RT traffic, EPL must be protected from non-RT communication through bridges or routers. Unlike PROFInet or EtherCAT, which need special ASICs, EPL employs standard Ethernet hardware. PROFInet PROFInet is a plant-wide fieldbus standard for distributed automation systems. It uses object-orientation and available IT standards (TCP/IP, Ethernet, XML, COM). PROFInet is also built on IEEE 802.3 and is interoperable with TCP/IPallowing it to be implemented on existing Ethernets. It is compatible with PROFIBUS-DP. PROFInet V1, has a response time of 10-100 ms. PROFInet-SRT (Soft Real-Time) allowed PROFInet to work with a factory automation cycle time of 5-10 ms, achieving RT solely in software. It uses TCP/IP and a dedicated software channel for RT communications. PROFInet-IRT brings a hard-RT element to the PROFInet protocols. The three PROFInet protocols allow differing degrees of RT. PROFInet for hard RT is PROFInet-IRT. PROFInet-IRT PROFInet IRT (Isochronous RT) was developed for systems requiring sub-microsecond synchronization, typically high- performance motion control systems. The benchmark for such a system is 1 ms cycle time, 1 s jitter accuracy, and guaranteed determinism [6]which IRT fulfils. Since software introduces jitter above 1 s, IRT (unlike SRT) is a hardware solution with highly synchronized Ethernet nodes. Using full-duplex switched Fast Ethernet, it divides the communication cycle into a standard TCP/IP open channel and a deterministic RT channel (see Figure 6). The channel ratio is system-dependent and is chosen by the system engineer.

Figure 6 PROFInet-IRT Channel Division Each PROFInet-IRT device has a special ASIC for handling node synchronisation and cycle subdivision and incorporates an intelligent 2- or 4-port switch. The PROFInet switch in every node is highly synchronized, contains a schedule of bus access and can deal with RT and non-RT traffic. It prioritizes RT traffic and provides full-duplex links for all ports. Contemporary switches (even cut-through) add jitter that would impact on determinism. PROFInet switches minimize jitter to where it has a negligible effect. The PROFInet communication model allows both RT and non-RT traffic to co-exist on one network without additional precautions. By 2005, PROFInet-IRT and SRT will incorporate PROFISafe, the PROFIbus safety solution for manufacturing and processing industries. PROFInet, of all the solutions discussed here, offers the greatest determinism and since this is built into the PROFInet-IRT device, the systems engineer is spared from the burden of configuration to guarantee RT communication. IEEE 1588 IEEE 1588 [7] specifies "A protocol to synchronize independent clocks running on separate nodes of a distributed measurement or control system to a high accuracy and precision". IEEE 1588 is, or will be, incorporated into EIP, EPL, EtherCAT and PROFInetmaking it a popular standard for delivering RT over Ethernet. In IEEE 1588, all network nodes down to the transducer level contain an IEEE 1588 clock, synchronized with all network peers (see Figure 7) using Precision Time Protocol (PTP). At device level, sensors can timestamp their data locally and actuators can operate at a precise time, avoiding stack and application delays between transducer and controller. The accuracy of the system depends on the synchronization of local RT clocks.

Figure 7 IEEE 1588 Configuration IEEE 1588 defines two separate types of clocks: ordinary and boundary. Boundary clocks (BC) are employed in devices such as hubs or switcheswhere more than one PTP communication path (port) exists. Ordinary clocks exist in devices having a single porte.g., normal network devices. Each BC port can act as a master or ordinary clock in its own segment. PTP is for networks that support multicasting but keep multicasts within a subnet and where each local clock fulfils exacting requirements. The grandmaster clock (GMC) is the best clock in the system with the best inherent stability, accuracy, resolution, etc. defined by the standard [ 8]. The Best Master Clock Algorithm (BMC), run by every live node, determines clock quality. Within each subnet, the BMC determines the master clock; in a single- subnet system the master is the GMC. The GMC determines system synchronization; system clocks synchronize their subnet clocks to the system. There is only one GMC per system, and only one master clock per subnet. IEEE 1588 (continued) Synchronization is performed as follows. All masters periodically broadcast "Sync" messages containing an estimate of the time the message will physically leave the master. The precise receipt time of these messages is noted at the slaves. The precise sending time of the message is noted at the grandmaster.

All precise timing measurements are performed as close to the physical layer as possible to eliminate the delays from the network stack and operating system while the estimated times are calculated by the IEEE 1588 code at the Application Layer (see Figure 8). Following the Sync message, the master transmits a related "Follow_Up" message containing the precise sending time of the Sync message. A slave uses the transmission and reception times to calculate its offset and can initiate synchronization with the delay measurement, which is not periodic and not performed as often as the protocol synchronization. Sync messages do not propagate beyond their originating subnet.

Figure 8 IEEE 1588 Node Timing The resolution of the system clock is the resolution of the GMC. If required, the GMC can be synchronized to an external source such as GPS. IEEE 1588 is a highly precise system for synchronizing distributed nodes for applications such as motion control and robotics. It was designed for multicasting networks but with the popularity of Industrial Ethernet, Annex D was included for an Ethernet implementation of PTP. Although IEEE 1588 does not alter Ethernet or make it more deterministic or reliable, it does provide a method for other protocols to do so. A highly synchronized system of distributed nodes coupled with an application for handling resolution and controlling trafficcould deliver hard, deterministic RT over Ethernet. Real-Time Ethernet is a fast- growing, exciting development of the Ethernet protocol. The ability to have RT control segments running on the same network as office applications brings many new possibilities for industrial applications. With different protocols offering different levels of RT service, it is vital to understand the RT requirement of the system before choosing a solution. Sub-microsecond synchronization accuracy, with IEEE 1588, along with an RT protocol can provide an Ethernet capable of delivering hard, fast and deterministic RT for applications such as motion control, while other solutions cater for softer applications. Therefore, when choosing RT-Ethernet, it is vital to consider the real- time, interoperability and flexibility requirements of your system along with all possible solutions before making a commitment.

References
1. Schiffer, V.; "The CIP Family of Fieldbus Protocols and its Newest Member Ethernet/IP," Emerging Technologies and Factory Automation, 2001. Proceedings. 2001 8th IEEE International Conference on, 1518 Oct. 2001, Pages: 377-384 Volume 1. 2. "ODVA Adds Time Synchronization Services for Real-Time Control to EtherNet/IP and DeviceNet available athttp://www.odva.org/index.htm . 3. Moldovansky, A., "Utilization of Modern Switching Technology in EtherNet/IP Networks," Proc. 1st International Workshop on Real-Time LANs in the Internet Age (RTLIA'2002) in conjunction with the 14th Euromicro Conference on Real-Time Systems, Vienna, Austria, June 18, 2002. 4. Beckhoff EtherCAT available at www.beckhoff.com/english/default.htm?ethercat/default.htm 5. Popp, M.; Wenzel, P. "PROFInet-linking Worlds", Emerging Technologies and Factory Automation, 2001. Proceedings. 2001 8th IEEE International Conference, Volume: 2 , 15-18 Oct. 2001, Page(s): 519522 Vol.2. 6. Baumann, G. "Solving the Compatible Real-Time Ethernet Conundrum", The OnLine Industrial Ethernet Book, Issue 16, September 2003. 7. IEEE Std. 1588 -2002, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." 8. Eidson, J. et al. "Synchronizing Measurement and Control Systems." Sensors, November 2002.