You are on page 1of 12

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

Industrial Ethernet Book Issue 66 / 44

Ethernet-based fieldbuses for industrial networks: the basics


From its base as a universal office network established 30 years ago, Ethernet has been moving into industrial applications for a decade. Drives, industrial automation, aircraft, railway vehicles and others are increasingly being interconnected and controlled via Industrial Ethernet. In this primer written for rookie network engineers, Reiner Grbmeyer and Stephan Rupp introduce Ethernet-based industrial control system architecture and some of its specialised variations.
INDUSTRIAL AUTOMATION and vehicle control demand real-time performance and safety. So far, Ethernet has been growing and meeting new demands in an evolutionary way. This article summarises the requirements and solutions for Ethernet-based control systems designed for industrial environments. Since the 1980s, Ethernet has been spreading fast as a universal medium to interconnect computers and all device types. One reason for this success is the evolutionary approach. In this way, the basic specification of both Layer 2 protocols MAC (Medium Access Control, IEEE 802.3) and LLC (Logical Link Control, IEEE 802.2) can be extended by further control protocols, such as IEEE 802.1 that - among others - contains the Spanning Tree Protocols, VLAN and port based access control, as well as application specific extensions (IEEE 802.4 and higher).

Switches and layers


An Ethernet switch's function is based on the Ethernet message format (Ethernet/bridging protocols): Layer 2 protocols. This layer contains local network addresses (MAC addresses). Layer 2 protocols include Link Aggregation (802.3ad), VLANs (802.1Q), Spanning Tree (802.1D, 802.1w), QoS (802.1p), flow control (802.3x), as well as GVRP (Dynamic VLAN Registration) and GMRP (Dynamic L2 Multicast Registration). Ethernet-switches allow all ports to operate at their nominal speed. Typically, local networks are operated as IPsub networks. This allows use of private IP addresses for hosts and devices in home and office networks. This means that the network can be structured flexibly at the Layer 3 Internet Protocol. In such a network, IP routing protocols may be applied. More sophisticated Ethernet switches also support Layer 3 protocols such as OSPFv2, RIPv2, VRRP, IGMP Snooping, IPv4 Forwarding, DiffServ, ARP, ICMP, as well DCHP Client/Server to receive or

1 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...


distribute IP addresses.

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

Because of their many configuration options, advanced Ethernet switches need a user interface, which allows operation via a command line interface (CLI), remote terminal (TELNET), or browser (webserver), as well as a management interface (SNMP). Devices with these options are known as 'managed switches'. Such switches also receive an IP address because they need to be addressed as hosts for configuration. Irrespective of protocol diversity, every Ethernet switch operates in basically the same manner. Acting in a similar way as a post office, a switch receives messages at one of its ports (message in), analyses the destination address of the message, and forwards it to a suitable port (message out). The source address and destination address (MAC addresses) of each message (Ethernet frame) is contained in the frame header. The switch matches ports to addresses from the source addresses that are received at the input port. Addresses and matching ports are maintained in a table (Switch Route Table), which can be looked up each time a message is received. If a destination port is known, the message is forwarded to this matching port only. Otherwise, the message is repeated to every port. Figure 1 shows the storage and forwarding of messages.

Fig. 1. (left) The storage and forwarding of messages: A switch receives messages at a port, analyses the destination address and forwards it to a suitable port. Each message's MAC address is contained in the frame header. The header of an Ethernet message (IEEE 802.3 Frame) contains further information beyond source and destination addresses, such as VLAN tags, which qualify different traffic classes. This information classifies a category or group a message belongs to and may also decide which way to forward the message. Depending on its classification, a message can be placed in a priority queue on a port. If a message is part of a multicast group, it will be copied and forwarded to all members (destination addresses) of the group. Note that multicast is the delivery of a message or information to a group of destination computers simultaneously in a single transmission from the source, creating copies automatically in other network elements, such as routers, only when the topology of the network requires it. In the same way, IP header information, which is part of an Ethernet frame's payload, can be accessed by the switch and used for the classification and handling of messages. This allows mapping IP-multicasts into MACmulticast over Ethernet ports. This is called IGMP snooping and it is used in telecommunication networks to reduce unicast streams for IPTV. Ethernet switches, which support Layer 3, sometimes provide such features.

