Can Training Presentation

CAN
CAN: Controller Area Network
Controller Area Network

INTRO
2 / Basica Liviu / 2009 © Continental AG For Internal Use Only

What is CAN ?
Controller Area Network (CAN) is bus standard for automotive applications, originally developed in
the 1980s by Robert Bosch GmbH, for connecting electronic control units (ECUs):
asynchronous;
bidirectional half duplex;
linear;
with protocol: address + data + data check + signal information;
multi-master: every node can start communication.
Requirements to Automation and Automotive Bus Systems:

The costs;
Transmission in a area with Radio Frequency noise;
Real-time behavior;
Easy handling;
Standardization.

How it began?
Engine Antilock Lighting Air condition

control Brakes
High speed CAN Instrument Low speed CAN

Cluster
(Dashboard)
Transmission Active
control Suspension Power Seats Power
windows

CAN Advantages
Less wires;
Less connections;
Less weight;
Less EMI problems;
Less space required;
Easier addition of new nodes;
Lower assembly costs;
Increased transmission reliability;
Standardization: ISO 11898, 11519, 11992, SAE j1939...
“The great thing about standards is that

SAE
ISO
CiA
DIN
there are so many to choose from.”

An ECU's CAN structure
ISO/OSI Model
Application Software All Application Layer
SW
People Presentation Layer
Seem Session Layer
ECU To Transport Layer

CAN Subsystem on Host Controller
Need Network Layer
Data Data Link Layer
CAN Controller
Processing Physical Layer
HW
CAN Transceiver
CAN bus

HARDWARE

CAN Bus / Network
double wire linear bus – basic termination
Network Node 1: Network Node n:

e.g. Engine e.g. Airbag
Control
CAN-H
~ ~~
120 Ω 120 Ω
CAN-L
double wire linear bus – split termination

~
CAN_H
RT /2 = 60 Ω RT /2 = 60 Ω
Cg Cg = 10 .. 100nF
RT /2 = 60 Ω RT /2 = 60 Ω
CAN_H

CAN Bus / Network
CAN star bus
RT = 180 Ω RT = 180 Ω
RT = 180 Ω
The multiple termination concept is used when network architecture differs from linear
structure e.g. the cable drop length of a few meters is needed. For such a topology a
multiple termination concept with three branches needs about three times the total
termination resistance: 180 Ω .

CAN Bus / Network
Daimler-Chrysler Patented Star Topology
T T
r CAN_H r
a 30 Ω a
n n
CAN s 10 Ω s CAN
node c c
e e node
i i
v 30 Ω v
e CAN_L e
r r
2 mH
ferrite bead: 44 Ω
10 pF
Daimler-Chrysler have patented a star topology with a common termination. This topology
avoids resonance problems, undesired harmonics and it's insensitive to incoming noise. All
noise traveling towards the termination point will be absorbed there and never reflected.

CAN Bus / Network
CAN Transmission via Fiber Optic Cable
Very high transmission rates are possible;

Access to data in systems with very high electromagnetic noise;
Data transmission of sensitive data in systems with very high security requirements is possible.
The communication in a car may be classified into three classes.

Related to the performance of different systems there are:
Class A - used for low-speed data communication: up to 10 kbit/s;

Class B - used for status and diagnostic data sharing: 10 to 125 kbit/s;
Class C - is used for real-time application communication at high speeds of 125 kbit/s to 1 Mbit/s.

CAN Bus / Network
High-Speed definitions according to ISO 11898
Volts
CAN-H
3.5
2.5
CAN-L
1.5
Time
Recessive Dominant Recessive

CAN Bus / Network
Low-Speed definitions according to ISO 11519
Volts
CAN-H
4.0
3.25
1.75
CAN-L
1.0
Time
Recessive Dominant Recessive

Physical Layer:
CAN Transceiver
The transceiver is able to convert a digital CAN controller signal in a symmetrical differential one and vice
versa.
Some of these transceiver offer special features like:

slope control;
bus short circuit protection to battery voltage and ground;
single wire transmission in case of short circuit of bus lines;
receive filter (low pass filter) against glitches (e.g. less 30 ns).
ISO 11898, ISO 11992, ISO 11519.

