2014 IEEE International Conference on Vehicular Electronics and Safety (ICVES)
December 16-17, 2014. Hyderabad, India
Study of ISO 14229-1 and ISO 15765-3 and
Implementation in EMS ECU for EEPROM for UDS
Application
Mahesh Wajape
PowerTrain, Engine Systems
Continental Automotive Components (India) Pvt. Ltd.
Bengaluru, Karnataka, India
mahesh.wajape@continental-corporation.com
Abstract — The diagnostic tester is presented here to read out
the contents of external EEPROM of an EMS ECU. The tester
and the EMS ECU are built with Unified Diagnostic Service
(UDS) on Controller Area Network (CAN) as per ISO 14229-1
and ISO 15765-3. When the tester requests the UDS on CAN bus,
the ECU invokes the respective routines. The micro-controller of
ECU uses Serial Peripheral Interface (SPI) protocol to read out
the contents of EEPROM. The ECU stores the contents read
from external EEPROM into a buffer and that will be
transmitted on CAN bus as response to the tester request.
In this paper, the work flow and the algorithms are provided
as, how the tester requests the UDS commands on CAN bus and
how the EMS ECU interprets this command to get the contents of
EEPROM for the tester, as per ISO 14229-1 and ISO 15765-3.
Index Terms — ISO 14229-1, ISO 15765-3, EEPROM, EMS,
ECU, UDS, CAN, SPI.
I. INTRODUCTION
A. Diagnostic Tester
The diagnostic testers are used to exchange the diagnostic
data with Electronic Control Units (ECUs). The testers which
are available in the markets and the testers which are internally
developed by the OEMs are mainly used for different
applications as mentioned below.
• Reading/writing the data from/to flash memory of
controllers,
• Re-programming of ECUs,
• To read the Diagnostic Trouble Codes (DTCs) from
the ECUs,
• During vehicle end of line for actuators test, and so
on.
B. ECU with External EEPROM
The micro-controller of ECU can save the critical data
into their internal FLASH memory before it gets powered-off
and retain the same data when it boots up next time. The
978-1-4799-1882-9/14/$31.00 ©2014 IEEE
Nithin Bhaskar Elamana
PowerTrain, Engine Systems
Continental Automotive Components (India) Pvt. Ltd.
Bengaluru, Karnataka, India
nithin.elamana@continental-corporation.com
controllers can also save such critical data into external
EEPROM as a different strategy, if supported. To read/write
the data with external EEPROM, the controller normally uses
Serial Peripheral Interface (SPI).
C. Controller Area Network (CAN)
The Controller Area Network (CAN) is a serial
communication protocol which efficiently supports distributed
real time control with a very high level of security. Its domain
of application ranges from high speed networks to low cost
multiplex wiring. In automotive electronics, engine control
units, sensors, etc. are connected using CAN with bitrates up to
1 Mbit/sec. At the same time it is cost effective to build into
vehicle body electronics, e.g. lamp clusters, electric windows
etc. to replace the wiring harness otherwise required.[3]
D. Communication between Diagnostic Tester and ECU
Both the ECU and the tester should communicate with each
other on CAN bus. The ECU should support the below ISO
standards.
ISO 14229-1:2013(E) - Road vehicles – Unified
Diagnostic Services (UDS) – Part 1: Specification and
requirements.
This standard contains a detailed specification of diagnostic
services and their parameters.
ISO 15765-3:2004 - Road vehicles – Diagnostic on
Controller Area Network (CAN) – Part 3: Implementation
of Unified Diagnostic Services (UDS on CAN).
This standard specifies the adaptation of UDS on CAN.
II. ISO 14229-1:20013(E) - ROAD VEHICLES – UNIFIED
DIAGNOSTIC SERVICES (UDS) PART 1: SPECIFICATION AND
REQUIREMENTS
A. ReadMemoryByAddress (23 hex) UDS Service Details
The ReadMemoryByAddress (23 hex) service allows the
client to request memory data from the server via a provided
168
 starting address and to specify the size of memory to be read memoryAddress parameter is always the least significant byte