State-based information
The features mentioned so far need no information about contexts beyond the individual Ethernet frame. An example is whether a frame belonging to a specific HTTP or Session Initiation Protocol (SIP) session would be state-based information. In a state based communication system, messages represent the entire state of a node. A sequence number represents state-based information, which the switch would need to store in terms of an individual frame context. The handling of such contexts needs to be by a CPU and is beyond the scope of pure Ethernet switches. Such Layer 3 information is handled by routers, which are usually implemented as software on a CPU, e.g. based on a Linux distribution. Layer 3 switches can handle such state-based information, not on the switch silicon, but by the switch controller's software. Managed switches, which provide a switch controller for user configuration, can implement Layer 3 functions such as NAT (network address translation). This is frequently used in IPv4 addressed domestic and private networks to translate private IP addresses into public IP addresses. The traffic throughput for Layer 3 functions depends on the switch controller's CPU power. Usually, managed switches are designed as wire speed Layer 2 switches with limited Layer 3 performance, which is sufficient for DHCP or NAT over 10 Mbps DSL lines. Wire Speed Layer 3 and Layer 4 features such as VPN, encryption, firewalls or deep packet inspection are implemented on high-performance multi-core CPUs, which are also used for servers and embedded servers. There are also

2 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

multi-core CPUs that specialise in packet processing. In such cases, the Layer 3 and Layer 4 functions are completely separate from Layer 2 Ethernet switches. Forwarding a message to a group of receivers is shown by Fig. 2 (previous page). Here, the sender sends a message to a multicast address (i.e. an address representing the group). The Ethernet switch resolves the multicast address into individual addresses and repeats the message to all respective ports. This is much faster and more efficient because it avoids generation of many unicast messages by the sender.

Fig. 2.Multicast addressing a group of receivers: The delivery of a message to destination computers simultaneously in a single transmission, creating automatic copies only when the topology needs it. The use of VLAN-tags within an Ethernet frame's header allows bigger LANs to be broken into segments, or a virtual LAN (VLAN). Figure 3 illustrates this using the colours as VLAN tags on Ethernet frames and switch ports. In this case, the Ethernet switch is configured such that the ports are allocated to specific VLANs. The switch marks all incoming messages to such a port with the corresponding VLAN tag and forwards packets received with a VLAN tag only to those ports that match the corresponding VLAN. For traffic from multiple LAN segments, ports can be configured to provide such interconnection: the trunks.

Fig. 3. Ethernet switch configuration: This illustrates VLAN tags on Ethernet frames and switch ports as colours. The Ethernet switch is configured such that ports are allocated to specific VLANs. Multiple LAN segments can also be implemented physically using enough Ethernet switches. In virtual LANs, the segmentation is achieved by configuring the switches accordingly. Layer 2 features like multicast, VLAN or priority queues for traffic classes are entirely based on information contained in individual frames, the port configuration and address tables. They do not need any state-based information and can be performed at wire speed by Layer 2 switches.

Embedded networks
Ethernet switches for embedded systems are implemented to match specific environmental conditions: such as an extended temperature range of between -40 to +70C. Embedded switches and routers are also hardened to withstand greater electromagnetic irradiation and support strict limits for its emission. Switches used in vehicles, aircraft and industrial plant must also withstand high shock and vibration, and be resistant to dust, humidity and many other hazardous substances. Moreover, embedded systems are frequently adapted to individual customer requirements and must match specific needs in terms of product availability, maintainability, service and repair. The composition of an embedded switch or router follows the process shown in Fig. 4. Depending on the application and customer specific requirements, the feature set is defined and an appropriate hardware platform is chosen.

3 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

Fig. 4. Showing the composition of an embedded switch or router: Depending on the application and customer specific requirements, the feature set is defined and an appropriate hardware platform chosen. With embedded systems, hardware development starts from a well-established base by using hardware standardised and supplier specific form factors.

Topology
In industrial environments there are network functional requirements beyond the scope of office networks. These include practicality, such as avoiding the hassle of a star topology for cabling, or dual star topologies for redundancy. In an industrial environment, a linear network topology is usually the better choice, and a ring topology provides the redundancy to heal single failures such as broken links.