Physical Layer:
CAN Transceiver
e.g. High Speed Double-Wire Transceiver PCA 82C250
- ISO/DIS 11898 compatible

- High Speed (up to 1 Mbit/s)
- Standby Mode
- Slope Control / Standby
- Short circuit protection for
Vref Rs - CAN_L and CAN_H
µ C TxD CAN_H CAN_H

RxD CAN_L
CAN_L
GND VCC
PCA82C250
Vref reference voltage output Rs slope resistor input

TxD transmit data input CAN_H HIGH level CAN voltage input / output
RxD receive data output CAN_L LOW level CAN voltage input / output
GND ground Vcc supply voltage

Physical Layer:
CAN Controller
To be able to participate in the CAN communication, the micro-controller has to be connected

to a CAN protocol controller.
The CAN controller may be a different chip or be integrated into the microcontroller:
Microcontroller Microcontroller
CAN controller
CAN controller
Transceiver Transceiver
CAN Bus

Physical Layer:
On-chip CAN Controller

Physical Layer:
Basic CAN
There are two types of microcontroller with on-chip CAN module:
Basic CAN Controller:
Limited number of Rx and Tx Buffers;
Reception of all CAN identifiers, all the time;
High CPU load;
Cheap implementation;
Message Object Register:
- Data 0 .. Data 7
- Message Configuration
Rx Message Rx Message - Arbitration Mask

CAN
Object 1 Object 2
- Message Control
Controller Tx Message Tx Message
Object 1 Object 2 opt. General Registers for:
memory
General Register Set - CAN Controller Init
area
- Handling of Status
Information

Physical Layer:
Full CAN
Full CAN Controller:
Many Full-CAN controller provide a "Basic-CAN-Feature";
Large number of buffers for Rx and Tx;
Buffers can be pre-defined for specific identifiers;
All transmit frames in these buffers participate in arbitration;
Less CPU load;
Message Object Register:
More expensive;
- Data 0 .. Data 7
- Message Configuration
Message Object n - Arbitration Mask

CAN .
. - Message Control
Controller .
Message Object 1 General Registers for:
memory
General Register Set - CAN Controller Init
area
- Handling of Status
Information

Physical Layer:
Bit timing
Problem:
Frequencies of the quartz oscillators of the CAN nodes usually differ;
Re-synchronization of nodes during transmission is necessary;
Solution: CAN Bit Timing

CAN Bit Timing divides the bit time into several segments;
Segments 1 and 2 can be lengthened or shortened during transmission;
Re-synchronization of nodes during transmission is possible.
Bit time
Synch Propagation Phase Buffer Segment 1 Phase Buffer Segment 2
Segm Time Segment
tq
sample point

Physical Layer:
The communication
Transmission with Carrier Sense Multiple Access with Collision Avoidance CSMA/CA;
each node monitors the bus;
each node can start transmission;
arbitration: dominant bits (low) win against recessive bits (high) on bus;
the arbitration winner continues transmission;
V+ 1 (high) V+
recessive dominant recessive
0 (low)
Bus Line
Transmit Transmit Transmit
Node A Node B Node N

Receive Receive Receive

Physical Layer:
Arbitration
The arbitration of messages on the CAN bus is a hardware implemented bit-wise process.
If one node switches a “HIGH” and reads a “LOW” he loses the arbitration and stops his transmission
immediately.
The lowest address number (ID) will always win this arbitration without any information loss of his
message
Idle Start dominant

Node A Bit
Idle Start
Node B Bit listening only
recessive
Idle dominant
Bus Level

Physical Layer:
Bit Coding - Bit Stuffing
CAN data is transmitted with NRZ (No-Return to Zero) bit coding;
Problems when using NRZ coding:
long sequences of bits of the same polarity;
no changes in voltage level for a longer time;
no falling edges for synchronization;
synchronization between sender and receiver may be lost;
Solution: Bit stuffing