[1]. of the address being referenced in the server. The most
The ReadMemoryByAddress request message is used significant byte of the address can be used as a
to request memory data from the server identified by the memoryIdentifier.
parameter memoryAddress and memorySize. The number of An example of the use of a memoryIdentifier would be a dual
bytes used for the memoryAddress and memorySize parameter processor server with 16-bit addressing and memory
is defined by addressAndLengthFormatIdentifier (low and high address overlap (when a given address is valid for either
nibble). The server sends data record values via the processor but yields a different physical memory device or
ReadMemoryByAddress positive response message [1]. internal and external flash is used). In this case, an otherwise
unused byte within the memoryAddress parameter can be
A.1. Request Message specified as a memoryIdentifier used to select the desired
The Request Message Definition of memory device. Usage of this functionality shall be as
ReadMemoryByAddress (23 hex) service is given in Table 1. defined
by vehicle manufacturer/system supplier.
A_D Parameter name Con Hex Mnemo memorySize
ata ven value nic The parameter memorySize in the ReadMemoryByAddress
byte tion request message specifies the number of bytes to be read
#1 ReadMemoryByAddress Request M 23 RMBA starting at the address specified by memoryAddress in the
Service Id server's memory. The number of bytes used for this size is
#2 addressAndLengthFormatIdentifi M 00- ALFID
defined by the high nibble (bit 7 - 4) of the
er FF
addressFormatIdentifier.
#3 memoryAddress[] = [ M 00- MA_
: byte#1 (MSB) : FF B1 Table 2. Request Message Data Parameter Definition [1]
#(m- : C1 : :
1)+3 byte#m ] a 00- Bm A.2. Positive Response Message
FF The Positive Response Message Definition of
#n- memorySize[] = [ M 00- MS_ ReadMemoryByAddress (23 hex) service is given in Table
(k-1) byte#1 (MSB) : FF B1
3.
: : C2 : :
A_Data Parameter name Con Hex Mnemonic
#n byte#k ] b 00- Bk
FF byte venti value
on
M (Mandatory) - The parameter has to be present.
#1 ReadMemoryByAddress M 63 RMBAPR
Response Service Id
C (Conditional) - The parameter can be present, based on certain
criteria (e.g. sub function/parameters). #2 dataRecord[] = [ M 00-FF DREC_
: data#1 : : DATA_1
a The presence of the C1 parameter depends on address length #n : U 00-FF :
information parameter of the addressAndLengthFormatIdentifier. data#m ] DATA_m
M (Mandatory) - The parameter has to be present.
b The presence of the C2 parameter depends on the memory size length
information of the addressAndLengthFormatIdentifier. U (User Option) - The parameter may or may not be present,
depending on dynamic usage by the user.
Table 1. Request Message Definition [1]
Table 3. Positive Response Message Definition [1]
The request message data parameters defined for
ReadMemoryByAddress (23 hex) are given in Table 2. The Positive Response Message Data Parameter
Definition of ReadMemoryByAddress (23 hex) service is given
Definition
in Table 4.
addressAndLengthFormatIdentifier
Definition
This parameter is a one byte value with each nibble encoded
dataRecord
separately (see annex G.1 for example values):
This parameter is used by the ReadMemoryByAddress
bit 7 - 4: length (number of bytes) of the memorySize
positive response message to provide the requested data record
parameter;
values to the client. The content of the dataRecord is not
bit 3 - 0: length (number of bytes) of the memoryAddress
defined in this document and shall reflect the requested
parameter.
memory contents. Data formatting shall be as defined by
memoryAddress vehicle manufacturer/system supplier.
The parameter memoryAddress is the starting address of
Table 4. Positive Response Message Data Parameter Definition
server memory from which data is to be retrieved. The
[1]
number
of bytes used for this address is defined by the low nibble (bit
3 - 0) of the addressFormatIdentifier. Byte#m in the

169
 A.3. Negative Response Message requested action will not be taken because
