Version 1.1 Application Note AN-ION-1-1100 Restrictions Abstract Public Document This application note is a brief introduction to the Higher-Layer CAN Protocol called CANopen. Table of Contents 1 Overview...1 1.1 History...2 1.2 Highlights...2 2 Standardized Structure...2 3 The Device Model...4 4 Physical Layer...4 5 The Object Dictionary...4 6 Communication Channels...5 7 Network Management...6 8 Pre-Defined Connection Set...8 9 CANopen System Configuration...8 10 Device Profiles...9 11 Conclusion...9 12 Contacts...9 1 Overview CANopen is a "Layer 7" CAN protocol that defines communication and device functions for CAN-based systems. CANopen is a standardized, highly flexible, and highly configurable embedded network architecture used in industries such as Railway, Medical, Industrial, Agriculture, Heavy Truck & Bus, Marine, Off-Highway, Factory Automation, Aerospace, and many others. CANopen is also becoming a popular choice for closed, company-specific embedded networks. The CANopen profile family specifies standardized communication mechanisms and device functionalities. The CANopen Standard is maintained by "CAN in Automation (CiA) International Users and Manufacturers Group" and can be implemented without a license. Copyright 2003 - Vector Informatik GmbH. 1 Contact Information: www.vector-cantech.com or 1-248-449-9290
1.1 History 1992 (Jul) Start of ESPRIT III Project ASPIC. CAN selected as a suitable field bus system. Start of communication and device profile development. 1994 (Jun) Profiles handed over to the CAN in Automation (CiA) international users and manufacturers group. 1994 (Sept) First implementations outside ASPIC. 1995 (Feb) The standard is given the name "CANopen". 1995 (Apr) CANopen robot cell shown at HMI. 1995 (Oct) Communication profile DS-301 available. 1996 (Feb) First device profile (DS-401) was available. 1996 (Apr) Multi-vendor system shown at HMI. 1996-1997 Development begins on several device profiles and a Framework for Programmable Devices (WD- 302). 1999 (Jun) The DS-301 submitted for European Standardization. 2001 The European standardization authorities accept CANopen version 4.01 as EN 50325-4. Present 1.2 Highlights Many device profiles and frameworks are available. Hundreds of implementations in the worldwide market. CANopen protocol characteristics: Open architecture Real-time transfer of process data without protocol overhead Modular and scalable Interoperability and interchangeability Profile concept similar to Interbus-S and Profibus Supported by many international manufacturers CANopen allows: Standardized configuration of networks Access to all device parameters Synchronization Cyclic and event-driven process data transfer combined with asynchronous domain transfer 2 Standardized Structure Compared to the ISO/OSI Stack, CANopen is a "Layer 7" communication profile based on CAN, which is standardized in ISO 11898. It is supplemented by a set of device profiles. The CiA manages the documents. The main document is the "CiA DS 301 - CANopen Application Layer And Communication Profile" (EN 50325-4). It describes all basic principles, data types, encoding rules and services. Application Note AN-ION-1-1100 2
Figure 1 The ISO OSI Stack The following set of papers supplement the DS-301 (there are more): CiA DSP-306 - CANopen electronic data sheet (EDS) for CANopen CiA DSP 302 - CANopen framework for CANopen managers and programmable CANopen devices CiA DSP 305 - CANopen layer setting services and protocol (LSS) CiA DR 303-1 - CANopen cabling and connector pin assignment A series of device, application, and interface profiles complete the specification. Figure 2 CANopen Documents Application Note AN-ION-1-1100 3
3 The Device Model A unified view of CANopen devices requires the use of a general device model so that different devices can be described by one standard. The device model consists of three main components: Communication Object Dictionary Application Figure 3 CANopen Device Model 4 Physical Layer The physical medium for CANopen devices is a differentially driven two-wire bus line with common return according to the ISO 11898 standard. The CANopen standard does not mandate a specific Physical Layer, which allows CANopen to be used in specific environments. CANopen does however provide a set of recommendations and specifications for industrial use. CiA DR 303-1 defines pin assignments for many connectors, such as the 9-pin D-sub connector (DIN 41652 or corresponding international standard), the 5-pin mini style connector, the open style connector and the multipole connector. 5 The Object Dictionary CANopen is built around the central concept of an Object Dictionary (OD), the interface between the application and communication within each device. Every function, variable and data type seen via the network must be described in the OD. Object Dictionary characteristics include: Collection of communication and application-relevant parameters Standardized structure Access to structured parameters (arrays, records) Reference to data types In order to allow access to all entries, the OD defines a standard addressing scheme where each object has an index. The index is a 16-bit offset into the OD. There is direct access to non-structured objects like Boolean, Unsigned32, etc. Main Index Variable Accessed Data Type 1000H Device Type Unsigned32 Table 1 Object Dictionary Standard Addressing Scheme From a programmer s point of view, this is equivalent to: Application Note AN-ION-1-1100 4
unsigned long DeviceType; Structured data types use an 8-bit sub-index to denote a field inside a structure or array. Main Index Sub Index Variable Accessed Data Type 6092H 0 Number Of Entries Unsigned8 1 Baud Rate Unsiged16 2 Number Of Data Bits Unsigned8 3 Number Of Stop Bits Unsigned8 4 Parity Unsigned8 Table 2 Array And Structure Indices From a programmer s point of view, this is equivalent to: typedef struct { unsigned char NumberOfEntries; unsigned short BaudRate; unsigned char NumberOfDataBits; unsigned char NumberOfStopBits; unsigned char Parity; } RS232; RS232 rs232; The indexes are organized in several index ranges: Index (hex) Object 0000 not used 0001-025F Data Types 0260-0FFF Reserved for further use 1000-1FFF Communication Profile Area 2000-5FFF Manufacturer Specific Profile Area 6000-9FFF Standardized Device Profile Area A000-BFFF Standardized Interface Profile Area C000-CFFF Reserved for further use Table 3 Pre-defined Index Ranges 6 Communication Channels The basic communication mechanisms are categorized as one of the following relationships: Client / Server - Point-to-point connection. The client always takes the initiative (N Clients, n Servers) Master / Slave - Point-to-point connection. The Master always takes the initiative (1 master, 1...127 Client Servers) Producer / Consumer - This broadcast connection is exactly like the CAN protocol s broadcast capability. The Producer takes the initiative during the unconfirmed relationship. The Consumer takes the initiative during the confirmed relationship (N Producers, M Consumers) The two most important communication types are the Process Data Object (PDO) and Service Data Object (SDO): Application Note AN-ION-1-1100 5
Process Data Object PDO High priority real-time data exchange Broadcast Non-acknowledged No protocol overhead Synchronous / asynchronous, cyclic/ acyclic, event driven transmission Maximum 8 bytes of data The PDO is used for normal process data communication, the primary purpose of the CANopen network. Service Data Object SDO Access to object dictionary Peer-to-peer communication Acknowledged service Low priority Transfer of domains The SDO is used for configuration and diagnostic access to a device. It is not as fast as PDO, but provides the most flexible means to read/write any amount of data. CANopen defines additional communication objects for real-time usage, such as TIME and SYNC. 7 Network Management A CANopen network requires a Network Management (NMT) Master and all NMT Slave devices to implement a state machine. The NMT Master controls the status of all the NMT Slaves on the network. After "power-on" and internal initialization, the NMT Master automatically brings every Slave device into the "Pre-operational" state. Each Slave device may be configured and parameterized via SDO (e.g., Master or configuration tool), but no PDO communication is allowed at this state. Now the NMT Master may switch all nodes (or a single node) to their "Operational" state. In the "Operational" state, all communication objects are active. Switching a node into a "Stopped" state terminates all PDO and SDO communication. Application Note AN-ION-1-1100 6
Figure 4 NMT State Machine CANopen has two alternatives for protecting the existence and status of the state machine: the Heartbeat and Guarding protocols. The Heartbeat protocol is only used in modern system designs. CANopen devices have signal error conditions, such as "Voltage low", for when an event occurs instead of having to be polled from a Master. The Emergency (or EMCY) message contains standard and profile-specific error codes. Figure 5 Heartbeat Application Note AN-ION-1-1100 7
8 Pre-Defined Connection Set Client/Server and Producer/Consumer connections can be set-up dynamically by configuring the Object Dictionary. Since most systems have a central application master, CANopen establishes a "Pre-defined Connection Set" to reduce the effort in inter-connecting devices. Every CANopen "ready" device is configured with communication settings to support the "Pre-defined Connection Set". Figure 6 - Resulting Connections Of The Pre-Defined Connection Set 9 CANopen System Configuration CANopen defines a means for system configuration. This is supported through standard PC file formats (Electronic Data Sheets or EDS), non-volatile central data storage, and distributed data storage. Figure 7 Configuration Of CANopen Systems Application Note AN-ION-1-1100 8
10 Device Profiles CANopen uses the concept of device profiles. These profiles define all mandatory functionality for particular device classes and enable standardized access to that functionality. The goals of these device profiles are: Define mandatory functionality and provide access to the basic functionality, for example: "set output" for I/O or "halt" function for drives. Provide pre-defined communication objects and interchangeability of standard functionality, for example: "set filter" for I/O or "feed command value" for drives. Unification of the device's state machine for easier setup of networks. Locate vendor-specific functionality in the Object Dictionary - realization of vendor-specific features such as "edge evaluation" for I/O Define additional error conditions - extension for pre-defined error codes in the DS-301 for device-specific errors such as "short circuit on the output" for I/O 11 Conclusion CANopen provides typical functionality required by distributed embedded communication systems. CANopen device implementations can be tested for compliance using the CiA conformance test tool. 12 Contacts Vector Informatik GmbH Ingersheimer Straße 24 70499 Stuttgart Germany Tel.: +49 711-80670-0 Fax: +49 711-80670-111 Email: info@vector-informatik.de Vector France SAS 168 Boulevard Camélinat 92240 Malakoff France Tel: +33 (0)1 42 31 40 00 Fax: +33 (0)1 42 31 40 09 Email: information@vector-france.fr Vector CANtech, Inc. 39500 Orchard Hill Pl., Ste 550 Novi, MI 48375 Tel: (248) 449-9290 Fax: (248) 449-9704 Email: info@vector-cantech.com Vector Japan Co. Ltd. Seafort Square Center Bld. 18F 2-3-12, Higashi-shinagawa, Shinagawa-ku, J-140-0002 Tokyo Tel.: +81 3 5769 6970 Fax: +81 3 5769 6975 Email: info@vector-japan.co.jp VecScan AB Fabriksgatan 7 412 50 Göteborg Sweden Tel: +46 (0)31 83 40 80 Fax: +46 (0)31 83 40 99 Email: info@vecscan.com Application Note AN-ION-1-1100 9