www.ijcrt.

org © 2020 IJCRT | Volume 8, Issue 6 June 2020 | ISSN: 2320-28820

Implementation of Read DID UDS Service based

on AUTOSAR
MADAN MOHAN N Dr. BHARATHI S H
MTech Student in VLSI Professor School of
Design and Embedded Electronics and
System, School of Electronics Communication,
and Communication, REVA University
REVA University Bangalore India
Bangalore India

Abstract—The AUTOSAR is a standard platform on which the

future vehicle applications are implemented and it minimizes the
current barriers between functional domains. The unified II. CAN DIAGNOSTIC STACK IN AUTOSAR
diagnostic services (UDS) based on AUTOSAR software
architecture is implemented. The work include implementation of A. Diagnostic Stack and Communication Path
one of the UDS Service Read Data By Identifier and reading
multiple Data Identifier(DID) in a single request which is provided Tester and DCM happens via communication stack
in DCM(Diagnostic Communication Manager).And Implemented part which implements a communication protocol like
service is tested using CANoe. Ethernet ,FlexRay, CAN etc. In this paper we have used
CAN for Communication protocol . So this DCM along
Keywords— UDS, DCM, Data Identifier,AUTOSAR, CANoe
with part of communication stack together is called Diag
Stack DCM handles service protocol like UDS, remaining
I. INTRODUCTION
layers handles communication protocol like CAN . When
The Automotive Industry due to stringent legislative we relate the DiagStack layers with the OSI model layers
emission norms and due to lot of competition, embedded then Can driver layer represents physical layer ,then CAN
system took major role in automotive control this embedded Interface layer represent data link layer , then CanTp
system were called ECU(Electronic control unit) for
represents Transport layer, PduR layer represent network
example Engine ECU have process control over engine
functionalities like exhaust system, injection system, ABS layer and DCM layer represents application and session
ECU to have control of braking system ,Radar and layer . If the Diag Stack is explained in OSI model
entertainment ECU for entertainment purpose and so on. terminology then each layer excepts data packet from the
Today in an average car more than thirty five ECU’s will be upper layer called Service Data Unit (SDU) and then adds
present. These ECU are embedded system means hardware its own protocol control information(PCI) to SDU and
and software to release the functionalities which is intended forms Protocol Data Unit (PDU) and send it down to
to do. Initially each company use to have their own software further lower layer. This PDU becomes SDU for the
architecture for their ECU, but now a days all the car lower layer and lower layer adds its own PCI to make its
manufacturer follows single software architecture foe their own PDU and so on. From this it clears that PDU is
ECU’s called as AUTOSAR. AUTOSAR stands for
different for each module of the DiagStack. For DCM
Automotive Open Software Architecture. Depending on
different functionalities ECU software consist of different module it’s called I-PDU which is complete service
packages for example COM stack handles inter ECU request message or response message this I-PDU is
communication . Similarly tester related communication present in DCM buffer. In PduR module it is also called
handled by AUTOSAR package called as DCM (Diagnostic I-PDU its just routes the PDU without any modification.
communication manager). An external tester tool is In CanTP module this I-PDU will be seen as N-SDU.
connected to ECU in order to retrieve some information CanTP handles segmentation of huge data into smaller
from ECU or to write something on ECU or to trigger some chunks fit for data length of underlined communication
events on ECU , this happens during the UDS protocol in protocol. CanTp breaks the service message which is
service request and response format . In each ECU particular same as N-SDU into smaller chunks and adds its own N-
software intended for tester ECU package ,DSP takes
PCI as defined. And forms N-PDU. This N-PDU act as
request from the tester , DSD process the request and
accumulate the response and sends back the proper response Data field for underlying communication protocol which
to tester. These functions are done by the module called is CAN. N-PDU can be maximum of 8 bytes. One N-
DCM. In Diagnostic module contains different service. This SDU is broken into multiple N-PDU which will be
paper deals with implementation of Diagnostic Read Data converted into multiple frames for lower layers. CanTp
Identifier Service. Generally tester are interested in reading module handles multi frame communication in
multiple Data Identifier at a time but CAN communication AUTOSAR. This N-PDU moves to Data Link layer or
protocol supports only 8bytes of data to request. So this CanIf(Can Interface) and acts as L-PDU and gets its PCI
paper gives idea of requesting multiple DID’s in a single to become its L-PDU.L-PDU is consist of CAN message
request through CAN communication protocol. Id , Data Length Code, and the actual data .And this L-
PDU is transferred to tester through CAN bus

