November 2016
38
I
ndustrIal
C
ontrol
& C
omputIng
Multi-protocol controller
for Industry 4.0
Andreas Schwope,
Renesas Electronics Europe
With the R-IN Engine architecture
described in this article,
a device can process both network
communications and complex
applications simultaneously,
with extremely low delays, low jitter
and minimum power consumption.
Thus a multi-protocol industrial
automation product can be simply
implemented using a flexible, low-cost
R-IN single-device approach.
n
The automation industry is currently step-
ping into a new era often referred to as Indus-
try 4.0. This revolutionary step in production
facilities is based upon cyber physical sys-
tems. These combine available technologies
like internet communication and automated
operation controlled by sensor networks under
real-time processing conditions. Industry 4.0
requires the provision of big internal and exter-
nal databases in secured environments, and
allows just-in-time production of highly cus-
tomized products with a lot size of one. Hav-
ing this in mind it’s easy to see that the new
industry phase needs a much higher degree
of automation than before. To facilitate coop-
eration inside a complex production plant, the
different system components must be safely
interconnected via a high-speed network guar-
anteeing deterministic and fast data exchange.
A frequent production requirement at this
point is real-time processing with extremely
short cycle times. In addition to the pure
speed necessary, further time-critical parame-
ters must be met under all circumstances. The
most important of these are low jitter (small
deviations in the system causing recurring
delays) and isochronous behaviour (identi-
cal timebase for synchronized processes in
all network nodes). In particular this extreme
real-time capability of dedicated system com-
ponents requires special hardware functions
in certain points of the communication layer.
This allows fast and smooth data exchange
under all possible system conditions targeted
by Industry 4.0.
Is communication always the same? Looking
at the different standards used in automation
the answer is quite simple: unfortunately not,
we have different types of communication in
the industrial network arena. In the past many
communication protocols were developed,
which are nearly all based on the same Eth-
ernet standard IEEE 802.3. Due to different
company interests, strategies and local distri-
bution in the world, only the bottom two lay-
ers of the OSI model are roughly compatible
between the different Industrial Ethernet (IE)
standards. However the physical layer of the
IEEE 802.3 Ethernet and the general frame
format are in fact the same through the differ-
ent standards. Some examples of established
industrial network protocols are EtherCAT,
Profinet, EtherNet/IP, CC-Link IE, Modbus
TCP, Sercos III and Powerlink.
Applying a simplified model all of these com-
munication technologies can be divided into
two groups. In one group we find those pro-
tocols which are running with the “standard
IEEE 802.3” hardware which you can also
find in each and every PC of the world. In
most implementations this communication
hardware consists of an Ethernet MAC and
an Ethernet switch with one internal and two
external ports. The two external ports are
customary in industrial networks to realize
secured ring structures, while the single inter-
nal device port inserts and extracts data from
the network traffic to run the local node func-
tions. Only the upper communication layers
of this first group include the special protocol
functions in software. Members of this group
are Profinet, Profinet RT (Real-Time), Eth-
erNet/IP and Modbus TCP. To be even more
precise most of these protocols are based upon
the same TCP/IP and UDP/IP software stacks
running on the standard IEEE 802.3 hardware.
Others, like Profinet RT use a modified stack
with lower processing latencies optimizing
their speed and real-time capability.
The lower communication layers of the sec-
ond IE protocol group require certain special,
non-standard and sometimes unique functions.
Among others these functions are used for real-
time time management including network
synchronization, and control the automatic
extraction and insertion of Ethernet frame data.
Since this runs under high speed real-time con-
ditions, these protocols deviate from the Ether-
net standard and can be implemented only in
hardware in the form of a protocol controller.
The port structure of such controllers used in
protocols like Profinet IRT (Isochronous Real
