CAN Protocol:

Application Of CAN Protocol

The main advantages of the CAN as a serial bus lie in the reduction of
expensive wiring, as well as an increased performance by enabling a
distributed processing system. CAN has been used in the following
applications as still now also it is increasing in different applications:

 Passenger Cars.
 Building Automation.
 Trucks and Buses.
 Industrial Machine Control.
 Lifts and Escalators.
 Trains.
 Maritime Electronic Systems.
 Aircraft & Aerospace Electronics.
 Medical Instruments etc.
What is CAN Protocol?
The CAN is a multi-master, broadcasting, multi-casting, message-based,
Event-driven, Flexibility, half-duplex, asynchronous type serial networking
protocol. It was designed by Robert BOSCH to use it in Automotive
vehicles for improving the vehicle networking feature with long-distance
communication.

Features of CAN protocol

There are different can feature those are making the CAN unique from
other protocol for which it is used in most of the places are:

 Information routing.
 System flexibility.
 Message routing.
 Multicast.
 Data consistency.
 Bit-rate.
 Priorities.
 Remote data requests.
 Multi-master.
 Arbitration.
 Data integrity.
 Error detection.
  Error Detection performance.
 Error signaling and recovery time.
 Fault confinement.
 Connection.
 Single-channel.
 Bus values.
 Acknowledgment.
 Sleep mode/wake-up.
Information Routing In CAN Protocol
In CAN network systems, a node does not make use of the system
configuration means of the node address.

System Flexibility In CAN Protocol

If you want to add a new node/ECU in the old available CAN network, then
you can add without the change in software or hardware of any node in the
network.

Message Routing In CAN Protocol

In CAN, every message is identified by the special unique identifier which
does not indicate the destination of the message but only describes the
meaning of the data available in the message. So that all the nodes are
connected in the network are able to decide by message filtering
technology using this message ID either to receive the data or not.

Multicast In CAN Protocol

The multicast means the nodes/ECU’s are connected in the network might
be any number of nodes can be simultaneously able to receive the same
transmitted message.

Data Consistency In CAN Protocol

The data consistency means in a CAN network it is guaranteed that a
message is accepted simultaneously either by all nodes or by no nodes. So
that the data consistency is a property of a system achieved by the
concepts of multicast and the error handling concepts.

Bit-Rate In CAN Protocol

The speed of the CAN may be different for different networks available in a
system. However, in a given network the bit rate is uniform and fixed for all
the nodes.
Priorities In CAN Protocol
The message identifier defines a static message priority during the bus
access in a CAN network. Mostly each message is having a unique
Identifier integer value and it is represented in a hexadecimal number
system for increasing the reading and programming flexibility for a
developer. The OEM should select the message or his ID as to how much
priority it is. The highest is the priority, the lowest is the value of that
message.

Remote Data Request In CAN Protocol

The CAN have to the feature of a remote frame request if the remote node
means in a CAN network or channel if a node needs data from another
node available in this network can request by the sending remote frame to
get the data. The requested remote frame and to the received data frame
will be having the same identifier.

Multi-Master In CAN Protocol

When the bus is free or you can say it is in an idle state, then any node can
stat to transmit the message. The node having the highest priority will send
the message.

Arbitration In CAN Protocol

Whenever the bus is free, any node may start to transmit the message. If
two or more nodes start transmitting messages at the same time, the bus
access conflict is resolved by the bit-wise arbitration using the Identifier.
The mechanism of the arbitration guarantees that neither information nor
time is lost. If a data frame and a Remote frame with the same Identifier are
initiated at the same time, the Data frame prevails over to the Remote
frame.

During the arbitration, every transmitter compares the level of the bit
transmitted with the level that is monitored on the bus. If these levels are
equal the node may continue to the send. When a recessive level is sent,
but a dominant level is monitored (discussed in the introduction part), the
node has lost arbitration and must withdraw without sending any further
bits.

Data Integrity In CAN Protocol

In order to achieve very high integrity of the data transfer, powerful
measures of error detection, signaling, and self-checking are implemented
in every CAN node.
Error Detection In CAN Protocol
To detect errors in a CAN network, the following measures have been
taken:

 Monitoring (each transmitter compares the bit levels detected

on the bus with the bit levels being transmitted).
 Cyclic Redundancy Check (CRC).
 Bit-Stuffing.
 Message Frame Check.
Error Detection Performance:
In the CAN network system the error detection mechanism having the
following properties are:

Error Detection Or Monitoring In CAN Protocol

1. All global errors are detected.

2. All local errors at transmitters are detected.
 CRC:
1. Up to 5 randomly transmitted errors within a sequence can be
detected.
2. Burst errors of length less than 15 in a message can be
detected.
3. Errors of any odd number of bits in a message can be
detected.
The total residual error probability of the undetected corrupted messages is
less than 4.7 x 1011.
Error Signalling And Recovery Time In CAN
Protocol
The corrupted messages are flagged by any node detecting an error. Such
messages are aborted and are retransmitted automatically. The recovery
time from detecting an error until the start of the next message is at most
29 bit times, provided there is no further error.

Fault Confinement In CAN Protocol

The CAN nodes are able to distinguish between short disturbances and
permanent failures. Defective nodes are the switched off is nothing but the
Bus-Off mechanism in the CAN network.

Connection In CAN Protocol

The CAN serial communication link is a bus to which a number of the
nodes may be connected or disconnected. This number has no theoretical
limit. Practically, the total number of the nodes will be limited by delay time
and/or electrical loads on the bus LIN(16) Single channel.

The CAN bus consists of a single bidirectional channel that carries the data
bits. From this data, the re-synchronization information can be derived. The
way in which this channel is implemented is not fixed in this specification,
e.g. single wire (plus ground), two differential wires, optical fibers, etc.

Bus Values In CAN Protocol

The CAN bus can have one of the two complementary values as dominant
or recessive. During the simultaneous transmission of the dominant and
recessive bits, the resulting bus value will be dominant. For example, in the
case of a wired-AND implementation to the bus, the dominant level would
be represented by a logical ‘0’ and the recessive level by a logical ‘1’.

Acknowledgment In CAN Protocol

All receivers in the CAN network, check the consistency of the message
being received and will acknowledge a consistent message and flag an
inconsistent message.

Sleep/Wake-up Mode In CAN Protocol

To reduce the system’s power consumption, a CAN device may be set into
sleep mode, in which there is no internal activity and the bus drivers are
disconnected. The sleep mode is finished with the wake-up by any bus
activity or by internal conditions of the system.

On wake-up, the internal activity is restarted, although the transfer layer will
wait for the system’s oscillator to stabilize and then wait until it has
synchronized itself to the bus activity (by checking for eleven consecutive
recessive bits) before the bus drivers are set to the ‘on-bus state again. In
order to wake up other sleeping nodes on the network, a special wake-up
message with the dedicated, lowest possible Identifier may be used.

Why CAN Protocol?

Whenever there was no CAN protocol available in the industry at that time
also vehicles were running with ECU. These ECUs are also were able to
communicate with each other using some other older protocols such as
PWM, VPW, J1850 serial protocol, etc. But at that time the technology was
not that much improved and so many demerits were also like low speed,
more noise, more accidents, etc were happening.
As gradually technology improved, user’s requirements also increased as
autonomous vehicles so that so many OEM and vehicle ECU suppliers
started their investigation to satisfy the customer requirement. Then Robot
BOSCH did the proper investigation with their best R&D team and
designed the first CAN controller chip with CAN transceiver to
communicate among the ECUs.

This method really works fine to get the 3 Mbps speed at 40 meters of
length with all other advantage features which I have explained above.
before this, there was no such protocol as CAN which can give these
features which causes it boomed the industry as nowadays most of the
industry trying to use the CAN protocol.

What are the types of CAN Protocol?

The CAN Protocol has been used in different fields as it is having so many
different features explained above mostly you will not get all the above
features in any kind of protocol. If do you think about any protocol like
Ethernet or anything but it is not that much inexpensive as compared to
CAN protocol. so, for this reason, it is categorized into a different type,
such:

 As per ISO standard, CAN is categorized as:

1. ISO-11898 Standard: Road vehicles – CAN for high-speed
communication
2. ISO-11519 Standard: Road vehicles – Low-speed serial data
communication Low Speed CAN / VAN
3. ISO-11992 Standard: Road vehicles – Electrical connections
between towing and towed vehicles.
4. ISO-11783 Standard: ISO-BUS is for “Tractors and machinery
for agriculture and forestry—Serial control and communications
data network”.
5. EIA RS-485 Standard: Electrical Characteristics of Generators
and Receivers for Use in Balanced Digital Multipoint Systems
(formerly used for CAN Physical Layer).
 As per Number of wire used for Physical Layer, CAN is
