Standardization of Industrial Ethernet – the Next Battlefield?

Standardization of Industrial Ethernet – the Next Battlefield?

Standardization of Industrial Ethernet – the Next Battlefield?
Max Felser
Berne University of Applied Sciences
School of Engineering and Information
Technology
Jlcoweg 1, CH-3400 Burgdorf
max.felser@hti.bfh.ch
Abstract
Roughly two years after the end of the fieldbus war,
the IEC TC65 has started a new standardization project.
The definition of a Real-time Ethernet standard is a
logical consequence of the introduction of Ethernet in
industrial automation. Currently, several vendors have
already introduced their approaches on the market or
have at least finished specification. This paper gives an
overview of the various Ethernet-related activities in
IEC TC65, specifically cabling, real-time, safety, and
security issues. It reviews the candidates for
standardization and tries to investigate the chances of a
new fieldbus war.
1. Introduction
International fieldbus standardization has always been
a difficult endeavour. After a timely start in 1985 and a
few enthusiastic years of development, the quest for the
one and only comprehensive international fieldbus
gradually became entangled in a web of company
politics and marketing interests [1]. What followed was
an unprecedented struggle inside CENELEC and IEC
committees that finally ended up in the complete
abandonment of the original idea. Instead of a single
fieldbus, a collection of established systems was
standardized. In Europe, CENELEC adopted a series of
multi-volume standards compiled from specifications of
proven fieldbus systems. On a worldwide scale, IEC
defined a matrix of protocol modules, so-called “types”
[2], together with guidelines how to combine the various
modules to actually working fieldbus specifications [3].
With the adoption of the IEC 61158 standard on the
pathetic date of Dec. 31st, 2000, the fieldbus war seemed
to be settled just in time for the new millennium – not
necessarily to the satisfaction of the engineers who had
participated in the development of the international
fieldbus since the beginning [4], but at least to that of the
automation vendors who had finally secured their market
shares. The fieldbus world, at least for industrial and
process automation, had finally come to rest. On the
0-7803-8734-1/04/$20.00 ©2004 IEEE.
Thilo Sauter
Austrian Academy of Sciences
Research Unit for Integrated Sensor Systems
Viktor Kaplan Str. 2
A-2700 Wiener Neustadt
thilo.sauter@oeaw.ac.at
horizon, however, a new field of tension and friction
appeared: Industrial Ethernet.
In parallel to the struggles between the “classical”
fieldbus solutions, the rise of Ethernet had begun in the
late 1990s. Driven by the idea of using office standards
to achieve simple interconnection between field and
company level, Ethernet was pushed down into the
fieldbus domain. Many of the arguments brought
forward to promote Industrial Ethernet were actually
marketing-oriented, and the usefulness of standard
Ethernet remained disputed among experts [5]. As a
matter of fact, Industrial Ethernet devices can neither be
as cheap as in the office world, nor can plain Ethernet be
applied to control applications demanding some sort of
(not necessarily hard) real-time behaviour. To cope with
these limitations, many research projects proposed
solutions for the introduction of quality of service,
modifications to packet processing in switches, or
synchronization between devices.
Nevertheless, when the IEC 61158 compromise was
unveiled and put to vote, it was surprising for many
spectators that several Ethernet-based solutions had
already sneaked into the standard. In parallel, several
other approaches were under development outside
without normative support. Still two years ago, it seemed
that this situation would likely not end up in a new war
because the major players were already “in” [1]. Today,
however, the situation is slightly different. The IEC
SC65C committee has, beside its maintenance work on
the international fieldbus and its profiles, started a new
standardization project with the aim to define additional
aspects of Industrial Ethernet. And as in the case of the
fieldbus, there are several competing solutions and their
proponents represented in the consortium.
The purpose of this paper is to give an overview of
the current status of the standardization work. At the
time of writing, this status is still highly volatile, so this
article can present only a snapshot. Section 2 will give
an introduction to the new structure of IEC SC65C.
Subsequent sections will then describe each new
working group with their main goals and topics to
handle.
2. New Structure of IEC SC65C
In former times, the technical standardization work in
the fieldbus area was done in the working group 6
(WG6) of the IEC/SC65C. With the finalization of IEC
61158 Ed. 2, the work was transferred from the technical
working group to the maintenance team 9 (MT9). In
parallel, WG1 started with the definition of the fieldbus
profiles in IEC 61784-1. Therefore, when the new
standardization project on Real-time Ethernet was
launched, it was natural to give this task to WG1.
However, Real-time Ethernet comprises several
aspects that can to a large extent be treated more
efficiently in parallel. In order to distribute the work load
evenly and still maintain close cooperation, a new
structure of the SC65C was suggested and adopted.
Cooperation is required in so far as all new working
groups will build on the Fieldbus standards of the IEC
61158 series and their unifying set of profiles, IEC
61784-1. Apart from a larger number of WGs, the new
structure (Figure 1) essentially consists in the
establishment of the new position of a Technical
Coordinator, who is subordinate to the Chairman and
Secretary and serving a primarily advisory role for
working groups 10 through 13 and maintenance team 9.
the development of cabling to support fieldbus
installation beyond the machinery network interface in
the ISO/IEC JTC1/SC25 model (derived from CLC EN
50173) will be entirely the responsibility of ISO/IEC
JTC1/SC25. Nevertheless, there is a certain amount of
overlap, and it is clear that work to address new
environments cannot proceed properly unless the work is
truly done jointly. The minimum of cooperation are
mutual comments, however a joint working group
(JWG) is more promising.
The scope of this joint work was decided as follows:
The first task is to produce installation guidelines for
industrial cabling systems, up to and including the
Machine – or ‘Automation island’ – Network Interface
point in the ISO/IEC JTC1/SC25 (EN 50173) model.
This shall then become a standard from ISO/IEC
JTC1/SC25 and probably an adaptation of or an addition
to ISO/IEC 11801. The second task is to produce
installation guidelines for the actual Fieldbus networks,
to be published by IEC SC65C.
The new SC65C WG11 has the tasks to refine a
classification scheme for Real-time Ethernet (RTE)
requirements, to define profiles and related network
components based on the international Standards
ISO/IEC 8802-3 and IEC 61784-1, and to cover the
aspects of referencing to these and other existing
standards.
A new proposal [6] defined the topics of
communication for functional safety and security aspects
of communication. Originally combined in one WG, this
new work proposal was split into two separate activities.
65C/WG12 will address communications for functional
safety and 65C/WG13 will address cyber-security. The
first task for each group will be to define the exact goals
to reach.
3. Industrial Cabling (JWG10)
Figure 1: Organizational structure of IEC SC65C
The WG 7 (Function Block) and MT9 (Fieldbus
Maintenance) are already existing groups and will
continue their work. WG10 to WG13 are new working
groups for industrial communication like Ethernet,
Fieldbus, and Internet applications and will tackle new
domains of standardization for the automation
technology.
The task of the new joint working group
SC65C/JWG10 is to define the wiring and cabling of
Ethernet in an industrial environment. This was
traditionally the realm of ISO/IEC JTC1/SC25, who
defined standards for generic wiring in office and similar
environments and already requested that this new work
be co-ordinated with them in order to have clear
boundaries of competence. It was therefore agreed that
There are different reasons for new definitions and
guidelines for Industrial Ethernet: Ethernet in the office
area was intended to be used with fixed basic
installations in a building, laid under raised floors with
variable device connections to the workplace and prefabricated device connection cables in a tree-shape
network structure. In automation technology the cabling
and routing of the cables is largely system-related, the
connection points are rarely changed and should be
prepared directly in the field.
Apart from the handling differences, there is a
distinctive difference in the network topology. The
industrial people are used to wiring their machines using
a bus topology with a fieldbus and not with the IT star
topology (Figure 2). In fact, elimination of this
expensive cabling scheme was one of the starting points
of fieldbus developments several years ago. Another
typical network structure are (possibly redundant) rings.
Campus
CD
Distributor
CD
Building
Building BD
Office
BD
Distributor
MD
FD
Building
Production
Machine
Distributor
therefore claim to be conformant with the IAONA
specification, even if the mechanical outlines are
different. This is different with the PROFINET
specification [9], where the mechanical outline of the
RJ45 sealed connector is exactly specified and defined.
MD
Floor
Distributor
Floor 1
FD
Floor 2
Machine 1
Machine 2
Industrial RJ45 pulse-net connector
from Alden www.aldenproducts.com
Industrial RJ45 connector as
presented by ODVA
Industrial RJ45 connector from
Phoenix contact
Harting RJ45 connector according to
the PROFINET specification
Figure 2: Different structures of office and
industrial Ethernet
An obvious difference concerns environmental
conditions. In the office environment there are no strict
requirements about network availability and only
moderate requirements for temperature (0-50°C). There
is no moisture to cope with, virtually no vibrations and
EMC burden. For automation technology the
environment changes depending on the location of the
installation: inside a cabinet, watch tower or electronic
room, or outside directly in the plant. The degree of
pollution may vary from IEC 625-1 grade 2 to grade 3
and the protection level from IP 20 up to IP 65 or even
IP 67. The requirements for shock are up to 20g/11ms
and vibrations of 5g. The typical temperature range is 20 up to 700C (requirements from [9]). The office
equipments do not fulfil these requirements.
Last not least, there is the problem of connectors. In
the IT world the RJ45 connector is most widely used. So
the first approach is to use the same connector but make
it harder with an additional housing. There exist at least
20 different solutions to modify a standard RJ45
connector in order to obtain an industrial-grade
connector. Figure 3 shows some examples supported by
different manufacturers and fulfilling the requirements of
different organisations. The major conclusion for the end
user is, that contrary to the office environment there
exists not just one industrial RJ45 connector but several
versions which are mutually incompatible. The
additional housing introduces another problem: The
spacing of sockets in office-world switches is very tight.
With the industrial versions of the connectors, it is
impossible to use all available sockets on conventional
switches, so that larger (in terms of port numbers) or
more components are needed.
Ethernet/IP of the ODVA organisation specifies in [7]
a sealed RJ-45 variant. The housing shall meet a
minimum of IP67 sealing performance as defined in IEC
60529. Likewise, also IAONA specifies in its guidelines
[8] only the protection class, but not the mechanical
outline of the connector. Every manufacturer may
Figure 3: Industrial RJ45 connectors
An alternative solution is to take an M12 connector
for the sealed IP67 Ethernet connection. For this a M124 D-coded layout as defined in IEC 61076-2-101 is
recommended by most systems. The coding however is
different and follows variant 1 of IEC 61076-3-106 for
Ethernet/IP, variant 4 for PROFINET (Figure 4 [9]) and
variant 6 for other profiles of IAONA. Some American
manufacturers, on the other hand, prefer the M12-8 pin
layout to permit full functional compatibility with the
RJ45 connector.
Figure 4: Layout and coding of a M12-4
Ethernet connector for PROFINET
4. Real Time Ethernet (WG11)
The Industrial Ethernet solutions originally contained
in the IEC 61158 are High Speed Ethernet (HSE) of
Foundation Fieldbus, Ethernet/IP (the Ethernet pendant
of ControlNet and DeviceNet), and PROFINET. These
three systems use fieldbus application layer protocols on
top of the standard Internet transport protocols TCP and
UCP. Below, they build on Ethernet in its original form,
i.e., the physical and data link layer of ISO/IEC 8802-3
without any modifications. The real-time capabilities of
Table 1: Communication profiles defined in IEC 61784-1
IEC 61784-1
Profile
CPF-1/1
CPF-1/2
CPF-1/3
CPF-2/1
CPF-2/2
CPF-3/1
CPF-3/2
CPF-3/3
CPF-4/1
CPF-4/1
CPF-5/1
CPF-5/2
CPF-5/3
CPF-6/1
CPF-6/2
CPF-6/3
CPF-7/1
CPF-7/2
IEC 61158 Protocols
Phy
Type 1
Ethernet
Type 1
Type 2
Ethernet
Type 3
Type 1
Ethernet
Type 4
Type 4
Type 1
Type 1
Type 1
Type 8
Type 8
Type 8
Type 6
Type 6
DLL
Type 1
TCP/UDP/IP
Type 1
Type 2
TCP/UDP/IP
Type 3
Type 3
TCP/UDP/IP
Type 4
Type 4
Type 7
Type 7
Type 7
Type 8
Type 8
Type 8
Type 6
Type 6
these approaches are limited and must rely on
application-level mechanisms controlling the data
throughput. For advanced requirements, like drive
controls, this is not sufficient. These known limitations
of conventional Ethernet stimulated the development of
several alternative solutions that were not only
adaptations of ordinary fieldbus systems. These entirely
new approaches were originally outside the IEC
standardization process, but are now candidates for
inclusion in the RT Ethernet standard.
The initial and boundary conditions for the
standardization work are targeted at backward
compatibility with existing standards. First of all, Realtime Ethernet is seen as an extension to the Industrial
Ethernet solutions already defined in the communication
profile families in IEC 61784-1. Furthermore,
coexistence with conventional Ethernet is intended. The
scope of the working document [10] states that “the RTE
shall not change the overall behavior of an ISO/IEC
8802-3 communication network and their related
network components or IEEE 1588, but amend those
widely used standards for RTE behaviors. Regular
ISO/IEC 8802-3 based applications shall be able to run
in parallel to RTE in the same network”. Reference to
the time distribution standard IEEE 1588 [12] is made
because it will be the basis for the synchronization of
field devices.
The work program of the RTE working group
essentially consists of the definition of a classification
scheme with RTE performance classes based on actual
application requirements [11]. This is a response to
market needs which demand scalable solutions for
different application domains. These classes will then be
the building blocks for additional communication
profiles. The intended structural resemblance to the
Brand names
AL
Type 9
Type 5
Type 9
Type 2
Type 2
Type 3
Type 3
Type 10
Type 4
Type 4
Type 7
Type 7
Type 7
Type 8
Type 8
Type 8
Type 6
Foundation Fieldbus (H1)
Foundation Fieldbus (HSE)
Foundation Fieldbus (H2)
ControlNet
EtherNet/IP
PROFIBUS-DP
PROFIBUS-PA
PROFInet
P-Net RS-485
P-Net RS-232
WorldFIP (MPS,MCS)
WorldFIP (MPS,MCS,SubMMS)
WorldFIP (MPS)
INTERBUS
INTERBUS TCP/IP
INTERBUS Subset
Swiftnet transport
Swiftnet full stack
fieldbus profiles is manifested by the fact that the
originally attributed document number IEC 62391 was
changed to IEC 61784-2. As stated in the original
working document [10], the technological basis for the
development will be switched Ethernet, a bus structure,
i.e., a shared medium is not of primary interest. In
reality, however, there will be at least one RTE solution
(namely, Ethernet Powerlink) which uses a shared
medium.
One possible classification structure could be based
on the reaction time:
• A first low speed class with reaction times around
100 ms. This timing requirement is typical for the
case of humans involved in the system observation
(10 pictures per second can already be seen as a lowquality movie), for engineering, and for process
monitoring. Most processes in process automation
and building control fall into this class. This
requirement may be fulfilled with a standard system
with TCP/IP communication channel without many
problems.
• In a second class the requirement is a reaction time
below 10 ms. This is the requirement for most
tooling machine control system like PLCs or PCbased control. To reach this timing behaviour special
care has to be taken in the RTE equipment: Powerful
and expensive computer resources are needed to
handle the TCP/IP protocol in real-time or the
protocol stack must be simplified and reduced to get
these reaction times on simple, cheap resources.
• The third and most demanding class is given by the
requirements of motion control: To synchronise
several axes over a network, a cycle time less than 1
ms is needed with a synchronization accuracy of not
more than 1 µs. Although this can be achieved with
distributed applications and high-accuracy clock
synchronization, the mainstream belief of automation
vendors is different: They focus on 100 MBit/s
Ethernet networks and modifications of both medium
access and hardware structure of the controllers.
At the moment there are several systems which have
the potential to fulfil at least parts of such an RTE
specification and are already or will be shortly
introduced on the market. From these systems, three are
extensions to fieldbusses already contained in IEC 61784
(Table 1):
Ethernet/IP defined by Rockwell and supported by
ODVA and ControlNet International makes use of the
Common Interface Protocol (CIP) which is common to
the networks Ethernet/IP, ControlNet, and DeviceNet.
CIP defines objects and their relations in different
profiles and fulfils the requirements of class 1 on
Ethernet/IP. With the CIPsync extensions it is possible to
get isochronous communication that satisfies class 2
applications. These extensions use 100 MBit/s networks
with the help of IEEE 1588 time synchronisation.
PROFINET is defined mainly by Siemens and
supported by PROFIBUS International. A first version
was based on automation components which are
connected over TCP/UDP/IP connection. A second step
was the definition of a Real Time (RT) solution for
PROFINET I/O. In this version class 2 performance is
reached also for small and cheap systems by eliminating
the TCP/IP stack for process data. Input and output (I/O)
data are directly packed into the Ethernet frame with a
specialized protocol. Class 3 communication is reached
with a special switch ASIC with a short and stable cutthrough time and special priority mechanism for realtime data. Synchronization is based on an extension of
IEEE 1588 using on-the-fly time stamping, an idea
which has been introduced before in a different context
by others [13]. The first application planned for
PROFINET IRT (Isochronous Real-Time) is the
PROFIdrive profile for motion control applications.
INTERBUS will also have an RTE extension.
Originally this was intended to be placed directly above
the MAC layer and to use parts of IEEE 802.1D/Q
(Priority / VLAN Tagging). Recently, however, Phoenix
Contact announced that they will not develop a separate
solution, but rather use PROFINET as the RTE basis for
INTERBUS. Nevertheless, there will be a special profile
defining the devices linking PROFINET and
INTERBUS.
The Foundation Fieldbus High Speed Ethernet is at
the time of writing of this paper not considered as a
candidate for RTE. Apart from these approaches that
merely extend well-known fieldbus systems, there is a
multitude of new concepts collected in IEC 61784-2
(Table 2). Many of these solutions, especially those from
the far East, are not well known in the community, and it
is difficult to obtain information about them.
Table 2: New RTE profiles in IEC 61784-2
IEC 61784-2 Profile
CPF-10
CPF-11
CPF-12
CPF-13
CPF-14
CPF-15
Brand names
VNET/IP
TCnet
Ethercat
EPL (Ethernet Powerlink)
EPA
MODBUS
VNET/IP has been developed by Yokogawa. The realtime extension of this protocol is called RTP (Real-time
& Reliable Datagram Protocol). Like many others, it
uses UDP as transport layer. Special about the approach
are an optimized IP stack (with respect to processing
times) and a concept for redundant network connections.
TCnet is a proposal from Toshiba. Here, the real-time
extension is positioned in the MAC layer. Also a dual
redundant network connection is proposed, based on
shared Ethernet.
EtherCAT defined by Beckhoff and supported by the
Ethercat Technology Group (ETG) uses the Ethernet
frames and sends them in a special ring topology. Every
station in the net removes and adds its information. This
information may be special input/output data or standard
TCP/IP frames. To realise such a device a special ASIC
is needed for medium access which basically integrates a
two-port switch into the actual device. The performance
of this system is very good: it may reach cycle times of
30 µs.
Powerlink was defined by B&R and is now supported
by the Ethernet Powerlink Standardisation Group
(EPSG). It is based on the principle of using a masterslave scheduling system on a shared Ethernet segment
called Slot Communication Network Management
(SCNM). The master ensures the real-time access to the
cyclic data and lets standard TCP/IP frame pass through
only in specific time-slots. To connect several segments,
clock synchronisation based on IEEE 1588 is used. This
solution is the only product available on the market
which fulfils the class 3 requirements already today. In
the future the CANopen drive profiles will be supported.
The EPA protocol (Ethernet for Process Automation)
is a Chinese proposal. It is a distributed approach to
realize deterministic communication based on a time
slicing mechanism.
Modbus/TCP defined by Schneider Electric and
supported by Modbus-IDA uses the well-known Modbus
over a TCP/IP network. This is probably the most widely
used Ethernet solution in industrial applications today
and fulfils the class 1 requirements without problems.
Modbus/TCP was – contrary to all other fieldbus
protocols – submitted to IETF for standardization as an
RFC [14]. The real-time extensions use the Real-time
Publisher Subscriber (RTPS) protocol which runs on top
of UDP.
An additional approach is SERCOS, well known for
its CNC control optical ring interface. With SERCOS III,
also an Ethernet based solution is under development.
The ring structure is kept and the framing replaced by
Ethernet frames to allow easy mixture of real-time data
with TCP/IP frames. In every device a special software
or for higher performance (an FPGA) will be needed
which separates the real-time time slot from the TCP/IP
time slot with a switch function. Originally, the
SERCOS activities were conducted completely outside
SC65C in IEC SC22G (Adjustable speed electric drive
systems incorporating semiconductor power converters),
who issued the respective standard IEC 61491. Recently,
however, there has been an interesting proposal to
introduce the SERCOS communication protocol in the
next revision of IEC 61158 and the communication
profile for Ethernet-based SERCOS III in IEC 61784-2
[15]. Currently, this motion is under vote. If adopted, it
will be a further step to gather all relevant fieldbus
systems under one umbrella standard.
Another recent proposal is to include also an RTE
profile for P-Net. From what is known today, this seems
to be a straightforward application of the well-known PNet protocol stack on top of Ethernet.
Table 3 (in the appendix) shows a summary of
features of the individual RTE approaches and a
comparison of their characteristics, as far as specific data
are already available. For practically all systems, the data
have to be seen as development objectives, as actual
implementations are not yet available. What the table
does show, however, is how different the individual
solutions are. This collection impressively confutes one
of the most used marketing arguments in the Industrial
Ethernet world: that Ethernet in automation provides a
uniform and consistent solution. It is precisely this
diversity that makes it so difficult for the WG11 to
define common criteria and classification schemes that
fit all proposals – and to make them comparable.
The WG11 defined as a goal, that all candidates must
be backwards compatible to the existing Ethernet
solutions. This definition of “compatibility” is not very
precise: does it mean that the new RTE solutions must be
able to be mixed with office Ethernet solutions? With
this interpretation most of the proposed solutions will not
be adopted. There is also a strong tendency inside the
standardisation group, that different RTE protocols will
only be accepted, if it is possible to build auto-detection
devices, which detect and adopt the correct protocol and
profile automatically. This argument is technically
sound, but could as well be the starting point for another
standardization battle.
5. Communications for functional safety
(WG12)
The IEC standard 61508 for functional safety in
programmable electronic systems [16] describes the
functionality of safety networks. The seven-part standard
defines the requirements for a safety system to comply
with the appropriate safety integrity level (SIL).
Recently introduced, IEC 61508 redefined the way
safety systems are assessed, switching from a
prescriptive rules-based approach to a goal-oriented
approach. This change has been instrumental in allowing
the development of advanced safety control systems and,
in particular, in the growing use of safety networks as an
alternative to hardwired circuits. Prior to IEC 61508, a
vendor demonstrated that its components and solutions
were designed in accordance with block diagrams
prescribed by the assessors. Now users and vendors
together perform risk assessments to examine potential
failures, documenting the consequences and probability
of occurrence. This analysis determines the SIL that
must be achieved by the protective system, which in turn
defines the maximum allowable probability of failure on
demand (PFD, Table 4).
The top-most integrity level (SIL 4) is applied to such
critical equipment as that used on aircraft and in nuclear
power plants. Meanwhile, SIL 3 is the highest level
found in traditional manufacturing and process
applications. With the new goal-oriented approach, the
end result is more important than the equipment used to
achieve it. So essentially, the new standard questions
whether a system is safe rather than if it “looks” safe.
Once this determination has been made, the decision of
whether to use a network is the same as deciding on
networks in standard applications, such as improved
diagnostics, lower cost or the need for a distributed
system.
Table 4: Definition of safety integrity levels
Safety
Integrity
Level
SIL 4
SIL 3
SIL 2
SIL 1
Mode of operation
Average probability of failure on demand – per hour
Low Demand
> 10-5 to < 10-4
> 10-4 to < 10-3
> 10-3 to < 10-2
> 10-2 to < 10-1
High Demand or Continuous
> 10-9 to < 10-8
> 10-8 to < 10-7
> 10-7 to < 10-6
> 10-6 to < 10-5
Now that the IEC standards framework no longer
excludes safety networks, several vendors and/or
organizations are rapidly developing multiple networks
to meet the expected demand from end users. Due to the
general nature of guaranteeing safety, these networks
will most likely share basic features, such as predetermined safety states, determinism and dual-CPU
designs. Most importantly, safety networks must be
designed to allow devices to enter a pre-determined safe
state when a communication error occurs. A safe state
for one device, such as the swinging robotic arm, could
be immediate “power off”. The safe state for an exhaust
fan, by contrast, could be “power on” ensuring that
harmful substances cannot accumulate and if present are
dispersed.
Second, a safety network must be deterministic to
ensure all safety messages are transmitted in a
predefined and predictable amount of time. A safety
network allows customization for each device to have its
own periodic response time. This is scaleable to a single
device or a chain of associated safety devices. From this,
safety devices have guaranteed expectation of message
delivery. In one system this is reached by the inclusion
of timestamps in the messages, other approaches might
just verify the delay in the receiver. Safety messages
arriving beyond the time expectation will cause the
affected connection and associated device(s) to go to
their safe state. To reach the expected accuracy one
system might use double transmission of the data with
inverted bits, while others use special CRCs to protect
the transmitted data from corruption.
All these principle are actually implemented in
different fieldbus systems available on the market with
different technical approaches. It is the goal of WG12, to
find a common description and structure for these
approaches. At the time of writing, the three systems
CIPsafety or Ethernet/IPsafety [17], INTERBUS Safety
[18] and PROFIsafe [19] are candidates to be considered
in this working group. This selection is somewhat
arbitrary and reflects the intentions of the committee
members. There are other approaches (like SafetyBUS or
WorldFIP) that were not proposed inside WG12.
6. Cyber security (WG13)
Security has never been a real issue in conventional
fieldbus systems. This is understandable in so far as
fieldbusses were originally mostly conceived as closed,
isolated systems, which raised no need for security
concepts. In building automation, where networks are
naturally larger and more complex, the situation is
different, and at least rudimentary security mechanisms
are supported [20]. In factory and process automation,
things changed with the introduction of vertical
integration and the interconnection of fieldbusses and
office-type networks. In such an environment, security is
an essential topic on all network levels. Given the lack of
appropriate features on fieldbus level, security concepts
had to be limited to the actual network interconnection
[21, 22].
With the introduction of Ethernet in automation, a
reconsideration of field-level security is possible. This is
facilitated by the fact that many Industrial Ethernet
solutions use IP and the Internet transport protocols UDP
and TCP on top of Ethernet. One should recognize,
however, that there are other approaches that use
proprietary protocols above Ethernet, and that Ethernet
per se is not the layer where security features can be
reasonably implemented.
The fact that automation networks do not have
security features up to now is also reflected in the work
of the IEC SC65C WG13. Unlike the other working
groups, where the aim of the members is to get concrete
proposals of established systems into the standards, no
ready-to-use proposals exist. Apart from general
considerations, the work has to be started largely from
scratch. There is, however, related work in other fields
that is being considered:
• IEC 61508 – Functional safety of electrical/electronic/programmable electronic safety-related systems,
maintained by IEC/SC 65A. Functional safety is in
principle covered by the work of WG 12, but the
common understanding is that safety-related systems
necessarily also have security aspects.
• Work being done in IEC TC57 / WG15– Power
systems management and associated information
exchange / Data and communication security.
• ISO/IEC 17799 – Code of Practice for Information
Security Management
• ISO/IEC 15408 – Common Criteria for IT Security
Evaluation
• ISA SP99 – Manufacturing and Control Systems
Security. It can be expected that this US activity will
have significant influence on the WG 13 work.
• AGA/GTI 12 – Cryptographic Protection of SCADA
Communications
• NIST PCSRF – Process Control Security
Requirements Forum
For the time being, the actual scope of the work still
needs to be defined. It is intended, though, to produce a
standard and not just a set of recommendations published
as a technical report. Subsequent meetings will bring
more clarity concerning the path to follow.
7. Summary
The recent activities of the IEC SC65C show that
there is substantial interest especially from the industry
in the standardization of Real-time Ethernet. This
situation resembles closely the one in fieldbus
standardization at the beginning of the 1990ies. Then,
the result was effectively an obstruction of the
standardization process for almost ten years. Given the
comparable initial situation, will history repeat itself?
Our opinion is that this will – despite the fierce
competition already noticeable on the market– not be the
case. There are two arguments that support this thesis:
• The structure of the working groups and especially
the structure of the intended standard documents
already anticipate a multi-part solution. So the
compromise that in former days needed so long to be
found is already foreseen this time.
• The big automation vendors have learnt their lessons
to avoid time- and resource-consuming struggles that
eventually end up in compromises anyway.
Moreover, the IEC itself cannot afford a new
standardization war that will damage their image.
Hence, all parties involved should have sufficient
interest that the standardization process will be smooth
and fast without too much noise inside the committees.
This time, the automation world should see a timely
conclusion of the work to be done. And indeed a timely
conclusion is necessary, even though this currently
seems difficult at least for the work of WG11. The
timeframe set by the IEC was that a committee draft be
ready in October 2004. If this deadline is not met, there
is the threat that the IEC will send the project back to the
start.
[8]
[9]
[10]
[11]
[12]
[13]
References
[14]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
M. Felser and T. Sauter, “The Fieldbus War: History or
Short Break between Battles?”, IEEE International
Workshop on Factory Communication Systems (WFCS),
Västerås, 28.-30. Aug. 2002, pp. 73-80.
International Electrotechnical Commission, IEC 61158,
Digital data communications for measurement and
control - Fieldbus for use in industrial control systems,
2003
International Electrotechnical Commission, IEC 617841, Digital data communications for measurement and
control - Part 1: Profile sets for continuous and discrete
manufacturing relative to fieldbus use in industrial
control systems, 2003
P. Leviti, “IEC 61158: An Offence to Technicians?”,
IFAC International Conference on Fieldbus Systems and
their Applications, FeT 2001, Nov. 15-16, 2001, Nancy,
France, pp. 36.
J. D. Decotignie, “A perspective on Ethernet-TCP/IP as a
fieldbus”, IFAC International Conference on Fieldbus
Systems and their Applications, FeT 2001, Nov. 15-16,
2001, Nancy, France, pp. 138-143.
TC65/SC65C, new work item proposal, 65C/307/NP,
2003.
ODVA: Volume 2: Ethernet/IP Adaptation of CIP;
Chapter 8: Physical Layer, Open DeviceNet Vendor
Assoc. & ControlNet International, April 26, 2001,
http://www.odva.org
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
IAONA: Industrial Ethernet Planning and Installation
Guide, Release 3.0, IAONA e.V. Magdeburg,
http://www.iaona-eu.com
PROFIBUS International: Installation Guideline
PROFINET, Version 1.8, November 2002, Order No.
2.252, http://www.profibus.com
TC65/SC65C, New work item proposal, 65C/306/NP,
2003.
TC65/SC65C, Meeting minutes, 65C/318/INF, 2003.
IEEE 1588, Standard for a Precision Clock
Synchronization Protocol for Networked Measurement
and Control Systems, 2002
R. Höller, G. Gridling, M. Horauer, N. Kerö, U. Schmid,
K. Schossmaier, “SynUTC – High Precision Time
Synchronization over Ethernet Networks”, LECC, Proc.
Of the 8th Workshop on Eletronics for LHC
Experiments, Colmar Sept. 9-13 2002, ISBN: 92-9083202-9; 428 - 432.
Schneider Automation, Modbus messaging on TCP/IP
implementation
guide,
May
2002,
http://www.modbus.org/
TC65/SC65C, Questionnaire, 65C/346/Q, July 2004.
International Electrotechnical Commission, IEC 61508 –
Functional safety of electrical/electronic/programmable
electronic safety-related systems
ODVA: Safety Networks: Increase Productivity,Reduce
Work-Related Accidents and Save Money, Open
DeviceNet Vendor Assoc.. White Paper, 2003,
http://www.odva.org
INTERBUS Club: INTERBUS Safety, White Paper (in
german), INTERBUS Club Deutschland e.V., 2003
PROFIBUS International: Profile for Failsafe with
PROFIBUS, DP-Profile for Safety Applications, Version
1.2,
October
2002,
Order
No.
3.092,
http://www.profibus.com
C. Schwaiger and A. Treytl, “Smart Card Based Security
for Fieldbus Systems”, 2003 IEEE Conference on
Emerging Technologies and Factory Automation,
Lisbon,16.-19. Sep. 2003 ,pp. 398-406, 2003.
T. Sauter and C. Schwaiger, “Achievement of secure
Internet access to fieldbus systems”, Microprocessors
and Microsystems, 26 (2002), pp. 331-339.
P. Palensky and T. Sauter, “Security Considerations for
FAN-Internet
Connections”,
IEEE
International
Workshop on Factory Communication Systems, Porto,
6.-8. Sep. 2000, pp. 27-35.
I/O data mapper with
RT protocol
(PROFINET IO)
IRT protocol in
switch ASICs
cycle of 1 ms with
150 axes
Communication
between systems,
Manufacturing
technology, motion
control
www.profibus.com
CIP
CIPsync
CIP, CIPsync
Based on IEEE
1588
-
-
Manufacturing
technology,
communication
between systems
www.odva.org
www.controlnet.o
rg
Technology
class 1
Technology
class 2
Technology
Class 3
Best
Performance
Application
Links
Siemens, Beckhoff,
Bosch Rexroth,
Danfoss, GE Fanuc,
Harting, Hilscher,
Kuka, Phoenix
Contact, Saia, SEW,
Sick, Turck
Line with special
Switch
PROFINET CBA
PROFINET IO
PROFIdrive
Distributed Functions
oriented on IEC
61599
(PROFINET CBA)
all important
manufacturers
mainly from US
Aplicationprofiles
Siemens
Rockwell
Main
manufacturer
Other
manufacturers
Switch
IEC 61784-1
CPF 3
PI
Profibus International
IEC 61784-1
CPF 2
ODVA (Open
DeviceNet Vendor
Association)
ControlNet
International
Standard
Profile
Organisation
Topology
PROFINET
Ethernet/IP
Product
Manufacturing
technology
Same as
PROFINET
Same as
PROFINET
Same as
PROFINET
Same as
PROFINET
Line with
special switch
Same as
INTERBUS
Phoenix
Contact
Phoenix
Contact
IEC 61784-1
CPF 6
INTERBUS
Club
INTERBUS
Manufacturing
technology
Cycle of 50 ms
with restricted
number of
stations
Realtime Datagram Protocol
(RDP)
-
TCP channel
Not specified
No restrictions
Yokogawa
Yokogawa
IEC 61784-2
CPF 11
VNET/IP
TCP channel
CANopen (not
exclusive)
Line, Tree
Beckhoff, ABB,
Baldor, Baumüller,
Kuka, Philips
Beckhoff
IEC 61784-2
CPF 13
ETG
Ethercat Technology
Group
Ethercat
Distributed control
www.ethercat.org
Decentralised IO and
motion control
Only one frame goes
through all stations,
special ASIC.
High speed cycle of Cycle 100 us with
10 ms with 64
100 axes
blocks of 64 words
Distributed memory application with
special MAC
-
TCP
Not specified
No restrictions
Thoshiba
Thoshiba
IEC 61784-2
CPF 12
TCnet
www.ethernetpowerlink.org
Motion control
Master-Slave
with standard
HW
Cycle 400 µs
with 8 leading
axes and up to
240 slave axes
Based on IEEE
1588
TCP timeslot
CANopen
B&R, ABB,
Baldor,
Baumüller,
Harting,
Hirschmann,
Kuka, Lenze,
Lust
Hub
B&R
IEC 61784-2
CPF 14
EPSG
Ethernet
Powerlink
Standardisation
Group
Powerlink
Appendix: Table 3: Overview of Real Time Ethernet (RTE) solutions
Client-Server
of Objects
Modbus
Schneider
Electric
Schneider
Electric, Jetter,
Lenze,
Phoenix
Contact, GE
Fanuc,
Mitsubishi
Switch
IEC 61784-2
CPF 16
Modbus-IDA
Modbus TCP
Process
automation
Cycle of 1ms in
one EPA
segment
www.modbus.
org
Communicatio
n between
systems
-
Macro cycle with under
RTE and non
development
RTE timeslots
-
TCP timeslot
Not specified
No restrictions
SUPCON
IEC 61784-2
CPF 15
China
EPA
www.sercos.de
Fast motion
control
Cycle 500 us
with 150 Axes
Timeslot with
special HW
TCP channel
Sercos
Ring/Line
Bosch Rexroth,
Rockwell
Bosch Rexroth
Sercos
Serial Realtime
Communication
System
IEC 61491
SERCOS III