IJCRT2006105 International Journal of Creative Research Thoughts (IJCRT) www.ijcrt.org 757

www.ijcrt.org © 2020 IJCRT | Volume 8, Issue 6 June 2020 | ISSN: 2320-28820
III. FLOW CONTROL it means sender can send 5 consecutive frames and wait for
the receiver to send one more flow control frame. This
A. Flow Control 1
happens when the receiver has one free space in its buffer
It is important to know about flow control frames
but not so much as to accommodate complete N-SDU. So
because the Read Data Identifier service can be used to
depending on how much free space is present it computes
read multiple DID at a time. But as a known fact CAN
how many consecutive frames can be taken in and puts that
communication protocol cannot handle more than
number as block size. Note that when BS is non zero than
8bytes.So in ordered to make request the service with
then the BS has no significance. Last byte is called ST min
multiple Data Identifier Flow control frame is used.
which stands for minimum separation time. This field tells
Flow control is a mechanism of communicating huge
what should be the minimum time gap between consecutive
chunks of data between ECU and tester by means of
frames. Value from 1-127 specify number of milliseconds
single frame or multiple frame. This mechanism is
delay between consecutive frames. Values from 241-249
described in ISO15765 protocol and handled in CAN-
specify delay increasing from 100ms to 900ms.
TP module in autosar architecture. There are 4 types in
The purpose of this Flow Control concept in this research
Flow-Control frame they are Single Frame(SF), First
work is because of we are reading multiple DID. Thus Can
Frame(FF), Consecutive Frame(CF) and Flow Control
Communication protocol will handle 8bytes of data at time
Frame. The sequence of flow control between tester and
the request message will contain more than 8bytes of data so
ECU 1. The size of N-SDU is less than data limit of
this flow control concept is important.
frame, since we are using CAN data limit is 8 bytes. In
this case we use single frame. The transmitter sends
entire data in a single frame to the receiver. 2. The size IV. UDS SERVICE
of N-SDU is greater than data limit. In this case multi-
frame communication is used. The N-SDU is divided A. Introduction to UDS
into multiple chunks with each piece after applying With rapid implementation of electronic embedded systems
N_PCI after forming N-PDU can fit in one frame of in vehicles, the need to track and control vehicles different
underlying communication protocol and transmitted one parameters was important. Thus diagnostic systems were
by one until complete data is transmitted successfully. developed so that clients could detect the fault in the vehicle
The transmitter sends first piece as a first frame to the by connecting their diagnostic tester to ECU. But there are so
receiver and the receiver responds the flow control many manufacturers in the world like BMW, Volkswagen,
frame to the transmitter and then transmitter sends and Ford and so on where each brand will have its own
series of consecutive frames one after the other in the architecture and software’s in its ECUs. So it’s not possible
correct order to the receiver. Each consecutive frame to make tester communication language for each car brand. In
carries one piece of N-SDU respectively order to make sure that all brands cars can communicate with
the single generic testing tool SAE came up with the standard
B. Flow Control 2 protocol for tester communication. This protocol is named as
In a multi-frame communication initiated by the sender unified diagnostic services. Every ECU present in every car
with a first frame the receiver needs to tell how the flow must be able to communicate with the tester tool as per this
of consecutive frames need to be sent to the receiver. protocol. Tester can trigger various actions in the ECU.
There are various parameters to be considered like, does When I say action it can be requesting data, writing some
the receiver has enough memory for complete N-SDU data, running tests on the car component and getting its result
and rate at which consecutive frames must be back, flashing a program in ECU, clearing the memory,
transmitted and so on. All these information needed for setting a schedule and many other things. A tester triggers
controlling flow of frames need to be communicated these in the form of service request. Since the tester request
from the sender to the receiver. Hence the flow control for the service it is called a client and the ECU receives the
frame. Consider the data field of flow control frame is request and provides the service. Hence the ECU is called
always 3 bytes. The higher nibble of MSB is index. server. So tester and ECU is present in client-server topology
Index for flow control frame is 3 or 0011 in binary. The and the UDS is nothing but the collection of diagnostic
lower nibble of MSB is flow status. It can have 3 services which can be requested by the tester as client and
possible values. They are 0, 1 and 2. 0 represents clear performed by ECU as a server. UDS defines the available
to send the consecutive frames, 1 represents wait for services, request message, response message, timing
next flow-control frame so the sender does not send any parameters and services handled by the tester and ECU. ISO
consecutive frame and waits for one more flow control I14229 is a UDS protocol is published in 5 documents where
frame from the receiver. And 2 represents abort the part 1 contains all the details of UDS services.
nd
multi-frame communication. The 2 byte of flow
control frame is block size. This field is significant only
when the flow status value is 0. If FS=0 and BS=0 that
means send all the consecutive frames till complete N-
SDU is communicated. Receiver makes block size as 0
only when the buffer has a free space to accommodate
complete N-SDU. On the other hand if FS=0 and BS=N
that means send N consecutive frames and wait for next
flow control frame. For example if block size is 5 than

