Introduction
A CAN message acts as a template to organize all the 1's and 0's being transmitted so that the data is easily read and understood by all receiving nodes. The CAN message structure limits the amount of data that can be transmitted sequentially to a relatively short 94 bits. This gives other messages a chance to transmit within a reasonable amount of time. Another important role of the CAN message structure is to uniquely identify each message so that receiving nodes can understand the content of the message and decide whether to act upon or ignore the incoming message.
Message Parts
A CAN message can be broken down into several parts that are defined by the ISO 11898 standard. We are only going to look at 3 parts of a standard CAN message, or data frame, that help us understand where the message is coming from, what the contents of the message will be, and how long the message is.
- Message ID
- Data Length Code
- Data
Message ID
The first part of the CAN message we will look at is the message ID. The ID is sent before the DLC and the data, and serves to let all the receiving nodes know some information about the incoming message before receiving all of the message data. Each node needs to transmit unique message ID's. Two or more nodes cannot transmit the same message ID on the same network. Protocols like CAN Open and SAE J1939 define which parts of the message ID are used for node and data payload identification.
Message IDs can be short or long. Short message IDs are 11 bits and long message IDs are 29 bits. When represented in hexadecimal, a short message ID can look like 0x2A2 and a long message ID can look like 0x18FEF103. It is completely possible to use both short and long message IDs on the same network, however most protocols usually specify using one or the other. SAE J1939 for example, only uses the 29 bit message ID.
Data Length Code
The Data Length Code, or DLC, is transmitted after the message ID, and it lets all of the receiving nodes know how long the message will be, or how much data will be sent in this message. The DLC is the number of bytes that will be sent whether they contain meaningful data or not. For example, the DLC of a message can be 8, but maybe only the first byte of that message is used by receiving nodes. Protocols may specify what DLCs are allowed and how they are used. For example, SAE J1939 requires the DLC of every message to be 8 except for one special circumstance. Nodes that use J1939 are typically programmed to reject messages if the DLC is not equal to 8, as those messages do not comply with the standard. If a J1939 message does not use all 8 bytes, the unused bits are all set to 1, resulting in a lot of 0xFF's showing up on a J1939 CAN trace.
The Data
The rest of the CAN message is the actual data being sent to the network. Up to 8 bytes of data are allowed to be sent with each CAN message. If the amount of data that needs to be sent exceeds 8 bytes, then the protocol being used should have a method for transmitting data greater than 8 bytes. For example, J1939 uses a multiplexing technique, where the first byte is a message counter, and the remaining 7 bytes are used for data. That way, a receiving node can receive multiple messages and re-combine the data using the message counter. Up to 1785 bytes of data may be sent using this method.
Although large amounts of data may be sent over CAN, that's not really what it is designed for. Well-designed CAN protocols try to keep the amount of data that needs to be sent to under 8 bytes, but also offer procedures for sending more data when necessary. For example, an automobile's VIN is 17 characters long, so the protocol being used will need to account for sending 17 bytes of data sometimes.