Fieldbus & Industrial Networking


Ethernet goes realtime

July 2003 Fieldbus & Industrial Networking

Persistent and uniform networking at all levels of a company by using Ethernet provides the advantages of company-wide access to all relevant information, and uniform, standardised interfaces. While Ethernet has already found acceptance at the control level there is still scepticism as to whether Ethernet is able to provide the process demanded deterministic behaviour of the device level.

Realtime applications - what is realtime?

If a system is able to react to all events correctly and within the expected time constraints, under all circumstances - then it is considered realtime capable. If a communication system meets all the time requirements of a certain application, it is - from the perspective of this application - realtime capable. This might mean that the duration of an interval between two events will not exceed a maximum limit. But often this also means that actions must happen at a certain specified time.

In the first case Ethernet, with few restrictions, is an appropriate protocol. The second case can generally not be guaranteed with Ethernet. Variations in the transmission duration can be caused by unpredictable delays in buffer queues. However, this can be overcome by combining guaranteed maximum transmission times and an appropriate precise time synchronisation mechanism. These kinds of synchronisation algorithms, which will provide a synchronisation precision far smaller than one microsecond, are currently being developed by the IEEE 1588 working group. This article describes how Ethernet is already able to provide a guaranteed maximum transmission time.

TCP or UDP

TCP (Transmission Control Protocol), a layer 4 protocol, is connection based. It establishes a virtual connection at the beginning of the communication process, and tears down the connection when the communication process has finished. As a result, loss of data can be detected and the lost data can be automatically re-transmitted. TCP also ensures that the transmitted data remains in the correct sequence.

In contrast to this, UDP (User Datagram Protocol) is connectionless. The data packets sent are absolutely independent from each other. For realtime applications UDP is normally used as the layer 4 protocol, since re-transmission and realtime capability are contradictory demands.

Bottleneck protocol stack

In most cases data transmission bottlenecks are not caused by the network infrastructure, but by the protocol stacks, which are generally a component of the applied realtime operating system. Investigations of typical realtime operating systems showed that stacks, as used today, have relatively high throughput times. Measurements of 400 MHz Pentium systems showed times around 200 µs, with a jitter of less than 10 µs.

Test of other systems showed throughput times fluctuating around five times longer. Consequently, no narrower indexes concerning the time behaviour can be assumed. Of course with more powerful CPUs and lower CPU workload, the process times are shorter. In specific cases a statement about the time behaviour of the stack should be requested from the provider of the operating system being used.

Network aspects

Ethernet was originally based on the CSMA/CD (carrier sense multiple access/collision detection) protocol. An end device wishing to send data checks the transmission medium. If the network is not being used by another device, it starts to transmit. It is possible that several end devices detect the network to be free and simultaneously start to send data.

This collision will be detected by the end devices, and all of them will stop transmitting. They will each try again after a random period of time. In this way there is a very high likelihood that the collision will not re-occur. This access technology is intrinsically not deterministic, since access to the network is based upon statistical probability. This behaviour has resulted in Ethernet's reputation as being unsuitable for realtime applications.

Switching

Today, Ethernet networks are mostly built using only switching technology. In contrast to CSMA/CD there is no shared medium, in which end devices must compete for access. Instead, each end device is assigned a full duplex connection to the switch. As a result, there is no contention for access to the transmission medium. It is impossible for collisions to occur. Incoming data can be immediately switched to its destination. For example, device A can send data to B, while C simultaneously sends data to D, and D concurrently sends data to A.

Complications arise if device A sends data to B and at the same time C also sends data to B. In this situation the data will be buffered by the switch and transmitted in sequence. This is how queues develop, incurring delays. In a real-life situation the amount of data to be transmitted is clearly defined and the number of end devices is known. Subject to the transmission speed of the network, the maximum delay can be determined.

Prioritisation according to IEEE 802.1p

A recent innovation in Ethernet, standardised by the 802.1p working group, is a prioritisation mechanism. An additional field, known as a tag, is added to the Ethernet frame. The tag contains information about the priority of the data.

Some Ethernet switches already support this function, and can usually distinguish between two or four priority levels. Each transmission port has separate queues for the supported priority levels. Data packets in a higher priority queue are always transmitted before those in a lower priority queue.

Ethernet, Fast Ethernet, Gigabit Ethernet

