1. Introduction Since Robert Bosch announced CAN (Controller Area Network) at the SAE (Society of Automotive Engineers) conference in February 1982, CAN has a history of over 20 years. In 1992, Mercedes-Benz used CAN technology in their high-end buses, and subsequently, dozens of companies such as Volvo, Volkswagen, and BMW applied CAN technology to their vehicles. Today, almost every new bus in Europe is equipped with a CAN controller area network. CAN technology has also developed rapidly in China in recent years, and high-end buses in the country have begun to use CAN technology. In the application of the CAN protocol, the user layer directly accesses the data link layer. Each manufacturer provides different data access methods, and the CAN standard does not specify application layer information. Therefore, the compatibility and interchangeability of CAN devices are not very standardized. Moreover, with the expansion of application areas, in actual industrial control applications, even when implementing some simple distributed networks, customers require more functions in addition to the physical layer and data link layer specified in the standard, such as sending data blocks longer than 8 bytes, responding to and confirming data transmission, identifier allocation, and network node status. If these functions are executed correctly, the boundaries between communication and application processes will be very clear, significantly improving the interchangeability and compatibility of devices from different manufacturers. For these reasons, several higher-level protocol standards based on the CAN protocol have emerged for different purposes and requirements. Below is a comparison of the CAN protocol and its higher-level protocols DeviceNet and CANOpen. 2. Comparison of the Three Protocols CAN (Controller Area Network) The CAN bus international standard was established in 1993 and revised in 2003. It is a bus developed by Bosch to improve the internal electrical wiring of automobiles. The CAN protocol is simple to implement, low in cost, highly reliable, and has strong anti-interference capabilities. DeviceNet has a relatively high market share in the United States. It is a low-cost communication link launched by Rockwell Automation based on CAN. It uses an abstract object model, and its protocol and specifications are open, so users do not need to purchase hardware, software, or licenses when connecting devices to the system. CANopen is developed by members of the CIA (CAN in Argumentation) and is mainly prevalent in Europe. It uses a subset of CAN (CAN Application Layer) in communication and system services as well as network management. Device modeling is based on the description of device functionality using an object catalog. Standard devices are specified in the form of device sub-protocols. The CANopen standard is supported by a group of CIA peer organizations, and device sub-protocols are developed by specialized peer organizations within the CIA. This paper compares the three protocols on the following items: (1) Allocation of information identifiers; (2) Methods of data exchange; (3) Methods of establishing information connections; (4) Network management; (5) Device modeling and sub-protocols. 2.1 Allocation of information identifiers Since CAN adopts a non-destructive arbitration method, the identifier determines the priority of block information transmission and information waiting time. The method of allocating information identifiers is considered to be the main structural element of the CAN system, and it also affects the efficiency of information filtering and identifier usage. Due to the different methods of identifier allocation, different protocols have taken different principles into account in their solutions. Both the CAN basic protocol and DeviceNet use predefined identifiers. The difference is that in the CAN protocol, node identifiers are determined during design and cannot be dynamically changed, while in DeviceNet, each node has multiple predefined identifiers with different priorities for different functions. In the CANopen protocol, besides some predefined management identifiers, other identifiers form a unified universal identifier library. Users can manually or automatically assign all device identifiers according to the device's needs. This allocation scheme allows users complete freedom in determining identifier usage and the real-time communication process of the system. [align=center]Table 1 DeviceNet's CAN Identifier Allocation[/align] DeviceNet's identifier allocation scheme is node-oriented. For a DeviceNet system with a maximum of 64 nodes, each node has a set of identifiers from three message groups, as shown in Table 1. Message group 1 provides a high-priority message group for each device's 16 messages; messages with smaller IDs are always sent first. The priority of messages in message group 2 mainly depends on the node number; the MAC-ID of the message can be the destination or source address. This segment allocates a total of 512 identifiers. Information group 3 is similar in structure to information group 1, but provides each device with 7 identifiers of lower priority. The priority of these identifiers is evenly distributed among all devices on the network. Information group 4 has only 48 identifiers and does not contain any device addresses; this group is primarily used for network management. Due to the use of a basic CAN-type controller, the potential for information filtering is limited. Information group 2, to support multiple devices with this limited potential, opted for filtering based on node numbers. DeviceNet defines a predefined master-slave connection group to facilitate observation of master-slave system configuration communication. The following channel functions support the exchange of I/O and explicit information between master and slave devices based on the predefined connection group: * Explicit information channel. * Master query change channel state loop. * Slave I/O change channel state loop. Explicit information primarily serves device configuration. The master query change channel allows the master to request I/O data from the device and send output data to the slave. The slave sends input data to the master via a change state loop or slave I/O (triggered by the change state loop or by the application). Using bit-select instructions, the host can request to receive input data from up to 64 slave devices. Since all these messages are responded to, eight message identifiers are assigned to these different functionalities. If the bit-selection request for data does not use an efficient identifier, the message is filtered on the slave device using the destination address field. CANopen system identifier allocation uses a subset of CLS (CAN-based Message Specification), where CMS defines eight priorities for message identifiers, each with 220 IDs ranging from 1 to 1760. The remaining flags (0, 1761–2031) are reserved for NMT (Network Message). In a CANopen system, 128 nodes can potentially be accessed, so 128 message identifiers are reserved for node protection. In a minimal system configuration, CANopen specifies a device-oriented identifier allocation scheme, allowing 127 devices to connect to a single master device by default (as shown in Figure 1). Sixteen basic functions can be distinguished in certain situations using 4-digit function codes. These situations include: receiving and transmitting data through two process channels, one point-to-point channel, node status control, node protection, emergency notification, and receiving synchronization information and time-stamped information. Since the priority of information is determined by its function, the function code is located in the highest few bits of the information identifier. [align=center] Figure 1: CAN Open Minimum System Identifier Allocation Scheme[/align] 2.2 Exchanging Process Data Sending process data between devices in a distributed automation system is the purpose of the CAN communication system, and it should be accomplished in the most efficient way. Therefore, for application-defined data (process data, I/O data), its transmission should be performed according to the producer-user model, meaning that the data sent is inferred from the relevant information ID. In this case, the information producer and user are assumed to have knowledge of using the data or understand the meaning of the sent data. In the basic CAN protocol, each node exchanges data using a defined pattern. The CAN data stream is represented and controlled by four different frame types: data frames, remote frames, error frames, and overload frames. Data frames carry data from the transmitter to the receiver. Remote frames are sent by bus units requesting the transmission of data frames with the same identifier. Any unit that detects a bus error sends an error frame. Overload frames are used to provide an additional delay between preceding and subsequent data frames (or remote frames). However, DeviceNet and CANOpen use different solutions for process data exchange. DeviceNet process data is transmitted via "I/O messages," while CANOpen process data is transmitted via "PDOS process data objects." DeviceNet supports the following triggering modes: loop, state change, and application object triggering. In the loop-triggered mode, message transmission is initiated when the specified message transmission trigger timer terminates. In the state change mode, message transmission begins when an application object state change is detected, and messages are also transmitted if no message is sent after a specific interval. In the application object triggering mode, the application object can decide when to trigger message transmission, and messages are also transmitted if no message is sent after a specific interval. CANOpen's triggering modes are divided into event-based, application request-based, or predefined synchronization message reception-based triggering modes. Event triggering can occur in sub-protocols (profiles) or application-specified events (asynchronous PDOs). PDO transmission can also be triggered by receiving a remote request message. Synchronous PDOs are triggered cyclically by receiving a specified number of synchronization messages. Synchronization messages can also be used for synchronization of data acquisition across the network and for synchronization of output data filtering. When transmitting real-time data, data is transmitted from one producer to one or more consumers, with transmission limits ranging from 1 to 8 bytes; that is, a PDO can transmit a maximum of 64 digital I/O values ​​or 4 16-bit AD values. During data exchange, network devices may generate or consume more than one mapped application object. DeviceNet and CANOpen provide robust methods for flexibly mapping application data to communication objects. In DeviceNet, application data grouping is defined by instances of collection objects. This instance of a "collection" object defines the format of the transmitted application object data. A device may contain more than one I/O collection, and the selection of its corresponding collection is a configurable device option. CANOpen specifies application object mapping, where application objects are mapped to PDOs through a data structure called a "PDO mapping record." This structure specifies the mapped application object data in the form of a list of object identifiers (object directory index sub-index) and data length. Since PDO mappings can be accessed via SDO (Service Data Object), PDO mappings can be configured using configuration tools. 2.3 Establishing Process Data Information Connections In a CAN network, information producers send information and information consumers receive information; the allocation of their respective identifiers establishes communication paths. Information connections can be established through predefined information identifiers that have already been assigned, or through the allocation of various information identifiers. The main advantages of non-predefined identifier allocation are: the possibility of establishing any type of communication structure, the effectiveness of the maximum number of information identifiers based on application requirements, and the effectiveness of information identifier allocation designed for control. In a predefined information system, the function of the information and the information identifiers have been defined. DeviceNet and CANOpen use a predefined connection group method with a 1:n system architecture. Based on the predefined group, a DeviceNet host that has been assigned a predefined query connection to a slave device already knows the information IDs about sending query requests and expecting query responses, as these are derived from the slave's MAC-ID. Similarly, in CANopen, in addition to other predefined information, the default predefined connection group provides two predefined receive and transmit PDOs. The usage and meaning of the default PDOs are determined by the device type. The DeviceNet identifier allocation method is determined by the information identifier library owned by the device, and this identifier comes from the identifier library of the information sending device. DeviceNet publishes a maximum of 64 valid identifiers for devices. During the connection process, a generating module allocates a free information ID from its information ID library and combines this free information ID with its source MAC ID to generate a so-called "connection ID". CANopen's variable identifier allocation scheme is based on a central information identifier library. The system administrator establishes the information connection by setting the corresponding PDO identifier in the device object directory through the SDO (Service Data Object) channel. 2.4 Network Management Because applications are distributed, certain events must be handled, such as application component failures or node failures. If the same application has not yet been assigned, these events will not occur. Therefore, the primary task of proper network management is to detect and display errors in the network and control the communication of distributed nodes in a coordinated manner through services. The state depends on the system solution; network functionality can be provided through explicit network management facilities or other methods. CAN network error detection includes bit errors, stuffing errors, CRC errors, formatting errors, and response errors. Each time an error is detected, the node's error counter is incremented by 1. When the node's error counter is greater than or equal to 256, the node enters a bus-off state. CANopen network management is based on CAN NMT (Network Management) service elements, which apply the "node protection" principle to detect node failures. For this purpose, an NMT master sends a protection request cyclically to each NMT slave node in the network via a remote request frame. The accessed slave responds to each request with its actual communication state. If the NMT master detects a change in node state or that the accessed node does not respond, a protection error is notified to the NMT master. Node protection is initiated when a node connects to the network. Each node also monitors the protection request information arriving at the node. If no further protection request information is received after a node's "time-to-live" expires, the application of that node is reported to have a network error. Based on a connection-oriented design, each connection in DeviceNet is monitored. Therefore, each receiving connection endpoint has an inactivity watchdog timer to monitor incoming information, according to the configured expected packet rate. If the timer overflows, the connection will perform a proprietary timeout action. After receiving explicit create service information, the connection can be configured using a proprietary explicit information service sequence, and the connection is only allowed after the entire connection configuration is complete. Before accessing each DeviceNet node, each node must repeatedly perform a MAC ID check. This special protocol sequence ensures the uniqueness of the device MAC ID. All DeviceNet modules are required to participate in this MAC ID detection algorithm. 2.5 Device Modeling and Device Sub-protocols In addition to standard communication, similar devices in open automation systems are required to have additional interoperability and interchangeability. CAN protocols have poor interoperability between different vendors' devices; DeviceNet and CANopen have improved this significantly. DeviceNet and CANOpen describe the functionality of devices seen on a network in the form of device models. To improve the interchangeability of similar devices, DeviceNet and CANOpen define device sub-protocols for major device types in industrial automation to ensure the same basic standard behavior for devices from different manufacturers. In addition to the functional description of the devices, the device model also provides descriptions of the device's identity characteristics, version number, status diagnostic information, communication facilities, and configuration parameters. The DeviceNet node model includes several objects, some required by DeviceNet and others required by the product's application functions. Objects provide descriptions of specific components within the device, related data attributes, and data process services. Object access in DeviceNet is based on a hierarchical access scheme, including media access control identifiers, type identifiers, instance identifiers, and attribute identifiers. Media access control identifiers distinguish a node from all other nodes in the same network, type identifiers identify the object type, instance identifiers identify an instance among all instances of the same type, and attribute identifiers identify attributes within a type or instance. DeviceNet's device profile contains three main pieces of information: the object model of the device type, the I/O data format of the device type, and configuration data and common interfaces. A device may contain up to 32 embedded objects, all of which are bus-addressable entities. Attributes, behaviors, and events can be determined based on the level of the embedded object. CANOpen describes the functionality of an object device through an object catalog. Catalog entries are identified by a 16-bit index and an 8-bit sub-index number, specifying the functionality of data and parameters. In addition to sections defining data types, there are three main sections: the communication sub-protocol section, the standardized device sub-protocol section, and the vendor details section. The communication sub-protocol section information is consistent across any CANOpen device type and contains information, parameters, and functions related to the device. These information, parameters, and functions are related to device authentication, error management, and the definition of device communication channels, including mapping application objects to process data objects. CANOpen device sub-protocol sections provide an interface to the functionality of basic standard devices for specific categories, with some entries being mandatory and others optional. Mandatory, common entries ensure that the device operates in a defined basic manner. Different device sub-protocols for major industrial equipment are used to improve device interchangeability. Vendor-specific or non-standard device functionality can be provided through vendor-specific sub-protocol segments. 3. Conclusion This article compares CAN, DeviceNet, and CANOpen in five aspects, enabling CAN bus users to gain a deeper understanding of these buses. The most obvious difference between these protocols is the use of information identifiers. DeviceNet is based on a connection-oriented viewpoint, while CANOpen is based on an information-oriented viewpoint. DeviceNet, CANOpen, and the CAN protocol constitute a complete protocol system. Due to its unique design philosophy, excellent performance, and high reliability, the CAN bus has been widely used in automotive, medical, and robotics fields. The higher-level protocols DeviceNet and CANOpen meet the compatibility and interoperability requirements of different products, making the CAN bus more functional and adaptable to more complex applications, further promoting the adoption and application of the CAN bus in the industrial field.