Diagnostics Standards For Electronic Breaking System Software

Published Date: 02 Nov 2017

In present day automotive system, the numbers of ECUs are in significant number, Because of which the troubleshooting and diagnosing a fault in the functionality of a system calls for automated process. Diagnostic is one such process where in the user or a tester (professional) can get the status of each ECU by executing pre-defined messages called the diagnostic services. These messages are sent through the CAN bus and are specific to each ECU present in the system.

The diagnostic services are defined by ISO standards namely 14229(UDS-unified diagnostic services), 14230(KWP-key word protocol 2000) as per the requirements.

The customer product specification applies to the diagnostic functionality within Continental Automotive Corporation. Few of the diagnostic services are listed below:

Diagnostic Session Control (SID$10): ECU enters the requested diagnostic session (standard/Extended Session).

Diagnosis Information Erase (SID$14): This service clears the stored DTC and FFD in EEPROM.

Read DTC Information (SID$19): This service outputs the stored/supported DTCs and FFD according to the requested parameter.

Read Data by Identifier (SID$22): This service outputs the current data in the ECU (ex. wheel speeds, sensor value etc.) according to the requested Data Identifier. The output data is raw value. Then, the ECU doesn’t output the fixed data which specified as the abnormal value even if it has any failure.

Read Memory by Address (SID$23): This service outputs the data in EEPROM according to the requested address and size.

Security Access (SID$27): This service unlocks the ECU for the functionalities which require the security access. To unlock the security, the tester has to execute "Request Seed 27 01" and "Send Key 27 02" processes.

Write Memory by Address (SID$3D): This service writes the data into EEPROM according to the requested Memory Address. Especially, this service is used to write Evacuation & Filling process byte, G sensor process byte and Variant coding data.

Tester present (SID$3E): This service ensures that the ECU is in extended mode so that other services which needs ECU to be in extended mode can be executed. This service message is periodically sent by the tester to the ECU, period defined by the customer.

Introduction:

In present day automotive system, the numbers of ECUs are in significant number, Because of which the troubleshooting and diagnosing a fault in the functionality of a system calls for automated process. Diagnostic is one such process where in the user or a tester (professional) can get the status of each ECU by executing pre-defined messages called the diagnostic services. These messages are sent through the CAN bus and are specific to each ECU present in the system.

The diagnostic services are defined by ISO standards namely 14229(UDS-unified diagnostic services), 14230(KWP-key word protocol 2000) as per the requirements.

Diagnostic service messages are communication through CAN. These services are responded by corresponding ECU in a standard CAN message format. This message can be single frame or multiple frames.

Single frame is defined as the message length <= 8 bytes (i.e. Transmission finishes with 1 frame). Multi frame is defined as the message length > 8bytes (i.e. Transmission doesn’t finish with 1 frame).

Communication layer consists of mainly two layers. They are

1) Network layer

2) Communication layer

There are some diagnostic modes (ex. Normal Diagnosis Mode and Extended Diagnostic Mode etc) for the diagnostic services. The default mode after IGN ON is Normal Diagnosis Mode. And if the ECU receives the request of Extended Diagnostic Mode from the tester, the ECU enters Extended Diagnostic Mode.

Unified Diagnostic Services (UDS):

This International Standard has been established in order to define common requirements for diagnostic Systems, whatever the serial data link is.

To achieve this, the standard is based on the Open Systems Interconnection (O.S.I.) Basic Reference Model in accordance with ISO 7498 and ISO/IEC 10731, which structures communication systems into seven layers.

When mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU, server) are broken into:

Unified diagnostic services (layer 7),

Communication services (layers 1 to 6).

These are the few SID’s that implemented and testing as per the requirement given below:

Write memory by Address (SID $3D)

Read data by Identifier (SID $22)

Security Access (SID $27)

Write memory by Address (SID $3D):

Service Description:

The Write Memory by Address request message writes information specified by the parameter dataRecord [] into the server at memory locations specified by parameters memory Address and memory Size. The number of bytes used for the memory Address and memory Size parameter is defined by address And Length Format Identifier (low and high nibble). It is also possible to use a fixed address And Length Format Identifier and unused bytes within the memory Address or memory Size parameter are padded with the value 00 hex in the higher range address locations.

The format and definition of the dataRecord shall be vehicle manufacturer specific, and may or may not be secured. It is the vehicle manufacturer's responsibility to assure that the server conditions are met when performing this service. Possible uses for this service are:

