iCC 2003 CAN in

Integration of CAN-based Networks into the PROFInet Environment

Axel Pöschmann, Lutz Rauchhaupt, Thomas Werner, ifak e. V. Magdeburg

PROFInet is an international standard for -based industrial communication systems. It considers the integration of systems, such as CANopen, which is well established in the field level of industrial automation. In the paper the different concepts of the PROFInet model are introduced. In particular the so called migration concept is explained, which deals with the possibility to integrate fieldbus systems into the PROFInet environment using a so called Proxy device. For CANopen the architecture of such a Proxy is described and the relation to the CANopen model elements is discussed. Finally an implementation concept of a CANopen Proxy with static CANopen device assignment is presented. Ethernet meets CAN transparent and consistent view inside both systems. Solutions which combine Ethernet-based communication (mostly also IP-based) and PROFInet Model CAN-based communication have been PROFInet is a modern concept for known for a long time (e.g. [1], [2]). distributed automation standards. It is However, in factory automation, the open based on Ethernet and is able to integrate integration of field level networks in existing fieldbus systems. Automation factory-wide information networks is systems usually consist of several sub- demanded by end-users. One approach of units, which act as technological modules integration is the TCP/IP and DCOM largely autonomously and coordinate their based international standard PROFInet for interactions by means of a manageable distributed components. Other solutions number of synchronisation signals, are known as Ethernet/IP, FF HSE and sequence control signals and information IDA. An overview of all these systems is exchange signals. These technological given in [6]. modules consist of a combination of The main goal of the PROFInet mechanical, electrical and software parts, architecture is to provide a common i. e. parts belonging to an intelligent platform or framework to combine function. The technological modularisation mechanical, electrical, and software simplifies the re-use of pre-manufactured components under a common engineering and pre-tested components. In order to view. Even if PROFInet includes hard real communicate with other components time solutions and soft real time solutions within a distributed system, a component based on Ethernet, the integration of supports a defined interface to the outside standard fieldbus systems like CAN is an world. PROFInet unifies these interfaces important point, saving investment by using the following concepts. integrating the installed base and Engineering Concept combining useful technologies. A so called Proxy is used to represent the fieldbus as The PROFInet standard contains a a whole or even single stations as manufacturer independent engineering components in the PROFInet sense. CAN- concept. Manufacturer or user specific based automation networks are used enhancements of the functionality can be world-wide in control systems and inside enabled by means of facets. The machines. Therefore, the design of such a engineering model can be used to develop Proxy will become very important. The own engineering tools, e. g. a connection CAN Proxy for PROFInet must combine editor. Using such an editor, components the configuration, diagnostics and process of different vendors can be connected with data facilities of both systems to achieve a each other.

09-9 iCC 2003 CAN in Automation

PROFInet components are described with the logical device (LDev), the runtime XML files which are used within the automation (RT-Auto) and the active engineering system. The used XML control connection object (ACCO). scheme is defined in the PROFInet Each PDev represents one physical standard [15]. An XML file is generated component and provides its access to an manufacturer specific within a so called IP network. The implemented software is componer and is part of the PROFInet represented by one or more LDevs. It device. During the engineering process all enables navigation to the further objects. communication relations are defined The ACCO handles all connections. The simply by graphical wires. After the system automation functionality is represented by definition with the connection editor, all the RT-Auto. connections can be loaded into the devices, which belong to the plant In the case of CANopen the runtime network. Furthermore, device-specific data environment is located in a special device, is loaded, if defined. The engineering tool the so called Proxy. The CANopen supports an online view to check the devices remain unchanged and are states of the devices and all connections. nevertheless part of the PROFInet system. This is the engineering infrastructure The way how this is accomplished is which could be used also for CANopen explained in the following chapters. sub-networks. Migration Concept Runtime Concept An open migration concept enables the The runtime communication concept of integration of devices, connected by PROFInet is based on the DCOM Wire fieldbus systems, to PROFInet using a Protocol and TCP/IP. For real time Proxy. There are two main strategies purposes PROFInet also offers an available to integrate a fieldbus based optimised communication channel (SRT). automation sub-system. The first one is to Components are described with the object hide the fieldbus system and its devices model. The data is transferred via the behind one PROFInet component as configured communication relations, using depicted in Figure 2. In this case the the object protocol. underlying communication infrastructure is not of interest. From the PROFInet point of The source code of the PROFInet stack is view it is not visible. Only the relevant available for different operating systems. It inputs and outputs are made available to can be downloaded for free by members connect them with other components. of the user organisation. This software consists of the following layers: DCOM, connection oriented RPC and DCOM application. In Figure 1 the DCOM PROFInet Component application is shown containing the runtime objects physical device (PDev), Ethernet/PROFInet