Real Time (RT) operations


If Ethernet is used as a field bus to control manufacturing equipment or vehicles, the network must respond in a certain time. An industrial environment typically demands RT responsiveness, i.e. responses within a specified interval. Figure 5 illustrates the environment and RT requirements. As shown on the right, a field bus transmits control messages from a controller to an actor (e.g. a drive), and from a sensor to the controller. Message transfer times between devices and the controller are subject to variable delays called 'jitter'. This behaviour follows statistical models such as the Poisson distribution illustrated in Fig. 5 (left part).

Fig. 5. Illustrating realtime requirements in an industrial environment: As shown on the right, a field bus transmits control messages from a controller to an actor (e.g. a drive), and from a sensor to the controller. While a constant delay can easily be compensated for in an industrial control, delay variations cannot. The challenge is to keep the jitter low with respect to the response times, which vary according to the application. Controlling drives needs response times below 1ms. For other devices, response times of 10ms are sufficient. Machines or vehicles operated by a user terminal typically need response times in the same order of magnitude as the human response time: about 100ms. RT performance typically demands deterministic response times. Sensors and devices do not change their state within a deterministic threshold. But when knowledge of their state is requested in a cyclic interval, they do respond. The response times that an Ethernetbased field bus can achieve depends upon network size and topology, transmission speed, and message size in Bytes. One reason is the storage and forwarding of messages within each switch. Deterministic response times cannot be guaranteed by Ethernet without fixing extra conditions. In an industrial environment, a field bus also will need to handle different traffic classes, such as process data relevant to control, diagnostics data and status messages, as well as other traffic. Response times matter for control process data. Other traffic is less critical, or not critical at all, so may travel in a lower class with a lower priority.

Meeting application requirements


For industrial applications, different approaches are needed to meet specific requirements. Some of these approaches are compatible with IEEE 802 and some are not. The handling of traffic classes, for instance, is part of regular Ethernet and IP

4 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

standards as applied to Internet-based telecommunication networks. Under Quality of Service (QoS), suitable methods for handling different classes of traffic are described both for Layer 2 (IEEE 802.1p) and for Layer 3 (DiffServ, corresponding to RFC 2474 and 2475, as well as some supplementary RFC). The principle (Fig. 6) is based on the classification of messages (Ethernet frames or IP packets) in a specified field in the respective message header. At each node (Ethernet switch or IP router) messages are handled according to their traffic class. Higher class messages are handled with priority. The procedure corresponds to an airline check-in: for each flight (port) there is a counter and a queue for each traffic class. The highest class passenger (message) is dispatched with priority and forwarded to the gate first. This procedure rearranges the order of messages to a specific destination according to their priority (class of service) at each node (switch or router).

Fig. 6. Showing priorities for different classes of service: The principle is based on the classification of messages (Ethernet frames or IP packets) in a specified field in the respective message header. This procedure cannot guarantee a specific response time, which depends upon the total traffic volume. Regarding the highest class of service, the amount of process data that needs to be communicated in this class is known, so the traffic situation within the class can be regulated using suitable cycles and the corresponding volume of data and messages. However, there is interference with traffic from the lower classes. For instance, while a secondclass message ('Business' class in Fig. 6) is in transmission over the destination port, the first class message ('Senator' class in Fig. 6) needs to wait. The delay depends on the length of the lower class message. The length of Ethernet frames can vary significantly from between 64 and 1518 Bytes (9000 Bytes for 'Jumbo' frames). IP packets may extend up to 64KB. By not discarding Jumbo frames, the length of 'vehicles' on the data highway varies by a factor of 1000. At 100Mbps transmission rate (Fast Ethernet), a Jumbo frame takes 0.7ms to transmit. Depending on the number of nodes between sender and receiver, this situation may repeat and so accumulate delays. This, in turn, can generate high jitter. The transmission of the 64-Byte control message would have taken just five microseconds. In addition, the same effect leads to the solution for providing RT responses with deterministic response times and limited jitter while using regular QoS features over Ethernet or IP. In such a control applications network, the maximum packet length should be limited to a suitable size, such as a maximum of 512 Bytes/message, corresponding to a 40ms transmission time. All senders should keep to this limit. Total delay and jitter then depend on the number of network nodes. In a control application, the network topology and number of control segment nodes can be designed accordingly. A different approach projects traditional field bus principles on to Ethernet-based field busses. With the former, all senders (sources of process data) and receivers (sinks of process data) share the bus as joint communication medium. In such an arrangement, a moderator (bus master) arranges communication by placing requests for information to individual participants in a controlled way. The bus master does not necessarily represent the controller or master: it just arranges the communication flow (Fig. 7).