Clear non-volatile memory

Change calibration values

This service writes the data into EEPROM according to the requested Memory Address.

Especially, this service is used to write Evacuation & Filling process byte, G sensor process byte and Variant coding data.

Request Message

Byte

Data

Contents

1

$3D

Write Memory By Address SID

2

$14

Address And Length Format Identifier

3

$XX

Memory Address Byte #1

4

$XX

Memory Address Byte #2

5

$XX

Memory Address Byte #3

6

$XX

Memory Address Byte #4

7

$XX

Memory Size

8

$XX

Data #1

:

:

:

N

$XX

Data #n

Positive Response

Byte

Data

Contents

1

$7D

Write Memory By Address Positive response SID

2

$14

Address And Length Format Identifier

3

$XX

Memory Address Byte #1

4

$XX

Memory Address Byte #2

5

$XX

Memory Address Byte #3

6

$XX

Memory Address Byte #4

7

$XX

Memory Size

Negative Response

Byte

Data

Contents

1

$7F

Negative response

2

$3D

Write Memory By Address SID

3

$XX

Negative response code

Negative response code (NRC)

NRC

Description

$13

Message length is incorrect

$22

Current session is Normal Diagnosis Mode

$31

Memory Address Byte is out of range

OR Memory Size Byte is out of range

OR Memory Address Byte + Memory Size Byte is out of range

OR Data is out of range

$72

Writing data into EEPROM is failed

Supported Address and Data

Content

Address

Data

Variant coding

0x000009B0

*1

Evacuation & Filling process byte

0x00000962

1Byte*2

G sensor process byte

0x00000963

2Byte*2

Read data by Identifier (SID $22):

The ReadDataByIdentifier service allows the client to request data record values from the server identified by one or more record Data Identifiers.

Service description:

The client request message contains one or more two (2) byte record Data Identifier values that identify data record(s) maintained by the server for allowed record). The format and definition of the dataRecord shall be vehicle manufacturer or system supplier 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.

Upon receiving a ReadDataByIdentifier request, the server shall access the data elements of the records specified by the record Data Identifier parameter(s) and transmit their value in one single ReadDataByIdentifier positive response containing the associated dataRecord parameter(s).

The server shall behave as follows after the reception of a request message that contains one or more record Identifiers, which are not supported by the server (compliant with ISO 15031-5):

Physical communication:

If a single requested record Data Identifier is not supported by the server then a negative response message with response code $31 shall be sent.

In case the client requests multiple record Data Identifiers where at least one record Data Identifier is not supported then the server shall send a negative response message with response code $31. There shall be no positive response for the supported record Data Identifiers.

Functional communication:

If a single requested record Data Identifier is not supported by the server then no response message shall be sent.

In case the client requests multiple record Data Identifiers where at least one record Data Identifier is supported then the server shall send a positive response message with the supported record Data Identifiers and the associated record data.

The server may limit the number of record Data Identifiers that can be simultaneously supported as agreed upon by the vehicle manufacturer and system supplier. Exceeding the maximum number of record Data Identifiers that can be simultaneously supported shall result in a negative response with response code 31 hex.

This service outputs the current data in the ECU (ex. wheel speeds and sensor value etc.) according to the requested Data Identifier. The output data is raw value. Then, the ECU doesn’t output the fixed data which specified as the abnormal value even if it has any failure.

Request Message

Byte

Data

Contents

1

$22

Read Data By Identifier SID

2

$XX

Data Identifier #1 (MSB)

3

$XX

Data Identifier #1 (LSB)

:

:

:

N-1

$XX

Data Identifier #n (MSB)

N

$XX

Data Identifier #n (LSB)

Positive Response

Byte

Data

Contents

1

$62

Read Data By Identifier Positive response SID

2

$XX

Data Identifier #1 (MSB)

3

$XX

Data Identifier #1 (LSB)

4

$XX

Data Record #1 (MSB)

:

:

:

4+x

$XX

Data Record #1 (LSB)

:

:

:

N-y-2

$XX

Data Identifier #n (MSB)

N-y-1

$XX

Data Identifier #n (LSB)

N-y

$XX

Data Record #n (MSB)

:

:

:

N

$XX

Data Record #n (LSB)

Negative Response

Byte

Data

Contents

1

$7F

Negative response

2

$22

Read Data By Identifier SID

3

$XX

Negative response code