Physical Physical Device Device (=Hardware) PROFInet 1 Ethernet- Component Fieldbus-Gateway * Logical Device ACCO Fieldbus 1 1

1

Fieldbus Fieldbus Fieldbus Device Device Device

* • Process Data (I/O Data) RT-Auto Logical Device • Diagnosis (=Software) • Alarms • Data records

Figure 1: PROFInet – Runtime Figure 2: Sub-system as PROFInet Object Model [7] component 09-10 iCC 2003 CAN in Automation

PROFInet Component

Ethernet/PROFInet

Proxy Proxy Proxy

PROFInet PROFInet PROFInet Ethernet- Component Component Component Fieldbus-Gateway

Fieldbus

Fieldbus Fieldbus Fieldbus Fieldbus Fieldbus Device Device Device Device Device

• Process Data (I/O Data) • Process Data • Process Data • Diagnosis • Diagnosis • Diagnosis • Alarms • Alarms • Alarms • Data records • Data records • Data records

Figure 3: Fieldbus devices as PROFInet component

If it is necessary that also fieldbus devices to available PROFInet mechanisms. are visible in the context of PROFInet the Physically the Proxy contains the Proxy concept must be applied. This is PROFIBUS master, the PROFInet stack shown in Figure 3. and an Ethernet controller. The assigned In the PROFInet standard [7] an example slaves are connected to the Proxy via is given in detail using PROFIBUS. PROFIBUS. Figure 4 shows the appropriate object A similar solution is supposed to be model. It consists of a PDev that complies developed for CANopen. In the following the whole PROFIBUS system. Every slave chapter different approaches are shown device is represented by one LDev. A that are possible. special mapping provides access to the cyclic (process) data of the slave devices. Architecture of a CANopen Proxy The data is available at the interface of the The common architecture of a CANopen LDevs and can be connected with other Proxy is depicted in Figure 5. It contains LDevs (inside or outside PROFIBUS). the PROFInet software, an operating Local connections (inside) are detected system, an Ethernet controller, a and can be realised directly by the CANopen stack implementation and a PROFIBUS master. Furthermore, the special PROFInet system adaptation, that PROFIBUS diagnosis and the operating combines all components. The main tasks state of assigned slaves must be mapped of a Proxy are the implementation of local

Figure 4: PROFInet - object assignement 09-11 iCC 2003 CAN in Automation

CANopen Configuration Data

connection information performing the connections

Proxy

PROFInet - Runtime

TCP/IP Inputs Outputs

Ethernet CANopen node

CAN

Figure 5: Proxy architecture connections, the instantiation of objects for Either fieldbus specific tools shall be used every assigned CANopen node as well as or not. the mapping of data types, diagnosis and Type B: PROFInet component is a operating states between CANopen and CANopen device (static) PROFInet. Every CANopen node is a separate A CANopen Proxy needs special component. From the object model point configuration information which has to be of view the Proxy contains one PDev and transferred into the device via a in addition for each CANopen device one proprietary way, like ftp. It is possible to LDev, ACCO and RT-Auto. In this case it start this process from the connection is not possible to configure the fieldbus editor environment. A special componer from the view of PROFInet. It is a static generates the necessary XML files and the configuration. Furthermore the CANopen configuration data. With this data the sub-system is not visible within the Proxy has the ability to instantiate the network view of the connection editor. necessary runtime objects (loadable Reconfiguration can be done with objects). separate CANopen tools and processes. The previous described migration Type C: PROFInet component is a strategies can be applied as follows. CANopen device (dynamic) Type A: PROFInet component is a The modelling is like type B, but in this CANopen subsystem case there is a total integrated Proxy Building one PROFInet component with a implementation. That means the CANopen hidden CANopen system is the easiest sub-system can be defined within the way. This implementation is not a real connection editor and the download Proxy. It is only the creation of a pre- process combines the transfer of manufactured and pre-tested component, configuration data and connection data. that performs its own automation task. Therefore it is necessary to create a special facet for the own componer and for The real Proxy concept, described in the the own download mechanism that is used standard [3], can be separated into the within the connection editor. following two concepts. The reason for the difference between these concepts can be found in the engineering requirements.

