Arguably, when asked to name a vehicle network, the first one that comes to mind is the Controller Area Network (CAN). This is no surprise, given that CAN has been present in vehicles since the early 1990s, which is a testament to this protocol that remains in use today by automotive manufacturers and in a wide range of industrial applications. (CAN is everywhere)
Robert Bosch GmbH developed CAN in the 1980s to address the growing demand for improved reliability in complex vehicle wiring systems, which were increasing in proportion to the number of ECUs installed on modern vehicles. Such “modern” vehicles of the time (before CAN) relied upon dedicated wiring to carry signals to and from each control unit (Node), resulting in heavy and cumbersome wiring harnesses with an infinite number of connectors
Below we have an example of Node 1 conveying 6 pieces of information to Node 2 via 6 wires!
With the above architecture in mind, if Node 1 is required to communicate more information to Node 2 and other Nodes, the wiring count dramatically increases along with the weight and complexity of the wiring harness
Moving now to CAN, using just a single twisted pair of cables (CAN bus), each Node linked to the bus can transmit and receive messages such that every connected device can either listen or respond accordingly. (Now we have “communication”)
To put this in perspective, 2 wires (a twisted pair) have replaced potentially 1000s of wires that would traditionally be required to convey signals between Nodes (see example below using just 2 nodes)
The CAN protocol has delivered the exact requirements to vehicle manufacturers thanks to digitised communication over a twisted pair of wires (multiplexing). Wiring harness weight, complexity and connector count have now decreased with an exponential increase in reliability. In addition, “CAN” allows manufacturers the flexibility to customise the data exchange over the bus at varying speeds (baud rates) with inherent fault tolerance and the ability to expand and evolve with future vehicle developments
Before we describe the operation and functionality of CAN, an overview of the varying “flavours” and characteristics are highlighted below
- CAN version 2.0 (Classic CAN): Exhibiting the properties and specifications (foundation) upon which CAN is designed and built
- CAN 2.0A (Standard CAN): Contains an 11-bit identifier, returning 2,048 unique message priorities
- CAN 2.0B (Extended CAN): Contains a 29-bit identifier, increasing the number of unique message priorities to over half a billion
- CAN FD (Flexible Data-Rate): Backward compatible with CAN 2.0 but with increased data rate (Max 8 Mbit/s) and payload (Maximum 64 bytes per packet with CAN 2.0 carrying a maximum of 8 bytes)
- CAN XL (Extra Long): Backward compatible with CAN 2.0 and CAN FD with a further increase in the data rate (20 Mbit/s +) and a payload carrying up to 2,048 bytes per packet
There are also different aspects and protocols of CAN, but all with their roots stemming from Classic CAN. These include Convenience CAN (VW), CAN J1939, CANopen, DeviceNet, CAN aerospace and Single wire CAN
As can be seen above, CAN continues to be utilized in the majority of industrial machine and transportation applications with few limitations and bespoke characteristics, which are listed below:
- Only one ECU is permitted to transmit on the bus at any given time
- CAN does not require a Commander ECU or host controller; it is a multi-master bus
- Message priority governs which ECU has access to the bus, a method known as “arbitration.”
- A CAN network can accommodate 32 ECUs (nodes) on a bus length up to 40 meters.
- The maximum payload size for Standard CAN is 8 bytes (64 bits)
- A CAN ECU can act as a Gateway for relaying converted CAN messages to other networks
Armed with the above knowledge, we will now describe the operation and functionality of Standard CAN 2.0A
What is CAN 2.0A?
CAN 2.0A utilises a twin wire differential bus, with voltages driven to 3.5 V & 1.5 V from a recessive voltage of 2.5 V for binary signalling /communication (See image below)
The twin wire differential bus is connected to all Nodes and terminated at each end of the bus with 120 Ω resistors. The location of such termination resistors is typically found at the bus extremities, such as the Engine and ABS ECU; however, this is not mandated and so refer to vehicle technical data for location information (Note: Termination resistors may also be “stand-alone” devices and not contained inside a Node)
Below is a typical CAN bus consisting of Nodes, CAN Spine, CAN branches and Termination resistors
To summarise CAN communication, it is a bi-directional, event-triggered message-based protocol utilising various baud rates (speeds) including 125, 250 and 500 kbit/s. (1 Mbit/s is possible)
Bi-Directional: Data (messages) can travel in either direction along the bus and every connected node will receive the messages and can transmit accordingly
Event-triggered: Messages are transmitted when an “event” occurs, such as a change of state. E.g. Brake pedal moving from Off to On
Message-based: CAN messages are identified by their priority, not by the node that transmitted the message.
How does CAN Bus communicate?
The CAN bus voltage is held in the recessive state (2.5 V) via the CAN transceivers inside each Node (Bus standby). The transceivers drive the bus voltage on the twisted pair of wires to differing levels (3.5 V CAN Hi & 1.5 V CAN Lo) during signalling (i.e. communication)
Based on the bus voltage levels, the CAN transceivers calculate the differential voltage between the CAN Hi & CAN Lo wires to denote a logic 1 or 0. Subtracting CAN Hi & CAN Lo voltages returns a 0 – 2 V differential, where we generate the following binary states:
- Recessive low state (CAN bus differential at close to 0 V denotes logic 1)
- Dominant high state (CAN bus differential close to 2 V denotes logic zero)
The following image describes how we arrive at “logic” states from our physical bus voltage
Using the PicoScope CAN decoder, we can visualise how the differential voltage levels are encoded to denote the logic states (1-0), so transmitting data (See image below)
Note: The Pico CAN decoder can display encoded values in Binary, Hexadecimal and Decimal
For more information on applying the Pico CAN decoder to determine if messages are being sent correctly, please visit our YouTube channel here https://www.youtube.com/watch?v=D-Uqou348uk and skip to 7:46 minutes
How is a standard CAN packet formed?
The image below shows a Standard CAN packet and indicates the 7 major segments (fields)
- Start of frame or packet (1-bit)
- The arbitration field includes:
Identifier (11-bit) indicates the priority of the following data (see “How do we avoid collisions on the bus”)
- Control field includes:
DLC (4-bit) includes a coded value denoting the length of data
- Data field includes:
Data up to 8 bytes (0 – 64 bits) of data to be transmitted
- Cyclic redundancy field (CRC) includes (15-bit) error detection of transmitted data
The (CRC) sequence is calculated over defined fields in a packet, providing data verification and error detection. The calculated value is then transmitted with each packet, whereby the receiving Node will perform the identical calculation defined by the CAN protocol. The derived value (calculated by the receiving Node) is then compared against the transmitted CRC. Should the CRC values fail to compute, an error is detected and managed accordingly
- Acknowledge field includes:
ACK (1-bit) Confirmation that the transmitted message has been received, denoted by the transmission of a dominant bit by receiving Nodes. Typically, the ACK bit achieves a higher voltage level than the entire data packet due to network impedance fluctuations caused by all Nodes (that receive the message) simultaneously transmitting a dominant bit (loading the bus)
- End of frame
- Reveals the baud rate at 500 kbit/s based on a single bit time of 2 µs (500 kHz)
To find the baud rate of a CAN bus, measure the width of the Acknowledge bit and use the reciprocal of the obtained “time” value, e.g. 1 / 0.000002 s (2 µs) = 500,000 Hz or 500 kHz (500 kbit/s)
Note: A time interval of 4 µs equates to a frequency value of 1 / 0.000004 = 250,000 or 250 kHz (250 kbit/s)
How do we avoid collisions on the bus?
This comes down to point 2 above (Arbitration) and the value of the 11-bit identifier. In a scenario where 2 Nodes wish to transmit data at the same time, the message with the highest priority (lower ID value) will be granted access to the bus, whilst the other Node will try again once the “End of frame” signal has been transmitted and the bus voltage remains recessive for the period known as the Intermission space consisting of 3 recessive bits (6 µs for a 500 kbit/s bus)
Below we have 2 CAN packets that wish to transmit a message, one with ID 280 (Hex) 010 1000 0000 (binary) and the other with ID 380 (Hex) 011 1000 0000 (binary), only one will win arbitration and access the bus based on the lower numerical value of the ID
If we overlay both packets (see below), we note that ID280 transmits a dominant value when ID 380 transmits a recessive value. At this point, a dominant value overrides a recessive and ID 380 no longer transmits (lost arbitration), whilst ID 280 is allowed to continue
Once ID 280 has sent its message and received an “Acknowledgement” from other Nodes on the bus, ID 380 is now free to transit, unless of course, there is another Node (with a lower ID value) that wishes to transmit. Below, we see how ID 380 immediately follows ID 280
CAN bus voltage thresholds
We have described above how CAN bus voltages switch from the recessive 2.5 V to the dominant 3.5 V and 1.5 V to convey logic states 1 and 0, respectively. However, there must be an allowance for voltage drop and impedance/capacitance variations across the entire bus.
To combat signal degradation, the following bullet points indicate the actual voltage thresholds utilised by the Nodes on the CAN bus, along with several tips to aid diagnosis
- CAN Nodes will interpret a differential voltage of more than 0.9 V as a dominant level
- CAN Nodes will interpret a differential voltage below 0.5 V as a recessive level
- The voltage deviations in a CAN packet provide a means to identify Nodes based on their unique voltage levels (voltage signature)
- CAN Nodes can request data from other Nodes!
The Pico decoder table includes a column entitled RTR (Remote Transmission Request) after the ID column to indicate the type of data transmission. A recessive bit (logic 1) within the RTR field indicates the Node is requesting data
- Current flow in a CAN bus branch flows away from a Node on CAN Hi & to the ECU on CAN Lo (It does not flow through the termination resistors)
- A CAN packet cannot contain a sequence of more than 5 consecutive recessive (1) or dominant (0) bits. Where these events occur, a single “stuff bit” of the opposite polarity (logic state) is inserted into the data stream for synchronisation and error checking
- “Ringing” present on CAN signals is a typical characteristic of the network and attributed to component inductance/capacitance and tolerated by the CAN protocol
- To combat “ringing”, utilise the Pico high impedance 10:1 attenuated test leads
Fault-tolerant CAN
Previously, in this article, we mentioned CAN reliability and fault tolerance, particularly in harsh environments. This is achieved by twisting the CAN bus wires such that they are equally exposed to external noise (EMI). Given the CAN nodes are calculating then evaluating the differential voltage on the twisted pair, any noise present in one wire (E.g. CAN Hi) will also be present in the remaining wire (CAN Lo) in equal and opposite measure
Below we have an example of an EV CAN with an exceptional noise level present when the e-motor is energised, and the vehicle is pulling away from rest. (Likely caused by the switching of on-board power electronics)
Using the built-in Math channel A-B (CAN Hi – CAN Lo), we reveal the “cleansed” differential voltages as calculated by the CAN Nodes to denote the logic states 1 -0. (High-frequency noise is removed)
More information
The above article serves as an introduction and overview of standard CAN 2.0A. To dive deeper, please refer to official publications to both broaden your knowledge and improve diagnostic skills. Thank you as ever for taking time to read these articles and associated videos here: https://www.youtube.com/playlist?list=PLwQU2pgVAGvEpq8u9OHz3hOIsZj1fPBR3
The conversation doesn’t stop here! We’d love for you to join us on the forum to discuss this article, see what other users are saying, and catch all the updates. Click here to jump in: https://www.picoauto.com/support/viewtopic.php?t=23852