The Negative Response Message Definition of the length of the received request message
ReadMemoryByAddress (23 hex) service is given in Table 5. does not match the prescribed length for the
specified service or because the format of the
A_Data Parameter name Con Hex Mnemoni parameters does not match the prescribed
byte ven value c format for the specified service.
tio 31 requestOutOfRange ROO
#1 Negative Response M 7F SIDRSI R
Service ID DNRQ This response code indicates that the
#2 ReadMemoryByAddres M 23 RMBA requested action will not be taken because
s Request Service ID the server has detected that the request
#3 responseCode M XX NRC_ message contains a parameter which attempts
M (Mandatory) - The parameter has to be present. to substitute a value beyond its range of
Table 5. Negative Response Message Definition [1] authority (e.g. attempting to substitute a data
byte of 111 when the data is only defined to
The NRC_ (Negative Response Code) are listed in the Table 7. 100), or which attempts to access a
dataIdentifier/routineIdentifer that is not
A.4. Positive Response supported or not supported in active session.
The circumstances under which Positive Response This response code shall be implemented for
would occur for 0x23 service are documented in Table 6. all services which allow the client to read
Hex Response Code Mnemonic data, write data or adjust functions by data in
Value the server.
00 positiveResponse PR 78 requestCorrectlyReceived- RCR
ResponsePending RP
This response code shall not be used
in negative response message. This This response code indicates that the request
positiveResponse parameter value is message was received correctly, and that all
reserved for server-internal parameters in the request message were
implementation. valid, but the action to be performed is not
Table 6. Positive Response Code [1] yet completed and the server is not yet ready
to receive another request. As soon as the
A.5. Negative Response Code (NRC_) requested service has been completed, the
The following negative response codes are server shall send a positive response message
implemented for 0x23 service. The circumstances under which or negative response message with a
each response code would occur are documented in Table 7. response code different from this.
Hex Response Code Mne
Value mon The negative response message with this
ic response code may be repeated by the server
11 serviceNotSupported SNS until the requested service is completed and
the final response message is sent. This
This response code indicates that the response code might impact the application
requested action will not be taken because layer timing parameter values. The detailed
the server does not support the requested specification shall be included in the data-
service. link-specific implementation document.

The server shall send this response code in
case the client has sent a request message
with a service identifier which is either
unknown or not supported by the server.
Therefore, this negative response code is not
shown in the list of negative response codes
to be supported for a diagnostic service
because this negative response code is not
applicable for supported services.
13 incorrectMessageLengthOrInvalidFormat
This response code indicates that the
This response code shall only be used in a
negative response message if the server will
not be able to receive further request
messages from the client while completing
the requested diagnostic service.
When this response code is used, the server
shall always send a final response (positive
or negative) independently of the
IML suppressPosRspMsgIndicationBit value.
OIF
A typical example of where this response

170
 code may be used is when the client has sent
a request message which includes data to be
programmed or erased in flash memory of III. APPLICATION OF ISO 14229-1 AND ISO 15765-3 FOR
the server. If the programming/erasing EEPROM OF EMS ECU
routine (usually executed out of RAM) is not
A. Block Diagram of the Work
able to support serial communication while
writing to the flash memory, the server shall The schematic representation for the implementation of the
send a negative response message with this work is as given below.
response code.

This response code is, in general, supported

by each diagnostic service, unless otherwise
stated in the data-link-specific
implementation document; therefore, it is not
listed in the list of applicable response codes
of the diagnostic services.
7F serviceNotSupportedInActiveSession
This response code indicates that the
requested action will not be taken because
the server does not support the requested
service in the session currently active. This
response code shall only be used when the
requested service is known to be supported in
another session, otherwise response code
SNS (serviceNotSupported) shall be used.
This response code is, in general, supported
by each diagnostic service, unless otherwise
stated in the data-link-specific
implementation document; therefore, it is not
listed in the list of applicable response codes
of the diagnostic services.
33 securityAccessDenied
This response code indicates that the
requested action will not be taken because
the server’s security strategy has not been
satisfied by the client.
The server shall send this response code if
one of the following cases occurs:
- the test conditions of the server are not
met;
- the required message sequence, e.g.
DiagnosticSessionControl, securityAccess, is
not met;
- the client has sent a request message which
requires an unlocked server.
Besides the mandatory use of this negative
response code as specified in the applicable
services within this part of ISO 14229, this
negative response code can also be used for
any case where security is required and is not
yet granted to perform the required service.
Table 7. Supported Negative Response Codes [1]
SNS
IAS
B. Steps Involved
The steps involved in reading the EEPROM contents of
ECU, using diagnostic tester are mentioned below.
B.1. Block Diagram of the Work
The diagnostic tester which is built with the UDS service,
used to request EMS ECU to read the contents of EEPROM.
As per ISO 14229-1, the tester is used to request
ReadMemoryByAddress (23 hex) UDS service on CAN [1][2].
SAD B.2. Application of ReadMemoryByAddress (23 hex) To Read
EEPROM Contents
In current work, the EMS ECU used has 4-byte (32-bit)
addressing micro-controller. The start address of external
EEPROM memory is mapped to 0x00000000 memory location
of ECU. Here it was demonstrated to read 1023 (0x3FF) bytes
of EEPROM.
The request message data parameters for the 0x23 UDS
service was prepared as below.
memoryAddress: It is the starting address of EEPROM,
which was considered as 0x00000000.
memorySize: The memorySize was considered as 1023
(0x3FF).
addressAndLengthFormatIdentifier: With the above
information of memoryAddress and memorySize, the
addressAndLengthFormatIdentifier was derived as 0x24.
With the above information, to read the EEPROM contents,
the tester request message was constructed as given in Table 8.

