The CAN architecture add a link layer protocol on top of the CAN physical layer. This layer is responsible for transmission of CAN frames.
Many CAN systems use a Producer-Consumer model. For people who are used to the idea of sending specific messages from A to B – a source-destination model, the producer-consumer is a very different concept, although this is widely used for industrial control systems.
Each CAN frame contains no source address, no destination address, no information, it just contains an CAN ID and perhaps some status data, e.g. to report this event is "on","off", or a "value" such as a temperature or amount of rotation.
A CAN node set up as a Producer has a set of input ports (interfaces to switches, sensors, etc). The node is configured to set what message is generated when these inputs change state.
For exmaple, this could eb coinfigured so that each port is associated with a specific CAN ID. In this example, when a change is detected on a specific input, the CAN node creates an Event (a message with the associated CAN ID) that is sent in a CAN frame using the bus.
An 8-input device might therefore output 8 different CAN messages, one for each of its inputs.
Nodes that can be configured to process an Event/Message are called Consumers.
There is no limit to the number of Consumers nodes attached to a bus, providing that they are a Receive Only - i.e. do not generate Events. All messages sent by any Producer node could be received by any other CAN node connected to the same CAN bus. However, by default all nodes ignore all received Events/messages. .
Every Consumer connected to a bus will of course see all the Events/Messages that are sent to the bus, but only reacts when it recognises an Event/message. Each Consumer node therfore needs to be configured with a list of the Events they wish to receive (i.e. they set of CAN IDs which are of interest), and the corresponding action the node will take when each specific Event is received. The action will depend on the configuration information and also the capabilities of the node. It could be as simple as to set a value on one of its output ports, or to pulse one of the port values, but, in principle, a Consumer could implement any other control action.
In summary, each Consumer has to be taught what to do with each Event/Message that it wishes to act upon. It will ignore all other Events.
We describe a simple example to implement a control panel as a Producer node. This will use 8 push button switches, one connected to each input port. The Producer node is configured to send different 8 Events, one for each switch. We number these events 1 to 8, but in reality each event could have any unique value.
Now, suppose we connect two 8-output Consumer nodes to the same CAN bus, located in different places. These can be configured in any way, but in the example, qach Consumer node is configured so that Event 1 sets the value of output 1, Event 2 sets the value of output 2, etc. When a button is pressed both nodes will then have an output on the corresponding output port. Of course the two Consumer nodes could also be set to use only some of the set of 8 Events, simply by changing their configuration.
When a switch is pressed on the producer node, it generates a CAN frame with a specific CAN ID to represent the event. The bus sends this frame to both the Consumer nodes (which ACK the frame). Each node then checks its list of configured CAN IDs in the event table. If it does not match, the Consumer takes no action, but if it matches it performs the associated action.
The model is an extremely powerful and very flexible. A producer can send one or many Events. None or more Consumers can be configured to act on a specific Event. An Event can trigger the same or different actions (e.g., one Consunmer may light an LED to show a button was pressed, another Consummer could move an actuater in response to the same Event). All of this is set simply by changing the configuration of the CAN nodes (typically the Consumer nodes) - no change is required to the wiring of the bus when a different action is needed.
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)
A Cyclic Redundancy Field (CRC-15) field is included in each frame . CAN provides sophisticated error-detection and error handling mechanisms such as CRC check, and high immunity against electromagnetic interference. Erroneous messages are retransmitted.
All nodes receive all the frames that are sent on the bus. They can be configured to filter based on a set of message IDs. Nodes discard any frames that do not match one of the configured filters.
Nodes discard frames with any formatting errors and/or CRC errors. When calculating the Frame CRC, the message is regarded as a binary polynomial. This is then divided using modulo-2 arithmetic with a CRC generator polynomial, following the form: 𝑥15 +𝑥14 +𝑥10 +𝑥8 +𝑥7 +𝑥4 +𝑥3 +1. This generates a CRC field that can be used to veirfy the integrity of each received frame.
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.
Two variants are common:
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 CAN ID indicates the type of content and its priority.
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 CAN ID. Note the first bit where a 0 (driven bus) is forced onto a 1 (floating bus) signal, recessive bit. This indicates the place where arbitration takes place. A dominant 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.
Prof. Gorry Fairhurst, School of Engineering, University of Aberdeen, Scotland (2025).