While Ethernet was originally designed with a data transmission rate of 10 Mbps, since 1995 there has been a standard for 100 Mbps (Fast Ethernet). In 1998 1000 Mbps (Gigabit Ethernet) was standardised. Today, many Ethernet terminal devices are able to support transmission rates of both 10 and 100 Mbps, and Gigabit Ethernet is already established for use in backbone applications. The IEEE 802.3 group is now working on a 10 Gigabit Ethernet standard.

With each increase in the transmission speed, the transmission time for a single packet is reduced by a factor of 10. On a 10 Mbps network it takes 1,2 ms to transmit the maximum Ethernet frame size of 1522 bytes. Using Fast Ethernet this time is only 120 µs, and with Gigabit Ethernet only 12 µs.

Realtime behaviour by segmentation

In addition to control data, which requires realtime communication capability, additional data with different load profiles and characteristics must use the network. For example, visualisation data, software updates, e-mail traffic, office applications, and Internet data traffic. For this reason the network must be meticulously designed, to include segmenting those parts of the network where realtime behaviour is necessary.

The terminal devices that require realtime behaviour should be linked over as few switches as possible. Inevitably, the more switches between two terminal devices, the higher the 'worst case' throughput and queue time. With backbones or other instances where there are no factors limiting realtime performance, the individual segments are commonly connected in a ring structure.

In addition, the interface between a realtime segment and the rest of the network must be precisely controlled. Since the data traffic from the general network can adopt any load profile, it must be monitored and restricted when entering a realtime segment. To prevent the realtime segment being overloaded, the amount of data traffic entering this segment must be limited. An effective way to achieve this is to configure the inter-segment link to 10 Mbps, while all devices on the realtime segment communicate at 100 Mbps. Further segmentation, as well as access control, can be accomplished by the use of routers and firewalls.

Broadcasts

The number of broadcast frames in a network is also a contributing factor to network overload. On one hand broadcasts stress the terminal devices, because the devices have to examine each broadcast. On the other hand, depending on the switch architecture, broadcasts place an additional load on the switches. This is because a broadcast frame has to be duplicated for each output port of the switch. To counteract the negative effects of broadcasts, some switches offer a function known as a Broadcast Limiter. This limits to a pre-defined threshold the number of broadcasts transmitted each second.

Intelligent usage of prioritisation

A third possible way in which the realtime segment can be disrupted by the rest of the network is the inappropriate use of prioritised frames. Normally prioritisation within the realtime cell ensures that the cyclic data traffic is favoured over the low prioritised traffic. However, it is possible that traffic from outside the realtime cell, also marked with the same high priority, is transmitted into the cell. To prevent this, some switches support the ability to manually adjust the priority of data traffic for specific ports. If the port to the rest of the network is configured with a lower priority, then incoming traffic cannot disrupt the cyclic data traffic.

Outlook

Operating systems manufacturers and network stack manufacturers are starting to improve the way their products perform with regard to network time behaviour. Until recently the realtime capabilities of many operating systems' protocol stacks were ignored by manufacturers. This deficiency is being addressed by some, although unfortunately not all manufacturers. Only continuous pressure on the manufacturers by the users will resolve the situation.

Protocol stacks in hardware

If protocol stacks are realised in hardware, the network protocol software is completely removed from the CPU. It is handled in a separate chip, which is located between the CPU and Ethernet chips. In this way the throughput of layer 3 and 4 is clearly improved compared with any software implementation, and becomes absolutely independent from all other operations.

Gigabit Ethernet

From the network perspective, further improvement will be achieved if terminal devices communicate using Gigabit Ethernet. Even if today the price of Gigabit Ethernet confines its use to backbones or possibly large server systems, the progress in semiconductor technology will dramatically reduce the costs within the next few years. In addition, features that have limited use today, such as prioritisation, (data)rate limiting, and rate shaping (smoothing of the load profile), will find wider acceptance.

Conclusion

If Ethernet is used for realtime applications, the current bottleneck is more likely to be the protocol stack than the network itself. In future, substantial enhancements are to be expected. On one hand, stacks will be improved regarding throughput time and jitter. On the other hand, hardware TCP/IP or UDP/IP stacks will work independently from all other software structures and processes. By employing Ethernet switches to prevent collisions, the use of prioritisation according to the IEEE 802.1p standard, and careful planning of the network infrastructure, realtime behaviour can already be achieved with Ethernet. In future the latency times will be reduced by a factor of 10 through the use of Gigabit Ethernet.

