From the OSI network model perspective, fieldbus networks generally implement only the 1 layer (Physical Layer), the 2 layer (Data Link Layer), and the 7 layer (Application Layer). Because fieldbus typically includes only one network segment, it does not require the 3 layer (Transport Layer) and the 4 layer (Network Layer), nor does it need the 5 layer (Session Layer) or the 6 layer (Presentation Layer).
CAN (Controller Area Network) fieldbus only defines the 1 layer and the 2 layer (see ISO11898 standard); in actual design, these two layers are fully implemented by hardware, and designers do not need to develop related software (Software) or firmware (Firmware).
At the same time, CAN only defines the physical layer and the data link layer, without specifying the application layer, and is not complete by itself; it requires a higher layer protocol to define the 11/29 bit identifier and the use of 8 byte data in CAN messages. Moreover, in industrial automation applications based on CAN buses, there is an increasing need for an open, standardized higher layer protocol: this protocol supports interoperability and interchangeability of various CAN vendor devices, enabling a standard, unified system communication mode within the CAN network, providing a device function description method, and executing network management functions.
The Application Layer (Application Layer): provides a set of useful services and protocols for every valid device in the network.
Communication Profile (Communication Profile): provides configuration for devices, meanings of communication data, and defines data communication methods.
Device Profile (Device Profile): adds compliant behaviors for device (class)
The following chapters will introduce the higher layer protocols based on CAN: CAL protocol and the CANopen protocol based on the CAL protocol extension. The CANopen protocol is one of the standards defined by CAN-in-Automation (CiA) and was widely recognized shortly after its release. Especially in Europe, CANopen is regarded as the leading standard in CAN-based industrial systems. Most important device types, such as digital and analog input-output modules, drive devices, operating devices, controllers, programmable controllers, or encoders, are described in a protocol called “Device Description”; “Device Description” defines different types of standard devices and their corresponding functions. With the support of the CANopen protocol, devices from different vendors can be configured through the bus.
In the OSI model, the relationship between the CAN standard and the CANopen protocol is shown in the figure below:
1、CAL Protocol
CAL (CAN Application Layer) protocol is currently one of the higher layer communication protocols based on CAN, originally developed by Philips Medical Devices Division. Now, CAL is managed, developed, and promoted by the independent CAN user and manufacturer group CiA (CAN in Automation).
CAL provides 4 types of application layer service functions:
CMS (CAN-based Message Specification)
CMS provides an open, object-oriented environment for implementing user applications. CMS provides objects based on variables, events, and domain types to design and specify how the functionality of a device (node) can be accessed (for example, how to upload and download a set of data (domain) larger than 8 bytes, and has the ability to terminate the transmission).
CMS inherits from MMS (Manufacturing Message Specification) , which is the OSI application layer specification for remote control and monitoring of industrial devices.
NMT (Network Management)
Provides network management services (such as initializing, starting, and stopping nodes, detecting failed nodes). This service is implemented using a master-slave communication mode (so there is only one NMT master node).
DBT (Distributor)
Provides dynamic allocation of CAN ID (officially named COB-ID , Communication Object Identifier) service. This service is implemented using a master-slave communication mode (so there is only one DBT master node).
LMT (Layer Management)
LMT provides services for modifying layer parameters: one node (LMTMaster) can set the layer parameters of another node (LMT Slave) (such as changing the NMT address of a node or changing the timing and baud rate of the CAN interface).
CMS defines 8 priority levels for its messages, with each priority having 220 COB-IDs, ranging from 1 to 1760 . The remaining identifiers (0, 1761-2031) are reserved for NMT , DBT , and LMT , see the table below
Note that this is the CAN2.0A standard, 11 bit ID range [0, 2047], limited to [0, 2031] for historical reasons. If using the CAN2.0B standard, the 29 bit ID does not change this description; the 11 bit in the table maps to the highest 11 bits in the 29 bit COB-ID, making the range of COB-ID in the table much larger
Mapping to COB-ID (11 bit CAN identifier) of CAL services and objects
2、CANopen
CAL provides all network management services and message transmission protocols, but does not define the content of CMS objects or the types of objects being communicated (it only defines how, no definition of what). This is precisely the entry point of CANopen.
CANopen is developed based on CAL, using a subset of CAL communication and service protocols, providing an implementation solution for distributed control systems. CANopen allows for the functional expansion of nodes, whether simple or complex, while ensuring interoperability of network nodes.
The core concept of CANopen is the device object dictionary (OD: Object Dictionary), which is also used in other fieldbus (Profibus, Interbus-S) systems. Note: the object dictionary is not part of CAL , but is implemented in CANopen.
For specific knowledge of CANopen, please pay attention to the next knowledge update.