Study of ISO 14229-1 and ISO 15765-3 and Implementation in EMS ECU For EEPROM For UDS Application [PDF]

Zitiervorschau

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

Nithin Bhaskar Elamana

PowerTrain, Engine Systems Continental Automotive Components (India) Pvt. Ltd. Bengaluru, Karnataka, India [email protected]

PowerTrain, Engine Systems Continental Automotive Components (India) Pvt. Ltd. Bengaluru, Karnataka, India [email protected]

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).

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.

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]

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.

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.

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.

II. ISO 14229-1:20013(E) - ROAD VEHICLES – UNIFIED DIAGNOSTIC SERVICES (UDS) PART 1: SPECIFICATION AND

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

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

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.

starting address and to specify the size of memory to be read [1]. The ReadMemoryByAddress request message is used to request memory data from the server identified by the parameter memoryAddress and memorySize. The number of bytes used for the memoryAddress and memorySize parameter is defined by addressAndLengthFormatIdentifier (low and high nibble). The server sends data record values via the ReadMemoryByAddress positive response message [1].

memoryAddress 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 memoryIdentifier. An example of the use of a memoryIdentifier would be a dual processor server with 16-bit addressing and memory address overlap (when a given address is valid for either processor but yields a different physical memory device or internal and external flash is used). In this case, an otherwise unused byte within the memoryAddress parameter can be specified as a memoryIdentifier used to select the desired memory device. Usage of this functionality shall be as defined by vehicle manufacturer/system supplier. memorySize The parameter memorySize in the ReadMemoryByAddress request message specifies the number of bytes to be read starting at the address specified by memoryAddress in the server's memory. The number of bytes used for this size is defined by the high nibble (bit 7 - 4) of the addressFormatIdentifier. Table 2. Request Message Data Parameter Definition [1]

A.1. Request Message The Request Message Definition of ReadMemoryByAddress (23 hex) service is given in Table 1. A_D ata byte #1

Parameter name

#3 : #(m1)+3

ReadMemoryByAddress Request Service Id addressAndLengthFormatIdentifi er memoryAddress[] = [ byte#1 (MSB) : byte#m ]

#n(k-1) : #n

memorySize[] = [ byte#1 (MSB) : byte#k ]

#2

Con ven tion M

Hex value

Mnemo nic

23

RMBA

M

00FF 00FF : 00FF 00FF : 00FF

ALFID

M : C1 a M : C2 b

MA_ B1 : Bm

A.2. Positive Response Message The Positive Response Message Definition of ReadMemoryByAddress (23 hex) service is given in Table 3.

MS_ B1 : Bk

A_Data byte

M (Mandatory) - The parameter has to be present.

#1

Parameter name

Con venti on M

Hex value

63 ReadMemoryByAddress Response Service Id #2 M dataRecord[] = [ 00-FF : : data#1 : #n U 00-FF : data#m ] M (Mandatory) - The parameter has to be present.

C (Conditional) - The parameter can be present, based on certain criteria (e.g. sub function/parameters). a The presence of the C1 parameter depends on address length information parameter of the addressAndLengthFormatIdentifier. b The presence of the C2 parameter depends on the memory size length information of the addressAndLengthFormatIdentifier.

Mnemonic

RMBAPR DREC_ DATA_1 : DATA_m

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. Definition addressAndLengthFormatIdentifier This parameter is a one byte value with each nibble encoded separately (see annex G.1 for example values): bit 7 - 4: length (number of bytes) of the memorySize parameter; bit 3 - 0: length (number of bytes) of the memoryAddress parameter. memoryAddress The parameter memoryAddress 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 addressFormatIdentifier. Byte#m in the

The Positive Response Message Data Parameter Definition of ReadMemoryByAddress (23 hex) service is given in Table 4. Definition dataRecord This parameter is used by the ReadMemoryByAddress positive response message to provide the requested data record values to the client. The content of the dataRecord is not defined in this document and shall reflect the requested memory contents. Data formatting shall be as defined by vehicle manufacturer/system supplier. Table 4. Positive Response Message Data Parameter Definition [1]

169

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.

A.3. Negative Response Message The Negative Response Message Definition of ReadMemoryByAddress (23 hex) service is given in Table 5. A_Data byte

Parameter name

Con ven tio

Hex value

Mnemoni c

#1

Negative Response Service ID ReadMemoryByAddres s Request Service ID responseCode

M

7F

M

23

SIDRSI DNRQ RMBA

M

XX

NRC_

#2 #3

31

M (Mandatory) - The parameter has to be present.

Table 5. Negative Response Message Definition [1] The NRC_ (Negative Response Code) are listed in the Table 7. A.4. Positive Response The circumstances under which Positive Response would occur for 0x23 service are documented in Table 6. Hex Response Code Mnemonic Value 00 positiveResponse PR

78

This response code shall not be used in negative response message. This positiveResponse parameter value is reserved for server-internal implementation. Table 6. Positive Response Code [1]

RCR RP

The negative response message with this response code may be repeated by the server until the requested service is completed and the final response message is sent. This response code might impact the application layer timing parameter values. The detailed specification shall be included in the datalink-specific implementation document.

This response code indicates that the requested action will not be taken because the server does not support the requested service.

13

This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services which allow the client to read data, write data or adjust functions by data in the server. requestCorrectlyReceivedResponsePending

ROO R

This response code indicates that the request message was received correctly, and that all parameters in the request message were valid, but the action to be performed is not yet completed and the server is not yet ready to receive another request. As soon as the requested service has been completed, the server shall send a positive response message or negative response message with a response code different from this.

A.5. Negative Response Code (NRC_) The following negative response codes are implemented for 0x23 service. The circumstances under which each response code would occur are documented in Table 7. Hex Response Code Mne Value mon ic SNS 11 serviceNotSupported

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. incorrectMessageLengthOrInvalidFormat

requested action will not be taken because the length of the received request message does not match the prescribed length for the specified service or because the format of the parameters does not match the prescribed format for the specified service. requestOutOfRange

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 suppressPosRspMsgIndicationBit value.

IML OIF

A typical example of where this response

This response code indicates that the

170

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.

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 the server. If the programming/erasing routine (usually executed out of RAM) is not able to support serial communication while writing to the flash memory, the server shall send a negative response message with this response code.

7F

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. serviceNotSupportedInActiveSession

III. APPLICATION OF ISO 14229-1 AND ISO 15765-3 FOR EEPROM OF EMS ECU A. Block Diagram of the Work The schematic representation for the implementation of the work is as given below.

SNS IAS

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.

33

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. securityAccessDenied

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]. 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.

SAD

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.

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.

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]