09-12 iCC 2003 CAN in Automation

Relevant CANopen Model Elements process data objects is visible as properties of a PROFInet component As described in the previous chapters, Therefore, the input and output data of the several concepts are possible to define a CANopen device can be mapped to input PROFInet Proxy. These concepts concern and output data of other PROFInet mainly the visibility of CANopen devices in devices using the available PROFInet the PROFInet environment and therewith engineering tools. Furthermore, the the configuration of the CANopen CANopen devices may be added and subsystem. removed flexible to the PROFInet system. Next the relation to the relevant CANopen The prerequisite is, that the device model elements is explained. configuration data is provided by an XML Type A: PROFInet component is a file. The XML file format is specified in the CANopen subsystem PROFInet standard. It seems to be From the perspective of PROFInet, the reasonable to develop a so called componer, which generates these XML CANopen system is hidden in this case. Only the contents of the process data files for CANopen devices. The componer objects (PDOs) of the system, or a part of could be integrated into existing CANopen configuration tools. them, are visible as so called properties of a PROFInet component. Therefore, the The generated XML files can be imported CANopen subsystem is configured as into the connection editor. Depending on usual, this means the application, connections between • by the control application for smaller PROFInet components (also CANopen systems, e.g. using the pre-defined devices behind the Proxy) can be connection set established or removed off-line. After downloading the connection data, the • by a CANopen configuration tool, CANopen Proxy is able to transfer process which stores the configuration data data between CANopen devices and other into the CANopen devices non-volatile PROFInet devices. Furthermore, it is during the system commissioning or necessary that the CANopen devices can • by a CANopen configuration tool, be controlled by the overall application. which generates a configuration data For this purpose, the PROFInet device set of the system and stores it into a state machine has to be mapped to the configuration manager. CANopen NMT state machine. In addition, During runtime the application in the a solution has to be implemented to map Ethernet/CAN gateway uses services of the information about exceptional states of the CANopen stack as well as of the the CANopen device into the diagnostic PROFInet stack to transfer the process functionality of the PROFInet system. data between the CANopen subsystem This concept is an intermediate-step. and other PROFInet components. Specific network information is not Furthermore, the application of the managed by the PROFInet engineering CANopen subsystem has to provide tool, but by the CANopen configuration information about exceptional states to the tool. The CANopen specific network PROFInet system as far as they are information is supposed to be integrated related to the process data. into PROFInet engineering tools, if required. This leads to the next concept. This concept is more a special PROFInet device than a CANopen Proxy for Type C: PROFInet component is a PROFInet. CANopen device (dynamic) Type B: PROFInet component is a In the third case the configuration of the CANopen device (static) entire system, including all CANopen components, is managed by PROFInet In this case the CANopen device is part of tools. This means the CANopen system the PROFInet infrastructure. However, it is and device configuration is not done still configured using the above mentioned directly by CANopen tools. However, methods. The contents of the configured these tools may be integrated into the 09-13 iCC 2003 CAN in Automation connection editor, using a so called facet. Automation FGCA (Research Society for This approach corresponds to the use of a Computer Automation). In this project configuration manager in CANopen small and medium sized companies have systems. the possibility to gain first hand experience with the PROFInet technology and the For this approach, an XML file must also integration of CAN-based networks. be generated for the CANopen Proxy. In addition, preparations, as described for the The implementation concept of the previous concept, are necessary. CANopen Proxy is as follows. The hardware platform is an embedded The description of the three concepts has industrial PC solution with x86 shown that mappings are required from architecture, 16Mbyte RAM and 8MByte PROFInet to the CANopen. Flash memory. The board contains an First of all it concerns the basic data types. Ethernet controller with 100MBit/s and a A direct link is possible between CAN controller. The software platform is UNSIGNED8, UNSIGNED16, an embedded Linux complemented by UNSIGNED32, INTEGER8, INTEGER16, PROFInet software version v1.2 with INTEGER32, REAL32 and REAL64 specific Linux adaptations [4], [5]. whereas the transfer syntax has to be Furthermore a CANopen driver is part of regarded. For all other basic data types, the existing software. The PROFInet especially for e.g. UNSIGNED24, DCOM application is being enhanced by BOOLEAN, TIME_OF_DAY and strings,, the Proxy functionality, which includes conversion rules have to be specified. The access to the CANopen driver. Therefore, definition of structures and arrays of basic loadable objects and a mechanism to data types are foreseen in both systems. store and read the configuration data, defined in the componer (file interface), is Next the mapping of the PDO and SDO services to PROFInet services has to be being implemented. This PROFInet device specified. In particular the mapping of the will be integrated into an existing PROFInet multi-vendor environment at objects in PDOs is to dissolve. ifak. On the other hand conventional PROFInet describes a diagnosis CANopen devices (I/O devices and servo mechanism which has to be supported by inverters) will be connected to the all PROFInet devices. In the case of CANopen Proxy. CANopen devices the emergency object and the Boot-Up object has to be Conclusion considered. Today it is accepted by experts, that heterogeneous communication Finally it is necessary to map the NMT state machine to the PROFInet device architectures are indispensable to meet state machine. Namely the state Stopped the requirements of future industrial automation systems most efficiently. In the and the sub-states Reset Application and Reset Communication have no equivalent end, it is a matter of saving investments in PROFInet and must be generated by and finding the networks which are best other means. suitable for the different parts of an application. Conclusively it can be said that the combination of CANopen and PROFInet is This paper deals with the PROFInet Proxy technically possible. For a first step the approach in the view of CANopen networks. It has been shown that different presented Type B is supposed to be preferred. That is why the following concepts are possible, depending on how chapter deals with an implementation the CANopen network and its devices are used in the relevant part of the application. concept of this variant. Some clues are given, on what is to be Implementation Concept considered to combine the two A first implementation of a CANopen technologies CANopen and PROFInet. A Proxy is currently being developed in a more detailed guideline is currently being research project, which is supported by worked on as part of the above mentioned the Forschungsgesellschaft Computer research project. 09-14 iCC 2003 CAN in Automation