Negative Response Code (NRC)

NRC

Description

$13

Message length is incorrect

(inc. one of DID is not 2 bytes OR requested number of DID exceeds maximum number)

$22

Data cannot be read because of EEPROM/RAM is abnormal

$31

Data Identifier is not defined

OR Data Identifier is not supported

$78

Preparation for Routine Control is in progress

Security Access (SID $27):

The purpose of this service is to provide a means to access data and/or diagnostic services, which have restricted access for security, emissions, or safety reasons. Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where security access may be required. Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or security standards.

Service description:

The security concept uses a seed and key relationship.

A typical example of the use of this service is as follows:

Client requests the "Seed"

Server sends the "Seed"

Client sends the "Key" (appropriate for the Seed received)

Server responds that the "Key" was valid and that it will unlock itself

A vehicle manufacturer specific time delay (can be zero (0)) might be required before the server can positively respond to a service SecurityAccess ‘requestSeed’ message from the client after server power up/reset. If a delay timer is supported then this delay shall be activated after a failed SecurityAccess service attempt (see further description below) and when the server is powered up/reset and a previously performed SecurityAccess service has failed. In case the server supports a delay timer then after a successful SecurityAccess service execution the server internal indication information for a delay timer invocation on a power up/reset shall be cleared by the server. In case the server supports a delay timer and cannot determine if the last SecurityAccess service prior to the power up/reset has failed then the delay timer shall always be active after power up/reset. The delay is only required if the server is locked when powered up/reset. The vehicle manufacturer shall select if the delay timer is supported.

The client shall request the server to "unlock" by sending the service SecurityAccess ‘requestSeed’ message. The server shall respond by sending a "seed" using the service SecurityAccess ‘requestSeed’ positive response message. The client shall then respond by returning a "key" number back to the server using the service SecurityAccess ‘sendKey’ request message. The server shall compare this "key" to one internally stored/calculated. If the two numbers match, then the server shall enable ("unlock") the client's access to specific services/data and indicate that with the service SecurityAccess ‘sendKey’ positive response message. Vehicle manufacturer may choose to implement a delay after a certain number of failed attempts. An invalid key requires the client to start over from the beginning with a SecurityAccess request message.

If a server supports security, but is already unlocked when a SecurityAccess ‘requestSeed’ message is received, that server shall respond with a SecurityAccess ‘requestSeed’ positive response message service with a seed value equal to zero (0). The client shall use this method to determine if a server is locked by checking for a non-zero seed.

Attempts to access security shall not prevent normal vehicle communications or other diagnostic communication.

Servers, which provide security shall support reject messages if a secure service is requested while the server is locked.

Some diagnostic functions/services requested during a specific diagnostic session may require a successful security access sequence. In such case the following sequence of services shall be required:

Diagnostic Session Control service

SecurityAccess service

Secured diagnostic service

This service unlocks the security for the diagnostic service which has the guard to execute. To unlock the security, the tester has to execute "Request Seed" and "Send Key" processes.

Flow Chart: (SEED Algorithm)

Flow Chart: (KEY Algorithm)

FLOW CHART :( NRC’s)

The following Sub Function is supported.

Request Seed

Send Key

Sub Function

$01

$02

Request Message

Byte

Data

Contents

1

$27

Security Access SID

2

$XX

Sub Function

3

$XX

Key #1

4

$XX

Key #2

5

$XX

Key #3

6

$XX

Key #4

*Seed #1-4 is sent only for Sub Function $02.

Positive response

Byte

Data

Contents

1

$67

Security Access Positive response SID

2

$XX

Sub Function

3

$XX

Seed #1

4

$XX

Seed #2

5

$XX

Seed #3

6

$XX

Seed #4

*Seed #1-4 is sent only for Sub Function $01.

Negative Response

Byte

Data

Contents

1

$7F

Negative response

2

$27

Security Access SID

3

$XX

Negative response code

Negative response code (NRC)

NRC

Description

$12

Sub Function not supported

$13

Message length is incorrect

$22

Current Diagnostic Session is not Extended Session

($03, $43 or $63)OR The ECU is still transmitting normal periodic messages on CAN (Only if Diagnostic Session Type is $43/$63)OR Send Key ($02) is requested before Request Seed ($01)

$35

Receive invalid key

$36

Exceed number of times of invalid key to "Send Key" request (>= 4 times)

$37

Receive "Request Seed" request before Delay timer not passed after NRC$35