Ralf Messerschmidt is project manager at the CVS at IAF of Otto-v. -Guericke-Universität, Magdeburg, Germany. Andreas Dreher is director of R&D at Hirschmann Electronics' Automation, Neckartenzlingen, Germany and Network Solutions division. Both men are IAONA Hard Realtime Joint Technical Working Group members, and holders of German Engineering Diplomas.

IAONA Working Group Hard Realtime

The IAONA Hard Realtime Joint Technical Working Group analyses both the realtime capability of off-the-shelf Ethernet components (including the influence of current TCP/IP protocol stacks) and also new approaches for further improved realtime behaviour. Within the framework of the DEFIA project (deterministic Ethernet for industrial applications), the approach is to combine a TCP/UDP/IP stack with TDM methods (time-division multiplex).



Credit(s)



Share this article:
Share via emailShare via LinkedInPrint this page

Further reading:

EtherCAT interoperability removes industrial networking barriers
Fieldbus & Industrial Networking
Selecting the right communication technology is one of the most important decisions engineers make, and interoperability helps with that decision. Key development tools and standards ensure interoperability among many EtherCAT devices and manufacturers.

Read more...
Condition monitoring to go
Turck Banner Southern Africa Fieldbus & Industrial Networking
Anyone who wants to efficiently monitor the climate in control cabinets will find a comprehensive range of control cabinet monitors for the DIN rail in Turck Banner’s cabinet condition monitoring family.

Read more...
Affordable building management system product range
Fieldbus & Industrial Networking
Schneider Electric has unveiled its EasyLogic Building Management System range, designed for basic building architectures, to the local marketplace. This is a complete and cost-effective range of field controllers and sensors that are both easy to install and scalable.

Read more...
Flexible EtherCAT communication interface for DALI-2
Beckhoff Automation Fieldbus & Industrial Networking
The EL6821 EtherCAT Terminal from Beckhoff allows up to 64 DALI/DALI-2 slaves and 64 DALI-2 input devices to be connected. The TwinCAT 3 System Manager makes it easy to configure and parameterise DALI devices flexibly.

Read more...
EtherCAT-based control technology for building automation
Beckhoff Automation Fieldbus & Industrial Networking
Modern non-residential buildings place many high demands on building automation. This can be optimally implemented with EtherCAT-based control technology from Beckhoff, which provides an efficient central automation architecture thanks to ultra-fast data communication.

Read more...
PC-based control for university studies
Beckhoff Automation Fieldbus & Industrial Networking
The IDEA box developed at Heilbronn University of Applied Sciences is designed to introduce students to the topic of Industry 4.0 in a simple and practical way. At the core of the corresponding demo case is PC-based control from Beckhoff.

Read more...
A new standard in high-speed Ethernet communication
Fieldbus & Industrial Networking
The TXMC897 module from TEWS Technologies supports a range of Ethernet standards and speeds, making it suitable for diverse applications, including the defence, industrial, and IIoT markets.

Read more...
Data-driven battery production
Turck Banner Southern Africa Fieldbus & Industrial Networking
The availability of high-performance batteries at moderate prices is one of the most important factors for the success of electromobility. As a long-standing automation partner to the automotive industry, Turck Banner supports the major battery manufacturers with its know-how.

Read more...
Bring critical temperature data to your condition monitoring system
Turck Banner Southern Africa Fieldbus & Industrial Networking
Data conversion just got easier. Turck Banner converters are compact, simple add-ons that seamlessly fit into your factory applications. You can take various types of signals such as discrete, analogue and many others, and convert them to protocols like IO-link, PICK-IQ, PWM/PFM, and Modbus.

Read more...
Case History 190: Measurement problem ruins level control.
Michael Brown Control Engineering Editor's Choice Fieldbus & Industrial Networking
The widely held belief in many plants that tuning will solve all base layer control problems is completely fallacious. Bad tuning is generally not the main reason for loops to perform badly. It is important when performing optimisation that all elements in a loop are considered, in addition to the control strategy, before even thinking of tuning.

Read more...