Controller Area Network (CAN bus) in the

Automotive IndustryAn efficient way to establish in-system

communication.

By: BESSAAD NASSIM

2016

Introduction:The needs leeds to innovation. First Approach. Conception of the CAN bus. Details about CAN. CAN in cars. OBD and CAN. Conclusion.

PLAN

In order to understand the birth of the CAN bus technology, we must go back in time.

After WWII, most of the military application manufacturers (tanks, jets, …) switched to cars instead (Wolkswagen, SAAB..). The market grew exponentially, the automotive industry became the heart of the economy, that led to big competition and rivalry and this naturally leads to new horizons for the automotive industry. The car electronics became a large part of the car, naturally the wiring harness became a problem.

Introductions:

Peace-time

The man of the hour was Robert BoschIt was 1986, Detroit USA, the annual SAE Congress, Robert Bosch revealed the Controller Area Network bus system to support short messages that circulates between the vehicles embedded systems.

Solution:

From:

First Approach

To:

First Approach

This is a vehicle bus with: Serial communication protocole. Multi-master message model. System flexibility. Message anti-collision protection procedure

(arbitration). Communication speed up to 1 Mb/s. Error detection. Maximunm network size is limited only by electrical

loading.

CAN characteristics:

Bit Rate / Bus Length1M bit/sec 40 meters (131 feet)

500K bit/sec 100 meters (328 feet) 250K bit/sec 200 meters (656 feet) 125K bit/sec 500 meters (1640 feet)

CAN characteristics:

BUS : The physical medium that allows data to find its way from source to desired destination.

Conception:

The CAN is a gathering of nodes without a limited number of them, but the electrical loading suggests under 70 node is best.

This nodes communicates using messages called frames which is a common language for all nodes, the frame has four types:

DATA FRAME REMOTE FRAME ERROR FRAME OVERLOAD FRAME

Conception

The stream of bits in CAN bus is coded according to the non return to zero (NRZ) methode with bit stuffing.

after having sending five consecutive bits of identical value, a stuff bit is added, it’s a bit of inverse value of the past five. Of course it’s discarded by the receiver.

Conception

ConceptionThe data frame in 2.0 A has the following format:

Controller Area Network 2.0A which is the standard frame and 2.0B is the extended frame.

The main difference between the A and B is in the message frame, particularly in the Identifier, the standard CAN 2.0A uses identification field of 11 bits the extended CAN 2.0B has a 29 bit Identifier (Arbitration Field).

PS: We can Implement both CAN frame formats in the same Network with no problems of compatibility.

But if two different format nodes has the same 11 first bits in the arbitration, the one with CAN 2.0A wins regardless of the remaining bits of node with CAN 2.0B frame format.

Extended Message format:

CAN 2.0B

The microcontroller or the central processing unit: The brain of the node, it supervise the communication, sending and receiving and treating decisions.CAN controller: responsible of storing the received bits until a complete message is available.The CAN transceiver: it represents the physical link between the nodes core and the wires of a bus, it has the role of a converter,applies the voltage difference on the wires to create the

signal to be transmitted.

CAN node:

In CAN we find several error detection procedures: Bit Monitoring

Compares every bit placed on the CAN bus with the actual bus level

Stuff Check Compares arriving bit stream for a sequence of six homogeneous

bits. Form Check

Comparison of the arriving bit stream with the message format Cyclic Redundancy Check

Every node compares the received value of the CRC with the calculated one it has.

ACK Check Acknowledge error (ACK error) is detected if the recessive level

placed by the sender is not overwritten.

CAN data protection:

Every node has three states:

CAN data protection:

Multi-master priority based bus access. Non-destructive contention based arbitration Multicast message transfer by message acceptance filtering Remote data request Configuration flexibility System wide data consistency Error detection and error signaling Automatic retransmission for message that lost arbitration Automatic retransmission for message that were destroyed by

