CAN-based higher-layer protocols (HLP)

Most of the standardized CAN-based higher-layer protocols implement the application layer and the transport layer

Like all modern communication technologies, CAN-based network solutions follow the Open Systems Interconnect (OSI) reference model. It is standardized in ISO/IEC 7498-1. For CAN networks, this model has been adapted. The CAN reference model comprises the CAN physical layer (layer-1), the CAN data link layer (layer-2), and the CAN application layer (layer-7). The other layers (3 to 6) are often not explicitly implemented. However, some application layers also include the network and transport layer functionality. All these communication services and protocols specify only the communication behavior. The application functionality is not in the scope of the OSI model. It is part of the device or application profile specifications.

The ISO 11898 series covers only the lower layers (physical and data link layer). The CAN network designer additionally has to deal with the functionality of the higher-layer protocols (from the network layer to the application layer). In many CAN applications, only the application layer functions need to be implemented. This can include some kind of network management. The network management is normally responsible for starting and stopping CAN nodes. Another common function is node supervising in event-driven networks. This is necessary to detect “missing nodes”, which could be in bus-off state or could have lost power permanently or temporarily. Some application layers use special messages for this purpose (e.g. Heartbeat or Still-alive). Others do this implicitly by means of message time-outs for periodically transmitted frames.

One of the most important services provided by higher-layer protocols is the segmentation of data and the re-assembling on the receiver side. Although this segmentation and re-assembling of data is part of the transport layer functionality, it is implemented in the application layer protocol (e.g. in CANopen, DeviceNet, and J1939-21).

Standardized higher-layer protocols simplify device and network design by enabling the reuse of software routines. Those higher-layer protocols are normally implemented in software by means of protocol stacks. If they are standardized, they are often available from different manufacturers. This can help avoid dependency on just one supplier.

Standardized HLPs

International standardization bodies or consortia have specified the following HLPs:

Not all approaches are listed here. They are either very specific (e.g. MILCAN A and B, UAVCAN) or they are not really supported by the related industries.

Most of the HLPs also specify CAN bit-timing including the location of the sample-point.

Make or buy

When implementing standardized HLPs in your device, you can buy a protocol stack or you can program it yourself. Off-the-shelf protocol stacks prevent the reinvention of the wheel. But they may not be optimized for the resources of your device and your application requirements.

If you want to buy a HLP protocol stack, you can find product information in CiA’s Product Guides and in the CAN Newsletter Online. Protocol stacks are available in source and object code. Often, this software is modularized, so that you can select the functionality you really need. Off-the-shelf HLP stacks are normally in a mature state, due to their use in many different devices.

In order to be compliant to a HLP specification, you can use conformance test tools. For example, CiA provides the CANopen conformance test tool to its members free-of-charge .