Appendix B: Real-Time Ethernet Installation

Ethernet communication in real-time

Ethernet takes the next step as a “Fieldbus” in Beckhoff’s TwinCAT control system. In addition to tough real-time requirements, it permits the use of standard components “on the same wire”. The BK9000 Ethernet Bus Coupler and the AX2000-B900 servo amplifier are the first Fieldbus components to benefit from the real-time capability. New network variables accelerate the real-time data exchange
between controllers, making it as easy to implement as connecting another digital input.

Beckhoff’s range of Ethernet products has been in use for years, and is becoming increasingly popular. The advantages of using the office Ethernet standard communication method in industrial settings are clear:
- Uses standard hardware components (e.g. a standard of-the-shelf )Switch
- Standard protocols can be employed
- Data transmission rates are very high compared to other networks
- Linking the network to the rest of the world over the Internet is straightforward
- Remote maintenance and diagnosis

Communication over Ethernet has now become accepted in industrial automation and many groups and committees are concerning themselves with this topic. The absence of effective real-time capability, however, is a problem, which has limited Ethernet’s use in the classical fieldbus area. Some techniques do allow a certain degree of real-time capability, but are based on proprietary systems, and do not allow standard components and protocols to be used at the same time.
- "Real-time capability" is a somewhat flexible term when used in control theory.
- "Real-time" depends heavily on the requirements of the particular application and the control loops in which the automation components are used. However, from the point of view of automation engineering, and against the background that fieldbus specialist Beckhoff have to offer, a rough division can be drawn:
- The toughest requirements involve cycle times of around 50 µs and permissible jitter (deviations from the desired cycle time) of around 10 µs. Requirements tighter than this are currently still handled with the aid of special hardware rather than directly over fieldbusses. Typical cycle time requirements with position-controlled drives are in the range of milliseconds (1-4 ms), in which case jitter times should be less than 20 µs. Pure PLC applications often require cycle times no shorter than 10 ms; correspondingly, jitter times may here be significantly longer, and lie in the millisecond range. Data communication between the controller and the supervisory system can often satisfactorily be handled with cycle times in the range of seconds. In fact it may not be configured cyclically, but may be event driven.

Remote servicing and diagnosis should also be mentioned. Cycle and jitter times here are less relevant than reaction times and the general possibility of being able to communicate across the boundaries of networks. TwinCAT automation software now offered with Real-time Ethernet means that all the communication requirements that have just been mentioned can be satisfied using one and the same technology, both from the point of view of the devices used and of the protocols employed.

Principle of operation

The TwinCAT network card driver is linked into the system in such a way that it appears as a network driver, compatible with the operating system, and additionally as a TwinCAT fieldbus card. An internal prioritization system and buffer is provided at the transmitter end which always finds a free transmission channel for Ethernet frames from the real-time system that may be queuing. The operating system’s Ethernet frames are only later transmitted in the “gaps” if sufficient time is available.
At the receiving end, all the Ethernet frames received are examined by the TwinCAT I/O system, and those with real-time relevance are filtered out. All other frames are passed on to the operating system after examination, outside the context of the real-time system.

Using commercially available switches, all of which support full duplex operation at 100 Mbaud, the transmitted frames are passed on to the receiver with a constant delay. A switch ensures that collisions are avoided and only delays occur. In a cyclic control system it is therefore only necessary to ensure that all the relevant input information has arrived before the next cycle starts. When, or in what sequence, they have arrived is not significant.
If the number of participating devices or the frame rate is restricted in accordance with the required cycle time, the preconditions for Ethernet communication with real-time capability are satisfied.

The above picture shows the principle of how the original Windows operating system protocol stack (TCP/IP and UDP/IP) is used besides TwinCAT Real-Time Ethernet. We call this principle "Y-driver" architecture.

Operating modes/protocols

In contrast to the widely used TCP/IP and UDP/IP protocols, which are responsible for the provision of individual Ethernet frames around the world, real-time communication does not leave the local subnet. The overhead involved in TCP/IP, and even that of UDP/IP, can be omitted, and the devices can be addressed directly by means of the hardware addresses (MAC-ID) of the network cards. The structure of Ethernet frames ensures that it is always possible to co-exist with other protocols; even the “real-time frames” can, if necessary, be transmitted with TCP or UDP, if they have to leave their own subnet.
A number of different operating modes have been defined for use in control engineering. They serve different communication tasks, and can, of course, be employed simultaneously.

1.) Master-slave process data communication

Cyclic or event-driven transmission of I/O data – the typical use of modern fieldbusses

