Introduction of TwinCAT Real-Time Ethernet
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.