CAN (Controller Area Network) - operational principle
The CAN bus is an asynchronous, serial field bus system for networking control units, sensors and actuators. Unlike other network protocols, CAN does not address the bus nodes (control units) but the transmitted message. In short: The message contains the information who has sent it and the bus nodes decide whether they use the message or not. For this purpose, the CAN bus has been designed as a multi-master topology (all nodes have equal access) where the bus access is regulated by the CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) procedure. Bus access collisions are avoided by using bit-by-bit arbitration. The data is NRZ-L coded. An additional cyclic redundancy check is performed via CRC.
CAN is a locally restricted system that belongs to the family of the LAN (Local Area Network) networks. Thus it conforms to the OSI network model.
The OSI network model defines seven layers.
| Layer |
Description |
|
| Application (7) |
Application layer / processing layer. The functionality of the network is provided to the user in this layer, e.g., e-mail in the Internet (Ethernet). |
|
| Presentation (6) |
Presentation layer. The system-dependent data (data in the transmission control unit) is changed to a system-independent representation that corresponds to the CAN protocol. This also includes data compression and encoding. In short: The data of the transmission control unit is translated into the "CAN language". |
|
| Session (5) |
Session layer. Communication between the control units in the vehicle is controlled here. |
|
| Transport (4) |
Transport layer. It is responsible for segmenting data packages and avoiding data backup on the CAN bus. |
|
| Network (3) |
Network layer. It is responsible for routing the data packages on the BUS. (The data streams are routed from the sending to the receiving stations. Can be compared to transferring a phone call from one extension to another.) |
|
| Data Link (2) |
Safety layer. The data is split into bit data streams and provided with checksums here (encoding of the data). |
|
| Physical (1) |
Bit transfer layer. This is the cabling (copper cable / optical cable). |
|
 |
|
The CAN bus in vehicles is used as a linear bus. Ring or star topologies are not allowed. The bus medium is a twisted or shielded two-wire copper line (CAN-H and CAN-L) that is terminated with a 120 Ω resistor. These terminating resistors are inevitable because otherwise the CAN signals could be reflected from an open or wrongly connected line end and return in the same line. These reflections overlay the signals that are actually provided on the CAN bus, thus causing the system nodes to become illegible.
| System node |
It consists of a micro-controller, a CAN controller and a bus driver. |
|
| Micro-controller |
Controls the CAN controller and processes transmission and receive data. |
|
| CAN controller |
Implements the transmission and receive operations via the CAN bus. |
|
| Bus driver |
Sending or receiving the bus level. |
|
| Bus line |
Two-wire line (twisted or shielded) |
|
| Bus terminator |
Resistors to avoid reflections. (inevitable) |
|

 |
|
The CAN signal is a digital signal (two conditions only "recessive = 1" and "dominant = 0") that is short-circuit proof for +24V vehicles in a range from -3 V to +32 V. The recessive level has been defined with 2.5 V for both lines, the dominant level with 3.5 V (3 V to 5 V) for CAN-H and 1.5 V (max. 2 V) for CAN-L. The difference between CAN-H and CAN-L is decisive for detecting a change in the condition. The voltage difference between CAN-H and CAN-L has been defined with 2 V (1.6 V - 5 V) for a dominant level and with 0 V (-1 V - 0.5 V) for a recessive level.
 |
|
A complete data package (dataset) on the CAN bus consists of seven fields.
| Start Frame |
The start frame marks the beginning of a message and synchronizes all stations. |
|
| Arbitration Field |
The arbitration field consists of a message identifier (11 bits) and one check bit. During transmission of this field the sending station checks for each bit, whether it is still authorized to send, or whether another station with higher priority is sending. The check bit decides whether the message is a data frame or a remote frame. |
|
| Check Field |
The check field contains the code for the number of data bytes in the data field. |
|
| Data field |
The data field transmits information for other stations. The information content is between 0 and 8 bytes (1 byte = 8 bits), max. 64 bits. |
|
| CRC Field |
The CRC field detects transmission faults. |
|
| Acknowledgement Field |
With the acknowledgement field, the recipient signals to the sender that it has received the message correctly. If a fault is detected, the sending station will be notified immediately. The sender will then resend the data. |
|
| End of Frame |
The end of frame marks the end of the message. This is the last chance to report faults. |
|
The SAE J1939 CAN protocol additionally defines another arbitration field from 11 bits (base frame format) - to 19 bits (extended frame format) - identification.
 |
|
The object identifier designates the contents of a message. On the basis of this identifier, the recipients decide whether the message is relevant to them or if it is discarded. This identifier is also used for priorization and arbitration of the messages.
CAN is a multi-master bus system. Arbitration and priorization regulate the transmission rights to the bus.
Arbitration principle:
The bus load is started by transmitting a dominant bit (SOF). The bits of the identifier are then transmitted to the bus one after another and compared to the actually provided bus level. If a difference is detected during arbitration (recessive sent - dominant detected), the sender of the recessive level will withdraw from the bus and switches to the reception mode immediately. The dominant bus level that was detected was received from a sender with higher priority.
More information on: Voith Turbo CAN - training material
More information on:
DIWA.5 CAN messages
Up
> Higher-level section
© by Voith Turbo GmbH & Co. KG
send remarks to joachim.ehleiter@voith.com (electronic department)
or r.theilacker@voith.com (electronic department) |