IJCRT2006105 International Journal of Creative Research Thoughts (IJCRT) www.ijcrt.org 758

www.ijcrt.org © 2020 IJCRT | Volume 8, Issue 6 June 2020 | ISSN: 2320-28820
B. UDS Request Message Format optional field. Single or multiple DIDs can be present in
the single service message. Next is data record field is
Request message is always from client to the server.
optional as per the service requested. For example read
UDS is a collection of diagnostic services. Each service
data by identifier does not require data record field in its
has a service identifier assigned to it. This service
service request. Whereas, write data by identifier needs
identifier is of 1 byte in length. The range of request
it. After mentioning the data identifier, you need to tell
service id is 0x00 to 0x3E. By this service id the server
the server what data value has to be written to that
understands which service is requested by client. For
element. For example the data identifier 0x9876
example, if the SID is 0x22 then requested service is
represents vehicle speed limit and its tester wants to
read data by identifier or if the SID is 0x31 then the
requested service is called routine control. This SID is change its current value then you also need to specify
what new value has to be stored in data element. Data
always the 1st byte of the service request message which identifier tells what data element is referred. Data record
is a mandatory field for all the request messages in UDS. specifies what new value has to be stored in that data
The optional field is called sub function whose length is element. In general, data record can be considered as
also 1 byte and the value of which tells the server for the Meta data of DID and it is mandatory for some specific
requested service which sub functionality is requested. services only.
For example for the routine control service (0x31) sub
function 0x01 is to start the routine, sub function 0x02 is
to stop the routine. Sub function 0x03 is to request V. IMPLEMENTATION METHOD A.
routine results. All these service belong to single service
called routine control. But to make the server understand Required Configuration To Test Read DID
what control is needed different sub function are
described in the UDS. Sub functions are needed for The CAN driver module is meant for the hardware
some selected services only. Services like RDBI, WDBI access and provides a hardware independent
are also there which does not require sub function. Sub communication to the upper layer. In the Can module
function is an optional field in the service request configuration Can Controller baudrate is configured , Can
message. The data identifier field is of 2 byte length. In
transmitting and receiving i.e Tx and Rx processing type
UDS the client and server only communicate numbers. If
is configured. The Configuration of hardware objects like
you want to read the information engine speed from the
CanHRO with CanID value as 0x72B and its type
tester then you cannot put the string “engine speed” in
the requested message. So for all the data elements configured as standard and CanHTO with CanID value as
which the tester may read must be assigned a number 0x62B and it is also standard type. For remaining
already. This number is identifier for that data element. communication layer like CanIF, CanTP, PDUR proper
In UDS this identifier number is of 2 bytes length. This Rx and Tx CanID and its type should be mapped and that
number is called data identifier or DID. Let’s say must be taken care. The DCM module consist of three sub
0x1234 is the number assigned to engine speed. Then modules those are Diagnostic Session Layer, Diagnostic
both tester and ECU knows that they are talking about Service Dispatcher and Diagnostic Service Processing
engine speed. Likewise different data elements are sub module. The DSL will ensures data flow of
predefined with data identifiers in both server and client. diagnostic requests and responses, and its take care of
But this assignment must match with both client and diagnostic protocol timing and manages diagnostic states
server. So in onboard diagnostics these DIDs are like diagnostic session and security. In DSD , there will
standardized globally. In UDS car manufactures define be container namely service table in which all the testing
their own DIDs, only tester tools from the OEMs can services needed to be configured . In this case Read DID
read these DIDs. service need to be configured with its service identifier
value i.e 0x22. The DSP sub module will look into the
Service Identifier actual diagnostic service requests. In the DSP sub module
Data oriented DID all the Did related information is configured, The size of
Routine control RID the DID will be two bytes. The Data Identifier is
configured with security level and session level.
The purpose of the identifier remains the same. There
are services that do not have DID field. So this is also