2.) Publisher-subscriber process data communication

Process data according to the publisher-subscriber model (also referred to as network variables) is used for regular communication between controllers when a fixed master-slave relationship would not be appropriate. The Publisher sends out its information without concerning itself with where it is going. The communication is only monitored in the Subscriber. Mutual publisher-subscriber relationships permit bi-directional and multi-directional communication. The publisher can be configured to send the data by broadcast, multicast or unicast. Multicasts reduce the loads at the network devices’ receive queues, because the messages are evaluated as soon as they reach the Ethernet controller. Only if unicasts are used the switch (without extensive configuration) can open parallel communication paths and increase the useful bandwidth.

3.) Data communication as required

This is a type of communication made possible in the TwinCAT system through ADS communication, and which sends communication strings from one device to another “as required”. Services are executed and parameters exchanged in this way.

The chosen protocol structure means that other operating modes or communication profiles can easily be integrated in the future, and can co-exist with the existing modes without difficulty.

Compatible components

The first components from the Beckhoff product range to have been extended for real-time Ethernet application are the BK9000 Ethernet Bus Coupler and the AX2000-B900 drive. These two components open up almost the entire range of industrial signals and applications.
All TwinCAT controllers (from Version 2.9 upwards) are compatible, and can participate both as “fieldbus masters” and in communication using network variables. TwinCAT Real-Time Ethernet supports all controllers (network adapters) of the Intel 8255x family. This is one of the most widespread Ethernet controllers, a component in the latest Intel chip set, which already include a compatible network connection. Support for further Ethernet controllers in the future may be considered – in the light of the wide popularity of the Intel family and its compatibility even with Gigabit Ethernet (Intel 8254x family) – but not absolutely essential. The new Embedded-PC CX1000 small controller is, of course, always fitted with an appropriate Ethernet controller.

Performance

Judging the performance of a fieldbus system exclusively on the basis of the baudrate is, without doubt, too simple, ignoring as it does other significant communication parameters such as the efficiency of the protocols, reaction time, jitter, minimum telegram length, pause times and so forth. All the same, 100 Mbaud permit significantly faster data transfer than is usual at present in fieldbus environments. In addition to this, the protocols used provide a significantly improved efficiency in contrast with TCP or UDP communication, in particular when data telegrams are short.
One factor which is often ignored when considering the capacity of a fieldbus system is the transfer of data between the controller CPU to the communication chip or processor; that is to say, between the host system memory and the subsystem memory. In PC based controllers, the data is usually copied over the ISA or PCI bus into the DPRAM of a fieldbus master card, and vice-versa. Whereas PC processors have reached speeds of around 3 GHz, even the supposedly fast PCI bus has become a bottleneck, so that 20-30 % of the CPU performance is lost for PCI transfers.
Modern network controllers operate in what is known as the “bus master DMA mode”, accessing the host system’s memory directly. This occurs in parallel with other CPU tasks, and therefore significantly reduces the CPU load.

Applications/Linking to TwinCAT

The high data transfer capacity, the fundamental real-time capability and the protocols that are employed cover all the communication demands made by a fast machine controller. When all these features are considered we are soon led to the conclusion that classical fieldbusses are no longer needed.
First of all, however, Ethernet technology must still be proven at the field level, and must meet all requirements such as those for simplicity of installation and configuration, mutual compatibility, EMC immunity and, not least, efficiency and device costs relevant to the industrial environment. Standard fieldbusses are widely accepted, and there are many devices offered by many vendors including Beckhoff. Therefore, they will continue to have great significance to the market. Here once again, TwinCAT’s flexible I/O system offers a way forward: It permits multiple fieldbusses to be operated in parallel, including, of course, the parallel operation of classical fieldbusses with real-time Ethernet – and all of this is entirely transparent to the application.

Application Example 1:

Relatively simple applications can manage with a single Ethernet connection, both for the real-time communication to the I/O level and for the higher-level communication for the purposes of administration and remote diagnosis. The prioritization that is used ensures that the real-time communication takes place without difficulty.

Application Example 2:

Larger applications make use of a second Ethernet connection, and divide the real-time communication and the higher level communication between two networks. The routing that is required in order, for instance, to remotely diagnose a drive that is connected to a real-time network is performed automatically by the operating system’s IP stack, and does not require any proprietary conversion to a different protocol.

Application Example 3:

Very large applications, for which the computing power even of a 3 GHz system is insufficient, can distribute the control tasks between a number of PC controllers, and can exchange even large amounts of data quasi-synchronously with the cycles (even at sub-millisecond speeds), using the real-time capable network variables.