5 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Knowledge | Technical Articles | Ethernet-b...

http://www.iebmedia.com/index.php?id=8249&parentid=63&themeid=2...

Fig. 7. Orchestrating deterministic behaviour: A moderator or bus master arranges communication between participants by placing requests for information to the individual participants in a controlled way. To obtain the greatest attention for process data, a specific time slot is reserved for process data (deterministic part), and all other communications will move to a second time slot (asynchronous part). The time slots are repeated cyclically. Within the deterministic interval, the bus master organises the flow of information between process data sources and sinks. The asynchronous interval can be used to transmit Ethernet traffic the usual way. While all messages are transferred as standard Ethernet frames, the multiplexing of time slots used like this needs special Ethernet switches, which support the specific multiplex. This concept is, therefore, compatible with regular Ethernet specifications and allows the transference of regular Ethernet traffic over the field bus segment, within which special Ethernet switches need to be used. These implement the time division multiplex feature. Another approach assumes a linear bus topology and packs all data intended for all devices down the chain into one single message. The format of the data is specified as a structure within the payload section of the Ethernet frame, which keeps the Ethernet frame according to IEEE 802 without modifications. Because process data is communicated as part of the payload section, any regular Ethernet switch can carry the message containing the process data. Within a linear field bus section - a daisy chain - all devices connect with a specific bus coupler. The bus couplers forward the frame to the next bus coupler further down the chain. While forwarding the message, the bus couplers access the process data and withdraw any information intended for the specific device, and include any output of the specific device into the process data structure. At the end of the chain, the message is returned back up it, and on its way it is merely passed to the next device upstream, without access to the process data being required. The concept also is compatible with IEEE 802. However, in the field bus section, it requires special bus couplers able to extract and fill-in process data while forwarding the message further downstream. Process data is handled at application layer; there is no impact on Layer 2. Upstream, messages are passed exactly like ordinary Ethernet frames. In order to interconnect different network segments or field bus segments, linear topologies provide the least effort in cabling. However, if a link fails, all devices behind the broken link are inaccessible. Continue reading part 2 of this article Reiner Grbmeyer and Stephan Rupp work for Kontron. www.kontron.com

Source: Industrial Ethernet Book Issue 66 / 44

2010-2012 Published by IEB Media GbR Last Update: 23.02.2012 17 User online Legal Disclaimer Contact Us

6 of 6

2/24/2012 9:50 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

Industrial Ethernet Book Issue 67 / 42

Ethernet-based fieldbuses for industrial networks: the basics - part 2


Click here to read part 1 of this article

In the final part of this article, Reiner Grbmeyer and Stephan Rupp conclude their primer for rookie network engineers. As a universal network protocol, Ethernet is fast moving into applications including include drives and equipment for industrial automation, as well as aircraft and railway vehicles, which are increasingly being interconnected and controlled via Ethernet.

ETHERNET HAS BEEN growing and meeting new demands in an evolutionary way. Part 1 examined industrial Ethernet components, state-based information, embedded networks, topologies, RT issues and application requirements. Part 2 of this article looks mainly at implementation.

Redundancy and rings


For industrial operation, some degree of redundancy is desirable to protect against single failures. This can be achieved relatively easily using a ring topology (Fig. 1).

Fig. 1. Ring redundancy: For operation in an industrial environment, some redundancy is desirable, allowing protection against single failures.A ring topology achieves such protection relatively simply.

1 of 6

2/24/2012 9:53 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

