Can System
The CAN bus is a high reliability, high data rate bus for communicating
between electronic devices in situations where high data reliability is
required. One use of the CAN bus is in the automotive applications where
the CAN bus is being used as a substitute for copper wiring looms in cars.
In this article we take a look at what the CAN bus is.
Can System on Board
Signal from CAN System without fault and load
Right indicator
Left indicator
Rear wiper
Stop light
Fuel pump
Reverse light
Every pattern is individual for every load, such: rear light, wipers,
windows, sensors, ABS, transmission, head lights etc.
Both channels should mirror each other as shown in a picture above.
CAN L is being pulled down from about 2.5V
CAN H is being pulled up from about 2.5V
This board shows a typical CAN node on a network. All nodes have a
microcontroller with I/O circuitry, have a CAN controller and a line
driver which interfaces the CAN L and CAN H differential
connections to the CAN controller. Some microcontrollers
have the CAN controller embedded which reduces the cost of the
node. WE can see that the connections to the CAN node are
power, ground, CAN H, CAN L and then other connections to I/O
as required CAN nodes in a car. In this context where
a node is a complete functioning unit the node is often referred
to as an Electronic Control Unit or ECU. Here you can see five ECUs:
an engine temperature sensor, an instrument panel, a switch on a
brake pedal and ECUs for the left and right hand rear light clusters.
Although the wires are not shown here all power and grounds are
connected, and all CAN H and CAN L terminals are connected
by 100ohm terminated twisted pair wires. In practice you may
find the foot brake connected to the instrument panel ECU etc.
A key feature of CAN is reliability, and this is kept to a maximum
by keeping traffic on the CAN bus to a minimum. In a conventional
network you might think that the foot pedal would tell the central
processor on the instrument panel that it has been pushed down,
and the instrument panel would then tell the light cluster ECUs to
turn the brake lights on. CAN works differently: When the pedal is
depressed the brake pedal ECU issues a message effectively stating
“brake pedal pressed”. This message is issued to the whole bus. The
ight cluster ECUs are programmed so that when they see the
“brake pedal pressed” message on the CAN bus they power up the
appropriate lamp. This has kept message flow to a minimum, and if
the instrument panel ECU—or any other ECU—is not working then
the core important functions of the network are still active. This is an
example of one type of data exchange for important ‘mission critical’
data: if your brake lights don’t come on then you could run into trouble,
or it would run into you. However if this method was employed by all
devices connected to the bus then the traffic would be quite large—with
more traffic meaning reduced reliability. So a second technique for data
exchange is used. Looking at temperature monitoring: the central
instrument cluster wants to know what the temperature of the block
is so that temperature can be displayed on the instrument console
and—if necessary—the warning light activated. The designers of the
system will have decided that the temperature needs to be monitored
at, say, 5 second intervals. So every 5 seconds the central console
will issue a message saying “can anyone tell me what the block
temperature is?” The ECU on the block is programmed to look for
the message “can anyone tell me what the block temperature is?”,
to then measure the temperature, and reply with a message stating
“the block temperature is” followed by the temperature data.
Next
Next