In this paper the integration of CAN-based Axel Pöschmann networks into the PROFInet environment ifak Magdeburg was described in the view of the CANopen Steinfeldstrasse 3 (IGZ) communication profile. However, these D-39179 Barleben concepts can easily be extended to systems which use specific device profiles Phone: +49 39203 810 - 26 e.g. the profile for drives and motion Fax: +49 39203 811 00 control. E-mail: [email protected] Finally it is strongly recommended to provide a common specification of Dr. Lutz Rauchhaupt mapping PROFInet to CANopen to get a ifak Magdeburg standardised way of interfacing. This is Steinfeldstrasse 3 (IGZ) also the precondition to be regarded in D-39179 Barleben PROFInet tools, which is necessary in the Phone: +49 39203 810 - 67 case of complete integration of CANopen Fax: +49 39203 811 00 devices as components in PROFInet. E-mail: [email protected] References

[1] K. H. Ang, K. H. Tang, Thomas Werner R. T. McLaughlin, B. Levin, "DeviceNet ifak Magdeburg over TCP/IP Gateway", Steinfeldstrasse 3 (IGZ) 6th International CAN Conference D-39179 Barleben (iCC' 99), Turin, Italy, Nov. 2nd-4th 1999, Proceedings p. 06-19 to 06-26 Phone: +49 39203 810 - 74 Fax: +49 39203 811 00 [2] G. Gruhler, G. Nusser, D. Bühler, E-mail: [email protected] W. Küchlin, "Teleservice of CAN Systems via Internet", 6th International CAN Conference (iCC' 99), Turin, Italy, Nov. 2nd-4th 1999, Proceedings p. 06-02 to 06-09 [3] IEC 61158: “Digital data communication for measurement and control - Fieldbus for use in industrial control systems”, Type 10, IS, IEC 2001 [4] A. Pöschmann, Th. Werner, "PROFInet - Die Linux-Anpassung", Computer & AUTOMATION, Heft 10, 2002 [5] A. Pöschmann, "PROFInet – Die Linux-Protierung für Embedded Systeme“, Embedded Intelligence 2002, Nürnberg, 19.12 - 21.12.2002 [6] A. Pöschmann, Th. Werner; "Ethernet in der Automation", Studie ZVEI, Frankfurt, 2003 [7] PROFIBUS Guideline, “PROFInet Architecture Description and Specification”, Version V 2.0, January 2003, PNO Karlsruhe

09-15