171
Message Client -> Server Send NRC 0x7F
Direction: ELSE(1)
Message Request IF(2) (Service is not supported in active
Type: SecurityLevel)
A_Data Description (all values are in Byte THEN(2)
byte hexadecimal) value
Send NRC 0x33
(hex)
#1 ReadMemoryByAddress request SID 23
ELSE(2)
#2 addressAndLengthFormatIdentifier 24 IF(3) (Service is configured to support
#3 memoryAddress [ byte#1 ] (MSB) 00 sub-function)
#4 memoryAddress [ byte#2 ] 00 THEN(3)
#5 memoryAddress [ byte#3 ] 00 IF(4) (Service request length <
#6 memoryAddress [ byte#4 ] 00 2)
#7 memorySize [ byte#1 ] (MSB) 03 THEN(4)
#8 memorySize [ byte#2 ] FF Send NRC 0x13
Table 8. Tester request message to read EEPROM contents ELSE(4)
Call 0x23 Service
B.3. EMS ECU Configurations Algorithm
ENDIF(4)
The following configurations were done in the EMS ECU ENDIF(3)
project. ENDIF(2)
• 0x23 service was configured in Default Diagnostic ENDIF(1)
Session, without Security Access.
• 0x7E0 CAN message ID was configured for the Tester
Request message as a physical addressing receive C. 0x23 Service Algorithm
message.
• 0x7E8 CAN message ID was configured for the Tester
Initialization:
Response message as a physical addressing transmit 0x78_Response_Active = 0
message. Maximum_Buffer_Size = 4096
E2P_Read_Completed = 0
IV. IMPLEMENTATION OF ALGORITHM AS PER ISO 14229-1 TO
IF[1] (0x78_Response_Active == 1)
READ THE EEPROM CONTENTS OF EMS ECU
THEN[1]
IF[2a] (E2P_Read_Completed == 1)
A. Behaviour of EMS ECU for the Tester Request THEN[2a]
Depending on the client request, the service scheduler of Copy data from SPI buffer to UDS buffer
the EMS ECU called the UDS service interpreter. The UDS Send Positive Response with UDS buffer data
service interpreter checks certain general conditions which 0x78_Response_Active = 0
were common for all the configured services. Once these ELSE[2a]
general conditions were met, the corresponding UDS service // SPI is busy in EEPROM Read operation
Send NRC 0x78
called.
ENDIF[2a]
B. UDS Interpreter Algorithm ELSE[1] // 0x78_Response_Active = 0
IF[2b] (Request Length == 8 bytes)
The algorithm of UDS interpreter is given below. THEN[2b]
IF[3] (Requested size < Maximum_Buffer_Size)
IF[1] (Requested Service ID not supported) THEN[3]
THEN[1] IF[4] (Requested memoryAddress ==
Send NRC 0x11 0x00000000)
ELSE[1] THEN[4]
Call Service_Request_Normal_Handling // Tester has requested to read
EEPROM memory location
ENDIF[1] Call E2P_Read_Routine
0x78_Response_Active = 1
Send NRC 0x78
Service_Request_Normal_Handling ELSE[4]
// Tester has requested to read
other memory location
IF[1](Service is not supported in active Send NRC 0x31
diagnosticSessionType) ENDIF[4]
THEN(1) ELSE[3]

172
 Send NRC 0x31 In the above report, CAN Frame 1 is called as First Frame