errors Distinction between temporary errors and permanent failures of

nodes Autonomous deactivation of defective nodes Low-cost, Lightweight network.

CAN proprieties (Advantage):

CAN was originally conceived for applications in the automotive industry, but its grand reliability and flexibility plus its Baud-rate that generates quick response enabling real-time application implementation, turn the heads of all area application designers in order to invest in the efficiency of this communication protocol.

So, we find today CAN in military, medical, automation …ETC

More than five billions integrated CAN chips are cheeped every year.

But the automotive industry still the biggest winner for CAN evolution as we shall see further in this presentation.

CAN applications:

CAN application

The Controller Area Network became an essential for cars, to understand how big its role we must understand the cars electronics and evaluate the thing that makes these machines one of the greatest invention of mankind.

CAN in automotive

The built-in system interface or “BSI” in a vehicle is a gateway to the diagnostic tool that can incorporate many electronic modules such as the interface electronics, the control electronics because it can directly communicate with the engine ECU and the petrol pump; also it contains

the vehicles information (VIN code, key code, HF remote control code…..).

CAN Built-in System Interface:

OBD monitors the components that make up the emission system and key engine components. It can usually detect a malfunction or deterioration of these components before the driver becomes aware of the problem.

Since the 1996 model year all vehicles must comply with OBD II requirements. OBD II requires the monitoring of virtually every component that can affect the emission performance of a vehicle plus store the associated fault code and condition in memory.

On-Board Diagnostic:

When the OBD system determines that a problem exists, a corresponding “Diagnostic Trouble Code” is stored in the computer memory.

Trouble codes are how OBDII identifies and communicates to technicians where and what on-board problems exist. The first number in the DTC indicates whether the code is an SAE generic code (applies to all OBDII systems) or is specific to the vehicle manufacturer. The remaining three numbers provide information regarding the specific vehicle system and circuit.

Theses DTCs comes handy for a technician in order to apply the necessary maintenance for the car because their interpretation is universal (generic).

ON-Board Diagnostic Trouble Codes

OBDII trouble code

OBD II: Pin-out

To be able to extract needed data the SAE J1979 standard define a method for requesting various diagnostic data and a list of standard parameters that might be available from the ECU, the available parameters are called Parameter identification numbers (PIDs).

Every manufacturer has the liberty of changing some listed PIDs in the SAE J199and add others freely.

The OBD II has (09) nine operation modes.

OBDII:

MODE 1:This mode returns certain current values of vehicles sensors.

MODE 2:This mode returns instant data of a malfunction; when a malfunction is detected by ECU it registers the sensors data at the moment of the fail appears.

MODE 03:Returns DTC registered, these codes are standardized for all brands of vehicles.

Mode 04:This mode Allows clearing the stored trouble codes; and shutting down the malfunction Indicator.

Mode 05:This mode doesn’t use the CAN bus.

OBD II modes:

Mode 06:This mode returns the test results of a diagnostic for ECUs using CAN bus only.

Mode 07:This mode shows pending Diagnostic Trouble Codes (detected during current or last driving cycle).

Mode 08:This mode shows Control operation of on-board component/system, not used a lot in Europe.

Mode 09:Returns Vehicles information .

OBD II modes:

The request and response uses functional addresses, the diagnostic tool uses a CAN ID of 0x7DF to broadcast a query later it accepts 8 ECUs responses using IDs from 0x7E8 to 0x7EF.

The ECU response has an ID of their assigned ID plus 8.

Figure: OBD II query PID on CANbus.

PBD II PIDs:

ECU response:

OBD II PIDs:

Many contributions affected the automotive industry in the last century, but the Controller Area Network and On-Board Diagnostic had a huge impact for what it brought of advantage for the car manufacturers and the simple consumer.

Therefore, the development of electronic gadgets based on those technologies is on the run, we now can diagnose the car and retrieve many informations easily thanks to those tools.

Conclusion