IJCRT2006105 International Journal of Creative Research Thoughts (IJCRT) www.ijcrt.org 759

www.ijcrt.org © 2020 IJCRT | Volume 8, Issue 6 June 2020 | ISSN: 2320-28820

B. Implemtation
.

Read data by Identifier service . In this paper we are

concentrating on the positive response for the requested

entry

Check the length of the failed incorrectMessageLengthOrIn

request message validFormat

success

Get Did indentifier

NO Did support service

0x22 in active session?

YES

NO
DID security check ok? SecurityAccessDenied

YES

E_NOT_OK
Set operation event Wait ConditionNotCorrect
for ConditionRead Check

E_OK
E_NOT_OK
Set operation event
Wait for Read Data ConditionNotCorrect

E_OK

Store the response data

YES
Further DID avaliable？

NO

At least one DID is supported NO

Requestoutofrange
in the acitive session?

YES

YES
Total response length exceeded Responsetoolong

NO

Positive response

Read DID service with multiple Data Identifier which are

configured in the DSP container accordingly. To get the
positive response for the Read Request these flow chat steps
This flow chart [4] will give the clear picture of are implemented.
implementing

IJCRT2006105 International Journal of Creative Research Thoughts (IJCRT) www.ijcrt.org 760

www.ijcrt.org © 2020 IJCRT | Volume 8, Issue 6 June 2020 | ISSN: 2320-28820
use of flow control frame and validating the positive
response received from the server. In future this service
different NRC can be tested.

VIII.ACKNOWLEDGMENT
I acknowledge our organization REVA university for all
VI. RESULTS support to do this work .

At last, we test the Read DID Service by using Canoe. The

Test Result is tabulated below. The Read DID service is
requested with the Configured multiple DID of value and IX. REFERENCE
the received response is validated by making use of Capl [1] AUTOSAR Development Partnership. Specification of DCM
Scripts. www.autosar.org
[2] AUTOSAR Development Partnership. Specification of PduR
www.autosar.org
[3] AUTOSAR Development Partnership. Specification of CanTp
www.autosar.org
[4] XIE, Yue-yin, Z. H. O. U. Chao, and L. U. O. Feng. "Implementation
of Automotive Unified Diagnostic Services Based on AUTOSAR."
DEStech Transactions on Computer Science and Engineering itme
Figure 1. Testing Environment (2017).

Channel Channel ID Name Event Type Direction Data Length Data [5] Di Natale, M., Zeng, H., Giusto, P., and Ghosal, A. , Understanding
CAN1 0x72B Read DID Request CAN Frame Tx 8 0422DD0000000000 and Using the Controller Area Network Communication Protocol,
Theory an d Practice, Springer, New York, NY, USA, 2012
CAN1 0x62B Response CAN Frame Rx 8 0666DD000A120000

Figure 2.Test Result of Read DID [6] ISO15765-3-2004, Road Vehicles—Diagnostics on Controller Area
Networks (CAN)-Part 3: Implementation of Unified Diagnostic
Services (UDS on CAN), 2004

VII. CONCLUSION [7] Jun Jiang, “A network fault diagnostic approach based on a statistical
traffic normality prediction algorithm”, Global Telecommunications
This paper is all about sending the Read DID service Conference, 2003. GLOBECOM '03. IEEE,Vol: 5, pp: 2918 -
Request with multiple number of DID at a time by making 2922,2003

IJCRT2006105 International Journal of Creative Research Thoughts (IJCRT) www.ijcrt.org 761