The CAN architecture layers a link layer protocol on the CAN physical layer. This 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.
A CAN node set up as a Producer has a set of input ports. The node is configured so that each port is associated with a CAN ID. When a change is detected on the input, the CAN node creates an Event (a message) which is sent in a CAN frame using the bus. This message. has ID corresponding to the port where the change was detected.
A frame contains no source address, no destination address, no information, just an Event number and perhaps some status data, e..g to say with this event is "on","off", or a "value" such as a temperature or ammount of rotation.
An 8-input device can therefore output 8 different CAN messages, one for each of its inputs.
All messages sent by any Producer node could be received by any other node connected to the same CAN bus. However, by default all nodes ignore all Events/messages. 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.
Nodes that can be configured to process an Event/Message are called Consumers. Every Consumer connected to a bus will of course see all the Events sent to the bus, but only reacts when it recognises an Event/message.
Each Consumer node needs to be configured with a list of the Events they wish to receive, and the corresponding action to take when the specific Event is received. The selected 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 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 that it wishes to act upon. It will ignore any 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 add two 8-output Consumer nodes, located in different places. Each Consumer node could be programmed 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.
The model is an extremely powerful and very flexible arrangement. Producers can send one or many Events. More than one Consumer can be configured to act on a specific Event, An Ecebt can trigger the same or different actions (e.g. one Consunmer may light an LED to show a button was pressed, another Consummer could 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 in the wiring of the bus if 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 automatically 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 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. 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 (2024).