categorized as:
1. SW CAN: Single Wire CAN used for low speed and less risk
data transmission CAN network. Single wire CAN interface has
a lower data rate of up to 33.3 Kbits/s and also named SAE-
J2411. The devices that do not require high performance like
seat and mirror adjuster use a Single wire CAN interface.
 2. DW CAN: Double Wire CAN used for high speed and fault-
tolerant CAN network.
 As per speed of Physical Layer, CAN is categorized as:
1. Low-Speed CAN Physical Layer:

The Low Speed CAN basically be used for 40 kbps to 125 kbps CAN bus.
This is also called a fault-tolerant CAN bus. This kind of CAN bus also can
run without a termination resistor.

 Dominant Voltage Level: CAN-L is 1.4 v and CAN-H is 3.6 v

 Recessive Voltage Level: CAN-L is 0 v and CAN-H is 5 v.
2. High-Speed CAN Physical Layer:

The High Speed CAN basically be used for 40 Kbps to 1 Mbps data rate.
This kind of bus must be terminated with a termination resistor from 108
Ohm to 132 Ohm as per bus system-specific.
  Dominant Voltage Level: CAN-L is 1.5 v and CAN-H is 3.5 v.
 Recessive Voltage Level: CAN-L is 2.5 v and CAN-H is 2.5 v.
 As per CAN generation Improvement, CAN is categorized as:
1. Classical CAN: Normal CAN protocol having speed up to 1
Mbps with a maximum of 8-bytes of Payload in a single data
packet.
2. Advanced CAN: CAN-FD(Flexible Data Rate) having speed
up to 8 Mbps with a maximum of 64-bytes of payload in a
single data packet.
 As per Data Rate, CAN is categorized as:
1. Low-Speed CAN: Speed between 1 kbps – 125 kbps.
2. Medium-Speed CAN: Speed between 125 kbps – 500 kbps.
3. High-Speed CAN: Speed between 500 kbps – 1 Mbps.
4. Ultra High-Speed CAN (CAN-FD): Speed between 1 Mbps – 8
Mbps.
 As per Length, CAN is categorized as:
1. Class-A: 50 Kbps speed at 1 Kilo Meter (1000 meter) of CAN
bus length.
2. Class-B: 125 Kbps speed at 500 Meters of CAN bus length.
3. Class-C: 1 Mbps speed at 40 Meters of CAN bus length.
 As per Identifier, CAN is categorized as:
1. Basic/Standard CAN: Message Identifier is 11-bit (211 = 2048)
which helps to create limited unique messages or message
identifiers for the lowest number of ECU with lowest data
communications in simple CAN networks.
2. Extended CAN: Message Identifier is 29-bit (229 =
536,870,912) which helps to create millions of unique
messages for data communications in complex CAN networks.
ISO Layer Used In CAN protocol
As we all know that each computer system follows the 7-layers
of the OSI (Open System for Interconnection) layer for communication
between two or more computers. In the automotive field, each ECU’s are
nothing but a computer system that used the same OSI layer as shows in
the below image:
General OSI Layer Design
Among all of the OSI layers, CAN protocol uses only two-layer since it is a
part of an ECU for data or information communication. So for
communication purposes, it is sufficient for most of the protocol. These
layers are:
1. Physical Layer: It defines the CAN transceiver characteristics.
2. Data-link Layer: It defines the CAN controller characteristics.

CAN Protocol OSI Layer Design

The Physical Layer is divided into 3-types:

1. PLS: Physical Signalling Characteristics defines the bit

encoding/decoding, bit timing, synchronization.
 2. PMA: Physical Medium Attachment defines the CAN
transceiver characteristics.
3. MDH: Medium Dependent Hardware defines the wiring,
connectors, BUS, etc.
The data-link layer is divided into two types:

1. LLC: Logical Link Control defines the acceptance filtering,

overload notification, and error recovery mechanism.
2. MAC: Medium Access Control defines the data
encryption/decryption, frame setup, bit stuffing/de-stuffing,
collision detection, arbitration, Acknowledgement, error
management, etc.

C
AN Protocol OSI Layer Detailed Design

What are the Types of CAN Protocol

Frames
I hope you would have cleared about all the types of CAN protocol
available but commonly one type which I missed and going to explain here
because it is common for each type of CAN which I have explained above.

As per CAN frames by which all the CAN standards are communicating
among the ECU in a CAN network. There are 5 types of CAN frames such
as:

1. Data Frame: Used to send the data in a CAN network.

2. Remote Frame: Used to request the data in a CAN network.
 3. Error frame: Used to send the error information in a CAN
network.
4. Overload Frame: Used to notify the incomplete data reception.
5. Inter-Frame Space (IFS): Used to delay the next packet data
transmission.
I hope we will not waste the time, Lets go discuss each frame in detail
below:

Data Frame Format In CAN Protocol

The data frame in the CAN protocol is used to send/broadcast the data in
the CAN network so that others can receive whoever all are available in the
CAN network according to their requirement if they need. The data frame
having consisted of 7 fields that are taking care of secure data transfer from
transmitter to receiver successfully.

Basically, there are two types of data frames according to the frame as the
standard frame (11-bit ID) and the extended frame (29-bit ID). First, let’s go
discuss the standard CAN frame after then we will discuss the Extended
CAN frame.

Standard or 11-bit CAN Protocol Frame Format