Nodes (Ethernet switches) are interconnected such that the linear topology cabling becomes a ring. Therefore, the nodes operate as in a linear topology, with one link representing a reserve link - the so-called Ring Protection Link (RPL), which is not used to transmit regular messages. If one link of the network fails, the reserve link is activated. All nodes are now connected to each other and form a new linear topology. Fail-over to the new topology needs to be fast enough to meet the demands of the industrial environment concerned - typical fail-over times are below 500ms. Detecting failures, activating the reserve link and failing-over to a new topology mean extra tasks that need a suitable control protocol and controller. One of the switches takes charge of this task and becomes owner of the reserve link (RPL-Owner). To check the ring for potential failures, the RPL-Owner sends control messages in both directions across the ring (including the reserve link, which does not carry conventional traffic). If the RPL-Owner receives messages from both directions, the ring is operational. If a broken link occurs, the RPL-Owner activates the reserve link and changes the topology. Because messages now need to be passed along different ways, switches need to change their MAC address tables accordingly. To allow the interoperation of switches from different manufacturers, a standardised procedure for ring supervision and fail-over is required.

Implementation examples
In the industrial environment, there are specifications and implementations for all of the approaches mentioned in this and the previous article in IEB66. The definition and handling of traffic classes by Ethernet and IP procedures (Fig. 2) is accepted in North America and specified as EtherNet/IP. Such implementations need no particular modifications of Ethernet switches. As mentioned in the previous section, the network topology and message sizes need to meet specific conditions to comply with response-times for process data requirements.

Fig. 2. Priorities for different classes of service: the principle is based on the classification of messages (Ethernet frames or IP packets) in a specified field in the respective message header. EtherNet/IP is standardised by the ODVA with participation of ControlNet International (CI), as well as the Industrial Ethernet Association (IEA) . Another implementation origination in Europe is Profinet, which has been specified by the Profibus and Profinet International (PI) Association and is part of the IEC 61158 and IEC 61784-2 international standards. Profinet carries process data, as well as general data, in process automation and information technology on the same network. For soft real-time requirements, Profinet reserves an own traffic class (named RT for Real-Time control), which is handled in a preferred way. For strict real-time requirements, Profinet uses a time division multiplex and reserves a cyclic interval for process data. The option that applies strict real-time requirements is termed Isochronous Real-Time (IRT). Figure 3 shows the principle. The implementation of the time division multiplex used for IRT requires specialised Ethernet switches within the field bus segment, which may carry regular traffic in the standard multiplex cycle. The same diagram also illustrates the fact that Profinet supports tree topologies, as well as the branching out of traditional fieldbuses such as CANopen or Profibus.
2 1

2 of 6

2/24/2012 9:53 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

Fig. 3. Isochronous Real-Time (IRT): Implementation of the time division multiplex used for IRT requires use of specialised Ethernet switches within the field bus segment. Specialised switches may also be integrated into the end devices or field bus couplers. As for Ethernet-based fieldbuses in general, cycle times and response times depend on the size and topology of the network. As fieldbuses are part of industrial facilities, corresponding network planning can always be achieved. A further implementation is EtherCAT of which the Beckhoff-led EtherCAT Technology Group develops this technology. EtherCAT represents an IEC standard and part of the international standards for IEC61158 and 61784-2 field buses. It uses a serial (daisy chain) connection of devices and drives to the control and summarises all process data that are intended for such a segment into a single datagram. This datagram is represented within the payload part of an Ethernet frame and passed down the chain. Figure 4 shows the chain, including an EtherCAT Master as the datagram source, as well as a chain of EtherCAT bus couplers. The master just needs merely a standard Ethernet network interface, as available in every industrial PC or industrial controller.
3

The elements further down the chain need a special building block to extract and drop in the process data intended for the specific device according to the structure of the datagram. This building block should be implemented in hardware in order to allow access while passing a frame further down the line. As shown in Fig. 4, access to process data only takes place in a forward path. On the return, there is no need to touch the payload section. After all devices in the chain have had their share of information, the last device sends the message back further up the chain back to the controller. Because it summarises process information for all a whole chain of devices into a single message, EtherCAT operates very efficiently in linear topologies. As also indicated in the same diagram, EtherCAT supports tree structures, plus the branching out of traditional fieldbuses.

Synchronisation
An important condition for control tasks in general is the exact synchronisation of all devices and controllers. In computer networks, clocks within hosts are synchronised by a control protocol such as the Network Time Protocol (NTP, RFC 5905), which allows synchronous operation of files systems and calendars. The accuracy of such protocols is not sufficient for