With the above information, to read the EEPROM contents, the tester request message was constructed as given in Table 8.

171

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.

Message Direction: Message Type: A_Data byte #1 #2 #3 #4 #5 #6 #7 #8

Send NRC 0x7F

Client -> Server

ELSE(1) Request Description (all values are in hexadecimal) ReadMemoryByAddress request SID addressAndLengthFormatIdentifier memoryAddress [ byte#1 ] (MSB) memoryAddress [ byte#2 ] memoryAddress [ byte#3 ] memoryAddress [ byte#4 ] memorySize [ byte#1 ] (MSB) memorySize [ byte#2 ]

IF(2) (Service is not supported in active SecurityLevel) THEN(2) Send NRC 0x33 ELSE(2) IF(3) (Service is configured to support sub-function) THEN(3) IF(4) (Service request length < 2) THEN(4) Send NRC 0x13 ELSE(4) Call 0x23 Service Algorithm ENDIF(4) ENDIF(3) ENDIF(2) ENDIF(1)

Byte value (hex) 23 24 00 00 00 00 03 FF

Table 8. Tester request message to read EEPROM contents B.3. EMS ECU Configurations The following configurations were done in the EMS ECU project. • 0x23 service was configured in Default Diagnostic Session, without Security Access. • 0x7E0 CAN message ID was configured for the Tester Request message as a physical addressing receive message. • 0x7E8 CAN message ID was configured for the Tester Response message as a physical addressing transmit message.

C. 0x23 Service Algorithm Initialization: 0x78_Response_Active = 0 Maximum_Buffer_Size = 4096 E2P_Read_Completed = 0

IV. IMPLEMENTATION OF ALGORITHM AS PER ISO 14229-1 TO READ THE EEPROM CONTENTS OF EMS ECU

IF[1] (0x78_Response_Active == 1) THEN[1] IF[2a] (E2P_Read_Completed == 1) THEN[2a] Copy data from SPI buffer to UDS buffer Send Positive Response with UDS buffer data 0x78_Response_Active = 0 ELSE[2a] // SPI is busy in EEPROM Read operation Send NRC 0x78 ENDIF[2a] ELSE[1] // 0x78_Response_Active = 0 IF[2b] (Request Length == 8 bytes) THEN[2b] IF[3] (Requested size < Maximum_Buffer_Size) THEN[3] IF[4] (Requested memoryAddress == 0x00000000) THEN[4] // Tester has requested to read EEPROM memory location Call E2P_Read_Routine 0x78_Response_Active = 1 Send NRC 0x78 ELSE[4] // Tester has requested to read other memory location Send NRC 0x31 ENDIF[4] ELSE[3]

A. Behaviour of EMS ECU for the Tester Request Depending on the client request, the service scheduler of the EMS ECU called the UDS service interpreter. The UDS service interpreter checks certain general conditions which were common for all the configured services. Once these general conditions were met, the corresponding UDS service called. B. UDS Interpreter Algorithm The algorithm of UDS interpreter is given below. IF[1] (Requested Service ID not supported) THEN[1] Send NRC 0x11 ELSE[1] Call Service_Request_Normal_Handling ENDIF[1]

Service_Request_Normal_Handling IF[1](Service is not supported in active diagnosticSessionType) THEN(1)

172

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.

Send NRC 0x31 ENDIF[3] ELSE[2b] Send NRC 0x13 ENDIF[2b] ENDIF[1]

In the above report, CAN Frame 1 is called as First Frame and CAN Frame 3 is called as First Consecutive Frame. These CAN frames are transmitted by diagnostic tester on 0x7E0 CAN ID and they contain the tester request message (squareblocked 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, it interprets that it’s a tester request and calls the respective UDS algorithms. The Positive Response Message from EMS ECU is transmitted on 0x7E8 CAN ID (bold highlighted data in oval blocks) from CAN Frame 8 onwards (other than CAN Frame 9). This can be compared with the data mentioned in the 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 tester.

Pass the tester requested data to SPI driver-> start address, size, READ operation. Start reading the data from the given memory location using SPI driver. Once the SPI completes the read operation, set E2P_Read_Completed = 1 V. RESULTS The result of EEPROM contents read from UDS was observed using CANalyzer tool. A small part of report from CANalyzer log (*.asc) file is provided below.

CAN frames 4 to 7 are transmitted by EMS ECU to tester 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 // version 7.6.0 Begin Triggerblock Fri Mar 7 08:08:36 am 2014 0.000000 Start of measurement 0.001323 CAN 1 Status:chip status error active 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% 4.995468 1 7E0 Rx d 8 10 08 23 24 00 00 00 00 Length = 238000 BitCount = 123 -> CAN Frame 1 4.995724 1 7E8 Rx d 8 30 FF 00 55 55 55 55 55 Length = 228000 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 BitCount = 115 -> CAN Frame 4 5.313299 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 BitCount = 115 -> CAN Frame 5 5.323309 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 BitCount = 115 -> CAN Frame 6 5.333301 1 7E8 Rx d 8 03 7F 23 78 55 55 55 55 Length = 222000 BitCount = 115 -> CAN Frame 7 5.343523 1 7E8 Rx d 8 14 00 63 B0 4E 00 00 B0 Length = 234000 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 5.358242 1 7E8 Rx d 8 21 4E 00 00 01 00 00 00 Length = 238000 BitCount = 123 -> CAN Frame 10 5.358501 1 7E8 Rx d 8 22 01 00 00 00 B0 4E 00 Length = 240000 BitCount = 124 -> CAN Frame 11 5.358753 1 7E8 Rx d 8 23 00 B0 4E 00 00 01 00 Length = 234000 BitCount = 121 -> CAN Frame 12 End TriggerBlock

VI. CONCLUSION The above paper discusses and proposes the usage of standard UDS protocol listed in ISO 14229-1 used for diagnostic communication. The author also presents a holistic view of how this protocol can be implemented in embedded software application. An attempt is also made to validate the data transmitted from EMS ECU with respect to standard driver. ACKNOWLEDGMENT We thank the management of Continental Automotive Components (India) Pvt. Ltd. for the encouragement. The authors would like to especially thank Mr. Girish Ramaswamy, General Manager of Continental Technical Centre India. We would also like to thank Dr. Vivek Venkobarao for motivating and supporting us. REFERENCES [1] ISO 14229-1:2013(E) - Road vehicles – Unified Diagnostic Services (UDS) – Part 1: Specification and requirements. [2] ISO 15765-3:2004 - Road vehicles – Diagnostic on Controller Area Network (CAN) – Part 3: Implementation of Unified Diagnostic Services (UDS on CAN). [3] BOSCH CAN Specification 2.0

173

Authorized licensed use limited to: Center for Science Technology and Information (CESTI). Downloaded on April 29,2021 at 07:06:01 UTC from IEEE Xplore. Restrictions apply.