Controller Area Network (CAN) Tutorial

This course will guide you through the basics of Controller Area Network (CAN), CAN channel setup, reading and storing data from a CAN network, sending data on to the network with Dewesoft X2.

Vehicle subsystems from the internal combustion engine to powered windows are controlled by electronic control units (ECU). These units are usually dependent of each other and have to pass information between one another.

For example a control unit in the car’s automatic gearbox shifts gears based on engine revolutions per minute and throttle position. Control unit in automatic transmission runs an algorithm that determines if the gear change is required based on the data that it gets from the engine control unit (engine speed (RPM), throttle position, emission sensors…). To ensure smooth gear shifting engine speed has to be adjusted to the next gear. Therefore both control units have to constantly communicate with each other to ensure correct operation.

Another example are powered windows in a road vehicle. Their upward and downward motion is controlled by an electronic control unit. This control unit switches the electric motor in the correct direction and also stops the electric motor when the window is in the fully closed or fully opened position. The electronic control unit gets messages to move windows from other control units. For example it can get an order from a control unit that checks the position of dashboard buttons or from a unit that receives signals from a vehicle remote control. Each of the mentioned control units performs its task and signals other control units to perform a task that is required from them. The messages can go either way. For example the window control unit can send a message back to other control units that the window is fully closed or fully opened.

As we can see from the previous example a single unit works only if it is connected to other units. Message transfer between units could be made with direct connections based on the dependency of electronic control units.

Electronic control units connected based on information flow between them

Electronic subsystems on modern road vehicles are usually controlled by more then 150 ECUs. These control units are highly dependent of each other and are connected to a single or multiple serial networks.

On a serial network data is being transmitted bit by bit onto a network. Each device can read all of the messages on the network but responds only to those that are meant for it. To ensure that critical messages get to their recipients with the least possible delay message priority is based on message importance.

Electronic control units connected on to a serial bus

Communication networks in modern road vehicles connect all of the electronic subsystems together. With transfer speeds of up to 10 Mb/s large amounts of data can be generated. With Dewesoft, we can decode and store this data.

Dewesoft device connected on to a serial bus

Controller Area Network (CAN) is the most widely used communication protocol in automotive applications. It was developed to replace complex wiring harnesses with a two-wire bus. CAN network consists of nodes – electronic control units (ECU) that are connected on to a two wire bus. Any electronic device with a CAN interface can be connected on to a network. 

Messages on CAN aren’t passed directly from node to node but are transmitted on to the network. Messages each have their unique message identification number which is also used to determine message priority. CAN network can operate without a central control node, message hierarchy is not based on nodes but on the messages that they transmit. Therefore, one node can transmit both high and low priority messages.

Error in message transmission is checked by all of the nodes that are connected to the network. If one of the nodes detects an error in message reception it sends a special error message on to the network. A node that originally sent the message has to retransmit it.

Different versions CAN configurations are defined by ISO standards. Normally there are two configurations used in automotive applications. High speed CAN is used for communications between critical subsystems that require high update rates and data correctness (anti lock braking system, electronic stability control, airbags, engine control unit…). Data transfer speeds of high speed CAN ranges from 1 kbit to 1 Mbit per second. Low speed CAN is used for fault tolerant systems that do not require high update rates. Their maximum data transfer rate is limited to 125 kbit per second but their wiring architecture can be more economical. In automotive applications low speed CAN is normally used for diagnostics, dashboard controls and displays, power windows…

During CAN bus operation additional nodes can be connected on to it. Dewesoft devices with CAN interfaces act like additional nodes on the CAN network. Dewesoft devices can read and also write data on to the CAN network.

CAN message types

There are four different message types/frames that can be transmitted on to the CAN network

1. Data frame
   A message that transmits data through the CAN network. It is the most common message type on the network. Message consists of:
   • arbitration field – field that contains the message identification number and remote transmission request bit. More important messages have lower ID numbers, when multiple nodes want to transmit at the same time they start a simultaneous arbitration. A node with the lowest message id number wins. The message identifier can be 11 bit (Standard CAN, 2048 different message identifiers) or 29 bit in length (Extended CAN, 537 million different message identifiers). The remote transmission request bit is dominant and signals that data is being transmitted,
   • data field – field in length from 0 to 8 bytes that holds data,
   • crc field – cyclic redundancy check field, shows if there were any mistakes during message transfer,
   • acknowledge field – every node changes this field if it received a message without any errors.
   • 
2. Dewesoft X can read or transmit data frames. It only needs message identification numbers and lengths of data fields of each data message. All of the other frames are automatically taken care of by Dewesoft devices and software.
3. Remote frame
   The purpose of the remote frame is to request a message from another node. By structure it is similar to the data frame. The difference is that it doesn’t contain any data and has a recessive remote transmission request (RTR) bit which signals a message request from another node.
4. Error frame
   Error frame is a special frame that violates CAN formatting rules and signals an error in data transmission. A node that detects an error while reading the message on the network transmits an error message. Because an error frame violates CAN formatting rules all of the nodes that were reading from the network retransmit it. After that a node that originally transmitted a message with an error has to retransmit the original message.
5. Overload frame
   It is similar to the error frame with regard to formatting. It is transmitted by a node that becomes too busy. It is primarily used as an extra delay between messages.