ENDIF[3] and CAN Frame 3 is called as First Consecutive Frame. These
ELSE[2b] CAN frames are transmitted by diagnostic tester on 0x7E0
Send NRC 0x13 CAN ID and they contain the tester request message (square-
ENDIF[2b]
ENDIF[1]
blocked data), which can be compared with the data mentioned
in the Table 8. CAN Frame 2 contains Flow Control parameters
which is transmitted by ECU.
E2P_Read_Routine
When the EMS ECU receives 0x7E0 CAN ID on CAN bus,
Pass the tester requested data to SPI driver-> start it interprets that it’s a tester request and calls the respective
address, size, READ operation. UDS algorithms. The Positive Response Message from EMS
Start reading the data from the given memory location ECU is transmitted on 0x7E8 CAN ID (bold highlighted data
using SPI driver. in oval blocks) from CAN Frame 8 onwards (other than CAN
Once the SPI completes the read operation, set Frame 9). This can be compared with the data mentioned in the
E2P_Read_Completed = 1 Table 3. The bold highlighted data in oval blocks, after the first
0x63 (RMBAPR), is the contents of EEPROM. CAN Frame 9
contains Flow Control parameters which is transmitted by the
V. RESULTS tester.
The result of EEPROM contents read from UDS was
observed using CANalyzer tool. A small part of report from CAN frames 4 to 7 are transmitted by EMS ECU to tester
CANalyzer log (*.asc) file is provided below. during the time when the controller of the ECU is busy with
EEPROM read operation.
date Fri Mar 7 08:08:36 am 2014
base hex timestamps absolute
internal events logged VI. CONCLUSION
// version 7.6.0
Begin Triggerblock Fri Mar 7 08:08:36 am 2014 The above paper discusses and proposes the usage of
0.000000 Start of measurement standard UDS protocol listed in ISO 14229-1 used for
0.001323 CAN 1 Status:chip status error active diagnostic communication. The author also presents a holistic
1.019953 1 Statistic: D 586 R 0 XD 0 XR 0 E 0 O 0 B 14.51%
2.019953 1 Statistic: D 586 R 0 XD 0 XR 0 E 0 O 0 B 14.51%
view of how this protocol can be implemented in embedded
4.995468 1 7E0 Rx d 8 10 08 23 24 00 00 00 00 Length = 238000 software application. An attempt is also made to validate the
BitCount = 123 -> CAN Frame 1 data transmitted from EMS ECU with respect to standard
4.995724 1 7E8 Rx d 8 30 FF 00 55 55 55 55 55 Length = 228000 driver.
BitCount = 118 -> CAN Frame 2
5.006094 1 7E0 Rx d 8 21 03 FF 00 00 00 00 00 Length = 242000
BitCount = 125 -> CAN Frame 3
5.303306 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 ACKNOWLEDGMENT
BitCount = 115 -> CAN Frame 4 We thank the management of Continental Automotive
5.313299 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000
BitCount = 115 -> CAN Frame 5 Components (India) Pvt. Ltd. for the encouragement. The
5.323309 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 authors would like to especially thank Mr. Girish Ramaswamy,
BitCount = 115 -> CAN Frame 6 General Manager of Continental Technical Centre India. We
5.333301 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 would also like to thank Dr. Vivek Venkobarao for motivating
BitCount = 115 -> CAN Frame 7
5.343523 1 7E8 Rx d 8 14 00 63 B0 4E 00 00 B0 Length = 234000 and supporting us.
BitCount = 121 -> CAN Frame 8
5.354852 1 7E0 Rx d 8 30 00 00 00 00 00 00 00 Length = 244000
BitCount = 126 -> CAN Frame 9 REFERENCES
5.358242 1 7E8 Rx d 8 21 4E 00 00 01 00 00 00 Length = 238000
BitCount = 123 -> CAN Frame 10 [1] ISO 14229-1:2013(E) - Road vehicles – Unified Diagnostic
5.358501 1 7E8 Rx d 8 22 01 00 00 00 B0 4E 00 Length = 240000 Services (UDS) – Part 1: Specification and requirements.
BitCount = 124 -> CAN Frame 11 [2] ISO 15765-3:2004 - Road vehicles – Diagnostic on Controller
5.358753 1 7E8 Rx d 8 23 00 B0 4E 00 00 01 00 Length = 234000 Area Network (CAN) – Part 3: Implementation of Unified
BitCount = 121 -> CAN Frame 12
Diagnostic Services (UDS on CAN).
End TriggerBlock
[3] BOSCH CAN Specification 2.0

173