Information is exchanged cross the CAN bus using messages, sent in CAN bus frames. Any control unit can send or receive messages. A message contains physical values such as the engine speed (rpm). The engine speed In this case, is represented as a binary value (a string of ones and zeroes). For example: The engine speed of 1800 rpm may be represented as 00010101 in binary notation.
The bit stream is sent over the TX line (transmit line) to the transceiver (amplifier). The transceiver converts the bit stream into voltage values that are then sent serially over the bus line one by one.
To receive messages, voltage values are converted back into a bit stream by the transceiver and sent over the RX line (receive line) to the control units. The control units then convert the serial binary values back into messages. For example: the value 00010101 is converted back to the engine speed 1800 rpm.
The CAN architecture layers a link layer protocol on the CAN physical layer. This is responsible for transmission of CAN frames.
A message can be received by any control unit. This principle is also called a broadcast message. The idea is derived from a transmitter which broadcasts a programme which any tuner (receiver) can receive. The broadcast ensures that all control units can recive all messages.
The CAN Frame format is structured like this:
Start of Frame (1b) = 0
Message ID (11b for CAN 2.0A)
Control fields (3b)
Data Length (4b)
Data (0-64b)
CRC (15b)
ACK fields (3b)
End of Frame Delimiter (7b)
All message IDs are unique (centrally assigned), lowest has highest priority.
All nodes receive all the frames sent on the bus, but can filter based on the message IDs. Nodes discard frames with any formatting errors and/or CRC errors.
Access to the bus is using a half-duplex with a distributed architecture. Bus nodes do not have a specific address. Instead, the address information is contained in the identifiers of the messages that are transmitted. Hence each message ID indicates the type of content and the priority. The lack of addresses allows the number of nodes to be changed dynamically without disturbing the communication of existing nodes - useful when nodes need to be replaced or new nodes added to an existing bus.
When a node has no data to send (or between frames), a node sends at least 3 recessive bits (1-value), called the Intermission. This time allows nodes to perform internal processing before the start of the next message.
A "Data Frame" is generated by a CAN node when a node wishes to transmit data. Each frame carry up to 8 data bytes. The small size results in a low latency between transmission request and start of transmission.
Access to the bus access is handled via the Carrier Sense Multiple Access/Collision Detection with Non-Destructive Arbitration, which allows any node to start transmission of a message after an Intermission. It requires any sending node to monitor the bus to see if the transmission is successful. Each message starts with the message ID. The use of the CAN_H and CAN_L signals result in two bus states, called "dominant" (the two lines driven in opposite directions) and "recessive" (both lines floating to the same level). Note the first bit where a 0 (driven bus) is forced onto a 1 (floating bus) signal. This indicates the place where arbitration takes place. A bit with a 0 level always wins. This means that during the transmission of the message ID the lowest numbered message always wins, other nodes stop sending and retransmit later. A Cyclic Redundancy Field (CRC-15) field follows the frame data. CAN provides sophisticated error-detection and error handling mechanisms such as CRC check, and high immunity against electromagnetic interference. Erroneous messages are automatically retransmitted.
CAN specifies 4 types of frames:
The original CAN specifications (Versions 1.0, 1.2 and 2.0A) specified an 11 bit message identifier, CAN 2.0B supports both 11 and 29 bit formats. This is known as "Standard CAN". Although systems can and usually do use Most standard/public messages many also carry proprietary messages specified by particular vendors.
Two variants are common:
Prof. Gorry Fairhurst, School of Engineering, University of Aberdeen, Scotland (2014).