3 of 6

2/24/2012 9:53 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

industrial controls, which need precision better than 1ms. Such precision can be achieved using the Precision Time Protocol, which follows the IEEE1588 standard . To synchronise clocks in two systems, the principle of operation is based on sending messages - including time stamps - which allows computing the delay times between the reception and the sending of the message, as well as the offset between the clocks. One of the clocks must be defined as master, providing the time that other clocks will adjust to. Measuring both offset and delay needs two messages with time stamps: System 1 (Clock Master), which sends a message containing a time stamp to System 2 (Clock Slave). System 2 answers with a message, which contains the measured time at the reception of the first message. To level the amount of information in both systems, System 1 (Clock Master) then sends a third message to System 2, which contains the reception time of the second message at System 1. The difference between the time stamps and reception time of the first message contains both the message delay and the clock offset. The difference between the time stamp and the reception time of the second message contains the message delay minus the clock offset. This information is available in both systems. This way, System 2 may compute the offset and adjust its clock according to the clock in System 1 (Clock Master). The Precision Time Protocol (PTP) according to IEEE 1588 is implemented in all mentioned fieldbus standards. To achieve a high time stamp accuracy, they cannot be generated by application level software - the jitter generated by the operating system scheduler would spoil the accuracy. The generation of time stamps need to be supported by hardware, i.e. by the network interface chip (NIC) and by the Ethernet switch.
4

Redundancy management
Ring topologies are typically used in telecommunication networks and are also defined for Ethernet in such applications, e.g. by recommendation ITU-T G.8031 (Ethernet Ring Protection Switching). In an industrial environment, a different standard is frequently used: the Media Redundancy Protocol (MRP) , which is specified as IEC standard 62439. MRP also operates according to the principle described in the last section (just as with ITUG. 8031). One of the switches is tasked as redundancy manager (RPL-Owner), checks the network for connectivity and activates the redundant link in case of failure. A key condition is short fail-over times, which cannot be achieved by the usual IEEE 802.1 Spanning Tree Protocols. MRP is fully compliant with IEEE 802.3 and IEEE 802.1, but extends Spanning Tree Protocols by another procedure. The mechanisms for erasing address tables within switches and the port states used during the fail-over are the same as used in the Rapid Spanning Tree Protocol (RSTP). MRP guarantees fail-over times of 200ms, depending on the network topology. MRP can be used in all fieldbuses defined in IEC 61158-2.
5

In transport
Fieldbuses in transport applications are also migrating to Ethernet, and some aircraft and many rail vehicles have been controlled by wire (via fieldbuses) for a considerable time. For aircraft, failure protection requirements tend to be higher because (obviously) operation cannot be interrupted and must continue without much degradation. However, no new devices need to be added during operation, so the network topology can be fixed and configured in a static way. Railway vehicles need to support a flexible network topology - during operation, train sections may be added or removed, the direction of travel (and hence the location of the drivers cab) may change at a station terminus. For operation in aircraft, the avionics industry has specified Avionics Full-Duplex Switched Ethernet (AFDX) , which represents the ARINC 664 standard. AFDX is aimed at being a successor to the current field bus according the ARINC 429 standard for Aircraft Data Networks (ADN). AFDX defines embedded systems and switches and supports arbitrary network topologies, as shown in Fig. 5 (upper schematic).
6

Fig. 5. Avionix Full-Duplex Switched Ethernet (AFDX). This defines embedded systems and switches and supports arbitrary network topologies. The network is configured in an entirely static way - there is no learning of MAC addresses, there are no dynamic extensions, and all paths are defined in a deterministic manner. AFDX does not use MAC addresses at all, but uses address fields to

4 of 6

2/24/2012 9:53 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