after five consecutive bits of same polarity, insert one bit of reverse polarity;
CRC code is calculated before bit stuffing is done;
bit stuffing is done by the sender directly before transmission;
de-stuffing is done by the receiver directly after reception;
CRC code check is done after de-stuffing the frame;
bit stuffing is applied to part of the frame from SOF to CRC field

Data Link Layer:
The message – Data Frame
Data frames: generated by a CAN node when a node wishes to transmit data;
standard frame – 11bit identifier (also called CAN 2.0A);
extended frame – 29bit identifier (also called CAN 2.0B);

Data Link Layer:
SOF: Start of Frame. SOF = 0;

marks the start of any CAN frame;
provides a falling edge for hard synchronization of transmitter and receivers
IDE: Identifier Extension
IDE = 0 – Standard Frame;
IDE = 1 – Extended Frame;
DLC: Data Length Code
the bytes number of the data field
Data Field: contains the actual information to be transmitted;
number of data bytes may range from 0 to 8 in units of bytes;
transmission starts with the first data byte (byte 0), MSB first

Data Link Layer:
CRC: Cyclic Redundancy Check

15 bit check sum generated by transmitter and controlled by receiver
the CRC Field Delimiter (DEL) marks the end of the CRC field
ACK: Acknowledge – on Tx is recessive and on Rx is dominant;
the ACK Field Delimiter (DEL) marks the end of the ACK field
EOF: End of Frame
consists of seven consecutive recessive bits;
marks the end of the Data Frame;
IFS: Interframe space
consists of at least three consecutive recessive bits;
no transmission is allowed during the Interframe Space (IFS);
is needed by controllers to copy received frames from their Rx buffers

Data Link Layer:
The message – Remote Frame
Remote frames: Destination node is able to require data from another node: RTR = 1
standard frame;
extended frame;

