Abstract: This paper introduces the CAN bus application layer protocol CANopen; describes the application of CANopen systems; and details the CANopen protocol structure, communication objects, and identifier address allocation. Keywords: Fieldbus; CAN bus; CANopen; Protocol Introduction The application research of fieldbuses is becoming increasingly widespread. Among the many fieldbuses, CAN bus has become a promising fieldbus due to its ease of use and development. However, CAN is not a complete network protocol, lacking application layer and network management components. CANopen is an application layer protocol based on the CAN communication protocol, initially developed by members of CiA (CAN in Automation) for industrial systems. CANopen has wide applications in many fields, including marine electronic equipment, medical equipment, and railway systems. I. CANopen Protocol Structure The CANopen protocol structure is based on the ISO 11898 international standard, using the Open Systems Interconnection (OSI) model as a reference. The structure is shown in Figure 1: [align=center] Figure 1 CANopen Communication Reference Model[/align] As shown, the data link layer has a CAN control chip, following the CAN 2.0A/2.0B protocol. The physical layer specifies adherence to the ISO 11898 international standard. Both the data link layer and physical layer are implemented in hardware according to the CANopen device specifications, allowing manufacturers to produce standard, universal devices without requiring special software to assemble network devices from different manufacturers. Basic network operations are guaranteed by explicit, mandatory device specifications. CiA provides the CiA-401 I/O model and the CiA-404 procedures for measurement devices and closed-loop control. These procedures are implemented using a standardized database called the "object dictionary." The object dictionary can be accessed using a 16-bit index, and in the case of arrays and structures, an 8-bit sub-index. This dictionary also describes all the application objects of the device. II. CANopen Communication Objects The CANopen communication standard defines four types of communication objects (messages), distinguished by communication identifiers (COB-ID) or CAN identifiers. 1. Network Management Messages (NMT) Network management messages provide network management services, such as initialization, error control, and device status control. All these functions are based on the master-slave concept. 1.1 NMT Object An NMT object maps to a single CAN frame with a 2-byte data length. Its identifier is 0. The first byte contains a command specifier, and the second byte contains the node identifier of the device that must execute the command. When the node identifier is 0, all slave nodes must execute the command. An NMT object sent by the NMT master forces a node to transition to another state. 1.2 NMT Node Guarding A node guarding object is a one-byte CAN frame remotely requested by the NMT master node. The data bytes mainly contain the node's status. The node guarding time is periodically sent by the object and is also specified in the object dictionary. In addition, a Life Guarding Time is specified, during which the NMT master station must protect one NMT slave station. This ensures that even if the master station is not present, the node can still react in the manner specified by the user. Figure 2 shows the relationship between NMT functions and specific command words: [align=center] Figure 2 NMT function command words[/align] 2. Process Data Object (PDO) Process data objects are used to transmit real-time data. The data is sent by a producer and can be received by one or more consumers. Data transmission is limited to 1 to 8 bytes. Each PDO has a unique identifier with high priority to ensure good real-time performance. If hard real-time control is required, the system designer can configure an inhibit-time for each PDO. This "inhibit-time" strictly prohibits the transmission of the object within a specific time. There are three transmission modes for PDO: (1) Event or timer triggered PDO mode. This transmission mode is also called asynchronous PDO mode. PDOs are transmitted when special device or manufacturer events occur within the device, such as changes in applied values, such as changes in digital inputs, changes in temperature, etc. This transmission mode has the lowest network bandwidth requirements. (2) Remote request triggered PDO mode. PDO consumers can send a CAN remote frame, and the corresponding PDO producer will respond to the remote frame. This transmission mode is not allowed during normal operation because the remote frame behavior of different CAN controllers is different. In addition, this transmission mode has higher bandwidth requirements than event or timer triggered PDO mode. (3) Synchronous triggered PDO mode. Synchronous PDO mode is triggered by Sync messages. The Sync producer is responsible for sending Sync messages. Synchronous producers can exist in simple input/output devices, drives, and complex process control devices. 3. Service Data Object (SDO) Service Data Objects are used to establish point-to-point communication between two CANopen devices. This connection is based on the client/server mechanism. The SDO server is the device that provides the object dictionary to the device that requests connection, and the SDO client is the device that wants to connect to the object dictionary of a specific device. SDO service is based on CAN messages with two different identifiers, one message used by the SDO server and the other by the SDO client. An SDO client can have up to 127 channels, which means that an SDO client can connect to up to 127 different devices simultaneously. 4. Scheduled Messages or Special Function Objects CANopen also defines three specific objects: synchronization, time stamp, and emergency object. (1) Synchronization object. The synchronization object synchronizes all devices through external events. There is a device on the network that is a synchronization generator, whose only function is to generate a synchronization signal. Any device on the network must synchronize after receiving the synchronization signal. The synchronization signal is a short message, which is just a CAN message without any data, but it can have up to 8 bytes of user-specific data. (2) Time stamp object. The time stamp object uses the system clock to synchronize the local clock. A general time frame reference is provided to the device, which contains a time and date value. The associated CAN frame has an identifier 256 and a data field of 6 bytes. (3) Emergency object. Emergency objects are used to convey status information of application devices. They are triggered by a fatal error occurring within the device. Therefore, emergency objects are suitable for interrupt-type alarm signals. Each "error event" can only send an emergency object once; it can only be sent again when a new emergency event occurs. The CANopen communication standard specifies emergency error codes, which are a single CAN frame with 8 data bytes. III. Identifier Address Allocation To reduce the workload of simple network management, CANopen defines a mandatory default identifier address allocation table. These identifiers are available in the pre-operation state after initialization. This default ID allocation table includes a function part and a module ID part. Identifiers specify the priority level of their objects. These ID allocation tables allow a single master device to communicate peer-to-peer with up to 127 slave devices. Unacknowledged NMT broadcasts, synchronization and time-calibration objects, and node protection are also supported. The predefined master/slave connection set supports one Emergency object, one SDO, up to four Receive-PDOs and four Transmit-PDOs, and a Node Guarding Object. The predefined master/slave connection set defines some CAN identifiers, while others are open and can be defined by the designer. NMT(0), default SDOs (1405-1535 and 1537-1663), and NMT error control messages (1793-1919) are fixed and cannot be changed. IV. Conclusion In summary, CANopen provides customers with a standard CAN application layer protocol. CANopen's highly flexible application layer protocol and many selectable features are beneficial for embedded network designers to design more competitive products. Furthermore, there are many general-purpose management tools and software available, allowing customers to design specific network devices according to their needs. With the deepening research into fieldbus, CANopen will be widely used in more fields. References [1] CAN-in-Automation, CAL, CAN Application Layer for Industrial Applications, CiA Draft Standard DS-201 to DS-207, Version 1.1, Feb 1996. [2] CAN-in-Automation, CANopen, CAL-based Communication Profile for Industrial Systems, CiA DS-301, Version 4.0, June 16 1999. [3] CAN-in-Automation, CANopen Device Profile for I/O Modules, CiA DSP-401, Version 1.4, Dec 1996. [4] Yang Xianhui, Fieldbus Technology and Its Applications, Tsinghua University Press, 2001.12