define Virtual Links (VL) for all communication and relations between end devices. End devices are able to perform traffic flow control on the Virtual Links. To achieve a low failure rate, AFDX operates on fully redundant data paths. The term 'Full- Duplex' in AFDX relates to this redundant type of operation (rather than the duplex operation of the individual Ethernet data links). As shown in the lower part of Fig. 5, networks are completely duplicated. Each end device sends an Ethernet frame over both networks A and B. Ethernet switches within each network do not need to know anything about redundancy at all. The end device at the other end of the Virtual Link receives frames from both networks. Should one frame be lost or arrive late, the end device chooses the frame from the opposite line. This way, there is no failover mechanism or change of network topology in case of a failure at all. Redundancy is managed by the receiving end device. Single failures can be corrected immediately, without loss of data, and without interruption and without affecting latency. For railway vehicles, there is a field bus described as Train Communication Network (TCN)7, which is specified as IEC standard 61375-1 by an international alliance of railway manufacturers. This is structured in a hierarchical way with the following components: the interconnection of train segments (so called consists) is handled by a Wire Train Bus (WTB), within the train segments, devices are controlled by a Multifunction Vehicle Bus (MVB). The specification of an Ethernet based successor is in progress with an IEC working group and is intended to be published as IEC standard 61375-3-4 (Ethernet Consist Network, successor to MVB) and 61375-2-5 (Ethernet Train Backbone, successor to WTB). Figure 6 shows the overall architecture.

Fig. 6. The Train Communication Network (TCN): The overall architecture for railway vehicles. This, specified as IEC 61375-1 is structured in a hierarchical way. The hierarchical architecture of the predecessor IEC 61375-1 will be maintained by the new TCN field bus - within a train segment, devices are controlled via an Ethernet Consist Network, which interconnects End Devices (EDs) by Consist Switches (CS). As one train may contain multiple train segments (consists), the segments (which are - respectively - consist networks) are interconnected via Ethernet Train Backbone Nodes (ETBNs). The type of network topology within a Consist Network is not restricted by the standard. Typically, ring topologies will be applied for the same reasons as in industrial control in combination with the MRP protocol providing ring redundancy. The real-time and fault protection requirements for rail vehicles are comparable to those for industrial automation. The ETBN can be implemented in a redundant way. The connections between the train segments via ETB can also be implemented using by dual Ethernet links. If fault tolerance and recovery time allows, protocols such as Ethernet Link Aggregation may be used on the ETB connections. The Consist Switches represent regular Layer 2 switches, and to separate process data from all other traffic (measurements, announcements of camera images etc), they should support different classes of services (QoS) according to the native procedures of Ethernet and IP. As with AFDX, the concept and data models of the proceeding field bus may be kept and implemented at application layer. In TCN, a dedicated role is assigned to the ETBN. While the train is in driving mode, it simply operates as an ordinary router, which connects train segments at Layer 3. While driving (moving), it allows the translation of local IP addresses, e.g. by Network Address Translation. Before entering the driving state, there is an initial phase, at which IP addresses are allocated dynamically via DHCP, with the SHCP server implemented on the ETBN. On the train, a segment may be added or removed, and the direction of driving may be changed. At such changes, the ETBN discovers the topology and enumerates all train sections correctly. This is important, so as to, for example, confirm that when the driver clears doors for opening at a station, doors will only open on the platform side of the train. Click here to read part 1 of this article References: 1. Ethernet/IP Consortium: www.odva.org, www.ethernetip.de 2. Profinet and Profibus Association: www.profibus.com 3. EtherCAT Technology Group: www.ethercat.org

5 of 6

2/24/2012 9:53 AM

The Industrial Ethernet Book | Articles | Technical Articles | Ethernet-based...

http://www.iebmedia.com/index.php?id=8325&parentid=74&themeid=2...

4. IEEE 1588: IEEE Standard for a Precision Clock Synchronisation Protocol for Networked Measurement and Control Systems. IEEE Std. 1588, 2002, www.ieee1588.com 5.MRP:Media Redundancy Protocol for Ethernet ring topologies, IEC 62439, www.iec-normen.de 6. AFDX: Avionics Full Duplex Switched Ethernet, ARINC Standard 664, www.aeec-amcfsemc.com/standards/index.html 7. TCN: Train Communication Network, IEC 61375-1, 2007, www.iec-normen.de 8. Ethernet Powerlink: http://www.ethernet-powerlink.org Reiner Grbmeyer and Stephan Rupp work for Kontron.

Source: Industrial Ethernet Book Issue 67 / 42

2010-2012 Published by IEB Media GbR Last Update: 23.02.2012 21 User online Legal Disclaimer Contact Us

6 of 6

2/24/2012 9:53 AM

You might also like