Data Link Layer:
The message – Faults
Fault Types in a CAN Bus System:
Global Faults: lead to a breakdown of the system wide communication (e.g. short circuits or
interrupts of the line, deadlock of the bus due to a permanent transmitting node;
Local Faults: are limited to malfunctions of a node ore node components (e.g. interrupts in a bus
connector, transmit problems of a transmitter, etc.);
Temporary Faults: disturb the CAN bus system for a limited time;
Permanent Faults: disturb the CAN bus system all the time, they are not reversible.

Data Link Layer:
The message – Error Frame
Error frames: Each CAN node detecting an transmission error sends an “Error Frame” (Sequence of 6 bit
with the same level):
CRC code calculated by receiver (ACK)

Acknowledge Fixed-form bit field contains one
does not match received
bit is CRC code
recessive ore more illegal bits. e. g.
violation of end of frame EOF
format, CRC- or ACK-delimiter
More than five bits of equal
polarity inside of a frame are
detected until the ACK field
The bit actually appearing on

the bus is different from the
one transmitted
CRC
Bit
Bit
ACK
Form Error
Error
Error Monitoring
Stuffing
Error
ErrorMonitoringArea
Monitoring
Monitoring
MonitoringArea
Area Area
Area
IFS/IDLE SOF Message ID Control Data CRC ACK EOF IFS IDLE /SOF
Data Link Layer:
Error Frame – Status of the node
The error management unit uses two error counters:
a receive error counter REC
a transmit error counter TEC If to many errors are
CAN node status after reset: TEC = REC = 0.
detected by one node, this
node is automatically
Error active node : disconnected from the bus.
For each6detected
dominant
error there is
generated an active error flag Error
bits
(queue of six consecutive dominant Active
bits)
Error condition REC > 127 or
TEC > 127 REC < 128 and HW reset
Error passive node : TEC < 128
For each detected error there is
generated an passive error flag
(queue of six consecutive Error Bus
recessive6 bits)
recessiv bits Passive TEC > 255 Off
Error condition

Data Link Layer:
Error Frame – Superposition of error flags
In the case of one node detects a local error it will send an error flag. Other nodes may detect an
error because of this error flag. They send also an error flag;
After receiving/sending an error flag all nodes cancel the message;
Each node which detects an error increments its error counters;
Overlapping error flags result in a queue of 6 up to 12 active error bits followed by an error delimiter
(queue of 8 recessive bits)
Error condition
Superposition
Error Flag of Error Flags 8 Bit Error Delimiter IFS SOF / Idle
6 bit Up to 6 bit 8 bit 3 bit Bus Idle or

error flag error flag error delimiter IFS Start of Frame
Node A Node X Node X

Data Link Layer:
The message – Overload Frame
Bus Idle Overload Flag Overload Delimiter Interframe Bus Idle

Space
recessive
Bus Idle 6 dominant bits 8 recessive bits 3 bits Bus Idle
dominant
Unit sends Overload Frame when at present it cannot receive frames any more due to high workload;
Transmission of an Overload Frame is started during the first two bits of the Interframe Space (IFS) of the
preceding frame;
Other units react immediately by also transmitting Overload Frames Overload Flags overlap, resulting in
up to 12 consecutive dominant bits;
Implemented in very few (mostly older) controllers, though controllers must still be able to interpret
correctly Overload Frames they receive;
Overload Frames do not influence the error counters (TEC and REC)

Data Link Layer:
Transmitter / Receiver
A unit originating a message is called “TRANSMITTER” of that message. The unit stays
TRANSMITTER until the bus is idle or the unit loses ARBITRATION.
A unit is called “RECEIVER” of a message, if it is not TRANSMITTER of that message and the bus is
not idle.
The message is valid for the transmitter, if there is no error until the end of END OF FRAME. If a
message is corrupted, retransmission will follow automatically and according to prioritization. In order
to be able to compete for bus access with other messages, retransmission has to start as soon as the
bus is idle.
The message is valid for the receivers, if there is no error until the last but one bit of END OF
FRAME.

SOFTWARE

CAN subsystem:
Vector solution
ISO/OSI Model
Application Software Application Layer
CAN Subsystem DIAG Presentation Layer
Session Layer
IL
CCL
Transport Layer
TP GENy
Calibr Tool
NM Network Layer
CAN Driver Data Link Layer
CAN Controller
Physical Layer
CAN Transceiver
CAN bus

Data Link Layer:
CAN driver
The generic CAN Driver code is independent of the Application.
Functional scope:
Initialize the CAN controller;
Transmit a single CAN message: CanTransmit(<MsgHandle>);
Receive a single CAN message; A CAN controller is said to be in
Handle Bus-Off; "bus off" state if it's not
Support sleep mode;
participating in the bus traffic
Support special services. Some CAN Controller are supporting a
so called sleep mode with reduced
power consumption.
1. Interrupt control;
2. Assertions;
3. Support OSEK;
4. Multiple channels;
5. ...
Data Link Layer: CAN driver – Rx
CAN BUS
CAN message received
HW Acceptance Filters
For a Basic-CAN Controller or the Basic-CAN object of a
Normally,
The function
Full-CAN the CAN theDriver
ApplCanMsgReceived()
Controller hardware is informed
is calledby
acceptance bythethe CAN
filtering
Driver
CAN
providedon by
every
the reception
Controller of a CAN
via interrupt
CAN Controller of message
the
is not after
reception
sufficient. the
of a
Therefore
hardware
CAN acceptance
message.
a software filter is passed.
acceptance filtering has to be supported by
Receive Function
comparing the incoming message identifier
Thatthemeans
with completethelist
received CANmessage
of all relevant identifieridentifier.
has If a
SW Acceptance Filters passed the hardware
CAN message has passed acceptance
the hardware filtering of the
acceptance
CAN Controller
filtering and the
but is rejected by theentire message
software is stored
acceptance filtering
in a receive register.
(in case of a Basic CAN receive object) a special callback
DLC Check Generic
function precopy means
will be called that a common function
(if configured).
CAN ISR In case of a Basic-CANisobject,
ApplCanGenericPrecopy() the
called for all message
identifiers. has
Generic PreCopy Function toInbe retrieved
case and processed
IL component as fastprecopy
is used the generic as possible.
is
mandatory and it will be: IlCanGenericPrecopy()
PreCopy Function
After the generic precopy (if configured) a precopy
function separate for each message according to the entry
Copy DATA in Rx Reg. in the
In the description data
next step the is is
data called.
copied to the global data
buffer.
Indication Flag
Then the indication actions defined for this message are
performed. This means the indication flag is set and/or the
Indication Function indication function is called. The Application has to reset
the indication flag before or after data processing.
End Rx

Data Link Layer: CAN driver – Tx
Start Tx
First the CAN Driver checks whether the transmit path is
SW Appl: CanTransmit(msg)
switched to online state. If not the function returns with an
no error code.
CAN online ?
CAN Driver checks the availability of a hardware transmit
object. If no object is available the transmit request is
Queue Message stored in the transmit queue.
Within this user specific function the Application may
PreTransmit Function
copy the data to be transmitted directly to the CAN
Controller hardware registers.
Copy DATA in Tx Reg.
This functionality is used to check the transmit path of the
CAN Driver.The prototypes for the functions
Tx Observe 'ApplCanTxObjStart', 'ApplCanTxObjConfirmed',
CAN BUS 'ApplCanInit' are generated.
Confirm Tx Observe A confirmation function for all messages is called:

ApplCanTxConfirmation()
Common Confirmation Function The message-specific confirmation function is called.
CAN ISR Afterwards the confirmation flag is set.
Confirmation Function/Flag
If the CAN Driver is configured to use a transmit queue,
Check Queue after the processing the confirmation actions the CAN
Driver checks whether the transmit queue is empty. If so
End Tx the transmit interrupt routine is finished.

Network Layer:
Network Management (NM)
Functional scope:
Controls the transition to Sleep Mode;
enter the BusSleep mode simultaneously;
Determine and monitor the Network Configuration;
network nodes that are currently active;
Provide status information of the NM node and the network itself;
The NM ensures that all active ECUs within a network will enter the
Bus Off HandlingBusSleep
and Recovery;
mode simultaneously.
This is required because an ECU will be woken up by any message on the
Interaction with CAN driver;
CAN bus. That is the reason why a transition of a single ECU into the
BusSleep mode only makes sense, if all the other ECUs are also ready for
Multiple ECUs BusSleep mode and will not send further messages.
Multiple ECUs NM decidesunits
are control whenwhich
the CAN channel must
are assembled be activated
several or deactivated.
times within the CAN network with the same
software. Example: Seat in the front on the left hand side and on the right hand side

Network Layer:
OSEK Network Management (OSEK-NM)
Direct node monitoring requires a network-wide synchronization of NM messages. For this purpose a logical ring is used. In a logical
ring the communication sequence is defined independently from the network structure. Therefore each node is assigned a logical
successor.
Address related communication has to take into account receiver and emitter. Each node has a unique identification which is known in
the network.
The network can enter different states like: NMOff, NMOn( NMAwake, NMBusSleep, NMActive ), NMShutDown
logical predecessor
message
D1 -> E1 E1 -> A A -> B2
Node A
Node D1 Node E1 Node B2
- two logical nodes -
CAN 0 CAN 1
A -> B1 B2 -> C2
logical successor
C1 -> D1 message
Node C1 Node B1 Node C2
C2 -> A
B1 -> C1
Transport Layer:
Transport Protocol (TP)
A TP is needed if the data length exceeds 8 bytes. In this case, the sender must divide
up the data into a number of CAN messages with the same identifier. Additional
information is necessary for the recipient to put the data back together again.
In a Single TPCAN
The classIDonly one connection
contains is addressing information (to each
the complete
possible, source
which isand
using the only available
target address combination a unique CAN ID is assigned)
Functional scope: TpChannel.
Message construction: unsegmented / segmented;

Addressing modes: normal / extended / normal fixed / mixt;
Unsegmented messages are transmitted
TP
byclasses: singlemessage.
a Single Frame / static multi
Single/ dynamic multi;
The Frame
CAN IDmessages
contains only the source
can have a length of 7
Error
address detection;
data bytes at a maximum (normal the
and the first data byte contains
target addressingrespectively
addressing) information.6 data bytes
While(extended addressing).
using Static TPThe
classesThere
extended
everyisCAN
no Flow-
ID contains the
e.g.: Control.
ISO 15765, SAE j1939, - single
Bosch frame;
McNet... The receiver is informed of the length of the whole
connection is fixed assigned
complete to addressing
a TpChannel information according
- first frame; message in the First Frame by the sender. The receiver
J1939
- flow control; answers
The idea of with a FlowTP
dynamic Control.
classesThe receiver
is to use thegives the Block
Size andAdditionally
- consecutive frame; circumstances the Separationto the extended CAN ID,inaccording
that not all connectionssender
Time to the are used this Flow
at the
- DLC. Control. J1939,
The the first data
sender transmits byte contains
the maximum a second
Block target
Size
same time. Therefore a connection is necessary allocating
address information. Since ISO15765-2: 2003 the
aConsecutive
TpChannel at Frames after the reception of the Flow
run-time.
Control. additional
The receiver addressing
does notmode
answer mixed addressing
it with a Flow on
Control, 11-bit CANhas
if all data IDsbeen
is defined. The address extension
transmitted.
is stored in the first byte followed by the TPCI
information.

Presentation / Session Layer:
Interaction Layer (IL)
Functional scope:
Interface between application layer and data link layer;
Access macros and functions;
Guarantees the consistency of any transmitted or received data and relieves the application of this
area of responsibility;
Multiple channel support;
Receive messages:
Signal oriented access to data: signal value, indication, firstvalue, data changed, timeout.
Transmit messages:
Signal oriented access to data to be sent;
Tx modes for signals and messages (e.g. cyclic, on request, if active);
Notification: confirmation, timeout.

Communication Control Layer (CCL)
The Communication Control Layer component is designed to simplify the use of the CAN
in ECU’s by covering all CAN communication components like CAN Driver, Interaction
Layer, Network Management, Transport Protocol etc..
Now the application has a simplified and smaller API to handle the CANbedded
components (e.g. initialization, task handling, transceiver handling, network management
handling etc.).
main integration interface

Generation Process
Tools: GENy; CANdrGen
All the above parameterization is
considered here: CCL, IL, NM, TP etc.
These file are the output of the execution of
the generation tool. They are reflecting the
project specific configuration.
(GENy) Generated SW Application

(GENy)
Configuration files
A Windows program were you configure Other project

the Software Components of CANbedded. related files
(GENy) SW Tool GENy generates configuration SW
files Project
for
each software component
Compiled and linked

CAN data base (GENy) Static files
project which will be
loaded into the ECU Own ECU
The .dbc file normally is designed by the vehicle manufacturer
and distributed to all suppliers
These thatavailable
files are develop together
an ECU.with
It the
contains information about all CANbedded components (e.g.
tool directly from the tool supplier (Vector). other ECU
network management type, messages and signals etc.). HW, SW and
These files will remain unchanged andEvery
are
Mechanical ECU.
supplier uses the SAME dbc file for one type of vehicle
independent from the project specific to Truck
guarantee a common basis for development.
configuration.
other ECU

HIGH LEVEL PROTOCOLS

j1939 standard
The particular characteristics of J1939 are:
29-bit identifier;
Peer-to-peer and broadcast communication;
Transport protocols for up to 1785 data bytes;
Network management;
Definition of parameter groups.
Interpretation of the CAN Identifier

PDU = Protocol Data Unit
Rez
Prio Data page PDU Format PDU Specific Source Address
1 bit
3 bits 1 bit 8 bits 8 bits 8 bits
0x0

j1939: PGN
Parameter groups
Parameter groups combine similar or associated signals. In the specification SAE J1939-71 the
parameter groups are defined with the signals they contain.
GlobalSample
PGNs for
of aparameter groups
parameter group that are sent to all (broadcast). Here all 16 bits of the PGN
definition:
are used; the
Name: value of the upper 8 bits (PDU format) must be greater than 239 (0xF0);
Engine temperature
Transmission rate: 1s
Data length: 8 bytes
Data
Specific page:for parameter groups
PGNs 0 that are sent to particular devices (peer-to-peer). With these
PDU format: 254
PGNs, only the higher-value 8 bits (PDU format) are valid and the value must be smaller than
PDUlower
240. The specific: 238specific) is always 0.
value byte (PDU
Default priority: 6
PG Number: 65262 (FEEE16 )
Description of data:
Each parameter
Byte: group is addressed
1 uniquely viacoolant
Engine a number (Parameter Group Number): PGN =
temperature
DP + PDUF + PDUS 2 Fuel temperature
3,4 Engine oil temperature
5,6 Turbo oil temperature
7 Engine intercooler temperature
8 Not defined

j1939: NM
Network management:
On a J1939 network, each device has a unique address. Each message that is sent by a device
contains this source address. There are 255 possible addresses:
0..253 – Valid addresses of an ECU

254 – Zero
255 – Global

j1939: BAM + DT
For broadcast transmission, the BAM (Broadcast Announce Message) protocol is used. Here, after a
BAM-PG the transmitter sends all data PGs at a minimum interval of 50ms.

j1939: BAM + DT
1st message: BAM (Broadcast Announce Message) -> data field
Control Byte Byte Size No. of Packets Rez PGN

0x20 2 Bytes 1 Byte 0xFF 3 Bytes
2nd message: DT (Data Transfer) -> data field
Sequence Number Data

1 Byte 7 Bytes
---
last message frame: DT (Data Transfer) -> data field
Sequence Number Data Reserved: 7-n Bytes

1 Byte n Bytes 0xFF

TESTING

Simulation: CANoe, CANalyzer
In the simulated CAN network For development, testing and analysis purposes a (CANoe)
and the physical CAN network simulation that runs on PC will simulate the behavior of the
the same CAN data base will rest of the network. This simulation must be as accurate as
be used (dbc). possible in order to avoid the appearance of differences
The CAN subsystem software between the simulated network and the physical network.
will also be the same in both
cases. In this simulation the tester can send and receive messages
from the data base and observe the behavior of his ECU.
Own ECU
CAPL (CAN Application
Programming
Simulated Language) programmed:
ECU -timers;
other ECU -reaction at messages;
-reaction at keyboard;
Truck (CANoe) PC -environment variables...
simulation
other ECU
Simulated
ECU
During development of own ECU the CANoe features:

rest of the CAN network nodes (the -simulated network nodes;
truck with the other ECUs) might not -normal and interactive generator blocks;
be available. -replay blocks;
-interface panels;
-trace windows, filters and logs;
-statistics, graphs ...
CANoe: Simulation setup window
Network Node:
- can be programmed in CAPL
language in order to interact in all
aspects with the CAN bus
- can interact with the CAN data
base
Generator Block:
- can output frames: data, remote, error
- can be triggered via key press, time
arrival of another message
- can interact with the CAN data base
Simulated CAN bus

- can be switched to real Associated CAN data
time mode base
Replay Block:
- can output messages
Interactive Generator Block: that are stored in a log
- can output frames: data, remote, error file ( e.g.: CANOE.asc
- can be triggered via key press, time file)
- can manipulate during simulation runtime
- can display and manipulate signals
inside message

CANoe: Measurement window
Statistics window:
- can graphically show the bus load with
data and error frames
Filters:
- all windows can have Bus statistics window:
applied filters: pass filter, - can show the bus load with data and
stop filter, channel filter error frames
- can show the CANoe error state:
active, passive, bus off
Trace window:
- shows the content of the bus: timing,
channels, message ID, name, direction,
length and data field
Data window:
- shows the values of various CAN
signals in raw value or/and physical
value
Graphics window:
- shows graphically the values of various
CAN signals in raw value or/and
physical value
Logging window:
- allows the user to record the content of
the CAN bus into a log file
ECU configuration:
CAN data base -source address;
CAN channel -received and transmitted messages
name and signals
Message configuration:
- ID, name, length, receiving and
transmitting ECU, signal layout,
transmission type and cycle time
- etc;
Signal configuration:
- length, bit ordering, unit, factor,
offset, min and max, send type,
timeout time, receiving ECUs,
- etc.
message list
signal list

CANoe: Hardware configuration
Channel information:
-hardware equipment for connecting to CAN bus;
-baudrate;
-CAN controller and transceiver used
Channel synchronization configuration:

-baudrate
-bit timing settings

Vector Hardware Configuration: Windows driver
Vector Hardware Driver can be found in Windows Control Panel
The Vector Hardware Configuration utility enables you to configure
installed Vector hardware. Besides the real hardware items in the
tree view, two virtual (simulated) CAN channels for testing purpose
(Vector applications) are available. For this purposes no hardware is
necessary.
Each hardware channel can be configured

to work together with different applications
like CANoe and CANalyzer depending on
the purchased license.

LITERATURE
ISO 11519 - Road vehicles — Low-speed serial data communication
ISO 11898 - Road vehicles — Controller area network (CAN);
ISO 11992 - Road vehicles — Interchange of digital information on electrical connections between towing and towed
vehicles;
ISO 14229 - Road vehicles — Unified diagnostic services (UDS) - Specification and requirements;
ISO 14230 - Road vehicles — Diagnostic systems - Keyword Protocol 2000;
ISO 15765 - Road vehicles — Diagnostics on Controller Area Networks (CAN);
ISO 16845 - Road vehicles — Controller area network (CAN) - Conformance test plan;
SAE j1939 - Recommended Practice for a Serial Control and Communications Vehicle Network;
http://www.semiconductors.bosch.de/en/20/can/index.asp
http://www.vector-informatik.com/vi_index_en,,9656.html

Can Training Presentation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Can Training Presentation

Uploaded by

Copyright:

Available Formats

CAN

CAN: Controller Area Network

Controller Area Network

2 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Requirements to Automation and Automotive Bus Systems:

3 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Engine Antilock Lighting Air condition

High speed CAN Instrument Low speed CAN

4 / Basica Liviu / 2009 © Continental AG For Internal Use Only

“The great thing about standards is that

there are so many to choose from.”

5 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Application Software All Application Layer

Seem Session Layer

ECU To Transport Layer

Data Data Link Layer

6 / Basica Liviu / 2009 © Continental AG For Internal Use Only

7 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Network Node 1: Network Node n:

double wire linear bus – split termination

8 / Basica Liviu / 2009 © Continental AG For Internal Use Only

CAN star bus

9 / Basica Liviu / 2009 © Continental AG For Internal Use Only

10 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Very high transmission rates are possible;

The communication in a car may be classified into three classes.

Class A - used for low-speed data communication: up to 10 kbit/s;

11 / Basica Liviu / 2009 © Continental AG For Internal Use Only

High-Speed definitions according to ISO 11898

Recessive Dominant Recessive

12 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Low-Speed definitions according to ISO 11519

Recessive Dominant Recessive

13 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Some of these transceiver offer special features like:

ISO 11898, ISO 11992, ISO 11519.

14 / Basica Liviu / 2009 © Continental AG For Internal Use Only

e.g. High Speed Double-Wire Transceiver PCA 82C250

- ISO/DIS 11898 compatible

µ C TxD CAN_H CAN_H

Vref reference voltage output Rs slope resistor input

15 / Basica Liviu / 2009 © Continental AG For Internal Use Only

To be able to participate in the CAN communication, the micro-controller has to be connected

16 / Basica Liviu / 2009 © Continental AG For Internal Use Only

17 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Rx Message Rx Message - Arbitration Mask

18 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Message Object n - Arbitration Mask

19 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Solution: CAN Bit Timing

20 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Transmit Transmit Transmit

Node A Node B Node N

21 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Idle Start dominant

22 / Basica Liviu / 2009 © Continental AG For Internal Use Only

Solution: Bit stuffing

23 / Basica Liviu / 2009 © Continental AG For Internal Use Only

24 / Basica Liviu / 2009 © Continental AG For Internal Use Only

SOF: Start of Frame. SOF = 0;

25 / Basica Liviu / 2009 © Continental AG For Internal Use Only

CRC: Cyclic Redundancy Check

26 / Basica Liviu / 2009 © Continental AG For Internal Use Only