The standard CAN was first invented by BOSCH where the maximum of
(211 = 2048 unique messages can be generated and used in a CAN network
for data communication. The total frame is divided into 7 typical fields which
help to identify, detect, correct, validate a CAN message in the CAN
network. Please look at the below figure as shown:

11-bit CAN Standard Frame

CAN Protocol Frame Field Explanation

A Data frame is composed of seven different bit fields: Start of the frame,
Arbitration field, Control field, Data field, CRC field, ACK-field, End of the
frame. The Data field can be of length zero. Each field is explained below
as:
SOF Field In CAN Protocol Data Frame
The Start of frame marks to the beginning of Data frames and remote
frames. It is consists of a single dominant bit. A node is only allowed to
start transmission when the bus is idle. All the nodes have to synchronize
to the leading edge caused by the Start of the frame of the node starting
transmission first.

Arbitration Field In CAN Protocol Data Frame

The arbitration field having consisted of different bit fields for different
purposes. In 11-bit can, The identifier is 11-bit and the RTR is 1-bit
dominant.

11-Bit Identifier: The Identifier field is the heart of the CAN data frame.
There are two main purposes of this identifier field is:
1. To determine which node needs to gain the bus access
whenever more than one node trying to send the messages on
the same can bus.
2. To identify the type of message it is. That means in can
protocol it is message-based so there is nothing like an
address for any ECU. It will broadcast whoever interested they
will receive it. Now you tell how it will get to know which data he
needs to receive or not? Yes for this in CAN protocol, each
identifier is unique and it will be assigned to a message. These
data including some more data will create a database called a
CAN database.
RTR: It is extended for the Remote Transmission Request. The main
objective of this bit is to identify either a data frame or a remote frame. If
the RTR bit is 1, it is data a remote frame else it is a data frame.
Control Field In CAN Protocol Data Frame
The Control field consists of six bits. It includes the Data length code and
two bits reserved for the future of the expansion. The reserved bits must be
sent as dominant. Receivers accept dominant and recessive bits in all the
combinations.

1. DLC: This Data length code is 4 bits wide and is transmitted

within the Control field. The DLC bits can code data lengths
from 0 to 8 bytes. If the DLC is more than 8 then it is
considered a don’t care condition and it will get rejected by the
Transmitter ECU.
2. IDE: If the Identifier Extension bit is Dominant then it is a
standard (11-bit ID) CAN and if the IDE bit is recessive then it
is an Extended (29 bit ID) CAN.
 3. R0: This is a reserved bit for future use. It might be used in the
future CAN standard amendment. It is always recessive in the
CAN data field.
4. Data Field: The Data field consists of data to be transferred
within the Data frame. It can contain from 0 to 8 bytes, each of
which contains 8 bits which are the transferred MSB first.
CRC Field In CAN Protocol Data Frame
The CRC field contains the 15-bit CRC Sequence followed by 1-bit CRC
Delimiter. The CRC field is nothing but an algorithm or a polynomial
function you can say. This function will be implemented in all the ECUs
available in the CAN network. If you will give the same input, then the
output will be the same for all. So when a transmitter will send a data
frame, it will give the SOF, Arbitration, Control, and data field data as input
and it will generate a 15-bit CRC data that will get added in the CRC field of
the CAN data field.

Then the Transmitter ECU will generate the total frame and it will send it
over the CAN bus. Then the receiver ECU will receive it. The receiver ECU
also has the same CRC algorithm. It will also give the received SOF,
Arbitration, Control, and data field as input to that algorithm. Then it will
generate a 15-bit CRC field and the controller will compare both the
received CRC and generated CRC. If both the CRC is the same it will
receive the data or else it will generate the CRC error.

CRC Delimiter: The CRC Sequence is followed by the CRC Delimiter

which consists of the single recessive bit.
ACK Field In CAN Protocol Data Frame
The ACK field is two bits long and contains the ACK Slot and of the ACK
Delimiter. In the ACK field, the transmitting node sends two recessive bits.
A RECEIVER that has received a valid message correctly reports this to
the TRANSMITTER by sending a dominant bit during the ACK Slot (i.e. it
sends ACK).

ACK Delimiter: The ACK Delimiter is the second bit of the ACK field and
has to be a recessive bit. As a consequence, the ACK Slot is surrounded
by the two recessive bits (CRC Delimiter, ACK Delimiter).
End Of Frame In CAN Protocol Data Frame
Each Data of the frame and Remote frame is delimited by a flag sequence
consisting of seven recessive bits. The 7 recessive bit is fixed to confirm
the idle state of CAN BUS.
Extended or 29-bit CAN Protocol Frame
Format
There are two types of CAN protocol defined in ISO 11898-1 standard.
Both standards are designed by Robot BOSCH. You would have thought
why there are two types of CAN? Yes obviously, let me explain this.
Basically, the main difference is the CAN data frame. In this data frame, the
Arbitration and control field is having some change, except this, there is no
more change in between them.

The main purpose or the advantage of the 29-bit CAN over the 11-bit CAN
is that a more number of unique CAN messages can be created. This is
required if you have more functionality and data you are going to use in
your vehicle, then it is not possible in an 11-bit CAN. So the 29-bit CAN be
used in this case. The below image is showing the 29-bit CAN frame
format.

29-bit CAN Frame Format

The above figure, it is showing each and every bit field with clear visibility.
As I have already told you except for the arbitration and Control field,
others are the same, we will only discuss these fields.

SRR: The SRR is extending for Substitute Remote Request. This bit is
always recessive in the extended frame format. If we are using the CAN-
2.0B CAN in our CAN system which is supporting both the 11 bit ID and 29
bit ID, but the problem is why we are using this bit. Then we have to think if
suppose simultaneously both 11-bit ID as a data frame and the 29-bit ID as
the remote frame is trying to send the message. At the same time, the
arbitration technology using to gain the bus access.
Then in 11-bit ID, the RTR bit is in the 12th number bit whereas in 29-bit ID
it will be in the 30th number bit where the arbitration will gain by the remote
frame which is then violating the CAN rule. So to not happen this they have
added an SRR bit which is always recessive and used to give the bus
access to the 11-bit Identifier instead of violating the BUS access rule.

R1 and R0: The Extended frame is having two reserve bit in the control
field like R0 bit in the 11-bit CAN.
CAN Protocol Remote Frame Format
In CAN, there are two types of communication. One is the sender and
receiver and the second one is client-server communication. The sender-
receiver means when the data will get updated the Transmitter ECU will
send it on the CAN bus, and whoever needs it will receive it. In the case of
a Client-server, when an ECU needs any data like the vehicle speed in
Instrument cluster ECU, it will send a remote frame to the CAN bus.

Then the ECU suppose VMCU ECU who is having this data will receive by
checking the RTR bit of that remote frame. After then the VMCU ECU will
read the vehicle speed from the sensor and put it in the data field of the
same frame and makes the RTR bit 0. Then the VMCU will send it again
back and the Instrument ECU will receive it.

A node acting as a RECEIVER for certain data can stimulate the relevant
source node to transmit the data by sending a Remote the Frame. A
Remote frame is composed of six different bit fields: Start of the frame,
Arbitration field, Control field, CRC field, ACK field, End of the frame.

The RTR bit of a Remote the frame is always recessive (cf. Data frames
where the RTR bit is dominant). There is no Data field in a Remote frame,
irrespective of the value of the Data length code which is that of the
corresponding Data frame and may be assigned any value within the
admissible range from 0-8.

CAN Remote Frame Format

The polarity of the RTR bit indicates whether a transmitted frame is a Data
frame (RTR bit dominant) or a Remote frame (RTR bit recessive).
CAN Protocol Error Frame Format
The error frame is used to notify an error that has occurred during the
transmission. The error frame consists of an error flag and an error
delimiter. The Error frames are transmitted by the hardware part of the
CAN controller.

The Error Frame in CAN protocol having consists of an Error Flag, which is
having 6 bits of the same value, and an Error Delimiter, which is 8
recessive bits. The Error Delimiter provides some space so that the other
nodes on the bus can send their Error Flags when they detect the first Error
Flag.

CAN Error Frame Format

The CAN protocol error frame is having two fields:

1. Error Flag
2. Delimeter Flag
Error Flag: The error flag bits are the minimum of 6 bits which generates
whenever any error will occur in the CAN network at the time of data
transmission. There are two types of error flags: the active-error flag and
the passive-error flag.
 Active-Error flag: 6-12 consecutive dominant bits.
 Passive-Error flag: 6-12 consecutive recessive bits.
Active Error Flag: The Active Error flag consists of six consecutive
dominant bits.
Passive Error Flag: The passive Error flag consists of six consecutive
recessive bits unless it is overwritten by the dominant bits from other
nodes.
Depending on the timing at which an error is detected by each unit
connected to the bus, error flags may overlap one on top of the other, up to
12 bits in total length. This is called an overlapping of the error flag.
Error Delimiter: The error delimiter consists of 8 recessive bits.

CAN Protocol Overload Frame Format

The overload frame is used by the receiver unit to notify that it has not been
prepared to receive frames yet. It consists of the overload flag and an
overload delimiter. There are three kinds of the Overload condition which
lead to the transmission of an Overload flag:

 Where the internal conditions of the receiver are such that the
receiver requires a delay of the next Data frame or Remote the
frame.
 On detection of a dominant bit during the INTERMISSION.
 If the CAN node samples a dominant bit at the eighth bit (i.e.
the last bit) of an Error Delimiter or Overload Delimiter, it will
start transmitting an Overload frame (not an Error frame). The
Error Counters will not be incremented.

CAN Overload Frame

Format
An Overload frame resulting from the Overload condition 1 is only allowed
to start at the first-bit time of an expected INTERMISSION, whereas
Overload frames resulting from Overload conditions 2 and 3 starts one bit
after detecting the dominant bit.

Overload Flag In Overload Frame Of CAN Protocol

It consists of 6 dominant bits. The overload of the flag is structured the
same way as the active-error flag of the error frame. The Overload flag’s
form destroys of the fixed form of the INTERMISSION field. As a
consequence, all other nodes also detect an Overload condition and each
starts to transmit an Overload the flag. In the event that there is a dominant
bit detected during the third bit of the INTERMISSION, then it will interpret
this bit as the Start of a frame.
Overload Delimiter In Overload Frame Of CAN Protocol
It consists of 8 recessive bits. The overload delimiter is structured in the
same way as the error delimiter of the error frame. The Overload Delimiter
is the same form as the Error Delimiter. After the transmission of an
Overload flag, the node monitors the bus until it detects a transition from a
dominant to a recessive bit.

At this point of time, every bus node has finished sending its Overload flag,
and all the nodes start transmission of the seven more recessive bits in
coincidence.

Inter-Frame Space In CAN Protocol

The IFS frame is used to separate the data frame and the remote frames.
The data and the remote frames, whichever the frame (data, remote, error,
or overload frame) may have been transmitted prior to them, are separated
from the preceding frame by an inserted inter-frame space. However, no
inter-frame spaces are inserted preceding overload and error the frames.

CAN Protocol Working Principle

The CAN bus is an inexpensive, robust vehicle bus standard designed for
multiple CAN device communications with one another without a host
computer connection. The CAN is also called a multi-master serial bus and
the CAN devices on the bus are referred to as nodes.

Two or more nodes are required on the CAN network to communicate. All
nodes are connected to each other via a two-wire bus (CAN H and CAN L)
and the wires are 120 ohms nominal twisted pairs. Termination resistor
commonly 120 ohms is a must in each node in order to suppress the
reflections as well as return the bus to its recessive or idle state.
CAN Working principle
Each node in the CAN bus requires the below modules to work together in
a CAN network.

1. Microcontroller (Host): It decides what the received

messages mean and what messages it wants to transmit.
2. CAN controller: They are often an integral part of the
microcontroller that handles framing, CRC, etc. like the Data
Frame, Remote Frame, Error Frame, Overload Frame, and
Inter-Frame Space generation.
3. CAN Transceiver: It converts the data from the CAN controller
to the CAN bus levels and also converts the data from CAN
bus levels to a suitable level that the CAN controller uses.
The transceiver drives or detects the dominant and recessive bits by the
voltage difference between the CAN_H and CAN_L lines. The nominal
dominant differential voltage is between 1.5V to 3V and the recessive
differential voltage is always 0V.

The CAN transceiver actively drives to the logical 0 (dominant bits) voltage
level and the logical 1 (recessive bits) are passively returned to 0V by the
termination resistor. The idle state will always be in the recessive level
(logical 1).

Individually, CAN_H will always be driven towards supply voltage (VCC)

and the CAN_L towards 0V when transmitting to the dominant (0). But in a
practical case, supply voltage (VCC) or 0V cannot be reached due to the
transceiver’s internal diode drop. CAN H/L will not be driven when
transmitting a recessive (1) where the voltage will be maintained at VCC/2.

The following figure depicts the block diagram and real-time capture of the
CAN signals.

CAN have different physical layers which classify certain aspects of the
CAN network such as signaling scheme, cable impedance, maximum data
rates, electrical levels, etc. The following are the most commonly used
physical layers.

How CAN Communication Works?

As mentioned early, CAN is a Peer-to-Peer network in which there is no
master that controls the transmission between nodes. When any CAN node
is ready to transmit data, it should undergo a process called message
arbitration. In this process, the CAN node will check to see if the bus is idle
and starts the transmission once it is idle.

This will also trigger other CAN nodes in the bus and hence results in two
or more nodes starting a message at the same time which results in a
conflict. The conflict is resolved in the following methods,

The transmitting node monitors the bus while they are sending data If any
node detects a dominant level (logical 0) while sending a recessive level
itself, it will fail in the arbitration process, and quits immediately will start
acting as a receiver. This arbitration process is performed while sending off
the arbitration ID field of the CAN frame and in the end, only one
transmitter is left on the bus i.e. the node with the highest priority (lowest
arbitration ID) will pass the arbitration.

Then the node which has won the arbitration will continue message
transmission as if nothing had happened. Other receiving nodes can decide
if a message is relevant or if it should be filtered using a combination of
hardware and software filters. This process is continuous and other nodes
will transmit their messages when the bus has become available.

Operation Of The CAN Network

 Each node is then assigned a unique identification number
called the Physical Address of the ECU.
  All the nodes are interesting to transmit compete for the
channel by transmitting a binary signal based on their
identification value.
 A node will drop out of the competition if it detects a dominant
state while transmitting a passive state.
 Thus the node which is having the lowest identification value
will win the bus network and start the transmission of the
message.
 If any error detects either the transmitter or receiver, it stops
the sending of Data Frame and start sending the Error Frame.
The error is having an error states to handle the error in CAN
Protocol called Error Handling in CAN Protocol. There are
5 types of error in CAN protocol that can occur.
CAN-TP Protocol
The ISO 15765-2 CAN-TP Protocol is an international standard protocol used for
sending more than 8-bytes of data over the CAN consecutive frames. It was not
possible in normal CAN data frames limited to the only maximum of 8 – bytes of
the data. The ISO transport protocol is on the fourth layer
(transport layer) of the OSI layer model. The ISO TP defined a transmission
method that allows to the send up to 4095 bytes via the CAN-bus. For this, the
messages to be sent are segmented and individual CAN frames divided. The most
common application for ISO-TP is the transfer of diagnostic messages with OBD-
II equipped vehicles using KWP-2000 and UDS but is also used broadly in other
application-specific CAN implementations. The CAN-TP is implemented over the
CAN stack so to identify it there are two types of addressing which are:
1. Basic Addressing.
2. Extended Addressing.
BASIC ADDRESSING: CAN-TP Protocol basic addressing mode is called a
normal addressing mode were to identify the CAN message or CAN-TP, we are
using the CAN Identifier. So for this, there will be some identifier will be for
CAN-TP, where if any message will receive then the server will understand that
this TP message. The advantages of this type of addressing are that full 8 bytes of
the data packet can be sent as data.
EXTENDED ADDRESSING: This addressing mode is the CAN-TP addressing
mode where the 1st byte of the CAN data field will be used for the additional
elements of the address whereby it reducing the data payload by one byte. The
primary task of the transport protocol is to transfer messages which cannot be
transmitted as a single Protocol Data Unit (PDU) due to their length. Messages
which contain more data that can be transmitted within a single PDU are
segmented by means of the transport protocol and divided into multiple, separate
PDUs. This procedure can also be implemented on the data link layer. The
segmentation of the message must then be carried out in PDUs of the
corresponding data link protocol. So to send the data like CAN, the CAN-TP
Protocol has been designed. Let us discuss how it can send multiple frames. So to
make it possible, the CAN-TP also having 4-types frames like CAN protocol is:
1. Single Frame.
2. First Frame.
3. Consecutive Frame.
4. Flow Control Frame.
1. SINGLE FRAME (SF): If the data payload is 7-bytes or less than that,
then the single frame will be used for the data transfer in CAN-TP
Protocol. Where the first byte of the data field is used for
addressing. Again this byte is divided into two divisions, where the
MSB 4-bit is used for addressing of TP frame type called PCI
(protocol information). The LSB 4-bit is used for the DLC (Data
Length Code).

CAN-TP: Single Frame Format

Basically, if you are going to spend less than then you can use the Single Frame
else to send the more than that you have to use the other 3 frames.

FIRST FRAME (FF): The first frame is an initial message of the multi-frame
message packet in CAN-TP Protocol. It is used when more than 6 or 7 bytes of
data segmented must be communicated. The first frame contains the length of the
full packet, along with the initial data. In FF, the first 2-bytes are used for the PCI,
where the MSB 4-bit of the 1st byte is used for the type of frame and the LSB 4-bit
and next 1-byte (total 8+4 = 12 bit)of the CAN data field is used for DLC (2^12 =
4095 data bytes). so in FF, only 6-bytes of the data can be transferred for the first
time. This frame is responsible for sending the information to the receiver about
the information as to how many total data bytes he is going to send.

CAN-TP: First Frame Format

CONSECUTIVE FRAME (CF): The primary task of the transport protocol or
you can also CAN-TP Protocol is to transfer messages which cannot be transmitted
as a single Protocol Data Unit (PDU) due to their length. Messages which contain
more data that can be transmitted within a single PDU are segmented by means of
the transport protocol and divided into multiple, separate PDUs. This procedure
can also be implemented on the data link layer. The segmentation of the message
must then be carried out in PDUs of the corresponding data link protocol.

CAN-TP: Consecutive Frame Format

In CF, the 1st byte is used for PCI byte, whereas the MSB 4-bit is defined for the
type of frame and the LSB 4-bit is defined for the Sequence number. The sequence
number always starts at 1 and increments with each frame sent (like as 1, 2,…, 15,
0, 1,…), with which lost or discarded frames can be detected. Each consecutive
frame starts at 0, initially for the first set of the data in the first frame will be
considered as 0th data. So the first set of CF(Consecutive frames) starts from “1”.
There afterwards when it reaches “15”, it will be started from “0” by resetting the
buffer register.

FLOW CONTROL FRAME (FC): The flow control mechanism of the CAN-TP
Protocol is used to configure the sender to match the properties of the receiver
(timing, available receive buffer, readiness to receive). The FCF is always sent by
the receiver so that to inform about the receiver capability of how the transmitter is
going to send the data.

CAN-TP: Flow Control Frame Format

In FC, the MSB 4-bit of the 1st byte is defined as the type of frame and the LSB 4-
bit defined the Flow Control Flag.

Flow Control Flag

The Flow Control (FC) frame is sent by the receiving node to the transmitting node
for flow control of the transmission. The flow control frame contains 3 bytes which
together form a PCI in CAN-TP Protocol. The first byte begins in the upper four
bits with a value of 3, indicates that there is flow control. In the four least
significant bits of the first byte shows a Flow Status (FS). Thus the transmitter to
the receiver can signal whether a segmented transmission Clear To Send (CTS),
Wait or Overflow. The second byte BS stands for Block Size and shows how many
consecutive frames need to be sent in one block. The last byte STmin shows the
minimum separation time between consecutive frames to be noticed.

An ISO-TP frame is always 8 bytes long and unneeded bytes filled with the
padding byte as 0xAA or 0x55.

Structure of TP message transfer

There are two types of data transfer methods of CAN-TP Protocol: single-frame
data transmission and multiple data transmission. The single-frame data
transmission (Unacknowledged Unsegmented Data Transfer) and the Multi-frame
Data transmission (Unacknowledged Segmented Data Transfer). In a CAN frame,
there is a maximum of 8 data bytes of user data. The data length of the ISO TP
message can reach a maximum of 4095 bytes. If an ISO TP message length
exceeds the data length of 8 data bytes, the UDS message must be segmented.

Single
Frame Data Transmission
 CAN TP Multi Frame

CAN-TP ERROR HANDLING

In CAN-TP Protocol, Both the transmitter and receiver monitors the data
transmission with a timer. The receiver monitors the time required by the
transmitter for sending Consecutive Frames. If this takes a long time, the
transmission is aborted and data already transmitted are discarded. Similarly, the
transmitter monitors the time for the receiver to send the flow control frame. Again
the transmission is aborted and data already transmitted are discarded if a timeout
is detected. The maximum waiting time for a frame is one second.

Basically, In addition to timing errors, errors in the message structure must be

recognized. If an erroneous PDU is detected the frame is ignored or if a
transmission is in progress, canceled it. Possible errors in the message structure are
incorrect sequence numbers in consecutive frames, invalid message length, and
invalid flow status in the flow control frames or an invalid PDU
type. Unexpectedly arriving frames are always ignored, with the exception of a
single frame and physically addressed the first frame. Functionally addressed first
frame, consecutive frame, and flow control are always ignored.

How to send 100 bytes of data using

CAN-TP Protocol?
Ans:
15 thoughts on “CAN-TP Protocol”
1. SUDHARSHAN REDDY
25/01/2021 AT 4:02 PM
the Data Example for 128 bytes of data Transfer Has been given
Below.

Flow.
Tx Request 02 10 03 00 00 00 00 00
Rx Response 02 50 03 00 00 00 00 00

Tx Request 02 27 01 00 00 00 00 00
Rx Response 06 67 01 00 00 16 7E 00
Rx Request 06 27 02 0D 99 BD C1 00
Rx Response 06 67 02 0D 99 BD C1 00

Tx Request 10 83 2E 01 08 12 12 12
Rx Response 30 00 0A 00 00 00 00 00
Tx Request 21 03 04 05 06 07 08 09
Tx Request 22 0A 0B 0C 0D 0E 0F 10
Tx Request 23 11 12 13 14 15 16 17
Tx Request 24 18 19 1A 1B 1C 1D 1E
Tx Request 02 10 03 00 00 00 00 00
Tx Request 25 1F 20 21 22 23 24 25
Tx Request 26 26 27 28 29 2A 2B 2C
Tx Request 27 2D 2E 2F 30 31 32 33
Tx Request 28 34 35 36 37 38 39 3A
Tx Request 29 3B 3C 3D 3E 3F 40 41
Tx Request 2A 42 43 44 45 46 47 48
Tx Request 2B 49 4A 4B 4C 4D 4E 4F
Tx Request 2C 50 51 52 53 54 55 56
Tx Request 2D 57 58 59 5A 5B 5C 5D
Tx Request 2E 5E 5F 60 61 62 63 64
Tx Request 2F 65 66 67 68 69 6A 6B
Tx Request 20 6C 6D 6E 6F 70 71 72
Tx Request 21 73 74 75 76 77 78 79
 Tx Request 22 7A 7B 7C 7D 7E 7F 80
Rx Response 03 7F 2E 82 00 00 00 00

UDS Protocol Architecture

Those services allow a tester (client) to control diagnostic functions in an
on-vehicle Electronic Control Unit (server) applied for example on the
electronic fuel injection, automatic gearbox, anti-lock braking system, etc.,
connected on a serial data link embedded in a road vehicle.

Furthermore, this part of the standard specifies generic services that allow
the diagnostic tester (client) to store or to resume non-diagnostic message
transmission on the data link. However, part 1 of the standard does not
specify any implementation requirements. Figure 7 shows a general
configuration of the client-server connection within a vehicle network.

Client-Server Communication in Vehicle

For vehicle 3, the servers are directly connected to the diagnostic data link,
and vehicle 4 connects its server/gateway directly to the vehicle 3
server/gateway. For vehicle 4, the servers are connected over an internal
data link and indirectly connected to the diagnostic data link through the
gateways. ISO 14229-1 or UDS Protocol applies to the diagnostic
communications over the diagnostic data link; the diagnostic
communications over the internal data link may conform to the same or
another protocol.
The server, usually a function that is part of the ECU, uses the application
layer services to send response data, provided by the requested diagnostic
service back to the client. The client is usually referred to as an External
Test Equipment when it is off-board but can in some systems, also be an
on-board tester. The usage of the application layer services is independent
of the client being an off-board or on-board tester. It is a possibility to have
more than one client on the same vehicle system.

OBD-II Gateway with Vehicle Network

The most typical network configuration of the client-server communication
for the vehicle diagnostics: the client as an Off-board tester.
Communication is based on a request-response model. In the context of
diagnostics, the following concepts are useful for a better understanding of
the semantics handled on the UDS standard environment:

1. Diagnostic Trouble Codes (DTC): The numerical common

identifier fault condition identified by the on-board diagnostic
system.
2. Diagnostic Data: Data that is located in the memory of an
electronic control unit that may be inspected and/or possibly
modified by the tester (diagnostic data includes analogue
inputs and outputs, digital inputs and outputs, intermediate
values and various status information). EXAMPLES: vehicle
speed, throttle angle, mirror position, system status, etc.
3. Diagnostic Session: The current model of the server, which
affects the level of diagnostic functionality.
4. Diagnostic Routine: The routine that is embedded in an
electronic control unit and that may be started by a server upon
a request from the client. NOTE: It could either run instead of
the normal operating program or run concurrently to the normal
operating program. In the first case, the normal operation of the
ECU is not possible. In the second case, multiple diagnostic
routines may be enabled that run while all other parts of the
electronic control unit are functioning normally.
 5. Tester: The system that controls functions such as test,
inspection, monitoring or diagnosis of an in-vehicle electronic
control unit and which may be dedicated to a specific type of
operator (e.g. a scan tool dedicated to garage mechanics or a
test tool dedicated to the assembly plant agents).
UDS Protocol Stack
As stated before, UDS is independent of lower-layer protocols. therefore,
car diagnostics could be executed, for example, by using the Unified
Diagnostic Services (UDS) on top at an application layer-level, generic
network layer services at an intermediate level and employing the means of
the controller area networks (CAN) or another communication bus protocol
(like LIN, FlexRay or Ethernet) for the data link and physical layers’ levels,
at lower stages.

Such an approach is compliant with the generic OSI model for the
networks. Figure 9 shows the hierarchical arrangement of layers for the
implementation of diagnostic services over the CAN according to standard
ISO-15765-3.

Security Layer in UDS Standard

When executing diagnostics over the CAN, the Client (diagnostic tester)
initiates a request and waits for confirmation. The server (function in ECU)
then receives the indication and sends a response.

Functions of Diagnostic Services In UDS

Protocol
Besides specifying services’ primitives and protocols that describe the
client-server interaction, UDS also defines within its framework several
functional units that comprise several services each, identified with a
hexadecimal code. These units are intended for the different individual
purposes that support the overall diagnostic function/task. The UDS
protocol having different services for the different types of work tasks to do
on the server. These are having 6- types as:

1. Diagnostic and communication management.

2. Data Transmission.
3. Stored Data Transmission.
4. Input/Output Control.
5. Remote activation of routine.
6. Upload/Download.
Each functional group has more than one service ID for different-2 tasks so
to get the detail of the above functional group and related services.

Diagnostic and communication

management:
There are 10 services are available in this module to control the diagnostic
and the communication-related in the ECU.

1. Diagnostic Session Control (0x10)

2. ECU Reset (0x11)
3. Security Access (0x27)
4. Communication Control (0x28)
5. Tester Present (0x3E)
6. Access Timing Parameter (0x83)
7. Secure Data Transmission (0x84)
8. Control DTC setting (0x85)
9. Response To Event (0x86)
10. Link Control (0x87)
Diagnostic Session Control (0x10):
The heart of the UDS Protocol is the Diagnostic session control service.
The diagnostic session control is the main door of the diagnostic server in
the ECU by which the tester or the diagnostic engineer will enter into the
diagnostic lab of the server and be able to take the decision that what is the
status of the problem and to which session he has to go to do the session.

Basically, this service is used to enable the different diagnostic sessions in

the server to work on it. In every session, they have defined some
diagnostic services which only enable these sessions so that they will work
perfectly without any negative impact on the server.
UDS Diagnostic Session
1. If the server is in default session and the client requests to start
the default session, then the server shall re-initialize
defaultSession completely.
2. If the server is in default session and the client requests to start
a non-default session (extendedDiagnosticSession or
programming session), then the server shall only reset the
events that have been configured in the server via the
ResponseOnEvent services before a transition to another
session.
3. When the server transitions from a non-default session to the
default session, then the server shall reset each event that has
been configured in the server via the ResponseOnEvent
service and security shall be enabled. Any configured periodic
scheduler shall be disabled and communication control and
ControlDTCSetting services shall be reset to default state. The
server shall reset all activated/initiated/changed
settings/controls during the activated session.
4. If the server is in a non-default Session and the client requests
to start the same or another non-default Session, then the
server shall (re-) initialize the non-default Session. Reset of
events that have been configured in the server via the
ResponseOnEvent service and enable Security shall be
performed.
SBF ID SBF NAME Description

After power on,

0x01 Default Session ECU will stay in this session

Programming ECU boot mode for new

0x02 Session software flashing
 SBF ID SBF NAME Description

Extended Diagnostic A real diagnostic session where

0x03 Session most of the diagnostic works done

System Safety Used to test all the safety

0x04 Diagnostic Session related ECUs. Ex: Airbag

SAE team can define any extra

diagnostic sessions under
0x05 – 0x3F ISO SAE reserved these SBF ID

Each OEM can define any extra

Vehicle Manufacturer diagnostic sessions under
0x40 – 0x5F Specific these SBF ID. Ex: Volvo, Audi, etc.

Any supplier can define any extra

System Supplier diagnostic sessions under
0x60 – 0x7E Specific these SBF ID. Ex: Robert BOSCH

It is still reserved for the future,

0x7F ISO SAE Reserved still, it is not used for any feature

Diagnostic Session Control Sub-function Identifier Table

Basically, most of the OEMs are using 3-4 Sub-functions which are really
important and we are also going to discuss only those here. mostly if you
have any other doubt or any query please search to get in my blog post
and Q&A forum page even if you can also write to us
at [email protected]
1. Default Session (0x01).
2. Programming Session (0x02).
3. Extended Diagnostic Session (0x03).
4. System Safety Diagnostic Session (0x04).
Default Session (0x01)
Whenever any ECU will get powered on, the ECU will be activated with the
default diagnostic session. In this session, only some basic diagnostic
functionalities will have access that can be executed at the run time means
if the vehicle is running you can do these tasks without any hamper or
disturbance of the run time vehicle. Let’s go discuss the request and
response frame format details as to how it is really working or implemented
by a developer.

PCI SID SBF DB4 DB3 DB2 DB1 D

02 10 01 00 00 00 00 00

Default session Request message from Client to Server

Here I will explain the byte from left to right for better understanding, so
please don’t make confusion yourself.

Where 1st byte is: 02–> PCI (Protocol Control Information) byte for CAN-
TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x2 –> LSB 4-bit –> DLC.

2nd byte: SID –> 0x10

3rd byte: Sub-function –> 01.

Since for this request, 2-byte is sufficient, and 1-byte is used for PCI,
except 3-byte others are not required.

NOTE: If you are not understanding what is PCI and CAN-TP please
search in my main menu for CAN-TP, first learn the CAN-TP protocol and
then come to this page for UDS protocol. Normally before learning this
protocol, first you need to know the CAN protocol and CAN-TP protocol. If
any doubt then you can comment in the comment below, else can send me
the mail at [email protected].
UDS Response: Server –>Client:
Positive Response:
06 50 01 00 19 07 D0 00

Default session response from Server to Client

Byte [1]: 06 –> PCI (Protocol Control Information) byte for CAN-TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x6 –> LSB 4-bit –> DLC.
Byte [2]: SID –> 0x50 (Positive response = Request SID + 0x40).

Byte [3]: SFID –> 0X01.

Byte [4-5]: P2 Server timing parameter (0x19 –> 25 ms in decimal).

Byte [6-7]: P2* Server timing parameter (0x7D0 –> 2 second in decimal).

Negative Response:
03 7F 10 12/13/22 00 00 00 00

Negative Response Frame For Diagnostic Session Control Service

Where 1st byte is: 04 –> PCI (Protocol Control Information) byte for CAN-
TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x4 –> LSB 4-bit –> DLC.

2nd byte: -Ve Response SID –> 0x7F.

3rd byte: 0x10 –> SID.

4th byte: 0x1 –> SFID.

5th byte: 0x12/13/22 –> -Ve response ID.

Diagnostic Session Control Request

message layout:
Data byte Parameter name Hex val

0 PCI 0x01

1 Diagnostic Session Request Service ID 0x10

2 Diagnostic Session Type 0x01-0x05

Example: Request Programming Session:

 Byte 0 1 2 3 4 5 6 7

Value 0x01 0x10 0x02 0x55 0x55 0x55 0x55 0x

NOTE: All the negative response ID is defined below.

ECU Reset Service Identifier (0x11)
The objective of this service is to reset the particular target ECU or all the
ECU nothing but the vehicle. There are different types of reset available or
defined in the UDS Protocol standard document, Such as hard reset, soft
reset, key off-on reset, etc for reset of any ECU. Each reset type has its
own functionality for how to reset and what needs to be reset. To know
more and deep about this service please select or click the above link to
read the ECU Reset Service ID
Security Access (27X)
This service Identifier is used to unlock an ECU in a vehicle. To learn about
security access I have written a separate tutorial for this. If you want to
know more about it you can follow this link as Security Access SID
(4) Communication Control Setting: UDS
Protocol
This service is used to control the communication with the server i.e enable
or disable transmission and reception of messages from the server.

Sub-Function:
SBF-ID SBF Name

0x00 Enable Rx & Tx

0x01 Enable Rx & Disable Tx

0x02 Disable Rx & Enable Tx

0x03 Disable Rx & Tx

Example:
Request: Client–>Server: 03 28 00 03
Where, 03 –> PCI (0–> Single Frame & 3–> TP Data Length)
28 –> SID
00–> SBF (Enable Rx & Tx)
03–> Communication Type as both (Normal & Diagnostic)
+Ve Response: 02 68 00
Where, 02 –> PCI (0–> Single Frame & 3–> TP Data Length)
0x68 –> +Ve response ID (0X28 + 0X40)
0X00 –> SBF

(5) TesterPresent (3E hex): UDS Protocol

The purpose of this service is that the Indication to a server (or servers)
that a client is still connected to the vehicle and that certain diagnostic
services and/or communications that have been previously activated are to
remain active. To keep one or multiple servers in a diagnostic session other
than the default Session. ServicesKeeps communication alive: avoid
communication timeout. There is no Subfunction parameter like other
services.

Example:
Request: Client–>Server: 02 3E 00
+Ve Response: Server–>Client: 02 7E 00

(6) Access Timing Parameter (0x83): UDS

Protocol
This service is used to read and change the default timing parameters of a
communication link for the duration of this communication link. By using
this service the Timeout values and message separation time can be
read /written.

SBF-ID SBF Name

0x01 readExtendedTimingParameterSet.

0x02 setTimingParametersToDefaultValues.

0x03 readCurrentlyActiveTimingParameters.

0x04 setTimingParametersToGivenValues.

Access Timing Parameter Service Sub-function Table

(7) Secure Data Transmission (0x84): UDS
Protocol
The purpose of this service is to transmit data that is protected against
attacks from third parties, which could endanger data security, according to
ISO 15764. This service is applicable if a client-server intends to use
diagnostic services defined in a secured mode. A secured mode in this
context means that the data transmitted is protected by cryptographic
methods. Security Sub Layer of the transmitter encodes the encapsulated
service. Security Sub Layer of the receiver decodes the encapsulated
service.

(8) Control DTC setting (0x85): UDS

Protocol
The ControlDTCSetting service shall be used by a client to stop or resume
the setting of diagnostic trouble codes (DTCs) in the ECU. It is used
to Activate / Deactivate storing of errors into error memory. Mostly, it is
used during flash programming and development.

SBF-ID SBF Name

0x01 DTC On

0x02 DTC Off

Example:
Client –> Server (Request Message)
02 85 01
Where,02 –> PCI [0–> Single Frame & 2–> CAN_TP Length]
85 –> SID
01 –> SBF [DTC Control setting ON]
Server –> Client (+Ve Response)
02 C5 01
02 –> PCI [0–> Single Frame & 2–> CAN_TP Length]
C5 –> +Ve Response SID
01 –> +Ve response acceptance SBF

(9) Response On Event (0x86): UDS

Protocol
The ResponseOnEvent service requests a server to start or stop the
transmission of responses on a specified event. This service provides the
possibility of automatically executing a diagnostic service if a specified
event occurs in the server. The client specifies the event (including optional
event parameters) and the service (including service parameters) to be
executed if the event occurs. See Figure 12 for a brief overview of client
and server behavior. Using this service you can Configure the ECU to send
a response without a request in case of a defined event.
Sub-Functions:
SBF-ID SBF Name

0x00 stopResponseOnEvent

0x01 onDTCStatusChange

0x02 onTimerInterrupt

0x03 onChangeOfDataIdentifier

0x04 reportActivatedEvents

0x05 startResponseOnEvent

0x06 clearResponseOnEvent

0x07 onComparisonOfValues

(10) Link Control (0x87): UDS Protocol

This service is used to control the communication link baud rate between
the Tester and the ECU(s) for the exchange of diagnostic data. This service
optionally applies to those data link layers which allow for a baud rate
transition during an active diagnostic session.

Sub-Functions:
SBF-ID SBF Name

0x1 verifyBaudrateTransitionWithFixedBaudrate
 SBF-ID SBF Name

0x2 verifyBaudrateTransitionWithSpecificBaudrate

0x3 transitionBaudrate

The baudrateIdentifier value determines the Baudrate. For example, 11 –

CAN 250 KBPS, 12 – CAN500KBPS, 13 – CAN 1 Mbps

Data transmission functional unit: UDS

Protocol
These Services are used to read or write the data to/from the server for the
different functional requirements.

Read Data By Identifier (22 hex): UDS

Protocol
The ReadDataByIdentifier service allows the client to request data record
values from the server identified by one or more data identifiers. The ECU
may limit the number of data identifiers that can be read in one
request. DataIdentifier – Identifies the ECU data record(s) that are being
requested by the ECU.

For Example:
 F180 – bootSoftwareIdentificationDataIdentifier.
 F181- applicationSoftwareIdentificationDataIdentifier.
 F191 –
vehicleManufacturerECUHardwareNumberDataIdentifier.
WriteDataByIdentifier (2E hex): UDS
Protocol
This service allows the client/Tester to write information into the
server/ECU at an internal location specified by the provided data
identifier. The WriteDataByIdentifier service is used by the client to write a
data Record to a server. The data is identified by a data identifier and may
or may not be secured.

Dynamically defined data identifier(s) shall not be used with this service. It
is the vehicle manufacturer’s responsibility that the server conditions are
met when performing this service. Possible uses for this service are:
–> programming configuration information into the server (e.g. VIN);
–> clearing non-volatile memory;
–> resetting learned values.
–> setting option content.

ReadMemoryByAddress (0x23): UDS

Protocol
The ReadMemoryByAddress service allows the client to request memory
data from the server via a provided starting address and to specify the size
of memory to be read.

The ReadMemoryByAddress request message is used to request memory

data from the server identified by the parameter memory address and
memory size. The number of bytes used for the memory address and
memory size parameter is defined by addressAndLengthFormatIdentifier
(low and high nibble). It is also possible to use a fixed
addressAndLengthFormatIdentifier and unused bytes within the memory
address or memory size parameter are padded with the value 00 hex in the
higher range address locations.

WriteMemoryByAddress (0x3D): UDS

Protocol
This service allows the client/Tester to write information into the
server/ECU at one or more contiguous memory locations. The tester sends
a memory address, and the number of bytes, and a data string (according
to the number of bytes ). The ECU writes the data string into its memory.
The addressAndLengthFormatIdentifier parameter in the request specifies
The number of bytes used for the memory address and memory size
parameter.

ReadScalingDataByIdentifier (24
hex): UDS Protocol
This service is used to read the scaling information of a record identified by
a provided data identifier from the ECU. The client request message
contains one data identifier value that identifies data record(s) maintained
by the server. The format and definition of the data record shall be vehicle-
manufacturer-specific and may include analog input and output signals,
digital input and output signals, internal data, and system status information
if supported by the server.
ReadDataByPeriodicIdentifier (2A
hex): UDS Protocol
The UDS Protocol is used to read the periodic data identifier from the
server by using a 0x21 service Identifier. This service allows the client to
request the periodic transmission of data record values from the server
identified by one or more periodicDataIdentifiers.The client request
message contains one or more 1-byte periodicDataIdentifier values that
identify data record(s) maintained by the server. The periodicDataIdentifier
represents the low byte of a data identifier out of the data identifier range
reserved for this service (F2xx hex, refer to C.1 for allowed
periodicDataIdentifier values), e.g. the periodicDataIdentifier E3 hex used
in this service is the data identifier F2E3 hex. The transmission mode is
also specified in the request. For Ex :sendAtSlowRate,
sendAtMediumRate, sendAtFastRate, stop sending and the values for
above is manufacturer specific.

Dynamically Define Data Identifier (2C

hex): UDS Protocol
The purpose of this service is to provide the client with the ability to group
one or more data elements into a data superset that can be requested en
masse via the ReadDataByIdentifier or ReadDataByPeriodicIdentifier
service. The data elements to be grouped can be referenced by either. This
provides the client with the ability to group one or more data elements into
a data superset that can be requested. The data elements to be grouped
can be reference by:

 a source data identifier, a position and size, or

 a memory address and a memory length, or
 a combination of the two methods.
Stored Data Transmission Functional
Unit: UDS Protocol
ReadDTCInformation (19 hex): UDS Protocol
The 0x19 service is the heart of ISO 14229 standard UDS Protocol. The
main intent of this service is to read the Diagnostic Trouble Codes from the
server or ECU. It has multiple sub-functions by which you can read different
data required for diagnostic analysis. You can follow this link to read more
on the Read DTC Information (0x19) Service Identifier.
Clear Diagnostic Information (14 hex): UDS
Protocol
Input-Output control functional unit: UDS
Protocol
Input-Output Control By Identifier (2F hex): UDS
Protocol
Remote activation of routine functional
unit: UDS Protocol
Routine Control (31 hex): UDS Protocol
The Vehicle Diagnostics may require testing the faulty component in a
given range of parameters. Moreover, during the vehicle testing phase,
some system tests may be required to run over a period of time. to perform
a test, a routine is triggered by the client, or to put it in another word, and a
routine is started by the client in the server’s memory. There are two
methods in this remote request service of UDS Protocol, one is where the
client interrupts the routine to stop it, and the other is when the server/ECU
finishes the routine after a specified time frame. Using this service, the
client can start a routine, stop a routine, and check the result of the routine
produced after a successful execution.

One of the Routine Control services defined in the UDS standard is the
Erase Memory or Erase Flash routine. It will perform the erasure of
EEPROM and flash memory before loading a new block. It has the routine
identifier FF01, specified on bytes #3-4 in the UDS request. The remaining
bytes of the request contain a routine control option record which is of
variable length depending on vehicle manufacturing specification and which
routine identifier is used. An example of a start Erase Flash Routine Control
service.

Let me explain actually why we need this routine control service. the
service diagnostic engineer in the garage may use this service to run the
engine fan for a certain period of time and record the results. This would
help him understand a particular issue well and rectify it without using any
hit and trial method.

Requests: RoutineControlType:
1. startRoutine (01 hex).
2. stopRoutine (02 hex).
3. reqestRoutineControl (03 hex).
RoutineIdentifier: This parameter identifies a server’s local routine.
Routine Control Request message layout:
 Data byte Parameter name Hex value

0 PCI 0x01

1 Routine Control SID 0x31

2 routine identifier 0x00-0xFF

3 routineControlType 0x01-0x03

Example:
A typical Erase Flash Routine Control UDS request. This request aims to
start an erasure of an EEPROM or flash memory sector before
downloading block 0x15.

Value 1 2 3 4 5 6 7

Byte 0x31 0x01 0xFF 0x00 0x01 0x15 –

Responses:
Positive response codes:
 routineControlType:This parameter is an echo of bits 6 – 0 of
the sub-function parameter from the request message.
 routineIdentifier: This parameter is an echo of the
routineIdentifier from the request message.
Negative response codes:
 Sub Function Not Supported (12 hex): This code is returned
if the requested sub-function is not supported.
 Incorrect Message Length Or Invalid Format (13 hex): The
length of the message is wrong.
 Conditions Not Correct (22 hex): This code shall be returned
if the criteria for the request RoutineControlare not met.
 Request Sequence Error (24 hex): This code shall be
returned if the “stop routine” subfunction is received without
first receiving a “start routine” for the requested routine
identifier.
 Request Out Of Range (31 hex): This code shall be returned
if the server does not support the requestedroutineIdentifier.
 Security Access Denied (33 hex): This code shall be sent if
this code is returned if a client sends a request with a valid
 secure routine identifier and the server’s security feature is
currently active.
 General Programming Failure (72 hex): This return code
shall be sent if the server detects an error when performing a
routine, which accesses server-internal memory. An example is
when the routine erases or programmes a certain memory
location in the permanent memory device (e.g. Flash Memory)
and the access to that memory location fails.
Upload download functional unit: UDS
Protocol
Request Download (34 hex): UDS Protocol
The request download service is called when data is to be transferred to
the ECU. The request shall contain the size of the data to be transferred
and the address to where it shall be placed. The ECU responds with the
size of its buffer so that the sender can divide the data into appropriate-
sized blocks and send them one at a time.

Requests: Four different request parameters can be included in the

request.
1. Request Download Service Identifier: This parameter is the
Service ID for any kind of download request.
2. DataFormatIdentifier: This data parameter is a one-byte value
with each nibble encoded separately. The high nibble specifies
the “compression Method” and the low nibble specifies the
“encrypting Method”. The value 0x00 specifies that no
compression Method or encrypting Method is used.
3. AddressAndLengthFormatIdentifier:
 bit 7 – 4: Length (number of bytes) of the memory size
parameter.
 bit 3 – 0: Lenght (number of bytes) of the memory
address parameter.
4. Memory Address: The parameter memory Address is the
starting address of the server memory to which the data is to
be written.
5. memory Size (unCompressedMemorySize): This parameter
shall be used by the server to compare the uncompressed
memory size with the total amount of data transferred during
the TransferData service.
Request Download Request message
Format:
 Data byte Parameter name Hex valu

0 PCI 0x01

1 Request Download SID 0x34

2 data format identifier 0x00 – 0xFF

3 addressAndLengthFormatIdentifier 0x00 – 0xFF

4…n memoryAddress 0x00-0xFF

n…m memory Size 0x00-0xFF

Responses:
Positive response codes:
 Length Format Identifier:
1. bit 7 – 4: length (number of bytes) of the
maxNumberOfBlockLength parameter.
2. bit 3 – 0: reserved by document, to be set to 0 hex.
Max Number Of Block Length: This parameter is used by the request
download positive response message to inform the client how many data
bytes (maxNumberOfBlockLength) shall be included in each TransferData
request message from the client. This length reflects the complete
message length, including the service identifier and the data parameters
present in the TransferData request message. This parameter allows the
client to adapt to the receive buffer size of the server before it starts
transferring data to the server.
Request Download Response message
LayOut:
Data byte Parameter name Hex value

0 PCI 0x01

1 Request Download RSID 0x74

2 lengthFormatIdentifier 0x00-0xFF
 Data byte Parameter name Hex value

3 maxNumberOfBlockLength 0x00-0xFF

Example:
Client –> Server (Request)
34 00 45 01 00 04 00 00 00 09 93 78
Server –> Client (+Ve Response)
74 20 0F FA
Server –> Client (-Ve Response)
7F 74 13/22/31

The Request Download Service (0x34) Full tutorial is available in our new
article. If you are interested to learn please click
this RequestDownloadService(0x34) Tutorial.
Negative response codes:
 Incorrect Message Length Or Invalid Format (13 hex): The
length of the message is wrong.
 Conditions Not Correct (22 hex): This return code shall be
sent if a server receives a request for this service while in the
process of receiving a download of a software or calibration
module. This could occur if there is a data size mismatch
between the server and the client during the download of a
module.
 Request Out Of Range (31 hex): This return code shall be
sent if:
1. the specified data Format Identifier is not valid,
2. the specified addressAndLengthFormatIdentifier is not
valid, or
3. the specified memory Address/memory Size is not
valid.
 SecurityAccessDenied (33 hex): This return code shall be
sent if the server is secure (for servers that support the
SecurityAccess service) when a request for this service has
been received.
 UploadDownloadNotAccepted (70 hex): This response code
indicates that an attempt to download to a server’s memory
cannot be accomplished due to fault conditions.
Request Upload (35 hex): UDS Protocol
The client requests the negotiation of a data transfer from the server to the
client. This service is just the reverse of the 0x34 SID. Suppose you have
downloaded some software or DID’s or PID’s, after some time it gets
crashed, to check the original file what you downloaded and now either it
crashed or not you can upload to your computer and compare also.

Data Byte Parameter Name Hex Valu

1 RequestUpload SID 35

2 dataFormatIdentifier 00-FF

3 addressAndLengthFormatIdentifier 00-FF

4 memoryAddress[]=[Byte1(MSB) – Byten()LSB] 00-FF to 00-FF

5 memorySize[]= [Byte1(MSB) – Byten()LSB] 00-FF to 00-FF

Data Format Identifier: This data parameter is a one-byte value with each
nibble encoded separately. The high nibble specifies the “compression
Method”, and the low nibble specifies the “encrypting Method”. The value
00 hex specifies that no compression Method nor encrypting Method is
used. Values other than 00 hex are vehicle manufacturer specific.
AddressAndLengthFormatIdentifier: This parameter is a one-byte value
with each nibble encoded separately for identification of address and data
in the memory array.
 Bit 7 – 4: length (number of bytes) of the “memory Size”
parameter;
 Bit 3 – 0: length (number of bytes) of the “memory Address”
parameter.
Memory Address: The parameter memory Address is the starting address
of server memory from which data is to be retrieved. The number of bytes
used for this address is defined by the low nibble (bit 3 – 0) of the address
Format Identifier. Byte#m in the memory Address parameter is always the
least significant byte of the address being referenced in the server. The
most significant byte of the address can be used as a memory Identifier.
Memory Size: This parameter shall be used by the server to compare the
uncompressed memory size with the total amount of data transferred
during the Transfer Data service. This increases programming security.
The number of bytes used for this site is defined by the high nibble (bit 7 –
4) of the address And Length Format Identifier.
Example:
Client –> Server (Request)
35 00 45 01 00 04 00 00 00 09 93 78
Server –> Client (Response)

Transfer Data (36 hex): UDS Protocol

The Transfer Data service receives blocks of data and checks so the
blocks are received in the right order. If the right block is received, then it is
written to the correct memory location and a positive response is sent.

Requests:
BlockSequenceCounter: The blockSequenceCounter parameter value
starts at 01 hex with the first TransferData request that follows the
RequestDownload (34 hex) service. its value is incremented by 1 for each
subsequent TransferData request. At the value of FF hex, the
blockSequenceCounter rolls over and starts at 00 hex with the next
TransferData request message.
Transfer Data Request message Frame
Format:
Data byte Parameter name Hex value

0 PCI 0x01/0x10/0x20-0x2F

1 Transfer Data SID 0x36

2 blockSequenceCounter 0x00-0xFF

3..n data 0x00-0xFF

Responses:
Positive response codes:
 Block Sequence Counter.
 This parameter is an echo of the block Sequence Counter
parameter from the request message.
Transfer Data Response message layout:
Data byte Parameter name Hex value

0 PCI 0x01/0x10/0x20-0x2F
 Data byte Parameter name Hex value

1 Transfer Data SID 0x76

2 block Sequence Counter 0x00-0xFF

Negative response codes:

 Incorrect Message Length Or Invalid Format (13 hex): The
length of the message is wrong (e.g. message length does not
meet the requirements of the max Number Of Block Length
parameter returned in the positive response to request
Download).
 Request Sequence Error (24 hex)
The server shall use this response code:
 If the Request Download service is not active when a request
for this service is received.
 If the Request Download service is active, but the server has
already received all data as determined by the memory Size
parameter in the active Request Download or Request Upload
service.
Request Out Of Range (31 hex): This return code shall be sent if the
transfer Request Parameter Record contains additional control parameters
(e.g. additional address information) and this control information is invalid.
 Transfer Data Suspended (71 hex): This return code shall be
sent if-
1. The response code indicates that a data transfer
operation was halted due to a fault.
2. The download module length does not meet the
requirements of the memory Size parameter sent in
the request message of the request Download
service.
 GeneralProgrammingFailure (72 hex): This return code shall
be sent if the server detects an error when erasing or
programming a memory location in the permanent memory
device (e.g. Flash Memory) during the download of data.
 WrongBlockSequenceCounter (73 hex): This return code
shall be sent if the server detects an error in the sequence of
the blockSequenceCounter.
The repetition of a Transfer Data request message with a block Sequence
Counter equal to the one included in the previous Transfer Data request
message shall be accepted by the server.

Request TransferExit (37 hex): UDS

Protocol
When the transfer of data is complete a message to the Request Transfer
Exit service is sent. If Transfer Data is complete and has received all data a
positive response is sent back.

Request:
Request Transfer Exit Request message
layout:
Data byte Parameter name Hex value

0 PCI 0x01

1 Request Transfer Exit SID 0x37

Response:
Request Transfer Exit Response message
layout:
Data byte Parameter name Hex value

0 PCI 0x01

1 Request Transfer Exit RSID 0x77

Negative response codes:

 Incorrect Message Length Or Invalid Format (13 hex): The
length of the message is wrong.
 Request Sequence Error (24 hex): The server shall use this
response code:
1. The programming process is not completed when a
request for this service is received.
2. The RequestDownload service is not active.