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 [email protected] 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 [email protected] 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