UDS Document

STANDARD
36 - 00 - 013 / - - C
DIAGNOSTIC ON CAN
DIAGNOSTIC SERVICES IMPLEMENTATION
Normalisation Renault Automobiles

RE-DS / Service 67210
Section Normes et Cahiers des Charges
RENAULT 36 - 00 - 013 / - - C
This document is to be considered as a whole, the parts of which shall not be separated.
© RENAULT 2010.
No duplication permitted without the consent of the issuing department.
No circulation permitted without the consent of RENAULT.
DATE OF ISSUE
May 2010 ---
REVISIONS
September 2002 --A
October 2004 - - B This issue originates from Draft NC 2004 0324 / - - A.

October 2010 - - C - UCE Traceability
- DiagMux LID reserved

- Timing Chart for DTC
- Bit 4 / bit 5 DTCStatus bits
- DTCExtendedDataRecordNumber. Mileage informations mandatory
- Corrections
- Adding comments from addemdum –B
This issue originates from Draft NC 2010 0590 / - - - .
REFERENCED DOCUMENTS
[REF 1] : [RENAULT] : 36-02-031

[NISSAN] : 25953 NDS 08
[REF 2] ECU Reprogramming : [RENAULT] : 01-58-110, 01-58-111, 01-58-112, 01-58-117, 01-58-118,
01-58-137.
[NISSAN] : 25953 NDS 09, 10, 11, 12, 13 and 16
[REF 3] : [RENAULT] : C.R.S. : Communication Requirement Specification
(specific for each ECU).
[NISSAN] : Software specification for each ECU.
ISO Standards : ISO 14229-1, ISO 15765-3, ISO 15031-5, ISO 15031-6.
© RENAULT 2010 Page 2/128

RENAULT 36 - 00 - 013 / - - C
CONTENTS
Page
1. FOREWORD 5
2. INTRODUCTION 5
3. TERMS AND DEFINITION 5
4. CONVENTIONS 6
5. DIAGNOSTIC SERVICES APPLICABILITY TO O.S.I. LAYER MODEL 6
6. APPLICATION AND SESSION LAYER 7
6.1. APPLICATION LAYER SERVICES 7
6.2. APPLICATION LAYER PROTOCOL 7
6.3. APPLICATION LAYER AND DIAGNOSTIC SESSION MANAGEMENT TIMING 7
7. NETWORK LAYER INTERFACE 7
8. STANDARDISED DIAGNOSTIC CAN IDENTIFIERS 7
9. DIAGNOSTIC SERVICES IMPLEMENTATION 8
9.1. DIAGNOSTIC SERVICES OVERVIEW 8
9.1.1. Negative responses : Definitions and code table 11
9.1.2. Processing long execution time service 13
9.1.3. General diagnostic service implementation rules 16
9.1.4. Restrictions on concurrent services 21
9.1.5. Getting Identifiers supported by the ECU 23
9.2. DIAGNOSTIC AND COMMUNICATION CONTROL FUNCTIONAL UNIT 29
9.2.1. $10 - StartDiagnosticSession Service 29
9.2.2. $11 - ECUReset service 35
9.2.3. $27 - SecurityAccess service 38
9.2.4. $28 - CommunicationControl service 44
9.2.5. $3E - TesterPresent service 46
9.3. DATA TRANSMISSION FUNCTIONAL UNIT 48
9.3.1. $21 - ReadDataByLocalIdentifier service 48
9.3.2. $22 - ReadDataByIdentifier service 55
9.3.3. $23 - ReadMemoryByAddress service 58
9.3.4. $24 - ReadScalingDataByIdentifier service 61

RENAULT 36 - 00 - 013 / - - C
9.3.5. $2C - DynamicallyDefineLocalIdentifier service 63
9.3.6. $3B - WriteDataByLocalIdentifier service 70
9.3.7. $2E - WriteDataByIdentifier service 73
9.3.8. $3D - WriteMemoryByAddress service 76
9.4. STORED DATA TRANSMISSION FUNCTIONAL UNIT 79
9.4.1. $14 - ClearDiagnosticInformation Service 79
9.4.2. $19 – ReadDTCInformationService 81
9.5. INPUT/OUTPUT CONTROL FUNCTIONAL UNIT 105
9.5.1. $30 - InputOutputControlByLocalIdentifier service 105
9.6. REMOTE ACTIVATION OF ROUTINE FUNCTIONAL UNIT 110
9.6.1. $31 - StartRoutineByLocalIdentifier service 110
DESCRIPTION 111
9.6.2. $32 - StopRoutineByLocalIdentifier service 115
9.7. UPLOAD/DOWNLOAD FUNCTIONAL UNIT 118
9.7.1. $34 - RequestDownLoad service 118
9.7.2. $35 - RequestUpLoad service 119
9.7.3. $36 - TransferData service 120
9.7.4. $37 - RequestTransferExit service 121
ANNEXE A DATA TRANSMISSION FUNCTIONAL UNIT DATA PARAMETER DEFINITIONS 122
ANNEX B TIMING CHART FOR DTC 128

RENAULT 36 - 00 - 013 / - - C
1. FOREWORD
This document is identical to NISSAN document 25953 NDS 07.
When modified, a notice shall be given to NISSAN Secretariat.
It complies with the agreement between RENAULT and NISSAN in June 2004.
2. INTRODUCTION
This document is historically based on the following international standards :
- ISO 14230 - 3 : “Keyword Protocol 2000 - Part 3 : application layer,
- ISO/DIS 14229-1 : Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification
and requirements,
- ISO/DIS 15765-3: Road vehicles — Diagnostics on controller area network (CAN) — Part 3:
Implementation of unified diagnostic services (UDS on CAN),
- ISO/DIS 15031-6: Road vehicles — Communication between vehicle and external test equipment
for emissions-related diagnostics — Part 6: Diagnostic trouble code definitions,
- and [REF 1].
The document defines the diagnostic services on vehicle Electronic Control Units (ECU) to be
implemented for diagnostic testing using after-sales, assembly line and supplier and manufacturer
design/development tools.
Several choices have been made with respect to the above mentioned ISO standards; they
correspond to the requirements for RENAULT and NISSAN.
This document is a generic specification, it shall be the basis for writing ECU specific diagnostic
specifications.
For the detailed specification of services used during reprogramming refer to [REF 2] document
related to this application.
3. TERMS AND DEFINITION
RENAULT / NISSAN responsible departments for diagnostic services.
RENAULT 65676 and Nissan KR6 are responsible for the diagnostic services.
ECU
Electronic Control Unit referred to as Server in ISO documents
Diagnostic tool
System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle ECU,
referred to as Client in ISO documents.
Diagnostic service
Information exchange initiated by a diagnostic tool in order to require diagnostic information from an
ECU or/and to modify its behavior for diagnostic purpose.

RENAULT 36 - 00 - 013 / - - C
Diagnostic information
Data located in the memory of an ECU and which may be monitored and/or possibly modified by the
diagnostic tool. Two types of values are defined for Diagnostic Data :
- current value: value currently used by or resulting from the normal operation of ECU,
- stored value: internal copy of a current value made at specific moments (e.g. when a malfunction
occurs or periodically); this copy is under the control of the ECU.
Diagnostic Session
Level of diagnostic functionalities provided by the ECU.
NOTE : Defining a specific repair shop or development testing session selects different ECU
functionality (e.g. access to all memory locations may only be allowed in the development
testing session).
Diagnostic Routine
Routine that is embedded in an ECU and that may be started by an ECU upon a request from the
diagnostic tool.
NOTE : It could either run instead of a normal operating program, or could be enabled in this mode
and executed with the normal operating program. In the first case, normal operation for the
ECU is not possible. In the second case, multiple diagnostic routines may be enabled that
run while all other parts of the ECU are functioning normally.
Functional Unit
Set of functionally close or complementary diagnostic services.
4. CONVENTIONS
Refer to ISO 14229-1 standard.
5. DIAGNOSTIC SERVICES APPLICABILITY TO O.S.I. LAYER MODEL
Application Diagnostic Application

System specific document
RNDS 36 02 013 / 25953 NDS 07

Application and session Layer
Diagnostic services
Scope of this document Specification and requirements
Network Layer RNDS 36 02 031 / 25953 NDS 08
Data link Layer

RNDS 36 02 030 / 25953 NDS 06
CAN Physical Layer

RNDS 36 02 026 / 25953 NDS 04
Physical Medium
Fig. 1 Diagnostic specifications vs ISO layers

RENAULT 36 - 00 - 013 / - - C
6. APPLICATION AND SESSION LAYER
6.1. APPLICATION LAYER SERVICES
Refer to ISO 14229-1 (§ 5.).
Restriction:
ECUs must not implement any functional address other than 0x33 (OBD functional address,
corresponding to 11 bits CANId 0x7DF).
6.2. APPLICATION LAYER PROTOCOL
Refer to ISO 14229-1 (§ 6.).
Restriction:
For RENAULT and NISSAN use, the bit suppressPosRspMsgIndicationBit is always set to 0 when
defined for the service.
Whatever the value of this bit, a response (positive or negative) is always sent.
6.3. APPLICATION LAYER AND DIAGNOSTIC SESSION MANAGEMENT TIMING
Refer to § 9.1.3. and ISO 15765-3 (§ 6.3.).
Restrictions:
1/ Table 2 — Application layer timing parameter definitions for the defaultSession:
For RENAULT and NISSAN physical communication, P2CAN_SERVER max value is set to 900 ms in all
sessions (to allow ECU to send positive response without using NRC $78). P2*CAN_SERVER is not
applicable because NRC $78 is forbidden for RENAULT and NISSAN (see § 9.1.1. Negative
responses : Definitions and code table).
2/ Table 7— Tool error handling defined in § 6.3.6. (Client error handling = Tool error handling):
The maximum number of retries shall be set to 0 (no automatic retries) except for receiving Negative
response NRC=$23 and $21 detailed description refer to § 9.1.1.2. The application (diagnostic tool
software) will decide wether to retry or not.
7. NETWORK LAYER INTERFACE
Refer to [REF 1]
The ECU is able to handle only half-duplex communication. So, ECU is in receiving mode until the
reception of a request indication from the network layer. After request indication, the ECU switch to
sending mode until the response is sent by the application to the network layer.
8. STANDARDISED DIAGNOSTIC CAN IDENTIFIERS
Refer to [REF 1] and ISO 15765-3 (§ 8.).
OBD ECUs implement 0x7DF CANId. On this OBD CANId, only OBD services (services $00 to $0F)
will be used (refer to ISO 15031-5).

RENAULT 36 - 00 - 013 / - - C
9. DIAGNOSTIC SERVICES IMPLEMENTATION
The main difference with ISO15765-3 or 14229-1 is that most services are still based on preceding
version of ISO 14230-3.
Table 1 — Service implementation conventions
Name Description
M Mandatory: The service shall be implemented in any ECU as defined in this document
U User option: The choice to implement or not a service is the responsibility of the function
manager in view of the requirements expressed by his customers (development, after-sales,
manufacturer’s assembly line, etc.).
However, if the choice is made to implement a service, it shall be done as defined in this
document.
Refer to ECU specific application diagnostic document to check if a free service is to be
implemented.
Table 2 — Service parameter description conventions
Name Description
Cvt Convention: specifies whether the item is “Mandatory”, “User option” or “Conditional”
Mnem Mnemonic
Hex Value Hexadecimal value
M Mandatory
U User option (function manager’s responsibility)l
C conditional
F Forbidden
NOTE : Supplier specific items (Id definition and ranges, sessions, ...) are not supported by Renault
and Nissan tools.
9.1. DIAGNOSTIC SERVICES OVERVIEW
Table 3 — Diagnostics on CAN -– Diagnostic services overview
Cvt. Diagnostic service name Service Id sub- suppressPosRspMsgIn Sect.

(*ISO 14229-1 definition) (Hex Value) function dicationBit = TRUE ('1') n°
supported (no response)
supported1)
Diagnostic and Communication Management Functional Unit
M StartDiagnosticSession $10 - N/A 9.2.1
U ECUReset $11 - N/A 9.2.2
U SecurityAccess $27 - N/A 9.2.3
U CommunicationControl $28 yes no 9.2.4
M TesterPresent $3E - N/A 0
Data Transmission Functional Unit
M ReadDataByLocalIdentifier $21 - N/A 9.3.1
1) It is implied that the tool always set suppressPosRspMsgIndicationBit to FALSE ('0'). The ECUs shall always send a
response (positive or negative) whatever the value of this bit.

RENAULT 36 - 00 - 013 / - - C
Table 3 — Diagnostics on CAN -– Diagnostic services overview
Cvt. Diagnostic service name Service Id sub- suppressPosRspMsgIn Sect.

(*ISO 14229-1 definition) (Hex Value) function dicationBit = TRUE ('1') n°
supported (no response)
1)
supported
Data Transmission Functional Unit
U ReadDataByIdentifier* $22 - N/A 9.3.2
U ReadMemoryByAddress* $23 - N/A 9.3.3
U ReadScalingDataByIdentifier* $24 - N/A 9.3.4
U DynamicallyDefineLocalIdentifier $2C - N/A 9.3.5
M/U WriteDataByLocalIdentifier $3B - N/A 9.3.6
U WriteDataByIdentifier* $2E - N/A 9.3.7
U WriteMemoryByAddress* $3D - N/A 9.3.8
Stored Data Transmission Functional Unit
M ClearDiagnosticInformation* $14 - N/A 9.4.1
M ReadDTCInformation* $19 yes no 9.4.2
Input/Output Control Functional Unit
U InputOutputControlByLocaldentifier $30 - N/A 9.5.1
Remote Activation Of Routine Functional Unit
U StartRoutineByLocalIdentifier $31 - N/A 9.6.1
U StopRoutineByLocalIdentifier $32 - N/A 9.6.2
Upload/Download Functional Unit
U RequestDownload $34 - N/A 9.7.1
U RequestUpload $35 - N/A 9.7.2
U TransferData $36 - N/A 9.7.3
U RequestTransferExit $37 - N/A 9.7.4
M/U: Mandatory for RENAULT applications (see § 9.3.6.2.3.), System dependant for NISSAN only
applications.
All the services described in the ISO standards are not necessarily implemented. This section provides
a short definition of diagnostic services chosen by RENAULT and NISSAN.
StartDiagnosticSession
The purpose of this service is to allow the tool to switch the ECU into a diagnostic session. A
diagnostic session is a specific operating mode (e.g. Extended Diagnostic session, Reprogramming
session and etc).
ECUReset
This service enables the tool to force the ECU to perform a reset, e.g. a power on reset or to allow a
new default parameter set to become active. The type of reset which is performed is up to the system.
SecurityAccess
The purpose of this service is to allow access to restricted information from the ECU. Proper unlocking
of the ECU is a prerequisite to the tool’s ability to perform some of the more critical functions, such as
deletion or downloading routines in the ECU memory.

RENAULT 36 - 00 - 013 / - - C
CommunicationControl
The purpose of this service is to switch on/off the transmission and/or the reception of certain
messages of an ECU (e.g. application communication messages).
TesterPresent
This service has no action other than to prevent the ECU to automatically return to default session.
ReadDataByLocalIdentifier
The ReadDataByIdentifier service allows the tool to request predefined data record values from the
ECU identified by one LocalIdentifiers. To implement this service is mandatory for keeping
compatibility with current diagnostic tool software.
ReadDataByIdentifier
The ReadDataByIdentifier service allows the tool to request predefined data record values from the
ECU identified by one or more dataIdentifiers. This service ensures compatibility with ISO14229-1.
ReadMemoryByAddress
The purpose of this service is to request, in a single response, the content of a memory area. The
address and the size of the memory area to be read are parameters defined.
ReadScalingDataByIdentifier
The ReadScalingDataByIdentifier service allows the tool to request scaling data record information
from the ECU identified by one or more dataIdentifiers. This service ensures compatibility with
ISO14229-1.
DynamicallyDefineLocalIdentifier
This service shall be used to dynamically define local identifier that may be requested by
ReadDataByLocalIdentifier service. In a single request, several or all data fields of Dynamically
defined Local Identifier may be defined each one by using memory locations or a selected data field of
already existing Local Identifiers.
WriteDataByIdentifier
The WriteDataByIdentifier service allows the tool to change predefined data record values in the ECU
identified by one Identifier. This service ensures compatibility with ISO14229-1.
WriteDataByLocalIdentifier
The purpose of this service is to provide a means for the tool to change the contents of Record Local
Identifier memory locations of the ECU. The Record Local Identifier and associated memory locations
need to be known by the ECU. This service does not allow the tool to change any locations other than
those predefined in the ECU. The number of data bytes included in each Record Local Identifier
depends on the system designer and intent of the usage for that record. The reason why this service is
maintained is that it is used by current Renault / Nissan tools.
WriteMemoryByAddress
The purpose of this service is to overwrite or to set the content of a predefined memory area. The
address, the memory area size and the data to be written are parameters defined.
ClearDiagnosticInformation
The purpose of this service is to provide a means for the tool to command an ECU to clear stored
diagnostic information (including diagnostic CAN fault counters), trouble codes and SnapShotData.

RENAULT 36 - 00 - 013 / - - C
ReadDTCInformation
The purpose of this service is to read from the ECU the number, values and status of stored diagnostic
trouble codes. This service is also used by the tool to access to data values which were stored as a
SnapShotData called Freeze Frame Data in old document and some extended data that contains
helpful information for diagnosis. This service ensures compatibility with ISO14229-1.
InputOutputControlByLocalIdentifier
The purpose of this service is to request the control of an input or output peripheral of the ECU.
StartRoutineByLocalIdentifier
The purpose of this service is to request the start or the status of the execution of a routine which is
resident in an ECU.
StopRoutineByLocalIdentifier
The purpose of this service is to request the stop of the execution of a routine which is resident in an
ECU.
RequestDownload
This service can be used by reprogramming application. However applicability of using this service is
defined by reprogramming specification [REF2].
RequestUpload
TransferData
RequestTransferExit
9.1.1. Negative responses : Definitions and code table
9.1.1.1. Negative response implementation
A negative response may be transmitted by an ECU for replying to any service request that cannot be
acknowledged or when the ECU is not able to completely perform the requested actions.
The failure reason is indicated by the value of the negative response code (NRC_). All possible values
of the NRC code are defined in § 9.1.1.2.
The minimum conditions whereby an ECU will send a negative response are as follows :
- the tool request has been correctly received by the ECU,
- the service requested by the tool cannot be acknowledged.

RENAULT 36 - 00 - 013 / - - C
Table 4 — The negative response message
A_Data Message parameter name Cvt Hex_Value Mnem.

Byte
#1 Negative response M $7F NACK
#2 Code of service received by the ECU M --- SID
#3 Negative response code M $xx NRC
The negative response identifier code is $7F mandatory followed by the service identifier of the
request received and by the negative response code indicating the failure reason.
9.1.1.2. Definition of supported negative response Code (NRC_)
The table below lists and gives the general definition of all the negative response codes authorized by
the tools used in engineering department, plants and after-sales servicing for RENAULT and NISSAN.
Table 5 — The negative response Codes

Value Negative response codes Mnem
$11 ServiceNotSupported SNS
This response code indicates that the requested service is not supported by
the ECU.
$12 SubFunctionNotSupported-InvalidFormat SFNS
This response code indicates that the requested service is supported by the
ECU, however the request has been badly formulated by the tool (bad or off-
limit parameters).
$21 Busy-RepeatRequest BRR
This response code indicates that the ECU is temporarily too busy to
perform the requested operation and the requested service has not been
started. When receiving this response code, the tool may repeat the same
request message or send another request message.
The ECU has understood the request, however the previous request is still
being executed.
Example: EEPROM read request whereas the previous request, an
EEPROM write request, has not yet been terminated.
For detailed explanation on how $21 shall be used, refer to § 9.1.2.
Processing long execution time.
$22 ConditionsNotCorrect CNC
This response code indicates that the current operating conditions of the
ECU do not allow for (or do not authorize) the execution of the request, or
sequence requests are issued in the wrong order.
NB : This negative response code is for example used when the vehicle
protection function is active.
$23 RoutineNotComplete RNC
This response code indicates that the request message was properly
received by the ECU and the service is in progress, but not yet
completed. In case the tool repeats the same request message, the ECU
does not reinitiate the task if the initial task is not yet completed.
For detailed explanation on how $23 shall be used, refer to § 9.1.2.
Processing long execution time.

RENAULT 36 - 00 - 013 / - - C
Table 5 — The negative response Codes

Value Negative response codes Mnem
$33 SecurityAccessDenied SAD
This response code indicates that the requested action will not be taken
because the ECUs security strategy has not been satisfied by the tool: The
requested action requires an unlocked ECU.
Beside the mandatory use of this negative response code as specified in the
applicable services within this standard, 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.
$35 InvalidKey IK
This negative response code is used by the SecurityAccess service if the
ECU receives a key other than the key it has computed internally.
$37 requiredTimeDelayNotExpired RTDNE
because the client's latest attempt to gain security access was initiated
before the server's required timeout period had elapsed.
$72 generalProgrammingFailure GPF
This response code indicates that the ECUI detected an error when erasing
or programming a memory location in the permanent memory device (e.g.
Flash Memory).
$7E SubFunctionNotSupportedInActiveSession SFNSIAS
because the ECU does not support the requested sub-function in the
session currently active.
$7F ServiceNotSupportedInActiveSession SNSIAS
because the ECU does not support the requested service in the session
currently active.
IMPORTANT NOTICE: The NRC $78 IS NOT supported by ANY of the Tools in use at RENAULT
and NISSAN, therefore it shall NEVER be sent by an ECU. Refer to § 9.1.2.2. for additional
information.
For NRC management when in BOOT mode refer to [REF 2] document.
9.1.2. Processing long execution time service
9.1.2.1. Definition of a long execution time service
A service is long if the Response cannot be sent within the P2CAN_SERVER timing, set to 900 ms (the
service execution time exceeds P2CAN_SERVER timing).
e.g. For reading services, an ECU will have to send a positive response to the tool as soon as data
requested by the tool are ready which might take some time: the performance timing to calculate data
will have to be as short as possible.
e.g. For writing services (WriteDataByLocalIdentifier, ECUReset, WriteMemoryByAddress), an ECU

will have to send a positive response to the tool as soon as data sent by the tool are actually written
which might take some time specially with EEPROM : the performance timing to write data will have to
be as short as possible.
Whatever the service, the ECU shall start transmitting a response before the end of P2CAN_SERVER
timing (starting at the end of the request). Even when processing a long execution request, an ECU

RENAULT 36 - 00 - 013 / - - C
shall manage diagnostic request on CAN. The only exception to this rule being reprogrammable ECUs
erasing their flash memory for reprogramming purposes (for more details ref to [REF 2] document).
In some restricted special cases (ex flash erasing), ECU are not able to handle diagnostic on CAN
(only for hardware reasons linked to the service). These cases shall be submitted for approval to
Renault / Nissan responsible departments for diagnostic services.

RENAULT 36 - 00 - 013 / - - C
For each request (Sid and parameters values) that could require long execution time, the rationale for
exceeding P2CAN_SERVER shall be documented by Ecu responsible/supplier and submitted to Renault /
Nissan responsible departments for diagnostic services.
These departments may refuse long execution time for performance reasons.
Examples of implementation to speed up service execution:
- for services using memory writing, the ECU could compare the present state of the memory with
the values to be written. If the values are identical, the ECU will respond positively to the service
without writing,
- for ClearDiagnosticInformation service, refer to § 9.4.1.
9.1.2.2. ECU Behavior during long execution time service
The negative response code $78 shall not be used. Instead, the ECU will send temporary response(s)
with NRC $23 and $21 while the request is being processed according to the following state diagram
(see Fig 2).
When the service execution is complete, the ECU will send the final response for the service request.
This final response is the one which will be referred to as “the response” in all diagnostic specification
documents (this document and all related system specific diagnostic specifications) for all services.
Request reception
Start P2CAN_SERVER
Stop S3SERVER Service
Idle in progress
Processing done
Stop P2CAN_SERVER
Start S3SERVER
S3SERVER
Same request received Send final response
elapsed
Start S3SERVER
Send final response
Different request received

Stop S3SERVER
Start P2CAN_SERVER Same Request received
Start P2CAN_SERVER
Final response not sent
Busy P2CAN_SERVER elapsed

Send $23 or $21
Depending on LongService
Processing done Different Request received

Start S3SERVER Send NRC $21
Fig. 2 Management of long execution time services within ECU
A more detailed description is also available in § 9.1.3.1.

RENAULT 36 - 00 - 013 / - - C
9.1.3. General diagnostic service implementation rules
As a general rule, the service management can be split in 2 different processes described in following
figure 3:
- service communication management interfacing to the network layer, managing the requests and
responses as well as timers (P2CAN_SERVER and S3SERVER),
- service processing executing the service and returning response data.

Network layer
REQUEST Launch service

Service Service
Communication processing
management
RESPONSE Service processing done
ECU SERVICE MANAGEMENT
Fig. 3 — ECU service Management
The two process are detailed below.
9.1.3.1. Service communication management process
As defined in § 9.1.1.2. the service communication management is based on 4 states:
Table 6 — States of Communication Management

State Status
Idle The ECU is ready to process any new request
Service in progress The resquested service is in progress, the Service communication management
process is waiting for the feedback of the service processing unit.
Busy The feedback from the service processing unit has not been received within the
P2CAN_server timing requirement.
Final response Not sent The feedback from the service processing unit is received while the process is in
Busy state.
The process behaviour is detailed on the flowcharts figure 4 to 7 Starting from the reception of a
request from the tool.

RENAULT 36 - 00 - 013 / - - C
Idle
pending request Request reception S3SERVER elapsed
Clear pendingRequest
Go to default session
Idle
Stop S3SERVER
Start P2CAN_SERVER
Service ID NO
Set NRC = $11
known by ECU?
YES
NO Service has YES

subFunction?
Service allowed in NO
Set NRC = $7F
active session?
YES
NO
Sub Function Set NRC = $12
supported?
YES
Sub Function supported NO Set NRC = $7E

in active session?
YES
Memorize service & Stop P2CAN_SERVER

parameters
LongService = false
Send negative response
Launch Service Start S3SERVER
Service in progress Idle
Fig. 4 — Service Communication management 1/4

RENAULT 36 - 00 - 013 / - - C
Service in progress
Service Processing done P2CAN_SERVER
Stop P2CAN_SERVER false

true
LongService ?
Forget memorized service

and parameters
Set NRC = $21 Set NRC = $23
Send stored response
LongService = true
Start S3server
Idle
BUSY
Fig. 5— Service Communication management 2/4
BUSY
Service Processing done Request reception
NO
Start S3server
Same request and Set NRC = $21
parameters?
YES

Start P2CAN_SERVER
Final response not sent Service in Progress BUSY

RENAULT 36 - 00 - 013 / - - C
Final response not sent
Request reception S3 timer elapsed
NO
Same request and Go to default session
parameters?
YES
Idle
Forget memorized service Forget memorized service
and parameters and parameters
Send stored response set pendingRequest
Start S3server
Idle
P2CAN_SERVER shall be set to 900 ms independently from the duration time of the execution of a service
which has to be as fast as possible (for performance requirement).
“Busy” means that the ECU is not able to process any new request.

RENAULT 36 - 00 - 013 / - - C
9.1.3.2. Service processing
The behaviour of the service processing entity is detailed below:
Idle
Launch service
NO
Service parameters Set NRC = $12
OK?
YES
Unlocking
NO required ?
YES
NO
ECU unlocked? Set NRC = $33
YES
NO
Conditions met? Set NRC = $22
For reprog ECU
YES
StartDiagSession YES
For repro ECU
for Reprogram?
NO Stop service execution

Application
Jump to loader YES

Application Error? Set NRC = $35 or $72
NO
Set Positive response
Service processing done
Idle
Fig. 8 — Service processing
For detailed meaning of “conditions met” and “application error”, refer to each service description.
Function manager will have to describe all those specific conditions for each service.

RENAULT 36 - 00 - 013 / - - C
9.1.4. Restrictions on concurrent services
The restrictions on the possible execution of a service when an IOControl or a routine is in progress
shall be detailed in the system specific diagnostic specification both in the definition of the IOControl or
routine currently in progress and in the description of the executing conditions of the requested
service. If the service cannot be executed, then a negative response with NRC = $22 shall be sent by
the ECU.
9.1.4.1. Example for a Request occurring while an IOControl is in progress
tool ECU
Request message A
ICOBLID:
$30$xx$20$yy
$70$xx$01$yy
Request message B
control is in progress
Response *1
*1 Refer to following
tables
Fig. 9 — Request occurring while an IOControl is in progress
Table 7 — ECU Behaviour while an IOControl is in progress

Request message
Response from ECU
Service IOLID CRTLOPT1 CRTLOPTi
$30 In progress Start permanent control Same Options $70 $xx $01
$30 In progress Start permanent control Other Options *2
$30 In progress Start temporary control - *2
$30 In progress Status request - $70 $xx $01
$30 In progress Stop control - $70 $xx $11
$30 Not in progress - - *3
Not $30 - *4
*2 Behaviour is system or IOLocalID dependant and shall be defined by the function manager in the
system specific diagnostic specification. Response shall be either a positive response
“$70 $xx $01” or a negative response with NRC = $22.
*3 Whether other IOLocalID’s IOControl services are accepted during IOControl processing is
defined by the function manager. Restrictions on use of simultaneous Local ID’s I/O control shall
be detailed in the system specific diagnostic specification. Response shall be either a positive
response “$70 $xx $01” or a negative response with NRC = $22. It is the responsibility of the tool
to wait for first IOControl completion before starting a new IOControl.
*4 Whether other services are accepted during IOControl processing is defined by the function
manager. Restrictions shall be detailed both in the IOControl definition and in the description of
the new requested service of the system specific diagnostic specification. Response shall be
either a positive response corrresponding to the new requested service or a negative response
with NRC = $22.

RENAULT 36 - 00 - 013 / - - C
9.1.4.2. Example for a Request occurring while a routine is in progress
tool ECU
Request message A
SRBLID:$31$xx$00$yy
$71$xx$01$yy
Routine in
progress
Request message B
Response *1
*1 Refer to following tables
Fig. 10 — Request occurring while a routine is in progress
Table 8 — ECU behaviour while a (Start) Routine is in progress

Request message
Response from ECU
SRBLID=$31 RLOCID RENTOPT1 RENTOPTi
Perform Routine requested
$31 In progress Same options $71 $xx $01
Perform Routine requested

$31 In progress Other options *2
Status Request
$31 In progress - $71 $xx $01
$31 Not In progress - - *3

Not $31 - *4
Table 9 — ECU behaviour while a (stop) Routine is in progress

Request message
Response from ECU
SPRBLID=$32 RLOCID REXITOPTi
$32 In progress x $72 $xx $02
$32 Not In progress - *3
Not $32 - *4
-: not applicable
*2 Behaviour is system or RLOCID dependant and shall be defined by the function manager in the
system specific diagnostic specification. Response shall be either a positive response
“$71 $xx $01” or a negative response with NRC = $22.
*3 Whether other RLOCID services are accepted during routine processing is defined by the function
manager. Restrictions on use of simultaneous RLOCID services shall be detailed in the system
specific diagnostic specification. Response shall be either a positive response “$71 $xx $01” or
“$72 $xx $yy” (depending on the requested service) or a negative response with NRC = $22. It is
the responsibility of the tool to wait for first routine completion before starting a new routine.
*4 Whether other services are accepted during routine processing is defined by the function
manager. Restrictions shall be detailed both in the routine definition and in the description of the
new requested service of the system specific diagnostic specification. Response shall be either a
positive response corrresponding to the new requested service or a negative response with
NRC = $22.

RENAULT 36 - 00 - 013 / - - C
9.1.5. Getting Identifiers supported by the ECU
9.1.5.1. Read of supported LocalIdentifiers

Concerned Services : ReadDataByLocalIdentifier
InputOutputControlByLocalIdentifier
StartRoutineByLocalIdentifier
StopRoutineByLocalIdentifier
WriteDataByLocalIdentifier
Services listed above use as parameter an identifier related to the data to be processed. This
parameter called “LocalIdentifier” organizes data frame according to specific use (standard, supplier,
system specific, ...).
The range [$00 - $7F] is assigned to the ECU specific “localIdentifier”. All values are not implemented.
To get the list of specific LocalIdentifiers (LId) used in the range [$00 - $7F] the test equipment shall
request reserved localIdentifier indicating by a bit coding which LIds are supported by the ECU.
Reserved LIds are $20, $40 and $60.
9.1.5.1.1.Request Implementation
Table 10 — Request message definition
A_Data Byte Service and Parameter Hex Value
#1 Service request $21, $30, $31, $32, $3B *
#2 Lid $00, $20, $40, $60
* $30, $31, $32 $3B ==> Not applicable for Renault ECU. Applicable for Nissan ECU & common R/N
ECU"
9.1.5.1.2.Positive response Implementation

Table 11 — Positive response message definition
#1 Service Response $61, $70, $71, $72, $7B
#2 Lid $00, $20, $40, $60
#3 .. #6 data A, data B, data C, data D $xx / $xx / $xx / $xx
Table 12 —Data organization inside the response

Requested LId Data A - B - C - D Corresponding LId bit value
$00 Data A bit 7 01
Data A bit 6 02 0 = LId not supported
: : 1 = LId supported
Data D bit 1 1F
Data D bit 0* 20
$20 Data A bit 7 21
Data D bit 1 3F
Data D bit 0* 40

RENAULT 36 - 00 - 013 / - - C

$40 Data A bit 7 41
Data D bit 1 5F
Data D bit 0* 60

RENAULT 36 - 00 - 013 / - - C

$60 Data A bit 7 61
Data D bit 1 7F
Data D bit 0 set to 0 N/A
* Bit 0 of Data D indicates that there are additional non reserved LIds supported in an upper range.
The tool shall request the corresponding reserved LId ($20 or $40 or $60) to receive the supported
remaining Lids.
The external test equipment shall only request reserved LIds $20, $40 and $60 if bit 0 of Data D in the
previous “Supported LId” response message is set to ‘1’.
Bit 0 of Data D linked to the reserved LId = $80 shall always be set to 0 because this LId is not used
for system specific data, it has a standard definition.
9.1.5.2. Read of supported Identifier
Concerned Services : ReadDataByIdentifier
To get the list of identifiers used in the range [$1000 - $1FFF] the test equipment shall request
reserved Id indicating by a bit coding which Ids are supported by the ECU.
Reserved Ids are $1x00, $1x20, $1x40 $1x60, $1x80, $1xA0, $1xC0 and $1xE0 where x may be a
value from $1 to $F.
9.1.5.2.1.Request Implementation
A_Data Byte Service and Parameter Hexa value
#1 Service request $22
#2 Id High Byte $1x
#3 Id Low Byte $00, $20, $40 $60, $80, $A0, $C0,
$E0
9.1.5.2.2.Positive response Implementation

A_Data byte Service and Parameters Hexa value
#1 Service response $62
#2 Id High Byte $1x
#3 Id Low Byte $00, $20, $40 $60, $80, $A0, $C0,
$E0
#4 .. #7 data A, data B, data C, data D $xx / $xx / $xx / $xx

RENAULT 36 - 00 - 013 / - - C
Table 15 — Data organization inside the response

Requested Id Data A - B - C - D Corresponding Id Bit value
$1x00 Data A bit 7 $1x01
Data A bit 6 $1x02 0 = Id not supported
: : 1 = Id supported
Data D bit 1 $1x1F
Data D bit 0* $1x20
Data D bit 1 $1x3F
Data D bit 0* $1x40
Data D bit 1 $1x5F
Data D bit 0* $1x60
... ... ... ...
$1xC0 Data A bit 7 $1xC1
Data A bit 6 $1xC2 0 = Id not supported
Data D bit 1 $1xDF
Data D bit 0* $1xE0
$1xE0 Data A bit 7 $1xE1
Data A bit 6 $1xE2 0 = Id not supported
Data D bit 1 $1xFF
Data D bit 0 set to 0 N/A2
* Bit 0 of Data D indicates that there are additional non reserved Ids supported in an upper range. The
tool shall request the corresponding Id low byte ($20 or $40 or $60, ..., $E0 ) to receive the remaining
supported Ids.
When bit 0 of Data D is set to 0 in an Id range, there is no need for the external test equipment to
request Ids in the next following range with the same high byte. In that case, if the tool requests these
Ids, the ECU will return a negative response with NRC $12.
9.1.5.3. Application example
In the example hereafter the test equipment requests ECU #1 the list of supported Lids for the
WriteDataByLocalIdentifier service and requests ECU#2 the list of supported Lids for
I/OControlByLocalIdentifier service.
Step 1 : Request supported LIDs by ECU #1
The external test equipment requests supported LIds (LIds = $00) from the ECU#1.
#1 Request current Lids for WriteDataByLocalIdentifier service $3B
#2 Reserved LId used to determine LIds support for LIds $01-$20 $00
2 All Id Ranges 1x00-1xFF, are independent and not linked

RENAULT 36 - 00 - 013 / - - C

#1 Request current Lids for WriteDataByLocalIdentifier $7B
service
#2 LId requested $00
#3 Data byte A, representing support for LId $01 10000000b = $80
#4 Data byte B, representing support for LId $0D 00001000b = $08
#5 Data byte C, representing no support for LIds $11-$18 00000000b = $00
#6 Data byte D, representing no support for LIds $19-$20 00000000b = $00
The ECU#1 sends back the response corresponding to LIds from the range [$01 - $20].
The ECU #1 supports the following LIds: $01 and $0D.
ECU #1 indicates with the response message that it does not support LId $20, so the external test
equipment has not to send another request, it has got all supported LId by ECU #1.
Step 2 : Request supported LIds by ECU #2
The external test equipment requests supported LIds (LId = $00) from the ECU#2.
#1 Request current Lids for I/OControlByLocalIdentifier $30

#2 LId requested $00
#3 Data byte A, representing support for LIds $01, $03, $08 10100001b = $A1
#4 Data byte B, representing support for LIds $09, $0C, $0F, $10 10010011b = $93
#5 Data byte C, representing support for LIds $11, $13, $15 10101000b = $A8
#6 Data byte D, representing support for LIds $1A, $1C, $20 01010001b = $51
The ECU#2 send back the response corresponding to LIds from the range [$01 - $20].
The ECU #2 supports the LIDs: $01, $03, $08, $09, $0C, $0F, $10, $11, $13, $15, $1A, $1C, and $20.
ECU #2 indicates with the response message that it supports LId $20, so the external test equipment
has to send another request to know which LId are supported by ECU #2.
The external test equipment requests supported LIds (LId = $20) from the ECU#2.

RENAULT 36 - 00 - 013 / - - C

A_Data Byte Service and Parameter Byte Value (Hex)

A_Data Byte Description (all values are in hexadecimal) Byte Value (Hex)
#2 LID requested $20
#3 Data byte A, representing support for LID 21 10000000b = $80
#4 Data byte B, representing no support for LIDs 29-30 00000000b = $00
#5 Data byte C, representing no support for LIDs 31-38 00000000b = $00
#6 Data byte D, representing no support for LIDs 39-40 00000000b = $00
The ECU#2 send back the response corresponding to LIds from the range [$21 - $40].
The ECU #2 supports also the LId $21.
ECU #2 indicates with the response message that it does not support LId $40, so the external test
equipment has not to send another request, it has got all supported LId by ECU #2.

RENAULT 36 - 00 - 013 / - - C
9.2. DIAGNOSTIC AND COMMUNICATION CONTROL FUNCTIONAL UNIT
9.2.1. $10 - StartDiagnosticSession Service
9.2.1.1. Service description
The StartDiagnosticSession service is used to enable different diagnostic sessions in the ECU(s).
A diagnostic session enables a specific set of diagnostic services and/or functionality in the ECU(s).
The function manager defines in the ECU specific application diagnostic document the exact set of
services and/or functionality enabled in each diagnostic session (superset of functionality that is
available in the defaultSession) The diagnostic functionality of the defaultSession shall also be
available when switching to any non-default diagnostic session (except for reprogramming session).
There shall always be exactly one diagnostic session active in an ECU at a time. An ECU shall always
start the default diagnostic session when powered up. If no other diagnostic session is started, then
the default diagnostic session shall be running as long as the ECU is powered and the ECU shall be
in locked state.
An ECU shall be capable of providing diagnostic functionality under normal operating

conditions and in other operation conditions defined by the vehicle manufacturer, e.g. limp
home operation condition.
If the tool has requested a diagnostic session, which is already running, then the ECU shall send a
positive response message and behave as shown in Fig. 11 — ECU diagnostic session state diagram
that describes the ECU internal behaviour when transitioning between sessions.
While processing the service, the ECU remains in the previous session and will enter the new session
upon transmission of a positive response.
To start a new diagnostic session an ECU may request that certain conditions be fulfilled. All such
conditions are user defined and specified in application specific diagnostic document. The access
requirements to each diagnostic session shall be defined by the user of this diagnostic session and
submitted to Renault / Nissan responsible departments for diagnostic services for information. . Once
in the new diagnostic session, any change in this preconditions shall not cause the ECU to exit this
session; if security or safety issues are at stake, the ECU may subsequently restrict access to internal
diagnostic resources, normally available in the session, by returning an appropriate NRC code
(typically $22) when the resources are addressed by the tool. Some applicative functions may also be
inhibited and the vehicle user notified through a dedicated message or warning indicator. Such
limitations shall be detailed on a per resource basis (data or service) in the system specific diagnostic
specification.
Fig. 11 — ECU diagnostic session state diagram provides an overview about the diagnostic session
transition and what the ECU shall do when it transitions to another session.
o th e r sessio n
(2 )
de fa u lt se ssio n sa m e o r o th e r se ssio n
any
d e fa u lt
(1 ) o th e r (3 )
s es s io n
s e ss io n
(4 )
d efa u lt se ssio n
Fig. 11 — ECU diagnostic session state diagram

RENAULT 36 - 00 - 013 / - - C
Diagnostic session transition description:
1) When the ECU is in the defaultSession and the tool requests to start the defaultSession then the
ECU shall re-initialize the defaultSession completely, which means that e.g. each DDLID
(DynamicallyDefineLocalIdentifier) shall be reset. The ECU shall reset all
activated/initiated/changed settings/controls during the activated session. This does not include
long term changes programmed into non-volatile memory.
2) When the ECU transitions from the defaultSession to any other session than the defaultSession
then the ECU shall initialize the diagnostic session, which means e.g. each DDLID shall be reset
and security shall be enabled (go to locked state).
3) When the ECU transitions from any diagnostic session other than the defaultSession to another
session other than the defaultSession (including the currently active diagnostic session) then the
ECU shall (re-) initialize the diagnostic session, which means that e.g. each DDLID shall be reset
and security shall be enabled (go to locked state).
4) When the ECU transitions from any diagnostic session other than the default session to the
defaultSession then the ECU shall (re-) initialize the default session, which means that e.g. each
DDLID shall be reset and security shall be enabled (go to locked state). The ECU shall reset all
activated/initiated/changed settings/controls during the current session. This does not include
long term changes programmed into non-volatile memory.
Changing session during routine execution.
Unless otherwise specified on a per routine basis, the following behavior applies: when a routine is in
progress and a new session (different from the active session) is required by the tool, the ECU service
processing shall wait the completion of the routine(s). If the ECU can’t complete the routine before
P2CAN_SERVER, it has to respond negatively to the StartDiagnosticSession request according to § 9.1.3.
The change of session will be effective after the routine is completed.
In application mode, no ECU reset is allowed when going back to default session (for boot mode
behavior, ref to [REF 2] document). The nominal operating conditions shall be restored when going
back to default session.
For OBD related ECU no accessibility limitation for OBD services is required whatever the active
session.
When a specific supplier diagnostic session is started, all CAN identifiers used for the supplier needs
shall be allowed by Renault and Nissan.
Table 22 shows the services, which are allowed (x) during the defaultSession and the non-
defaultSession (timed services). Any non-defaultSession is tied to a diagnostic session timer that has
to be kept active by the tool. With the exception of the expiration of the diagnostic session timer (see
§9.1.3.1 Service communication management process), an ECU shall never leave an active non
default session by itself : the only way to return to the default session when the tool is connected and
in communication with the ECU is performed through the StartDiagnosticSession.

RENAULT 36 - 00 - 013 / - - C
Table 22 — Services allowed during default and non-default diagnostic session

Service defaultSession non-defaultSession
1)
Secured dataIdentifiers require a SecurityAccess service and therefore a non-default diagnostic session.
2)
Secured memory areas require a SecurityAccess service and therefore a non-default diagnostic session.
3)
A dataIdentifier can be defined dynamically in the default and non-default diagnostic session.
4)
Secured routines require a SecurityAccess service and therefore a non-default diagnostic session. A routine that
requires to be stopped actively by the tool also requires a non-default session.
StartDiagnosticSession - $10 hex x x
ECUReset - $11 hex x x
SecurityAccess - $27 hex - x
TesterPresent - $3E hex x x
CommunicationControl - $28 hex - x
1)
ReadDataByLocalIdentifier – $21 hex X x
1)
ReadDataByIdentifier - $22 hex X x
2)
ReadMemoryByAddress - $23 hex X x
1)
ReadScalingDataByIdentifier - $24 hex X x
3)
DynamicallyDefineLocalIdentifier - $2C hex X x
1)
WriteDataByLocalIdentifier – $3B hex X x
1)
WriteDataByIdentifier - $2E hex X x
2)
WriteMemoryByAddress - $3D hex X x
ClearDiagnosticInformation - $14 hex X x
ReadDTCInformation - $19 hex X x
InputOutputControlByLocalIdentifier - $30 hex - x
4)
StartRoutineByLocalIdentifier - $31 hex X x
4)
StopRoutineByLocalIdentifier - $32 hex X x
RequestDownload - $34 hex - x
RequestUpload - $35 hex - x
TransferData – $36 hex - x
RequestTransferExit – $37 hex - x
”Allowed” in this context does not mean the implementation is mandatory; it is up to the system designer to
decide whether an “allowed” service is permitted or not in a session.. If a service is allowed in any session
but some parameters (LID or DID) or sub functions are restricted to some specific sessions, the ECU shall
respond with the appropriate NRC (typically $22 for LID or DID and $7E for sub functions) when these
parameters are addressed in the wrong session. Such restrictions are to be detailed in the sytem specific
diagnostic service specification on a per service or parameter basis.

RENAULT 36 - 00 - 013 / - - C
9.2.1.2. Request message
9.2.1.2.1.Request message definition

A_Data byte Parameter Name Cvt Hex Value Mnem
#1 StartDiagnosticSession Request Service Id M $10 SDS
#2 diagnosticSessionType M $00-$FF DIAGMODE
9.2.1.2.2.Request message sub-function parameter $Level (LEV_) Definition
This service does not use a sub-function parameter.

RENAULT 36 - 00 - 013 / - - C
9.2.1.2.3.Request message data parameter definition
The parameter diagnosticSessionType is used by the StartDiagnosticSession service to select the

specific behavior of the ECU. Explanations and usage of the possible diagnostic sessions are detailed
below.
Table 24 — Request message diagnosticSessionType parameter definition

Hex Description Cvt Mnem
$00 – $80 reserved M RESRVD
$82 – $84
$C1 - $EF
These values are reserved by this document.
$81 defaultSession M DS
This diagnostic session enables the default diagnostic session in the
ECU(s) and does not support any diagnostic session timeout handling
provisions (e.g. no TesterPresent service is necessary to keep the
session active).
$85 programmingSession U PRGS
This diagnosticSession enables all diagnostic services required to support
the memory programming of an ECU (ref to [REF 2] for detailed
specification)
$86 developmentMode U DM
to be defined by the function manager
$87 – $BF manufacturerMode U MM
to be defined by the function manager including reprogramming sessions
$C0 extendedDiagnosticSession M EXTDS
This diagnosticSession can e.g. be used to enable all diagnostic services
required to support the adjustment of functions like "Idle Speed, CO
Value, etc." in the ECUs memory. It can also be used to enable diagnostic
services, which are not specifically tied to the adjustment of functions.
$F0 – $FF systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.

RENAULT 36 - 00 - 013 / - - C
9.2.1.3. Positive response message
9.2.1.3.1.Positive response message definition

#1 StartDiagnosticSession Response Service Id M $50 SDSPR
#2 diagnosticSessionType M $00-$FF DIAGMODE
9.2.1.3.2.Positive response message data parameter definition
The following parameter is used for this service.

Table 26 — Response message data parameter definition
Definition
diagnosticSessionType
This parameter is an echo of the parameter from the request message.
9.2.1.4. Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances
under which each response code would occur are documented in Table 27.
Table 27 — Supported negative response codes

$12 SubFunctionNotSupported-InvalidFormat M SFNS

Send if the parameter in the request message is not supported
$22 conditionsNotCorrect M CNC
This code shall be returned if the criteria for the request
StartDiagnosticSession are not met.
$21 Busy-RepeatRequest M BRR
This NRC is applicable only to long execution time services, see
§ 9.1.2.2.
$23 RoutineNotComplete M RNC
This NRC is applicable only to long execution time services, see
§ 9.1.2.2.

RENAULT 36 - 00 - 013 / - - C
9.2.2. $11 - ECUReset service
ONLY USED IF ALL RELATED INTER-SYSTEMS ISSUES HAVE BEEN CLEARLY IDENTIFIED AND
SORTED OUT (SOLVED).
The EcuReset service is used by the tool to request an ECU reset.
This service requests the ECU to effectively perform an ECU reset based on the content of the
resetType parameter value embedded in the ECUReset request message. The ECUReset positive
response message shall be sent before the reset is executed in the ECU(s).
After a successful ECU reset with resetType parameter set hardReset or softReset, the ECU shall
activate the defaultSession.
When receiving this service, the ECU shall first check if the requested reset can be performed in
present conditions.
This service allows to reset the teach-ins. When the value $FF is used, it shall imply the cancellation of
all teach-ins executed. Depending on the needs, the function manager may define other parameter
values allowing a reset for each type of implemented teach-ins.

#1 EcuReset Request Service Id M $11 ER
#2 resetType M $00-$FF RT_
9.2.2.2.2.Request message sub-function parameter $Level (LEV_) definition
The following parameter is defined for this service.

Table 29 — Request message data parameter definition
Definition
resetType
This parameter identifies the type of ECU reset to be performed.

RENAULT 36 - 00 - 013 / - - C
Table 30 — Request message resetType parameter definition

$00 Reserved M RESRVD
$40 – $5F
$7F
This value is reserved by this document.
$01 hardReset U HR
This value identifies a "hard reset" condition which simulates the power-
on / start-up sequence typically performed after an ECU has been
previously disconnected from its power supply (i.e. battery). The
performed action is implementation specific and not defined by the
standard. It might result in the re-initialization of both volatile memory and
non-volatile memory locations to predetermined values.
$02 keyOffOnReset U KOFFONR
This value identifies a condition similar to the driver turning the ignition
key off and back on. This reset condition should simulate a key-off-on
sequence (i.e. interrupting the switched power supply). The performed
action is implementation specific and not defined by this RNDS. Typically
the values of non-volatile memory locations are preserved; volatile
memory will be initialized.
$03 softReset U SR
This value identifies a "soft reset" condition, which causes the ECU to
immediately restart the application program if applicable. The performed
action is implementation specific and not defined by the standard. A
typical action is to restart the application without reinitializing of previously
learned configuration data, adaptive factors and other long-term
adjustments.
$04 enableRapidPowerShutDown U ERPSD
This value requests the ECU to enable and perform a "rapid power shut
down" function. The ECU shall execute the function immediately after
"key/ignition” is switched off. While the ECU executes the power down
function, it shall transition either directly or after a defined stand-by- time
to sleep mode. If the tool requires a response message and the ECU is
already prepared to execute the "rapid power shut down" function, the
ECU shall send the positive response message prior to the start of the
"rapid power shut down" function. The next occurrence of a "key on" or
"ignition on" signal terminates the "rapid power shut down" function.
The tool shall not send any request messages other than the ECUReset
with the parameter disableRapidPowerShutDown in order to not disturb
the rapid power shut down function.
Note: This sub-function is only applicable to an ECU supporting a stand-
by-mode!
$05 disableRapidPowerShutDown U DRPSD
This value requests the ECU to disable the previously enabled "rapid
power shut down" function.
$06 – $3F vehicleManufacturerSpecific U VMS
$80 – $F9 This range of values may be used by function manager.
Range $06 – $3F : compliant with ISO definition
Range $80 – $F9 : compliance with previous RNDS (3600013-A and
25953NDS07[N] specification).

RENAULT 36 - 00 - 013 / - - C
Table 30 — Request message resetType parameter definition

$60 – $7E systemSupplierSpecific U SSS
$FA – $FE This range of values is reserved for system supplier specific use.
Range 60 – 7E : compliant with ISO definition
Range FA – FE : compliance with previous RNDS (3600013-A and
25953NDS07[N] specification).
$FF resetAllTeachIns U RATI
compliance with previous RNDS (3600013-A and 25953NDS07[N]
specification).

#1 EcuReset Response Service Id M $51 ERPR
#2 resetType M $00-$FF RT_
#3 powerDownTime C $00-$FF PDT
C: This parameter is present if the parameter is set to the enableRapidPowerShutDown value ($04hex)

Definition
resetType
This parameter is an echo of the parameter from the request message.
powerDownTime
This parameter indicates to the tool the minimum time of the stand-by-sequence the ECU will remain in the
power down sequence.
The resolution of this parameter is one (1) secound per count.
The following values are valid:
 $00 – $FE hex: 0 – 254 seconds powerDownTime,
 $FF hex: indicates a failure or time not available.

RENAULT 36 - 00 - 013 / - - C
$12 subFunctionNotSupported M SFNS
Send if the parameter in the request message is not supported
This code shall be returned if the criteria for the EcuReset request are not
met.
For example if a specific resetType requires a non default session and the
current session is default session.
This NRC is applicable only when a long execution time service is in
progress, see § 9.1.2.2.
This NRC is applicable only to long execution time services, see § 9.1.2.2.
$33 SecurityAccessDenied M SAD
This code shall be sent if the ECUReset requires an unlocked ECU.
$7F ServiceNotSupportedInActiveSession M SNSIAS
See § 9.1.1.2.
9.2.3. $27 - SecurityAccess service
The purpose of this service is to provide a mean 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 an ECU and reading specific memory locations from an
ECU are situations where security access may be required. Improper routines or data downloaded into
an ECU could potentially damage the electronics or other vehicle components or risk the vehicle’s
compliance to emission, safety, or security standards. The security concept uses a seed and key
relationship.
A typical example of the use of this service is as follows:
- tool requests the “Seed”,
- ECU sends the “Seed”,
- tool sends the “Key” (appropriate for the Seed received),
- ECU responds that the “Key” was valid and that it will unlock itself.

RENAULT 36 - 00 - 013 / - - C
When in default session, including after power up/reset, ECU is always locked.
An application specific time delay3 might be required before the ECU can positively respond to a
service SecurityAccess ‘requestSeed’ message from the tool after ECU 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 ECU is powered up/reset and a previously performed
SecurityAccess service has failed. In case the ECU supports a delay timer then after a successful
SecurityAccess service execution the ECU internal indication information for a delay timer invocation
on a power up/reset shall be cleared by the ECU. In case the ECU 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 tool shall request the ECU to "unlock" by sending the service SecurityAccess ‘requestSeed’
message. The ECU shall respond by sending a "seed" using the service SecurityAccess ‘requestSeed’
positive response message. The tool shall then respond by returning a "key" number back to the ECU
using the service SecurityAccess ‘sendKey’ request message. The ECU shall compare this "key" to
one internally stored/calculated. If the two numbers match, then the ECU shall enable ("unlock") the
tool's access to specific services/data and indicate that with the service SecurityAccess ‘sendKey’
positive response message. Depending on the application, the system designer may specify a delay
after a certain number of failed attempts. An invalid key requires the tool to start over from the
beginning with a SecurityAccess request message.
If an ECU supports security, but is already unlocked when a SecurityAccess ‘requestSeed’ message is
received, that ECU shall respond with a SecurityAccess ‘requestSeed’ negative response
message service with NRC equal to CNC ($22).
Attempts to access security shall not prevent normal vehicle communications or other diagnostic
communication.
ECUs, which provide security shall support reject messages if a secure service is requested while the
ECU 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:
- StartDiagnosticSession service,
- SecurityAccess service,
- Secured diagnostic service.
There are different accessModes allowed for an enabled diagnosticSession (session started) in the
ECU.
3 For reprogramming unlocking, delay is set to 10 s.

RENAULT 36 - 00 - 013 / - - C

Table 34 — Request message definition - parameter = requestSeed
#1 SecurityAccess Request Service Id M $27 SA
#2 securityAccessType = requestSeed M $01, $03, LEV_
$05, SAT_RSD
$07-$FD
securityAccessDataRecord[] = [ SECACCDR_
#3 parameter#1 U $00-$FF PARA1
: : : : :
#n parameter#m ] U $00-$FF PARAm
Table 35 — Request message definition - parameter = sendKey

#1 SecurityAcces Request Service Id M $27 SA
#2 securityAccessType = sendKey M $02, $04, LEV_
$06, SAT_SK
$08-$FE
securityKey[ ] = [ SECKEY_
#3 key#1 (high byte) M $00-$FF KEY1HB
: : : : :
#n key#m (low byte) ] U $00-$FF KEYmLB

RENAULT 36 - 00 - 013 / - - C
The following data-parameters are defined for this service

Definition
securityAccessType
This parameter indicates to the ECU the step in progress for this service, the level of security the tool wants
to access and the format of seed and key. If an ECU supports different levels of security each level shall be
identified by the requestSeed value, which has a fixed relationship to the sendKey value.
Examples:
 “requestSeed=$01 hex” identifies a fixed relationship between “requestSeed=$01 hex” and “sendKey=$02
hex”
 “requestSeed=$03 hex” identifies a fixed relationship between “requestSeed=$03 hex” and “sendKey=$04
hex”
Values are defined in Table 37 for requestSeed and sendKey.
securityKey (high and low bytes)
The “Key” parameter in the request message is the value generated by the security algorithm corresponding
to a specific “Seed” value.
securityAccessDataRecord
This parameter record is user optionally to transmit data to an ECU when requesting the seed information. It
can e.g. contain an identification of the tool that is verified in the ECU.
Table 37 — Request message securityAccessType parameter definition

This value is reserved by this document.
$01, $03-$5F requestSeed U RSD
$83-$FD
RequestSeed with the level of security defined by the vehicle
manufacturer.
$81 requestSeedForReprogramming C RSDRPG
RequestSeed for reprogramming.
$82 sendKeyForReprogramming C SKRPG
SendKey for reprogramming.
$02, $04-$60 sendKey U SK
$84-$FE
SendKey with the level of security defined by the vehicle manufacturer.
$61 - $7E systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
$7F, $FF Reserved M RESRVD
This value is reserved by this document for future definition.

RENAULT 36 - 00 - 013 / - - C

#1 SecurityAccess Response Service Id M $67 SAPR
#2 securityAccessType M $00-$FF SAT_
securitySeed[ ] = [ SECSEED_
#3 seed#1 (high byte) C $00-$FF SEED1HB
: : : : :
#n seed#m (low byte) ] C $00-$FF SEEDmLB
C: The presence of this parameter depends on the securityAccessType parameter. It is mandatory to be
present if the securityAccessType parameter indicates that the tool wants to retrieve the seed from the
ECU.

Definition
securityAccessType
This parameter is an echo of the sub-function parameter from the request message.
securitySeed (high and low bytes)
The seed parameter is a data value sent by the ECU and is used by the tool when calculating the key
needed to access security. The securitySeed data bytes are only present in the response message if the
request message was sent with the securityAccessType parameter set to a value which requests the seed of
the ECU.
This code shall be returned if the securityAccessType parameter in the
request message is not supported.
This code shall be returned if the criteria for the request SecurityAccess are
not met, or if the ECU is already in unlocked state.

RENAULT 36 - 00 - 013 / - - C

$35 invalidKey M IK
Send if the value of the key is not valid for the ECU.
$37 requiredTimeDelayNotExpired P RTDNE
because the client's latest attempt to gain security access was initiated
before the server's required timeout period had elapsed.
See § 9.1.1.2.

RENAULT 36 - 00 - 013 / - - C
9.2.4. $28 - CommunicationControl service
ONLY USED IF ALL RELATED INTER-SYSTEMS ISSUES HAVE BEEN CLEARLY IDENTIFIED AND
SORTED OUT (SOLVED)
The purpose of this service is to switch on/off the transmission and/or the reception of certain
messages of (a) ECU(s) (e.g. application communication messages).

A_Data byte Parameter Name Cvt Hex Mnem
Value
#1 CommunicationControl Request Service Id M $28 CC
#2 sub-function = [ M LEV_
controlType ] $00-$FF CTRLTP
#3 communicationType M $00-$FF CTP
The sub-function parameter controlType contains information on how the ECU shall modify
the communication type referenced in the communicationType parameter
(suppressPosRspMsgIndicationBit (bit 7 is set to 0) not shown in Table 42).
Table 42 — Request message sub-function parameter definition
Bit 6-0
$00 enableRxAndTx U ERXTX
This value indicates that the reception and transmission of messages shall
be enabled for the specified communicationType.
$01 enableRxAndDisableTx U ERXDTX
This value indicates that the reception of messages shall be enabled and
the transmission shall be disabled for the specified communicationType.
$02 disableRxAndEnableTx U DRXETX
This value indicates that the reception of messages shall be disabled and
the transmission shall be enabled for the specified communicationType.
$03 disableRxAndTx U DRXTX
This value indicates that the reception and transmission of messages shall
be disabled for the specified communicationType.
$04 - $7F Reserved U RESRVD
This range of values is reserved by this document for future definition.

RENAULT 36 - 00 - 013 / - - C
The following data-parameter are defined for this service:

Definition
communicationType
This parameter is used to reference the kind of communication to be controlled.
Table 44 — Request message communicationType parameter definition

$01 Application M APPL
Only allowed value for responseRequired parameter. Application
communication includes all CAN messages except the ECU specific
diagnostic messages (physical ECU addressing).
$02 - $FF
This range of values is reserved by this document.

#1 CommunicationControl Response Service Id M $68 CCPR
#2 controlType M $00-$FF CTRLTP

Definition
ControlType
This parameter is an echo of the sub-function parameter from the request message.

RENAULT 36 - 00 - 013 / - - C
Send if the sub-function parameter in the request message is not
supported
Used when the ECU is in a critical normal mode activity and therefore
cannot disable/enable the requested communication type.
See § 9.1.1.2.
$7E subFunctionNotSupportedInActiveSession M SFNSIAS
See § 9.1.1.2.
See § 9.1.1.2.
9.2.5. $3E - TesterPresent service
This service is used to indicate to an ECU that a tool is still connected to the vehicle and that certain
diagnostic services (Timed services) and/or communication that have been previously activated are to
remain active.
This service is used to keep the ECU in a diagnostic session other than the defaultSession. This is
done by transmitting the TesterPresent request message in case of the absence of other diagnostic
services to prevent the ECU from automatically returning to the defaultSession. The detailed session
requirements that apply to the use of this service when keeping a single ECU in a diagnostic session
other than the defaultSession can be found in the implementation specifications of § 9.1.3.

#1 TesterPresent Request Service Id M $3E TP
#2 responseRequired M $01 RSPREQ

RENAULT 36 - 00 - 013 / - - C

Table 49 — Request message responseRequired parameter definition
$01 YES M YES
Only allowed value for responseRequired parameter
$02 - $FF
This range of values is reserved by this document.

#1 TesterPresent Response Service Id M $7E TPPR
No parameter in the positive response message
This code shall be returned if the responseRequired parameter in the
request message is not supported.
This NRC is applicable only when a long execution time services is in

RENAULT 36 - 00 - 013 / - - C
9.3. DATA TRANSMISSION FUNCTIONAL UNIT
9.3.1. $21 - ReadDataByLocalIdentifier service
9.3.1.1. Service Description
The readDataByLocalIdentifier service requests data record values from the ECU identified by a
recordLocalIdentifier. The data record values are sent via the readDataByLocalIdentifier positive
response message. The format and definition of the “recordValues” are system specific (except for
standard frames). “RecordValues” may include analogue input and output signals, digital input and
output signals, internal data and system status information.
This service is used in “one shot” mode to read ECU data. Periodic transmission mode is not allowed.
The “Local Identifiers” $80, $81, $82, $83, $84, - $86, $B0 , $B1 and $B2 - $B4 have a cross definition
for all the ECUs. Their content and/or format are standardized (see following section).
The “Local Identifiers” of ranges $85 $87 to $8F and $B3, $B5 to $BF are reserved for future
transverse applications.
The use of “Local Identifiers” from range [$00 - $7F] is defined § 9.1.5.

A_Data Byte Parameter name Cvt. Hex Value Mnem.
#1 ReadDataByLocalIdentifier Request Service Id M $21 RDBLID
#2 Record Local Identifier M $xx RLOCID
The following data parameters are defined for this service.

Definition
Record Local Identifier
This parameter identifies groups of data predefined in the ECU. The content of the data is negotiated
between the function manager and his customers: After-Sales, Plant Process and others. The function
manager shall provide the supplier with the detailed specification. The values of this parameter are defined in
Table 54 for RENAULT/NISSAN applications.

RENAULT 36 - 00 - 013 / - - C
Table 54 — Request message RecordLocalIdentifier Values

RENAULT
RENAULT NISSAN
Hex Value Description Cvt. Cvt.
&
NISSAN
$00, $20, Indicate LocalIdentifiers used in the ranges $01-20, $21-40, $41- U M M
$40, $60 60, $61-7F
$01 - $1F
$21 - $3F Manufacturer specific Data to be defined by function manager U U U
$41 - $5F
$61 - $7F
$80 Renault’s system identification M F M
$81 Vehicle identification Number (VIN) M U M
$83 Nissan’s system identification F M M
$84 Traceability information M U M
$82,$ 85-$8F Reserved for networks diagnostic purpose (refer to [REF 3] for C2 C2 C2
applicability and detailed specification)
$90-$9F Supplier specific Data U U U
$A0-$AF Manufacturer specific Data: Design & Development U U U
$B1-$BF Reserved for networks diagnostic purpose (refer to [REF 3] for C2 C2 C2
applicability)
$B0, $C0 - Reserved F F F
$DF
$E0-$EF Reserved for DynamicallyDefineLocalIdentifier service U U U
$F0-$FF Reprogramming Data C3 C3 C3
C2: Refer to [REF 3] for applicability.
C3: For porgrammable ECUs.
As a general rule, each local ID definition except $00, $20, $40 and $60 is the same for both read and
write services.

A_Data Byte Parameter Name Cvt Hex Value Mnem
#1 ReadDataByLocalIdentifier Response Service Id M $61 RDBLIDPR
#2 Record Local Identifier M $xx RLOCID
#3 to n Record Value M $xx .. $xx RECVAL
For RecordLocalIdentifier values $00 / $20 / $40 / $60 refer to § 9.1.5.1.
Definition
Record Local identifier
This parameter is an echo of the data parameterLocalDataIdentifier from the request message.
Record Value
This parameter is used by the ReadDataByLocalIdentifier positive response message to provide the
requested data record values to the tool. Some Record Value structure are standardized for Renaut and
Nissan applications (see § 9.3.1.5.). The exact content of the Record Values are detailled in the system
specific diagnostic specification.

RENAULT 36 - 00 - 013 / - - C

This code shall be returned if the local Identifier in the request message is
not supported.
This code shall be returned if the criteria for the ReadDataByLocalIdentifier
request are not met.
This code shall be returned when the Local ID is available only in a session
different from the current session; e.g. when the current session is default
session and the requested LID is available in a non default session.
This code shall be sent if the Local Identifier requires an unlocked ECU.
9.3.1.5. Definition of standardized “Local Identifiers”
9.3.1.5.1.For Local Identifier = $80 and $83 : System identification
Table 58 — System identification definition

A_Data Parameter Name Cvt Hex Value Mnem
Byte
#1 ReadDataByLocalIdentifier Response Service M $61 RDBLID
Id PR
#2 Local Identifier = System identification M RENAULT $80 RLOCID
NISSAN $83
#3 to 26 Identification: 24 bytes (*) = M $xx / ... / $xx = IDENT
spare parts Number / $xx / $xx / $xx / $xx /
Diagnostic identification code / $xx /
Supplier Number / $xx /
Hardware Number / $xx / $xx / $xx /
Software Number / $xx / $xx / $xx / $xx /
Edition Number / $xx /
Calibration No / $xx / $xx /
Other system features / $xx / $xx /
Manufacturer identification code. $xx / $xx /
$xx / $xx / $xx /
$xx.
(*) Non-used bytes shall be set to $00 hexa.
The value of parameters “spare parts Number”, “diagnostic identification code”, “supplier Number” and
“Manufacturer identification code” is provided by RENAULT/NISSAN to the supplier.

RENAULT 36 - 00 - 013 / - - C
An agreement must be reached between the RENAULT/NISSAN function manager and the supplier to
define the value of parameters “Hardware Number”, “Software Number”, “Edition Number” and
“Calibration Number”.
The Diagnostic Code Identification identifies the content of the ECU diagnostic application. This code
is linked to the address attributed to each family of ECUs. Its value is assigned by the after-sales
diagnostic manager.
The use definition of 3 data bytes “Other system features” is the responsibility of the function manager.
Table 1 — Identification Data Coding according to car manufacturer

Identification : 24 bytes Renault R1 Nissan N1 Nissan N2 Nissan N3 Nissan N4
spare parts No. BCD (#MPR) ASCII ASCII ASCII ASCII
Diagnostic identification Hexa BCD BCD BCD BCD
code
Supplier Number ASCII (#ITG) Byte 1 in ASCII Hexa ASCII
ASCII
Bytes 2, 3 in
BCD
Hardware Number BCD BCD BCD BCD BCD
Software Number Hexa Hexa Hexa Hexa Hexa
Edition Number Hexa Hexa Hexa Hexa Hexa
Calibration Number Hexa Hexa Hexa Hexa Hexa
Other system features / / / / ASCII
Manufacturer $00 $80 $81 $82 $83
identification code
Identification : 24 Renault R2 Renault R3
bytes
spare parts No. ASCII BCD
Diagnostic identification Hexa Hexa
code
Supplier Number ASCII ASCII
Hardware Number ASCII BCD
Software Number Hexa Hexa
Edition Number Hexa Hexa
Calibration Number Hexa Hexa
Ntypes (R2/R3) Hexa Hexa
Manufacturer $88 $FF
identification code
Nissan responsible departments for diagnostic services will define precisely for each ECU of each vehicle
project which NISSAN Ni format will have to be used.
Nissan N4: Supplier number + Other system features = 6 bytes (ASCII, upper-setting, blank $20)
For an example, if the suppllier code is “ABCD”, Supplier number is $41$42$43, and Other system features
is $44$20$20.
For 5Digits applications, format used is Renault R2. PartNo and HardwareNo are a part of the
whole numbers (only the right fifth ASCII bytes of the 10 ASCII bytes references).
For R2/R3 formats “Ntypes” (3bytes) is divided in : PartNumberType (1 byte),HardwareNumberType (1

byte),
ApprovalNumberType (1 byte). (possible values are : $00 for N/A, $01 for hardware, $02 for software).
Values listed in above table for “Manufacturer identification code” are the only possibles

RENAULT 36 - 00 - 013 / - - C
values (no other value allowed).
Important rules :
- for RENAULT’s ECU the identification frame is accessible by the “LocalIdentifier” $80,
- for NISSAN’s ECU the identification frame is accessible by the “LocalIdentifier” $83,
- common ECU shall implement both identification frames $80 and $83,
- the byte “Manufacturer identification code” shall be present and correctly set whatever the identification
frame ($80 or $83).
9.3.1.5.2.For Local Identifier = $81 : VIN

#2 Record Local Identifier = Vehicle identification M $81 RLOCID
#3 to 19 V.I.N. in ASCII M $xx / ... / VIN
$xx
#20 to 21 CRC M $xx / $xx CRC
The V.I.N structure is standardized and includes 17 alphanumerical characters. Upon writing, the
diagnostic tool transmits the ASCII encoded characters to which it adds a 2 bytes CRC. The ECU shall
not implement a CRC computation algorithm; it shall simply manage a 19 bytes block to be returned
intact upon reception of a read request. It is conceivable for the ECU to use transcoding for data
storage, however it is mandatory that the data are sent back with their original coding when
responding to the read (VIN) service.

RENAULT 36 - 00 - 013 / - - C
9.3.1.5.3.For LID = $82, $85-$8F : multiplex network diagnostic

#2 Record Local Identifier = multiplex network diagnostic M $82, $85- RLOCID
$8F
diagMuxData [ ] = [
#3 data#1 M $xx / ... / DATA
: : $xx
#n data#m ]
For the content of the frame, refer to [REF 3] document specific for each ECU.
9.3.1.5.4.For LocalIdentifier = $B1-$BF : On board Networks configurations

#2 Record Local Identifier : On board Networks configurations M $B1-$BF RLOCID
networkConf [ ] = [
#3 data#1 M $xx / ... / DATA
: : $xx
#13 data#11 ]
For the applicability of LocalIdentifier $B1-$BF, refer to [REF 3] document specific for each ECU.
9.3.1.5.5.For LID = $84 : traceability information

#2 Record Local Identifier = Traceability information M $84 RLOCID
#3 to #22 Unitary data traceability M $xx /... / $xx TRACA
#19 to #22 Reserved M $20 / $20 /
$20 / $20
For RENAULT use, the format for the record Unitary data traceability is ASCII alphanumeric
characters :
From $30 to $39 0 to 9 characters,
From $41 to $5A A to Z characters,
From $61 to $7A a to z characters.
The use of “space” character ($20 value) may be used only as a padding character.
For reprogrammable ECU, traceability informations must not be modified during reprogramming
procedure.
Bytes 3 to 5.
Renault side = Defined by the supplier.
Nissan Side = Part code.

RENAULT 36 - 00 - 013 / - - C
Bytes 6 to 18 = Defined by the supplier.

Bytes 19 to 22
Renault side = Defined by the supplier.
Nissan Side = Supplier Code.
For “Part Code” & ” Supplier Code” refer to Nissan ECU designer.

RENAULT 36 - 00 - 013 / - - C
9.3.2. $22 - ReadDataByIdentifier service
The ReadDataByIdentifier service allows the tool to request data record values from the ECU
identified by one or more dataIdentifiers.
The tool request message contains one or more two (2) byte dataIdentifier values that identify data
record(s) maintained by the ECU. The format and definition of the dataRecord may include analog
input and output signals, digital input and output signals, internal data, and system status information if
supported by the ECU.
The ECU may limit the number of dataIdentifiers that can be simultaneously requested as agreed
upon by RENAULT/NISSAN and system supplier.
Upon receiving a ReadDataByIdentifier request, the ECU shall access the data elements of the
records specified by the dataIdentifier parameter(s) and transmit their value in one single
ReadDataByIdentifier positive response containing the associated dataRecord parameter(s). The
request message may contain the same dataIdentifier multiple times. The ECU shall treat each
dataIdentifier as a separate parameter and respond with data for each dataIdentifier as often as
requested.

Byte
#1 ReadDataByIdentifier Request Service Id M $22 RDBI
dataIdentifier[] #1 = [ DID_
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 ] M $00-$FF B2
: : : : :
dataIdentifier[] #m = [ DID_
#n-1 byte#1 (MSB) U $00-$FF B1
#n byte#2 ] U $00-$FF B2
9.3.2.2.2.Request message sub-function parameter $Level (LEV_) Definition
The following data-parameters are defined for this service.

Definition
dataIdentifier (#1 to #m)
This parameter identifies the ECU data record that are being requested by the tool (see 0 of this document
for detailed parameter definition).

RENAULT 36 - 00 - 013 / - - C

Byte
#1 ReadDataByIdentifier Response Service Id M $62 RDBIPR
dataIdentifier[] #1 = [ DID_
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 ] M $00-$FF B2
dataRecord[] #1 = [ DREC_
#4 data#1 M $00-$FF DATA_1
: : : : :
#(k-1)+4 data#k ] U $00-$FF DATA_m
: : : : :
dataIdentifier[] #m = [ DID_
#n-(o-1)-2 byte#1 (MSB) U $00-$FF B1
#n-(o-1)-1 byte#2 ] U $00-$FF B2
dataRecord[] #m = [ DREC_
#n-(o-1) data#1 U $00-$FF DATA_1
: : : : :
#n data#o ] U $00-$FF DATA_k

Definition
dataIdentifier (#1 to #m)
This parameter is an echo of the data parameter dataIdentifier from the request message.
dataRecord (#1 to #k/o)
This parameter is used by the ReadDataByIdentifier positive response message to provide the requested
data record values to the tool. The content of the dataRecord is not defined in this document and is system
specific.

RENAULT 36 - 00 - 013 / - - C
This code shall be returned if all the DataIdentifier in the request message is
not supported.
This code shall also be returned if the requested number of data identifier
exceeds the maximum limit supported by the ECU in a single request.
$22 conditionsNotCorrect U CNC
This response code shall be sent if the operating conditions of the ECU are
not met to perform the required action.
This code shall also be returned if ALL the requested data identifiers are
available in a session different from the current session; e.g. when the
current session is default session and all requested DID are available in a
non default session.
This code shall be sent if the DataIdentifier requires an unlocked ECU.

RENAULT 36 - 00 - 013 / - - C
9.3.3. $23 - ReadMemoryByAddress service
The ReadMemoryByAddress service allows the tool to request memory data from the ECU via
provided starting address and size of memory to be read.
The ReadMemoryByAddress request message is used to request memory data from the ECU
identified by the parameter memoryAddress and memorySize.
The number of bytes used for the memoryAddress is 4 and for memorySize is 2.
In case of overlapping memory areas it is possible to use the MA_B1 memoryAddress MSB as a
memoryIdentifier. (e.g. use of internal and external flash memory, EEPROM,…).
This service is highly recommended during development phase to access dynamic data for debugging
purposes. It may also be used for rescue mode along with SecurityAccess service.
IMPORTANT (security and protection)
The supplier has access to the microprocessor and peripheral registers; checking these components,
via this service, may seriously interfere with the operation of the ECU. It is therefore imperative that an
address filter be installed to avoid such incidents. The specification of this filter shall be provided by
the supplier to the function manager.
Some information must remain completely inaccessible by this service. The function manager shall
define the address filters to be installed to meet this requirement. Such protection filters apply for
example to BOOT software for reprogrammable ECUs refer to [REF 2] and Application software.

Byte
#1 ReadMemoryByAddress Request Service Id M $23 RMBA
memoryAddress[ ] = [ MA_
#2 byte#1 (MSB) M $00-$FF B1
: : : : :
#5 byte#4 ] M $00-$FF B4
memorySize[ ] = [ MS_
#6 byte#1 (MSB) M $00-$FF B1
#7 byte#2 ] M $00-$FF B2

RENAULT 36 - 00 - 013 / - - C

Definition
memoryAddress
The parameter memoryAddress is the starting address of ECU memory from which data is to be retrieved.
The number of bytes used for this address is 4.
Byte#4 in the memoryAddress parameter is always the least significant byte of the address being referenced
in the ECU. 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 ECU 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.
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 ECU's memory. The number of bytes
used for this size is 2.

Byte
#1 ReadMemoryByAddress Response Service Id M $63 RMBAPR
dataRecord[ ] = [ DREC_
: : : : :
#n data#m ] U $00-$FF DATA_m

Definition
dataRecord
This parameter is used by the ReadMemoryByAddress positive response message to provide the requested
data record values to the tool. The content of the dataRecord is not defined in this document.

RENAULT 36 - 00 - 013 / - - C
under which each response code would occur are documented in

This response code shall be sent if:
1. any memory address within the interval [$MA, ($MA + $MS -$1)] is
invalid,
2. any memory address within the interval [$MA, ($MA + $MS -$1)] is
restricted,
3. the memorySize parameter value in the request message is greater than
the maximum value supported by the ECU.
This code shall be sent if any memory address within the interval [$MA, ($MA
+ $MS -$1)] is secured and the ECU is locked.

RENAULT 36 - 00 - 013 / - - C
9.3.4. $24 - ReadScalingDataByIdentifier service
The ReadScalingDataByIdentifier service allows the tool to request scaling data record information
from the ECU identified by one or more dataIdentifiers.
The tool request message contains a two byte dataIdentifier value that identifies data record(s)
maintained by the ECU (refer to § 9.3.2. for allowed dataIdentifier values). The format and definition of
the dataRecord 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 ECU.
Upon receiving a ReadScalingDataByIdentifier request, the ECU shall access the scaling information
associated with the specified dataIdentifier parameter and transmit the scaling information values in
one ReadScalingDataByIdentifier positive response.

Byte
#1 ReadScalingDataByIdentifier Request Service Id M $24 RSDBI
dataIdentifier[] = [ DID_
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 ] M $00-$FF B2

Definition
DataIdentifier
This parameter identifies the ECU data record that are being requested by the tool (see 0 of this document

RENAULT 36 - 00 - 013 / - - C

A_Data Parameter Name Cvt Hex Mnem
Byte Value
#1 ReadScalingDataByIdentifier Response Service Id M $64 RSDBIPR
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 (LSB) ] M $00-$FF B2
#4 scalingByte #1 M $00-$FF SB_1
scalingByteExtension [] #1 = [ SBE_
#5 scalingByteExtensionParameter#1 C1 $00-$FF PAR1
: : : : :
#(p-1)+5 scalingByteExtensionParameter#p C1 $00-$FF PARp
]
: : : : :
#n-r scalingByte #k C2 $00-$FF SB_k
scalingByteExtension [] #k = [ SBE_
#n-(r-1) scalingByteExtensionParameter#1 C1 $00-$FF PAR1
: : : : :
#n scalingByteExtensionParameter#r C1 $00-$FF PARr
]
C1: The presence of this parameter depends on the scalingByte high nibble. It is mandatory to be present if
the scalingByte high nibble is encoded as formula, unit/format, or bitMappedReportedWithOutMask.
C2: The presence of this parameter depends on whether the encoding of the scaling information requires
more than one byte.

Definition
dataIdentifier
scalingByte (#1 to #k)
This parameter is used by the ReadScalingDataByIdentifier positive response message to provide the
requested scaling data record values to the tool (refer to ISO 14229-1 Annex C2 for detailed parameter
definition).
scalingByteExtension (#1 to #p / #1 to #r)
This parameter is used to provide additional information for scalingBytes with a high nibble encoded as
formula, unit/format, or bitmappedReportedWithOutMask (refer to ISO 14229-1 Annex C3 for detailed
parameter definition).

RENAULT 36 - 00 - 013 / - - C

This return code shall be sent if:
1. the requested dataIdentifier value is not supported by the device
2. the requested dataIdentifier value is supported by the device, but no
scaling information is available for the specified dataIdentifier.
$33 securityAccessDenied M SAD
This code shall be sent if the dataIdentifier is secured and the ECU is not in
an unlocked state.
9.3.5. $2C - DynamicallyDefineLocalIdentifier service

This service is only to be supported for developpment purposes (i.e will NOT be used in plants or
aftersales). Therefore it shall be limited to LID defined by addresses (definitionMode
“defineByMemoryAddress”. Definition mode “defineByLocalIdentifier mixed with defineByIdentifier” is
not to be implemented ; service $22 with multi Identifier support shall be used instead with the
constraint of being able to return as many data as permitted by ISO 15765-2 (i.e ~ 4 kbytes). If
applicable, the service shall be restricted to developpement session.
The DynamicallyDefineDataIdentifier service allows the tool to dynamically define in an ECU a data
identifier that can be read via the ReadDataByLocalIdentifier service at a later time.
The intention of this service is to provide the tool with the ability to group one or more data elements
into a data superset that can be requested via the ReadDataByLocalIdentifier / ReadDataByIdentifier /
ReadMemoryByAddress services. The data elements to be grouped together can either be referenced
by:
- a source data identifier(LocalID/Identifier), a position and size or,
- a memory address and a memory length.
This service allows greater flexibility in handling data needs of the diagnostic application that extend
beyond the information that can be read via statically defined data identifiers, and can also be used to
reduce bandwidth utilization by avoiding overhead penalty associated with frequent request/response
transactions.
IMPORTANT: Defined data Identifier shall be reset via session change / power down.

RENAULT 36 - 00 - 013 / - - C
9.3.5.2.1.1. definitionMode = defineByLocalIdentifier mixed with defineByIdentifier

Forbidden mode
#1 DynamicallyDefineLocalIdentifier Request Service Id M $2C DLIDDY
#2 DynamicallyDefinedLocalIdentifier M $E0-$EF DDLOCID
#3 definitionMode=[defineByLocalIdentifier]#1 M $01 DEFMODE
#4 PositionInDynamicallyDefinedLocalIdentifier#1 M $xx PIDYDLID
#5 LocalIdentifierDataLength #1 M $xx LIDDL
#6 RecordLocalIdentifier#1 M $xx RLOCID
#7 PositionInRecordLocalIdentifier#1 M $xx PIRLOCID
#8 definitionMode=[defineByLocalIdentifier]#2 C $01 DEFMODE
#9 PositionInDynamicallyDefinedLocalIdentifier#2 C $xx PIDYDLID
#10 LocalIdentifierDataLength #2 C $xx LIDDL
#11 RecordLocalIdentifier#2 C $xx RLOCID
#12 PositionInRecordLocalIdentifier#2 C $xx PIRLOCID
: : : :
#n-5 definitionMode=[defineByIdentifier]#m C $02 DEFMODE
#n-4 PositionInDynamicallyDefinedLocalIdentifier#m C $xx PIDYDLID
#n-3 IdentifierDataLength #m C $xx CIDDL
#n-2 RecordIdentifier#m (Highest Byte) C $xx RCID
#n-1 RecordIdentifier#m (Lowest Byte) C $xx
#n PositionInRecordIdentifier#m C $xx PIRCID
- The parameter positionInDynamicallyDefinedLocalIdentifier shall specify the position in the record

referenced by the parameter dynamicallyDefinedLocalIdentifier.
- The parameter LocalIdentifierDataLength shall specify the number of data bytes referenced by
the parameter recordLocalIdentifier.
- The parameter positionInRecordLocal/Identifier shall specify the starting position in the record
stored in the ECU’s memory.
The request may consist of multiple definitions.

RENAULT 36 - 00 - 013 / - - C
9.3.5.2.1.2. definitionMode=defineByMemoryAddress
#3 definitionMode=[defineByMemoryAddress]#1 M $03 DEFMODE
#4 PositionInDynamicallyDefinedLocalIdentifier#1 M $xx PIDYDLID
#5 MemoryAddressDataLength #1 M $xx MEMADDL
#6 MemoryAddress#1 (Highest Byte) M $xx MEMAHH
#7 MemoryAddress#1 (HL byte) M $xx MEMAHL
#8 MemoryAddress#1 (LH byte) M $xx MEMALH
#9 MemoryAddress#1 (Lowest Byte) M $xx MEMALL
#10 definitionMode=[defineByMemoryAddress]#2 C $03 DEFMODE
#11 PositionInDynamicallyDefinedLocalIdentifier#2 C $xx PIDYDLID
#12 MemoryAddressDataLength #2 C $xx MEMADDL
#13 MemoryAddress#2 (Highest Byte) C $xx MEMAHH
#14 MemoryAddress#2 (HL byte) C $xx MEMAHL
#15 MemoryAddress#2 (LH byte) C $xx MEMALH
#16 MemoryAddress#2 (Lowest Byte) C $xx MEMALL
: : : : :
#n-6 definitionMode=[defineByMemoryAddress]#m C $03 DEFMODE
#n-5 PositionInDynamicallyDefinedLocalIdentifier#m C $xx PIDYDLID
#n-4 MemoryAddressDataLength #m C $xx MEMADDL
#n-3 MemoryAddress#m (Highest Byte) C $xx MEMAHH
#n-2 MemoryAddress#m (HL Byte) C $xx MEMAHL
#n-1 MemoryAddress#m (LH Byte) C $xx MEMALH
#n MemoryAddress#m (Lowest Byte) C $xx MEMALL
- The parameter positionInDynamicallyDefinedLocalIdentifier shall specify the position in the record

referenced by the parameter dynamicallyDefinedLocalIdentifier.
- The parameter MemoryAddressDataLength shall specify the number of data bytes starting at the
specified memoryAddress in the ECU’s memory.
The request may consist of multiple definitions.

RENAULT 36 - 00 - 013 / - - C
9.3.5.2.1.3. definitionMode = ClearDynamicallyDefinedLocaldentifier

#3 definitionMode=[ClearDynamicallyDefinedIdentifier] M $04 DEFMODE

Definition
DynamicallyDefinedLocalIdentifier
The parameter identifies a data record which has been defined in the request service.
definitionMode
The parameter definitionMode specifies the method of how the data record is defined
positionInDynamicallyDefinedLocalIdentifier
The parameter identifies the position of the data in the readDataByLocal/Identifier positive response
message.
MemoryAddressDataLength, IdentifierDataLength, LocalIdentifierDataLength
These parameters identify the number of bytes of data identified by the MemoryAddress or recordIdentifier or
recordLocalIdentifier. Its format is an 8 bits format.
memoryAddress
The parameter identifies the start address of a data record in the ECU’s memory. Its format is a 32 bits
format. A 24 bits format is also allowed.
positionInRecordLocalIdentifier
The parameter identifies the position in the data record identified by the recordLocal/Identifier in the ECU’s
memory.
Table 83 — DynamicallyDefinedLocalIdentifier definition

Hex Description
$E0 - $EF DynamicallyDefinedLocalIdentifier
Table 84 — definitionMode parameter definition

Hex Description
$01 DefineByLocalIdentifier
$02 DefineByIdentifier
$03 DefineByMemoryAddress
$04 ClearDynamicallyDefinedLocalIdentifier

RENAULT 36 - 00 - 013 / - - C

Table 85 — definitionMode parameter definition
#1 DynamicallyDefineLocalIdentifier Response Service Id M $6C DLIDDYPR
9.3.5.3.2.Response message data parameter definition

Definition
DynamicallyDefinedLocalIdentifier
This parameter is an echo of the data parameter RecordLocalIdentifier from the request message.
This response code shall be sent if one of the parameters of the request is
not correct.
This code shall be returned if the operating conditions of the ECU are not
met to perform the DDLID service.
This code shall be sent if
1. any data identifier (dynamicallyDefinedDataIdentifier or any
sourceDataIdentifier) in the request message is secured and the
ECU is not in an unlocked state.
2. any memory address in the request message is secured and the
ECU is not in an unlocked state.
9.3.5.5. Message flow examples DynamicallyDefineDataIdentifier
The example builds a dynamic data identifier (DynamicallyDefinedLocalIdentifier: E0) using the
defineByLocalIdentifier method and then sends a ReadDataByLocalIdentifier request to read the just
configured dynamic data identifier.
The tool builds DynamicallyDefinedLocalIdentifier to contain engine speed (LID:$05), Water

temperature (LID: $05) and Fuel injection time (LID: $07).

RENAULT 36 - 00 - 013 / - - C
The following table shall be used for the example below. Note that the values being reported may
change over time on a real vehicle, but are shown to be constants for the sake of clarity.
Table 88 — Composit data blocks – Local Identifier
LID Data Byte Data Record Contents. Byte Value
$05 #1 Water temperature: TWN $7F
#2 Vehicle speed: VSP $27
#3 $A0
#4 Battery voltage: VB $31
#5 Intake air temperature: TAN $56
#6 throttle valve opening: TVO $15
#7 engine speed: NRPM $25
#8 $07
$07 #1 Fuel injection time: TISTd $25
#2 $51
#3 $A0
#4 $7A
#5 Throttle sensor voltage: TPSV $0C
#6 $25
1) Set each Data to DynamicallyDefinedLocalIdentifier.

Table 89 — DynamicallyDefineLocalIdentifier request message
A_Data Byte Parameter Name Hex Value Mnem
#1 DynamicallyDefineLocalIdentifier Request service Id $2C DLIDDY
#2 DynamicallyDefinedLocalIdentifier $E0 DDLOCID
#3 definitionMode=[defineByLocalIdentifier]#1 $01 DEFMODE
#4 PositionInDynamicallyDefinedLocalIdentifier#1 $01 PIDYDLID
#5 LocalIdentifierDataLength #1 $02 LIDDL
#6 RecordLocalIdentifier#1 $05 RLOCID
#7 PositionInRecordLocalIdentifier#1 $07 PIRLOCID

RENAULT 36 - 00 - 013 / - - C
Table 90 — DynamicallyDefineLocalIdentifier positive response

#1 DynamicallyDefineLocalIdentifier ResponseService Id $6C DLIDDYPR
#2 DynamicallyDefinedLocalIdentifier $E0 DDLOCID
2) Read defined DynamicallyDefinedLocalIdentifier.

Table 91 — ReadDataByLocalIdentifier request message
#1 ReadDataByLocalIdentifier Request Service Id $21 RDBLID
#2 Record Local Identifier $E0 RLOCID
Table 92 — ReadDataByLocalIdentifier positive response

#1 ReadDataByLocalIdentifier Response Service Id $61 RDBLIDPR
#2 Record Local Identifier $E0 RLOCID
#3 $25 RECVAL
Record Value (Engine Speed)
#4 $07 _NRPM
#5 Record Value (Water Temperature) $7F RECVAL_TWN
#6 Record Value (Fuel Injection time) $25
#7 $51 RECVAL
#8 $A0 _TISTd
#9 $7A

RENAULT 36 - 00 - 013 / - - C
9.3.6. $3B - WriteDataByLocalIdentifier service
This service is used to :
- write on ECU memory the data relevant to Engineering, After-Sales, Plant Process (example:
date) or Quality Department (or other),
- select a law, a calibration, a threshold, a coefficient or a vehicle assembly line configuration,
- correct certain parameters (example: injection idle rate setting) within the limits fully controlled by
the ECU.
It might be necessary to take certain precautions regarding vehicle production and last After-Sales
operation dates (e.g. prohibit the writing of the plant vehicle production date in the After-Sales
network). It is the responsibility of the function manager to specify this to the ECU supplier.
Depending on the Local ID, data may be written either on volatile memory or on non-volatile memory.
The choice will be done regarding diagnostic communication performance.
This service shall not be used to reset the memory including the stored fault codes.

A_Data byte Parameter name Cvt Hex Value Mnem.
#1 WriteDataByLocalIdentifier request Service Id M $3B WDBLID
#2 RecordLocalIdentifier M $xx RECLID
#3 to n RecordValue = values to be written : To be defined by U $xx RECVAL
the function manager

Definition
RecordLocalIdentifier
The parameter identifies the data groups predefined in the ECU that may be written. These groups are
negotiated between the function manager and his customers : After-Sales, Plant Process and other
departments. The function manager shall provide the supplier with the detailed specification.
RecordValue
This parameter provides the data record associated with the RecordLocalIdentifier that the tool is requesting
to write to ECU memory.

RENAULT 36 - 00 - 013 / - - C
Table 95 — Request message communicationType parameter definition

RENAULT NISSAN RENAULT&
Hex Description
Cvt Cvt NISSAN
$00,$20,$40, Indicate LocalIdentifiers used in the ranges $01-20, U M M
$60 $21-40, $41-60, $61-7F
$01 - $1F
$21 - $3F Manufacturer specific Data to be defined by function U U U
$41 - $5F manager
$61 -$ 7F
$80 Renault’s system identification F F F
$81 Vehicle identification Number (VIN) M U M
$83 Nissan’s system identification F F F
$84 Traceability information F F F
$82, Reserved for networks diagnostic purpose F F F
$85-$8F
$90-$9F Supplier specific Data U U U
$A0-$AF Manufacturer specific Data: Design & Development U U U
$B1-$BF Reserved for networks diagnostic purpose (refer to [REF 3] C C C
for applicability)
$B0, Reserved F F F
$C0 - $DF
$E0-$EF Reserved for DynamicallyDefineLocalIdentifier service F F F
$F0-$FF Reprogramming Data F F F
As a general rule, each local ID definition except $00, $20, $40 and $60 is the same for both read and
write services.

byte
#1 WriteDataByLocalIdentifier Response Service Id M $7B WDBLIDPR
#2 RecordLocalIdentifier M $xx RECLID
For RecordLocalIdentifier values $00 / $20 / $40 / $60 refer to § 0.

Definition
RecordLocalIdentifier
This parameter is an echo of the data parameter RecordLocalIdentifier from the request message.

RENAULT 36 - 00 - 013 / - - C
This response code shall be sent if
1. The RecordLocalIdentifier in the request message is not supported in the
ECU or the RecordLocalIdentifier is supported for read only purpose (via
ReadDataByLocalIdentifier service).
2. Any data transmitted in the request message after the
RecordLocalIdentifier is invalid (if applicable to the node).
3. The length of the message is wrong.
This code shall be returned if the operating conditions of the ECU are not met to
perform the WriteDataByLocalIdentifier service.
This code shall be returned if the the service is allowed in the current session but
the addressed RecordLocalIdentifier is not accessible in this session.
This code shall be sent if the LocalID, which reference a specific address, is
secured and the ECU is not in an unlocked state.
$72 generalProgrammingFailure M GPF
This return code shall be sent if the server detects an error when writing to a
memory location.
This NRC is applicable only when a long execution time services is in progress,
see § 9.1.2.2.

RENAULT 36 - 00 - 013 / - - C
9.3.7. $2E - WriteDataByIdentifier service
The WriteDataByIdentifier service allows the tool to write information into the server at an internal
location specified by the provided data identifier.
The WriteDataByIdentifier service is used by the tool to write a dataRecord to an ECU. The data is
identified by a dataIdentifier, and may or may not be secured. It is the function manager’s
responsibility that the ECU conditions are met when performing this service.
NOTE: The ECU may restrict or prohibit write access to certain dataIdentifier values (as defined by
the system supplier / function manager for read-only identifiers, etc.).

Byte
#1 WriteDataByIdentifier Request Service Id M $2E WDBI
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 ] M $00-$FF B2
dataRecord[] = [ DREC_
: : : : :
#m+3 data#m ] U $00-$FF DATA_m

Definition
dataIdentifier
This parameter identifies the ECU data record that the tool is requesting to write to (see 0 of this document
dataRecord
This parameter provides the data record associated with the dataIdentifier that the tool is requesting to write
to.

RENAULT 36 - 00 - 013 / - - C

Byte
#1 WriteDataByIdentifier Response Service Id M $6E WDBIPR
#2 byte#1 (MSB) M $00-$FF B1
#3 byte#2 ] M $00-$FF B2

Definition
dataIdentifier
$12 subFunctionNotSupported-InvalidFormat M SFNS
This response code shall be sent if
1. The length of the message is wrong.
2. The dataIdentifier in the request message is not supported in the ECU or the
dataIdentifier is supported for read only purpose (via ReadDataByIdentifier
service).
Any data transmitted in the request messager after the dataIdentifier is invalid (if
applicable to the node).
This response code shall be sent if the operating conditions of the ECU are not
met to perform the required action.
This code shall be returned if the the service is allowed in the current session but
the addressed Data Identifier is not accessible in this session
This code shall be sent if the dataIdentifier, which reference a specific address, is
secured and the ECU is not in an unlocked state.

RENAULT 36 - 00 - 013 / - - C

This return code shall be sent if the ECU detects an error when writing to a
memory location.
see § 9.1.2.2.

RENAULT 36 - 00 - 013 / - - C
9.3.8. $3D - WriteMemoryByAddress service
The WriteMemoryByAddress service allows the tool to write information into the ECU at one or more
contiguous memory locations.
The WriteMemoryByAddress request message writes information specified by the parameter

dataRecord[] into the ECU at memory locations specified by the parameter memoryAddress. The
number of bytes used for the memoryAddress parameter is 4.
The format and definition of the dataRecord is application specific, and may or may not be secured. It
is the function manager responsibility to assure that the ECU conditions are met when performing this
service. Possible uses for this service are:
- clear non-volatile memory,
- change calibration values.
IMPORTANT (security and protection)
The supplier has access to the microprocessor registers and its peripherals; the writing of these
components, via this service, may seriously interfere with the operation of the ECU. It is therefore
imperative that he install an address filter to avoid such incidents. The specification of this filter shall
be provided by the supplier to the function manager.
Certain information items must remain completely inaccessible to this service. The address filters to be
installed shall be negotiated between the function manager and the supplier (example: “lock code” on
the engine management system or on all ECUs contributing to the vehicle immobilization function).

Byte
#1 WriteMemoryByAddress Request Service Id M $3D WMBA
memoryAddress[ ] = [ MA_
#2 byte#1 (MSB) M $00-$FF B1
: : : : :
#5 byte#4 ] M $00-$FF B4
dataRecord[] = [ DREC_
: : : : :
#n data#m ] U $00-$FF DATA_m

RENAULT 36 - 00 - 013 / - - C

Definition
memoryAddress
The parameter memoryAddress is the starting address of ECU memory to which data is to be written. The
number of bytes used for this address is 4. Byte#4 in the memoryAddress parameter is always the least
significant byte of the address being referenced in the ECU. 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 ECU 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.
dataRecord
This parameter provides the data that the tool is actually attempting to write into the ECU memory addresses
within the interval {$MA, ($MA + n-6)}.

Byte
#1 WriteMemoryByAddress Response Service Id M $7D WMBAPR
memoryAddress[] = [ MA_
#2 byte#1 (MSB) M $00-$FF B1
: : : : :
#5 byte#4 ] M $00-$FF B4

Definition
memoryAddress
This parameter is an echo of the memoryAddress from the request message.

RENAULT 36 - 00 - 013 / - - C

1. The length of the message is wrong
2. Any memory address within the interval [$MA, ($MA + n-6)] is invalid.
3. Any memory address within the interval [$MA, ($MA + n-6)] is restricted.
4. The memorySize parameter value in the request message is greater than the
maximum value supported by the ECU.
This response code shall be sent if the operating conditions of the ECU are not
met to perform the required action.
This code shall be sent if any memory address within the interval [$MA, ($MA +
n-6)] is secured and the ECU is locked.
memory location.
see § 9.1.2.2.

RENAULT 36 - 00 - 013 / - - C
9.4. STORED DATA TRANSMISSION FUNCTIONAL UNIT
9.4.1. $14 - ClearDiagnosticInformation Service
The ClearDiagnosticInformation service is used by the tool to clear diagnostic information in an ECUs’
memory.
The ECU shall send a positive response when the ClearDiagnosticInformation service is completely
processed. The ECU shall send a positive response even if no DTC's are stored. If an ECU supports
multiple copies of DTC status information in memory (e.g. one copy in RAM and one copy in
EEPROM), the ECU shall clear the copy used by the ReadDTCInformation status reporting service
followed by the remaining copy.
The request message of the tool contains 1 parameter. The parameter groupOfDTC allows the tool to
clear a group of DTC's (e.g., Powertrain, Body, Chassis, etc.), or a specific DTC. Unless otherwise
stated, the ECU shall clear both emissions-related and non emissions-related DTC information
from memory for the requested group.
DTC information reset / cleared via this service includes but is not limited to the following :
- DTC status byte (see ReadDTCInformation service in section 9.4.2.),
- captured DTC snapshot data (DTCSnapShotData, see ReadDTCInformation service in

section 9.4.2.),
- captured DTC extended data (DTCExtendedData, see ReadDTCInformation service in section

9.4.2),
- other DTC related data such as first/most recent DTC, flags, counters, timers, etc. specific to
DTC's.
- CAN network autodiagnostic counters included in LocalIdentifiers defined for networks diagnostic
($82, $85-$8F).
Any DTC information stored in an optionally available DTC mirror memory in the ECU is not affected
by this service (see ReadDTCInformation (19 hex) service in section 9.4.2. for DTC mirror memory
definition).

#1 ClearDiagnosticInformation Request Service Id M $14 CDTCI
groupOfDTC[] = [ GODTC_
#2 groupOfDTCHighByte M $00-$FF HB
#3 groupOfDTCMiddleByte M $00-$FF MB
#4 groupOfDTCLowByte ] M $00-$FF LB
There are no sub-function parameters used by this service.

RENAULT 36 - 00 - 013 / - - C
The following data-parameter is defined for this service.

Definition
groupOfDTC
This parameter contains a 3-byte value indicating the group of DTC's. The definition of values for each
value/range of values is included in the following table
Table 111 — Definition of groupOfDTC and range of DTC numbers

$000000 Emissions-related DTCs U ERS
$000001 - Reserved U PG
$FFFFFE
$FFFFFF All Groups (all DTC's) M AG

#1 ClearDiagnosticInformation Response Service Id M $54 CDTCIPR
There are no data parameters used by this service in the positive response message.
The length of the message is wrong
This return code shall be sent if the specified groupOfDTC parameter is not
supported.
$22 conditionsNotCorrect C CNC
This response code shall be used if conditions within the ECU prevent the
clearing of DTC related information stored in the ECU.
The function manager shall list all these conditions
Presence of a failure is not to be considered as such a preventing condition
memory location.

RENAULT 36 - 00 - 013 / - - C
9.4.2. $19 – ReadDTCInformationService
This service allows the tool to read the status of Diagnostic Trouble Code (DTC) information from any
ECU. The service is based on Sub-functions. The exact description is available below on a per sub-
function basis.
9.4.2.2. sub-function definition
The sub-function parameters are used by this service to select one of the DTC report types specified
in the table below.
Table 114 — subFunction definition
Hex Description Cvt. Mnem.
Not allowed
$00 F
Reserved by the document
reportNumberOfDTCByStatusMask
$01 This parameter specifies that the ECU shall transmit to the tool the U RNODTCBSM
number of DTC's matching a tool defined status mask.
reportDTCByStatusMask
$02 This parameter specifies that the ECU shall transmit to the tool a list of M RDTCBSM
DTC's and corresponding statuses matching a tool defined status mask.
reportDTCSnapshotIdentification
This parameter specifies that the ECU shall transmit to the tool all
$03 DTCSnapshot data record identifications (DTC number(s) and U RDTCSSI
DTCSnapshot record number(s)).
Snapshot is same function as FreezeFrameData.
reportDTCSnapshotRecordByDTCNumber (FreezeFrameData)
This parameter specifies that the ECU shall transmit to the tool the RDTCSSBDT
$04 U
DTCSnapshot record(s) associated with a tool defined DTC number C
and DTCSnapshot record number.
reportDTCExtendedDataRecordByDTCNumber
This parameter specifies that the ECU shall transmit to the tool the RDTCEDRBD
$06 M
DTCExtendedData record(s) associated with a tool defined DTC N
number and DTCExtendedData record number (FF hex for all records).
reportSupportedDTC
$0A This parameter specifies that the ECU shall transmit to the tool a list of U RSUPDTC
all DTC's and corresponding statuses supported within the ECU.
reportFirstTestFailedDTC
This parameter specifies that the ECU shall transmit to the tool the first
$0B failed DTC to be detected by the ECU since the last clear of diagnostic U RFTFDTC
information. Note that the information reported via this sub-function
parameter shall be independent of whether or not the DTC was
confirmed or aged.

RENAULT 36 - 00 - 013 / - - C

reportFirstConfirmedDTC
This parameter specifies that the ECU shall transmit to the tool the first
confirmed DTC to be detected by the ECU since the last clear of
diagnostic information.
$0C The information reported via this sub-function parameter shall be U RFCDTC
independent of the aging process of confirmed DTC's (e.g. if a DTC
ages such that its status is allowed to be reset, the first confirmed DTC
record shall continue to be preserved by the ECU, regardless of any
other DTC's that become confirmed afterwards).
reportMostRecentTestFailedDTC
This parameter specifies that the ECU shall transmit to the tool the most
recent failed DTC to be detected by the ECU since the last clear of
$0D diagnostic information. Note that the information reported via this sub- U RMRTFDTC
function parameter shall be independent of whether or not the DTC was
confirmed or aged.
reportMostRecentConfirmedDTC
This parameter specifies that the ECU shall transmit to the tool the most
recent confirmed DTC to be detected by the ECU since the last clear of
diagnostic information.
$0E Note that the information reported via this sub-function parameter shall U RMRCDTC
be independent of the aging process of confirmed DTC's (e.g. if a DTC
ages such that its status is allowed to be reset, the first confirmed DTC
record shall continue to be preserved by the ECU assuming no other
DTC's become confirmed afterwards).
reportMirrorMemoryDTCByStatusMask
This parameter specifies that the ECU shall transmit to the tool a list of
RMMDTCBS
$0F DTC's out of the DTC mirror memory and corresponding statuses U
M
matching a tool defined status mask.
reportMirrorMemoryDTCExtendedDataRecordByDTCNumber
This parameter specifies that the ECU shall transmit to the tool the
DTCExtendedData record(s) - out of the DTC mirror memory - RMMDEDRB
$10 U
associated with a tool defined DTC number and DTCExtendedData DN
record number (FF hex for all records) DTC's.
reportNumberOfMirrorMemoryDTCByStatusMask
RNOMMDTCB
$11 number of DTC's out of mirror memory matching a tool defined status U
SM
mask.
reportNumberOfEmissionsRelatedOBDDTCByStatusMask
RNOOBDDTC
$12 number of emissions-related OBD DTC's matching a tool defined status U
BSM
mask.
reportEmissionsRelatedOBDDTCByStatusMask
This parameter specifies that the ECU shall transmit to the tool a list of
ROBDDTCBS
$13 emissions-related OBD DTC's and corresponding statuses matching a U
M
tool defined status mask.

RENAULT 36 - 00 - 013 / - - C

$14 reportDTCFaultDetectionCounter U RDTCFDC
This parameter specifies that the server shall transmit to the client a list
of current "prefailed" DTCs which have or have not yet been detected
as "pending" or "confirmed".
The intention of the DTCFaultDetectionCounter is a simple method to
identify a growing or intermittent problem which can not be
identified/read by the statusOfDTC byte of a particular DTC. The
internal implementation of the DTCFaultDetectionCounter shall be
vehicle manufacturer specific (e.g., number of bytes, signed versus
unsigned, etc.) but the reported value shall be a scaled 1 byte signed
value so that +127 (7F hex) represents a test result of "failed" and any
other non-zero positive value represents a test result of "prefailed".
However DTCs with DTCFaultDetectionCounter with the value +127
shall not be reported according to below stated rule. The
DTCFaultDetectionCounter shall be incremented by a vehicle
manufacturer specific amount each time the test logic runs and
indicates a fail for that test run.
A reported DTCFaultDetectionCounter value greater than zero and less
than +127 (i.e., 01 hex – 7E hex) indicates that the DTC enable criteria
was met and that a non completed test result prefailed at least in one
condition or threshold.
Only DTCs with DTCFaultDetectionCounters with a non-zero positive
value less than +127 (7F hex) shall be reported.
The DTCFaultDetectionCounter shall be decremented by a vehicle
manufacturer specific amount each time the test logic runs and
indicates a pass for that test run. If the DTCFaultDetectionCounter is
decremented to zero or below the DTC shall no longer be reported in
the positive response message. The value of the
DTCFaultDetectionCounter shall not be maintained between operation
cycles.
If a ClearDiagnosticInformation service request is received the
DTCFaultDetectionCounter value shall be reset to zero for all
DTCs. Additional reset conditions shall be defined by the vehicle
manufacturer. Refer to annex B2 for example implementation
details.
$05 Not allowed
$07-$09 Reserved by the document F
$14-$FF
All sub-functions shall be supported in any session including default session. Sub-functions $0F, $10
and $11 (related to MirrorMemory) may be protected by a security access.

RENAULT 36 - 00 - 013 / - - C
9.4.2.3. Parameter definition
All the sub-functions detailed in the previous section are using the following parameters:
DTCStatusMask
Contains eight (8) DTC status bits. The definitions for each of the eight (8) bits are specified in the
table below. This byte is used in the request message to allow a tool to request DTC information for
the DTC's whose status matches the DTCStatusMask. A DTC’s status matches the DTCStatusMask if
any one of the DTC’s actual status bits is set to ‘1’ and the corresponding status bit in the
DTCStatusMask is also set to ‘1’ (i.e., if the DTCStatusMask is bit-wise logically ANDed with the
DTC’s actual status and the result is non-zero, then a match has occurred). If the tool specifies a
status mask that contains bits that the ECU does not support, then the ECU shall process the DTC
information using only the bits that it does support.
7
result ( DTCj ) = ∑ bji • mi • SAMi
Matching result can be expressed as: i =0 where mi is bit i of the
requetsd DTCstatusMask, bji is the status bit i of the DTCj and SAMi is bit i of the Status availability
mask indicating the status bits supported by the ECU for all the DTCs; if result is different from ‘0’ then
the corresponding DTC matches the request criteria.
DTC status information shall be cleared upon a successful ClearDiagnosticInformation request from
the tool (see DTC status bit definitions in table below for further descriptions on the DTC status bit
handling in case of a ClearDiagnosticInformation service request reception in the ECU).
The monitoring cycle has been replaced in UDS by the concept of Operation cycle defined below :
Operation Cycle: An operation cycle defines the start and end conditions for monitors to run. During an
operation cycle several monitoring cycles may have passed (regardless of their test results). An ECU
may support several operation cycles. For body and chassis ECU's it is up to the manufacturer to
define an operation cycle (e.g. time between powering up and powering down the ECU or between
ignition on and ignition off). For powertrain ECU's, there are additional criteria defining an operation
cycle. Emissions-related powertrain ECU's use an engine-running or engine-off time period to define
an operation cycle which is referred to as driving cycle
Table 115 — DTC status bits definition
OBD Non
bit Description OBD Mnem
Cvt Cvt
TestFailed
This bit shall indicate the result of the most recently performed test.
A logical ‘1’ shall indicate that the last test failed. Reset to logical '0'
0 if the result of the most recently performed test returns a “pass” U C1 TF
result.
Reset to logical '0' if a call has been made to
ClearDiagnosticInformation.

RENAULT 36 - 00 - 013 / - - C
OBD Non
Cvt Cvt
TestFailedThisOperationCycle
This bit shall indicate whether or not a diagnostic test has reported a
TestFailed result at any time during the current Operation cycle (or
that a TestFailed result has been reported during the current
Operation cycle and after the last time a call was made to
1 ClearDiagnosticInformation). Reset to logical '0' when a new M C1 TFTMC
Operation cycle is initiated.
If this bit is set to logical '1', it shall remain a '1' until a new
monitoring cycle is started.
Reset to a logical ‘0’ after a call to ClearDiagnosticInformation.
pendingDTC
This bit shall indicate whether or not a diagnostic test has reported a
testFailed result at any time during the current or last completed
Operation cycle. The status shall only be updated if the test runs and
completes. The criteria to set the pendingDTC bit and the
TestFailedThisOperationCycle bit are the same. The difference is
2 that the testFailedThisOperationCycle is cleared at the end of the M U PDTC
current Operation cycle and the pendingDTC bit is not cleared until
an Operation cycle has completed where the test has passed at
least once and never failed.
If the test did not complete during the current Operation cycle, the
status bit shall not be changed.

RENAULT 36 - 00 - 013 / - - C
OBD Non
Cvt Cvt
confirmedDTC
This bit shall indicate whether a malfunction was detected enough
times to warrant that the DTC is stored in long-term memory
(pendingDTC has been set = '1' one or more times, depending on
the DTC confirmation criteria).
A confirmedDTC does not always indicate that the malfunction is
necessarily present at the time of the request. (pendingDTC or
3 testFailedThisOperationCycle can be used to determine if a M M CDTC
malfunction is present at the time of the request.).
Reset to logical '0' after a call to ClearDiagnosticInformation or after
aging criteria has been satisfied (e.g., 40 engine warm-ups without
another detected malfunction).
DTC confirmation and aging criteria are defined by the function
manager or mandated by On Board Diagnostic regulations.
testNotCompletedSinceLastClear
This bit shall indicate whether a DTC test has ever run and
completed since the last time a call was made to
ClearDiagnosticInformation. One ('1') shall indicate that the DTC test
4 C2 C2 TNCSLC
has not run to completion. If the test runs and passes or if the test
runs and fails (testFailedThisOperationCycle = '1') then the bit shall
be set to a '0' (and latched).
testFailedSinceLastClear
This bit shall indicate whether a DTC test has ever returned a
testFailedThisOperationCycle = '1' result since the last time a call
was made to ClearDiagnosticInformation (latched
5 testFailedThisOperationCycle = '1'). C2 C2 TFSLC
Zero ('0') shall indicate that the test has not run or that the DTC test
ran and passed (but never failed). If the test runs and fails then the
bit shall remain latched at a '1'.
testNotCompletedThisOperationCycle
This bit shall indicate whether a DTC test has ever run and
completed during the current Operation cycle (or completed during
the current Operation cycle after the last time a call was made to
ClearDiagnosticInformation).
6 M U TNCTMC
A logical '1' shall indicate that the DTC test has not run to completion
during the current Operation cycle. If the test runs and passes or
fails then the bit shall be set (and latched) to '0' until a new
Operationcycle is started.

RENAULT 36 - 00 - 013 / - - C
OBD Non
Cvt Cvt
warningIndicatorRequested
This bit shall report the status of any warning indicators associated
with a particular DTC. Warning outputs may consist of indicator
lamp(s), displayed text information, etc. If no warning indicators exist
for a given system or particular DTC, this status shall default to a
logic '0' state.
7 M U WIR
Conditions for activating the warning indicator shall be defined by the
function manager / implementation, but if the warning indicator is on
for a given DTC, then confirmedDTC shall also be set to '1'.
Additional reset conditions shall be defined by the function manager
/ implementation.
C1: Bit 1 (testFailedThisOperationCycle) is Mandatory if bit 2 (pendingDTC) is supported.
Bit 1 (testFailedThisOperationCycle) is FREE if bit 2 (pendingDTC) is not supported.
At least one bit is Mandatory among bit 0 and bit 1
C2: Bit 4 (testNotCompletedSinceLastClear) and bit 5 (testFailedSinceLastClear) shall always be
supported together
DTCRecord
3-byte value containing DTCHighByte, DTCMiddleByte and DTCLowByte as defined in ISO 15031-6..
Depending on the application, two configurations are possible.
Case 1 : DTC low byte set to $00, mainly applicable in older powertrain applications
DTCHighByte and DTCMiddleByte represents a 2 bytes DTC as specified in ISO 15031-6 figure 9.
Function manager shall specify for each value of such defined DTC the associated deviceIdentifier
and failureTypeByte.
Table 116 — OBD DTC example

OBD DTC Device and failure type OBD deviceIdentifier failureTypeByte
P0001 Fuel Volume Regulator Control Circuit/Open Circuit Open ($13)
P0002 Fuel Volume Regulator Control Circuit Fuel Volume Range/Performance
Range/Performance Regulator Control
P0003 Fuel Volume Regulator Control Circuit Low Circuit Id Low
P0004 Fuel Volume Regulator Control Circuit High High
P0005 Fuel Shutoff Valve "A" Control Circuit/Open Fuel Shutoff Valve Circuit Open ($13)
P0006 Fuel Shutoff Valve "A" Control Circuit Low "A" Control Circuit Low
Id
P0007 Fuel Shutoff Valve "A" Control Circuit High High
The conversion table is maintained by Renault / Nissan responsible departments for diagnostic
services.
Case 2 : DTC Low byte different from $00 (recommended for new designs)
DTCLowByte is FailureTypeByte as defined in annex D of ISO 15031-6.
DTCHighByte and DTCMiddleByte represents a unique 2 bytes deviceIdentifier.

RENAULT 36 - 00 - 013 / - - C
DTCSnapshotRecordNumber
1-byte value indicating the number of the specific DTCSnapshot data record requested for
a tool defined DTCMaskRecord via the reportDTCSnapshotByDTCNumber / sub-functions. For
emissions-related servers (OBD compliant ECUs) the DTCSnapshot data record number 00 hex shall
be the equivalent data record as specified in ISO 15031-5 service 02 hex frame number 00 hex. For
ECU that do support multiple DTCSnapshot data records for a single DTC, the tool shall set this to a
value ranging from $01 hex to the maximum number supported by the ECU (which may range up to
$FE hex, depending on the ECU). A value of $FF hex requests the ECU to report all stored
DTCSnapshot data records at once.
DTCExtendedDataRecordNumber
1-byte value indicating the number of the specific DTCExtendedData record requested for a tool
defined DTCMaskRecord via the reportDTCExtendedDataRecordByRecordNumber sub-function.. For
emissions-related servers (OBD compliant ECUs) the DTCExtendedDataRecordNumber 00 hex shall
be reserved for future OBD use. A DTCExtendedDataRecordNumber value in the range of 01 hex
through FE hex requests the server to report the stored DTCExtendedData record. A value of $FF
hex requests the ECU to report all stored DTCExtendedData records at once. All ECU should have the
function for receiving the value of $FF hex.
Table 117 — DTCExtendedDataRecordNumber definition

DTCExtended
DataRecord Description RENAULT NISSAN
Number
Mileage: Mileage, in km, upon last DTC confirmation.
$80 C1 C1
mileage : the most recent failure detection
AgingCounter: number of monitoring cycles since a DTC was
latest confirmed.
$81 U U
(AgingCounter– FailedMonitoringCycle as defined in ISO 14229-
1)
DTCOccurrenceCounter: The number of
$82 C2 C2
“TestFailedThisMonitoringCycle” occurrence.
Request All: Request all stored DTCExtendedData records at
$FF C2 C2
once
$00-$7F
Not allowed: Reserved by the document F F
$83-$FE
C1: Mandatory in systems where mileage information is avalable.
C2: If bit 1 of the status byte is not supported then Data record $82 cannot be supported. If bit 1 is
supported then use of Data record $82 is user optional.

RENAULT 36 - 00 - 013 / - - C
Table 118 — DTCExtendedData definition

Definition
Mileage
This extended data is encoded over 3 bytes unsigned integer with big endian byte ordering. This data is
available only when the “ConfirmedDTC” status bit is set to 1.
If the mileage has not been received once at the time of failure detection, the stored value is 0xFF FF FF.
If mileage information is not avalable in the system, this Extended data is not supported by ECU.
AgingCounter
1 byte unsigned integer value. Maximum value is system dependant (refer to system specific diagnostic
specification for appropriate value). When maximum value is reached counter is frozen or the DTC is cleared
(system dependant, refer to system specific diagnostic specification for appropriate behaviour). This data is
available only when the “ConfirmedDTC” status bit is set to 1. Initial value is 0. Reset to 0 upon reception of a
ClearDiagnosticInformation service.
DTCOccurenceCounter
1 byte unsigned integer value. Maximum value is 255. When maximum value is reached counter is frozen.
When supported, this data is always available. Initial value is 0. Reset to 0 upon reception of a
ClearDiagnosticInformation service.

RENAULT 36 - 00 - 013 / - - C
9.4.2.4. SubFunction = reportNumberOfDTCByStatusMask,

reportNumberOfMirrorMemoryDTCByStatusMask,
reportNumberOfEmissionsRelatedOBDDTCByStatusMask
9.4.2.4.1.Service Description
A tool can retrieve a count of the number of DTC's matching a tool defined status mask by sending a
request for this service with the sub-function set to reportNumberOfDTCByStatusMask. The response
to this request contains the DTCStatusAvailabilityMask, which provides an indication of DTC status
bits that are supported by the ECU for masking purposes.
The handling of the sub-function reportNumberOfMirrorMemoryDTCByStatusMask is identical to the

handling as defined for reportNumberOfDTCByStatusMask, except that all status mask checks are
performed with the DTC's stored in the DTC mirror memory of the ECU.
The DTC mirror memory is an additional optional error memory in the ECU that cannot be erased by
the ClearDiagnosticInformation (14 hex) service. The DTC mirror memory mirrors the normal DTC
memory and can be used for example if the normal error memory is erased. Use of mirror memory is
system dependant; refer to sytem specific diagnostic specification to determine whether a mirror
memory is required.
The handling of the sub-function reportNumberOfEmissionsRelatedOBDDTCByStatusMask is identical

to the handling as defined for reportNumberOfDTCByStatusMask, except that A tool can retrieve a
count of the number of "only emissions-related OBD" DTC's matching a tool defined status mask.
9.4.2.4.2.Request message
9.4.2.4.2.1. Request message definition

A_Data Parameter Name Cvt Hex Mnem
byte Value
#1 ReadDTCInformation request Service Id M $19 RDTCI
reportNumberOfDTCByStatusMask $01 RNODTCBSM
reportNumberOfMirrorMemoryDTCByStatusMask $11 RNOMMDTCBSM
reportNumberOfEmissionsRelatedOBDDTCByStatusMask $12 RNOOBDDTCBSM
#3 DTCStatusMask M $00- DTCSM
$FF
9.4.2.4.2.2. Request message data parameter definition

Table 120 — Request data parameter definition
Definition
DTCStatusMask
See § 9.4.2.3.

RENAULT 36 - 00 - 013 / - - C
9.4.2.4.3.Positive response message

Table 121 — Response message definition
#1 ReadDTCInformation response Service Id M $59 RDTCIPR
#2 reportType = [ M LEV_
reportNumberOfDTCByStatusMask $01 RNODTCBSM
reportNumberOfMirrorMemoryDTCByStatusMa $11 RNOMMDTCBSM
sk $12 RNOOBDDTCBS
reportNumberOfEmissionsRelatedOBDDTCByS M
tatusMask ]
#3 DTCStatusAvailabilityMask M $00-$FF DTCSAM
#4 DTCFormatIdentifier = [ M DTCFID_
ISO15031-6DTCFormat] $00 15031-6DTCF
DTCCount[] = [ DTCC_
#5 DTCCountHighByte M $00-$FF DTCCHB
#6 DTCCountLowByte ] M $00-$FF DTCCLB
9.4.2.4.4.Response data parameter definition

Table 122 — Response data parameter definition
Definition
DTCStatusAvailabilityMask
A byte whose bits are defined the same as statusOfDTC and represents the status bits that are supported by
the server. Bits that are not supported by the server shall be set to 0.
DTCFormatIdentifier
The DTCFormatIdentifier defines the format of a DTC. NISSAN&RENAULT use ISO15031-6 DTC Format.
This parameter is fixed to $00. If any other type of DTC Format is needed, the function manager and the
supplier have to explain to Renault / Nissan responsible departments for diagnostic services.
DTCCount
This 2-byte parameter refers collectively to the DTCCountHighByte and DTCCountLowByte parameters that
are sent in response to a reportNumberOfDTCByStatusMask or reportNumberOfMirrorMemoryDTC request.
DTCCount provides a count of the number of DTC’s that match the DTCStatusMask defined in the client’s
request.

RENAULT 36 - 00 - 013 / - - C
9.4.2.5. SubFunction = reportDTCByStatusMask,

reportMirrorMemoryDTCByStatusMask,
reportEmissionsRelatedOBDDTCByStatusMask
The tool can retrieve a list of DTC's, which satisfy a tool defined status mask.
The evaluation shall be done as follows: The ECU shall perform a bit-wise logical AND-ing operation
between the mask specified in the tool’s request and the actual status associated with each DTC
supported by the ECU. In addition to the DTCStatusAvailabilityMask, the ECU shall return all DTC’s
for which the result of the AND-ing operation is non-zero (i.e., (statusOfDTC & DTCStatusMask) != 0).
If the tool specifies a status mask that contains bits that the ECU does not support, then the ECU shall
process the DTC information using only the bits that it does support. If no DTC's within the ECU match
the masking criteria specified in the tool’s request, no DTC or status information shall be provided
following the DTCStatusAvailabilityMask byte in the positive response message.
Note regarding behavior towards DTCs linked to configuration parameters:

These DTCs are associated to optional ECU peripherals or functions configured during vehicle
assembly process for adapting the ECU to the host vehicle. Such DTC shall never be returned to the
tool in the positive response whatever the requested status mask as long as the related function or
peripheral is not supported.
Refer to the ECU specific diagnostic service specification for applicable list of optional DTCs and
associated configuration parameters.
The handling of the sub-function reportMirrorMemoryDTCByStatusMask is identical to the handling as

defined for reportDTCByStatusMask, except that all status mask checks are performed with the DTC's
stored in the DTC mirror memory of the ECU.
The handling of the sub-function reportOnlyEmissionsRelatedOBDDTCByStatusMask is identical to

the handling as defined for reportDTCByStatusMask, except that all status mask checks are
performed with the OBD DTC.

Value
reportDTCByStatusMask $02 RDTCBSM
reportMirrorMemoryDTCByStatusMask $0F RMMDTCBSM
reportEmissionsRelatedOBDDTCByStatusMask ] $13 ROBDDTCBSM
#3 DTCStatusMask M $00-$FF DTCSM

Definition
DTCStatusMask
See § 9.4.2.3.

RENAULT 36 - 00 - 013 / - - C
9.4.2.5.3.1. Positive response message definition

reportDTCByStatusMask $02 RDTCBSM
reportMirrorMemoryDTCByStatusMask $0F RMMDTCBSM
reportEmissionsRelatedOBDDTCByStatusMa $13 ROBDDTCBS
sk ] M
DTCAndStatusRecord[] = [ DTCASR_
#4 DTCHighByte#1 C1 $00-$FF DTCHB
#5 DTCMiddleByte#1 C1 $00-$FF DTCMB
#6 DTCLowByte#1 C1 $00-$FF DTCLB
#7 statusOfDTC#1 C1 $00-$FF SODTC
#9 DTCMiddleByte #2 C2 $00-$FF DTCMB
: : : : :
#n-3 DTCHighByte#m C2 $00-$FF DTCHB
#n-2 DTCMiddleByte#m C2 $00-$FF DTCMB
#n-1 DTCLowByte#m C2 $00-$FF DTCLB
#n statusOfDTC#m ] C2 $00-$FF SODTC
C1: This parameter is only present if at least one DTC information is available to be reported.
C2: This parameter is present if more than one DTC information is available to be reported.
9.4.2.5.3.2. Positive response message data parameter definition

Definition
DTCAndStatusRecord
This parameter record contains one or more groupings of either DTCHighByte, DTCMiddleByte, DTCLowByte
and statusOfDTC.

RENAULT 36 - 00 - 013 / - - C
9.4.2.6. SubFunction = reportDTCSnapshotIdentification
A tool can retrieve DTCSnapshot record identification information for all captured DTCSnapshot
records by sending a request for this service with the sub-function set to
reportDTCSnapshotIdentification. The ECU shall return the list of DTCSnapshot record identification
information for all stored DTCSnapshot records. Each item the ECU places in the response message
for a single DTCSnapshot record shall contain a DTCRecord (containing the DTC number (high,
middle, and low byte)) and the DTCSnapshot record number. In case multiple DTCSnapshot records
are stored for a single DTC then the ECU shall place one item in the response for each occurrence,
using a different DTCSnapshot record number for each occurrence (used for the later retrieval of the
record data).
NOTE: ECU may support the storage of multiple DTCSnapshot records for a single DTC to track
conditions present at each occurrence of the DTC. Support of this functionality, definition of
“occurrence” criteria, and the number of DTCSnapshot records to be supported shall be
defined by the function manager.

Value
reportDTCSnapshotIdentification $03 RDTCSSI
9.4.2.6.2.2. Request data parameter definition
There is no data parameter for this sub function.

RENAULT 36 - 00 - 013 / - - C
9.4.2.6.3.1. Positive response message definition

reportDTCSnapshotIdentification ] $03 RDTCSSI
DTCRecord[] #1 = [ DTCASR_
#5 DTCLowByte#1 ] C1 $00-$FF DTCLB
#6 DTCSnapshotRecordNumber #1 C1 $00-$FF DTCSSRN
: : : : :
DTCRecord[] #m = [ DTCASR_
#n-1 DTCLowByte#m ] C2 $00-$FF DTCLB
#n DTCSnapshotRecordNumber #m C2 $00-$FF DTCSSRN
C1: The DTCRecord and DTCSnapshotRecordNumber parameter is only present if at least one
DTCSnapshot record is available to be reported.
C2: The DTCRecord and DTCSnapshotRecordNumber parameter is only present if more than one
DTCSnapshot record is available to be reported.

Definition
DTCRecord
See § 9.4.2.3.
See § 9.4.2.3.

RENAULT 36 - 00 - 013 / - - C
9.4.2.7. SubFunction = reportDTCSnapshotRecordByDTCNumber
A tool can retrieve captured DTCSnapshot record data for either a tool defined DTCMaskRecord in
conjunction with a DTCSnapshot record number by sending a request for this service with the sub-
function set to reportDTCSnapshotRecordByDTCNumber.
If the ECU supports the ability to store multiple DTCSnapshot records for a single DTC (support of this
functionality to be defined by the function manager), then it is recommended that the ECU also
implement the reportDTCSnapshotRecordIdentification sub-function parameters.
The ECU shall report one DTCSnapshot record in a single response message, except if the tool has
set the DTCSnapshotRecordNumber to FF hex, because this shall cause the ECU to response with all
DTCSnapshot records stored for the tool defined DTCMaskRecord in a single response message.
The ECU shall negatively respond if the DTCMaskRecord or DTCSnapshotRecordNumber parameters

specified by the tool are invalid or not supported by the ECU. If the parameters are supported but the
ECU has no DTCSnapshot data associated with it (e.g., because a failure event never occurred for the
specified DTC or record number), The ECU shall send the positive response containing only the
DTCAndStatusRecord (echo of the requested DTC number (high, middle, and low byte) plus the
statusOfDTC).

Value
reportDTCSnapshotRecordByDTCNumber ] $04 RDTCSSBDTC
DTCMaskRecord[] = [ DTCMREC_
#3 DTCHighByte M $00-$FF DTCHB
#4 DTCMiddleByte M $00-$FF DTCMB
#5 DTCLowByte ] M $00-$FF DTCLB
#6 DTCSnapshotRecordNumber M $00-$FF DTCSSRN

Definition
DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]
DTCMaskRecord is a 3-byte value containing DTCHighByte, DTCMiddleByte and DTCLowByte, which
together represent a unique identification number for a specific diagnostic trouble code supported by an ECU.
The definition of the 3-byte DTC number shall be done by using the decoding of the DTCHighByte,
DTCMiddleByte and DTCLowByte according to the ISO 15031-6 specification.
See § 9.4.2.3.

RENAULT 36 - 00 - 013 / - - C
9.4.2.7.3.1. Response message definition

reportDTCSnapshotRecordByDTCNumber ] $04 RDTCSSBDTC
#5 DTCLowByte M $00-$FF DTCLB
#6 statusOfDTC ] M $00-$FF SODTC
#7 DTCSnapshotRecordNumber #1 C1 $00-$FF DTCSSRN
#8 DTCSnapshotRecordNumberOfIdentifiers #1 C1 $00-$FF DTCSSRNI
DTCSnapshotRecord[] #1 = [ DTCSSR_
#9 dataIdentifier#1 byte #1 (MSB) C1 $00-$FF DIDB11
#10 dataIdentifier#1 byte #2 C1 $00-$FF DIDB12
#11 snapshotData#1 byte #1 C1 $00-$FF SSD11
: : C1 : :
#11+(p-1) snapshotData#1 byte #p C1 $00-$FF SSD1p
: : : : :
#r-(m-1)-2 dataIdentifier#w byte #1 (MSB) C2 $00-$FF DIDB21
#r-(m-1)-1 dataIdentifier#w byte #2 C2 $00-$FF DIDB22
#r-(m-1) snapshotData#w byte #1 C2 $00-$FF SSD21
: : C2 : :
#r snapshotData#w byte #m ] C2 $00-$FF SSD2m
: : : : :
#t DTCSnapshotRecordNumber #x C3 $00-$FF DTCSSRN
#t+1 DTCSnapshotRecordNumberOfIdentifiers #x C3 $00-$FF DTCSSRNI
DTCSnapshotRecord[] #x = [ DTCSSR_
#t+2 dataIdentifier#1 byte #1 (MSB) C3 $00-$FF DIDB11
#t+3 dataIdentifier#1 byte #2 C3 $00-$FF DIDB12
#t+4 snapshotData#1 byte #1 C3 $00-$FF SSD11
: : C3 : :
#t+4+(p-1) snapshotData#1 byte #p C3 $00-$FF SSD1p
: : : : :
#n-(u-1)-2 dataIdentifier#w byte #1 (MSB) C4 $00-$FF DIDB21
#n-(u-1)-1 dataIdentifier#w byte #2 C4 $00-$FF DIDB22
#n-(u-1) snapshotData#w byte #1 C4 $00-$FF SSD21
: : C4 : :
#n snapshotData#w byte #u ] C4 $00-$FF SSD2u
C1: The DTCSnapshotRecordNumber and the first dataIdentifier/snapshotData combination in the
DTCSnapshotRecord parameter is only present if at least one DTCSnapshot record is available to be reported
(DTCSnapshotRecordNumber unequal to $FF hex in the request or only one record is available to be reported if
DTCSnapshotRecordNumber is set to $FF hex in the request).
C2/C4 There are multiple dataIdentifier/snapshotData combinations allowed to be present in a single
DTCSnapshotRecord. This can e.g. be the case for the situation where a single dataIdentifier only references an
integral part of data. When the dataIdentifier references a block of data then a single dataIdentifier/snapshotData
combination can be used.
C3: The DTCSnapshotRecordNumber and the first dataIdentifier/snapshotData combination in the
DTCSnapshotRecord parameter is only present if all records are requested to be reported
(DTCSnapshotRecordNumber set to $FF hex in the request) and more than one record is available to be
reported.

RENAULT 36 - 00 - 013 / - - C

Definition
DTCAndStatusRecord
and statusOfDTC.
See 9.4.2.3
DTCSnapshotRecordNumberOfIdentifiers
This single byte parameter shows the number of dataIdentifiers in the immediately following
DTCSnapshotRecord.
DTCSnapshotRecord
The DTCSnapshotRecord contains a snapshot of data values from the time of the system malfunction
occurrence. DTCSnapshot information shall be cleared upon a successful ClearDiagnosticInformation
request from the tool. The function manager shall define format and content of the DTCSnapshotRecord.
Function manager should specify the deletion of stored DTCSnapshot data in case of a memory overflow
(memory space for stored DTCsnapshot data completely occupied in the ECU). Snapshot is same function as
FreezeFrameData.

RENAULT 36 - 00 - 013 / - - C
9.4.2.8. SubFunction = reportDTCExtendedDataRecordByDTCNumber,

reportMirrorMemoryDTCExtendedDataRecordByDTCNumber
A tool can retrieve DTCExtendedData for a tool defined DTCMaskRecord in conjunction with a
DTCExtendedDatarecord number by sending a request for this service.
Along with the DTC number and statusOfDTC, the ECU shall return a single pre-defined
DTCExtendedData record in response to the tool’s request (DTCSnapshotRecordNumber unequal FF
hex).
The ECU shall negatively respond if the DTCMaskRecord or DTCExtendedRecordNumber parameters

specified by the tool are invalid or not supported by the ECU. If the ExtendedDataRecord is supported
but the ECU has no available data associated with it (e.g., because a failure event never occurred for
the specified DTC), the ECU shall send the positive response containing only the
DTCAndStatusRecord (echo of the requested DTC number (high, middle, and low byte) plus the
statusOfDTC). If the DTCExtendedDataRecordNumber equals FF hex, the ECU shall return all
available ExtendedDataRecord.
Clearance of DTCExtendedData information upon the reception of a ClearDiagnosticInformation

service depends on the DTCExtendedDataRecordNumbe (see Table 118). It is in the responsibility of
the function manager to specify the rules for the deletion of stored DTC's and DTCExtendedData data
in case of a memory overflow (memory space for stored DTC related data, DTCSnapshot data and
ExtendedData, completely occupied in the ECU.
The handling of the sub-function reportMirrorMemoryDTCExtendedDataRecordByDTCNumber is

identical to the handling as defined for reportDTCExtendedDataRecordByDTCNumber, except that the
data is retrieved out of the DTC mirror memory.

Value
reportDTCExtendedDataRecordByDTCNumber $06 RDTCEDRBD
reportMirrorMemoryDTCExtendedDataRecordByD $10 N
TCNumber ] RMDEDRBDN
DTCMaskRecord[] = [ DTCMREC_
#5 DTCLowByte ] M $00-$FF DTCLB
#6 DTCExtendedDataRecordNumber M $00-$FF DTCEDRN

RENAULT 36 - 00 - 013 / - - C

Definition
DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]
DTCMaskRecord is a 3-byte value containing DTCHighByte, DTCMiddleByte and DTCLowByte, which
together represent a unique identification number for a specific diagnostic trouble code supported by an ECU.
The definition of the 3-byte DTC number shall be done by using the decoding of the DTCHighByte,
DTCMiddleByte and DTCLowByte according to the ISO 15031-6 specification.
See 9.4.2.3

reportDTCExtendedDataRecordByDTCNumber $06 RDTCEDRBD
reportMirrorMemoryDTCExtendedDataRecordByD $10 RMDEDRBDN
TCNumber ]
#5 DTCLowByte M $00-$FF DTCLB
#6 statusOfDTC ] M $00-$FF SODTC
#7 DTCExtendedDataRecordNumber #1 C1 $00-$FF DTCEDRN
DTCExtendedDataRecord[] #1 = [ DTCSSR_
#8 extendedData #1 byte #1 C1 $00-$FF EDD11
: : C1 : :
#8+(p-1) extendedData #1 byte #p ] C1 $00-$FF EDD1p
: : : : :
#t DTCExtendedDataRecordNumber #x C2 $00-$FF DTCEDRN
DTCExtendedDataRecord[] #x = [ DTCSSR_
#t+1 extendedData #x byte #1 C2 $00-$FF EDDx1
: : C2 $00-$FF :
#t+1+(p-1) extendedData #x byte #p ] C2 $00-$FF EDDxp
C1: The DTCExtendedDataRecordNumber and the extendedData in the DTCExtendedDataRecord
parameter are only present if at least one DTCExtendedDataRecord is available to be reported
(DTCExtendedDataRecordNumber unequal to $FF hex in the request or only one record is available to
be reported if DTCExtendedDataRecordNumber is set to $FF hex in the request).
C2: The DTCExtendedDataRecordNumber and the extendedData in the DTCExtendedDataRecord
parameter are only present if all records are requested to be reported
(DTCExtendedDataRecordNumber set to $FF hex in the request) and more than one record is available
to be reported.

RENAULT 36 - 00 - 013 / - - C
9.4.2.8.3.2. Response data parameter definition

Definition
DTCAndStatusRecord
and statusOfDTC.
See 9.4.2.3
DTCExtendedDataRecord
The DTCExtendedDataRecord is an ECU information that may contain extended status information
associated with a DTC. (e.g. IGN Counter) DTCExtendedData contains DTC paramter values, which have
been identified at the time of the request (see § 9.4.2.3. Table 118)
9.4.2.9. SubFunction = reportSupportedDTC
A tool can retrieve the status of all DTC's supported by the ECU by sending a request for this service
with the sub-function set to reportSupportedDTCs. The response to this request contains the
DTCStatusAvailabilityMask, which provides an indication of DTC status bits that are supported by the
ECU for masking purposes. Following the DTCStatusAvailabilityMask the response also contains the
listOfDTCAndStatusRecord, which contains the DTC number and associated status for every
diagnostic trouble code supported by the ECU.

Value
reportSupportedDTC $0A RSUPDTC

RENAULT 36 - 00 - 013 / - - C

reportSupportedDTCs] $0A RSUPDTC
#3 DTCStatusAvailabilityMask M $00-FF DTCSAM
#9 DTCMiddleByte #2 C2 $00-$FF DTCMB
: : : : :
#n-1 DTCLowByte#m C2 $00-$FF DTCLB
#n statusOfDTC#m ] C2 $00-$FF SODTC
C1: This parameter is only present if DTC information is available to be reported.
C2: This parameter is only present if more than one DTC information is available to be reported.

Definition
DTCAndStatusRecord
and statusOfDTC.

RENAULT 36 - 00 - 013 / - - C
9.4.2.10. SubFunction = reportFirstTestFailedDTC, reportFirstConfirmedDTC

reportMostRecentTestFailedDTC,
reportMostRecentConfirmedDTC
Retrieving the first / most recent failed DTC
The tool can retrieve the first failed, most recent failed, first confirmed or most recent confirmed DTC
from the ECU by sending a request with the sub-function byte set to “reportFirstTestFailedDTC”,
“reportMostRecentTestFailedDTC”, “reportFirstConfirmedDTC” or “reportMostRecentConfirmed DTC”,
respectively. Along with the DTCStatusAvailabilityMask, the ECU shall return corresponding DTC and
associated status to the tool.
No DTC or status information shall be provided following the DTCStatusAvailabilityMask byte in the
positive response message if there were no failed / confirmed DTC's logged since the last time the tool
requested the ECU to clear diagnostic information. Also, if only 1 DTC became failed / confirmed since
the last time the tool requested the ECU to clear diagnostic information, the lone failed / confirmed
DTC shall be returned to both reportFirstTestFailedDTC and reportMostRecentTestFailedDTC
requests or both reportFirstConfirmedDTC and reportMostRecentConfirmedDTC requests from the
tool.

Value
reportFirstTestFailedDTC $0B RFTFDTC
reportFirstConfirmedDTC $0C RFCDTC
reportMostRecentTestFailedDTC $0D RMRTFDTC
reportMostRecentConfirmedDTC ] $0E RMRCDTC

reportFirstTestFailedDTC $0B RFTFDTC
reportFirstConfirmedDTC $0C RFCDTC
reportMostRecentTestFailedDTC $0D RMRTFDTC
reportMostRecentConfirmedDTC ] $0E RMRCDTC

RENAULT 36 - 00 - 013 / - - C

#7 statusOfDTC#1 ] C1 $00-$FF SODTC
C1: This parameter is only present if DTC information is available to be reported.

Definition
DTCAndStatusRecord
and statusOfDTC.
9.4.2.11. Supported negative response codes(NRC_)
This code shall be returned if:
1. The ECU does not support the requested DTCMaskRecord.
2. The ECU does not support the requested
DTCSnapshotRecordNumber / DTCExtendedDataRecordNumber
3. The ECU does not support the requested sub-function
4. The length of the request message is wrong.
This code shall be returned if the operating conditions of the ECU are not
met to perform the ReadDTCInformation service.
This code shall be sent if the ReadDTCInformation requires an unlocked
ECU (for sub-functions $0F to $11 only)

RENAULT 36 - 00 - 013 / - - C
9.5. INPUT/OUTPUT CONTROL FUNCTIONAL UNIT
9.5.1. $30 - InputOutputControlByLocalIdentifier service
This service is used to substitute a value for an input signal or internal ECU function, it is used also to
control an ECU output (actuator). The entity control is according to a control cycle predefined in the
ECU.
A temporary control is a control which ends on its own. The control parameters are fixed and defined
in conjunction with the customers of this type of function (after-sales, assembly line process test, etc.)
and the supplier by the function manager. A temporary control may nevertheless be stopped before its
completion by the Stop control command from the tool.
There is a permanent control as opposed to a temporary control. The permanent control normally
requires a stop control from the tool.
In any case, if there is a risk of damaging the actuator by a too long permanent control, the ECU shall
be able to stop the control by itself.
The function manager defines the necessary security conditions enabling the system to allow a control
request. If the request is not allowed, a negative reply with NRC $22 - for applicative conditions not
met - or $33 – for control protected by securityAccess service - shall be sent by the ECU.
The ECU shall send a positive response message if the request message was successfully executed.
The positive response message shall include controlStatus information which is available during or
after the control execution.
For each control, the following items shall be detailed in the system specific diagnostic specification:
- Prerequisites to activate the control,
- Control duration,
- Normal control exit conditions,
- Emergency control exit conditions (controlled by ECU),
- ECU behavior after a stop requested by the tool or upon emergency exit conditions.
The Local Identifiers from range [$01 - $7F] supported by ECU can be retrieved by reserved LIDs $00,
$20, $40 and $60 as defined in §.9.1.5.

RENAULT 36 - 00 - 013 / - - C

#1 I/OControlByLocalIdentifier Request Service Id M $30 IOCBLID
#2 inputOutputLocalIdentifier = Input/Output number to M $xx IOLID
be controlled
#3 controlOption = Control parameter C1 $xx CRTLOPT1
#4 to n OptionalParameter C2 tbd CRTLOPTi
C1:: Present only if inputOutputLocalIdentifier different from $00 / $20 / $40 / $60 values. Mandatory for all
other values.
For inputOutputLocalIdentifier values $00 / $20 / $40 / $60 refer to § 9.1.5.1.
C2: Present only If Control Option is start control (permanent or temporary see § 9.5.1.2.2.) and the
specified IOLocalId needs parameters
The following data parameters are defined for this service.

Definition
inputOutputLocalIdentifier
The parameter identifies the ECU an ECU local input signal, internal parameter or output signal.
controlOption
The parameter is used to describe how the ECU has to control its inputs or outputs. The function manager
should not define any other parameter values
The conditions for using $00, $20 and $11 values are inputOutputLocalIdentifier dependant.
OptionalParameter
The parameters are defined by the function manager to manipulate the ECU input or output signal.
Table 147 — inputOutputLocalIdentifier definition

Hex Description Cvt
$00 Indicate LocalIdentifiers used in the ranges $01-20 M
$20,$40,$60 Indicate LocalIdentifiers used in the ranges $21-40, $41-60, $61-7F C
$01 - $1F
$21 - $3F
Free allocation for the function manager U
$41 -$5F
$61 - $7F
$FA - $FE Supplier specific affectation U
$80 – $F9, Not allowed : Reserved by the document F
$FF

RENAULT 36 - 00 - 013 / - - C
Table 148 — controlOption parameter definition

Hex Description Cvt
$00 Start temporary control C1
$20 Start permanent control C1
$01 Status request M
$11 Stop control C2
$02 – $10
$12 – $1F Not allowed : Reserved by the document F
$21 – $F9
$FA – $FE Supplier specific affectation U
$FF Not allowed : Reserved by the document F
C1: For each ID, ECU must support at least one start control option.
C2: For each ID, if “start permanent control” is supported then “Stop control” is Mandatory. If only temporary
control is supported then “stop control” is user optional.
9.5.1.3.1.Response message definition

#1 I/OControlByLocalIdentifier Response Service Id M $70 IOCBLIDPR

#2 inputOutputLocalIdentier = Input/Output number to be M $xx IOLID
controlled
#3 controlStatus M $xx CRTLSTAT1
#4 to m other controlStatus to be defined by the function U $xx CRTLSTATi
manager
For inputOutputLocalIdentifier values $00 / $20 / $40 / $60 refer to § 9.1.5.1.
9.5.1.3.2.Response message data parameter definition

Definition
inputOutputLocalIdentier
This parameter is an echo of the inputOutputLocalIdentier from the request message.
controlStatus
This parameter is used to give information about the status of the requested control and other related
information.
For “control in progress” value, the state has to exist in ECU even if tool is not able to read it enough quickly.
other controlStatus
This parameters are defined by the function manager to indicate additional status

RENAULT 36 - 00 - 013 / - - C
Table 151 — controlStatus definition
Hex Description Cvt

$00 Not allowed : Reserved by the document F
$01 Control in progress M
$02 Control complete and OK M
$11 Control stopped by ControlOption parameter set to “Stop Control” (11) C
$03 – $10 Not allowed : Reserved by the document for future standardized error codes F
$12 – $F9 Control aborted due to internal error, defined by function manager in the U
system specific diagnostic
$FA –$FE Supplier specific affectation U
9.5.1.4. Supported Negative response codes (NRC_)
1. The requested inputOutputLocalIdentievalue is not supported,
2. The requested controlOption is not supported / invalid.
This code shall be returned if the criteria for the request InputOutputControl are
not met.
If the ECU cannot support another LocalID’s I/O control service during I/O
control processing, the ECU should return negative response message with this
negative response code. Restriction on use of simultaneous Local ID’s I/O
control shall be detailed in the system specific diagnostic specification.
This code shall be returned if a tool sends a request with ControlOption
parameter equal to “start permanent/temporary control”and valid secure
IOLocalIdentifier and the ECU is locked.
This NRC is applicable only when a long execution time service is in progress,
see § 9.1.2.2.
See § 9.1.1.2.

RENAULT 36 - 00 - 013 / - - C
9.5.1.5. State machine diagram
Start control
Routine time is over *2

Control Complete Control in progress
Status: $02 Status: $01
Session timeout / Start control
Emergency exit
Session changed by SDS
Stop
ro l
Sess
Ses
*1
ont
Em
cont
ted
sion
ion c
rt c
erg
ues
rol re
Sta
enc
time
hang
req
ques
y ex
out
trol
ed b
it
con
ted
y SD
*1
p
Sto
S
Control was stopped

Status: $11 : ECU handling
*1 If ControlStatus $11 is not supported, the ControlStatus should change to $02

*2 Only for temporary control
This service is not supported in default session.
Before a control has ever been started in an operation cycle, the status is $02 “control complete and
ok”, i.e.If a status request is received before the control was started in the operation cycle, the returned
status shall be 0x02.
Fig. 12 — I/O control management
9.5.1.6. Response Timing
The ECU shall set current status to $01 when the request message with Start Control was
successfully executed then send a positive response message with CTRLSTAT1 = current status. The
ECU shall send a positive response message with CTRLSTAT1 = current status when subsequent
request messages with status request are received.
If a request with stop control is received and ECU supports stop control, the ECU shall stop the control
when the current status is $01 and change the current status to $11 then send a positive response
message with CTRLSTAT1 = current status.
9.5.1.6.1.Start Control
The ECU should send a positive response message when the control is started which shall occur
before P2CAN_SERVER.
P2 Timeout
IinputOutputControl Control in progress

Request CRTLSTAT1=$01
Fig. 13 — Response timing on start control

RENAULT 36 - 00 - 013 / - - C
9.5.1.6.2.Status request
The ECU shall send a response message immediately when ECU is processing the request.
9.5.1.6.3.Stop request
The ECU shall send a response message when the control has been completely stopped.
9.6. REMOTE ACTIVATION OF ROUTINE FUNCTIONAL UNIT
9.6.1. $31 - StartRoutineByLocalIdentifier service
This service has to be used when accurate timing control precision are required (not possible to be
controlled by a tool) or sequence complexity needs dedicated software module for control and results
storage (example: teach-ins).
After receiving the request the ECU shall start the specified routine. Then a positive response shall be
sent with the status “in progress” ($01). If the routine can not be started the ECU shall send a negative
reply with NRC $22 - for applicative conditions not met - or $33 – for routine control protected by
securityAccess service.
The Local Identifiers from range [$01 - $7F] supported by ECU can be retrieved by reserved LIDs $00,
$20, $40 and $60 as defined in §.9.1.5.


#1 StartRoutineByLocalIdentifier M $31 SRBLID
#2 RoutineLocalIdentifier = “Routine” number M $xx RLOCID
#3 RoutineEntryOption = “Routine” input parameters C $xx. RENTOPT1
#4 to n Optional parameters to be defined by the function U $xx. RENTOPTi
manager
C: If the routine was aborted by the ECU, The return code reflects the exact reason for abortion and must
be defined on a per routine basis

RENAULT 36 - 00 - 013 / - - C
9.6.1.2.3.Request message data parameters definition
The following parameters are defined for this service.

Definition
routineLocalIdentifier
This parameter identifies an ECU local routine.
routineEntryOption
This parameter is to specify the start conditions of the routine.
optionalParameter
This parameters are defined by the function manager to perform the ECU routines.
Table 155 — routineLocalIdentifier definition

Hex Description Cvt
$01 - $1F
$21 - $3F Free allocation for the function manager U
$41 - $5F
$61 - $7F
$80 - $8F Reserved for reprogramming C
$FF
Table 156 — routineEntryOption definition

Hex Description Cvt
$00 Perform routine requested M
$01 Status request M
$02 – $F9 Not allowed : Reserved by the document F
When routineEntryOption = Status request, the request is limited to 3 bytes.

RENAULT 36 - 00 - 013 / - - C


#1 StartRoutineByLocalIdentifier Response Service ID M $71 SRBLIDPR
#2 Routine Local Identifier = “Routine” number M $xx RLOCID
#3 RoutineEntryStatus = “Routine” input status M $xx RENTSTAT1
#4 to m Optional parameters to be defined by the function U $xx RENTSTATi
manager
For RoutineLocalIdentifier values $00 / $20 / $40 / $60 refer to § 9.1.5.1.
9.6.1.3.2.Positive response message data parameters definition

Table 158 — Positive response message data parameter definition
Definition
routineEntryStatus
This parameter is used by a response message to give additional information about the status following the
start of the routine
Table 159 — routineEntryStatus parameter definition

Hex Description Cvt
$01 Routine in progress M
$02 Routine completed and OK M
$03 - $FF Routine completed and not OK C

RENAULT 36 - 00 - 013 / - - C
1. The ECU does not support the requested RoutineLocalIdentifier,
2. The user optional routineEntryOption contains invalid data for the
requested StartRoutineByLocalIdentifier.
StartRoutineByLocalIdentifier are not met.
For example if a specific RoutineLocalIdentifier requires a non default
session and the current session is default session.
This code shall be returned if a tool sends a request with RoutineEntryOption
parameter equal to “Perform routine requested” and valid secure
RoutineLocalIdentifier and the ECU is locked.
$7F ServiceNotSupportedInActiveSession U SNSIAS
See § 9.1.1.2.

RENAULT 36 - 00 - 013 / - - C
9.6.1.5. State machine diagram
Stop routine is requested Perform routine requested Perform routine requested
Routine Completed Routine completed and OK Routine in progress

Status: $02 Status: $01
OK
ot
dn
Stop routine is requested
an
ted
le
mp
d
te
co
es
qu
ne
re
u ti
e
in
Ro
ut
ro
rm
rfo
Pe
Routine Completed
and not OK
Status: $03 - $FF
ECU handling
Request message
Stop routine is requested
Before a routine has ever been started in an operation cycle, the status is $02 “routine complete and
ok”, i.e.If a status request is received before the routine was started in the operation cycle, the returned
status shall be 0x02.
Fig. 14 — Start Routine Management
The ECU shall set current status to $01 when the request message with “Perform Routine requested”
was successfully executed then send a positive response message with RENTSTAT1 = current status.
The ECU shall send a positive response message with RENTSTAT1 = current status when
subsequent request messages with status request are received.
9.6.1.6.1.Perform routine requested
The ECU should send a positive response message when the routine is started which shall occur
before P2CAN_SERVER.
P2CAN_SERVER Timeout
Perform routine Routine in progress

requested RENTSTA1=$01
Fig. 15 — Response timing on Start Routine
9.6.1.6.2.Status request
The ECU shall send a response message immediately when ECU is processing the request.

RENAULT 36 - 00 - 013 / - - C
9.6.2. $32 - StopRoutineByLocalIdentifier service
This service is used to stop the routine referenced by a routineLocalIdentifier that was activated by the
StartRoutineByLocalIdentifier service. The routine shall be stopped before the positive response
message is sent.
The use of “Local Identifiers” from range [$01 - $7F] is defined §.9.1.5.


#1 StopRoutineByLocalIdentifier Request Service Id M $32 SPRBLID
#3 to n RoutineExitParameters = exit parameters to be defined U $xx REXITOPTi
by Function manager
9.6.2.2.3.Request message data parameters definition
The following parameters are defined for this service.

Definition
routineLocalIdentifier
The parameter identifies an ECU local routine.
RoutineExitParameters
Exit parameters to be defined by Function manager
Table 163 — routineLocalIdentifier definition

Hex Description Cvt
$01 - $1F
$21 - $3F
Free allocation for the function manager U
$41 - $5F
$61 - $7F
$FF

RENAULT 36 - 00 - 013 / - - C

#1 StopRoutineByLocalIdentifier Response Service Id M $72 SPRBLIDPR
#3 RoutineExitStatus = “Routine” Status parameters M $xx REXITSTAT1
#4 to m Optional information to be defined by the function U $xx REXITSTATi
manager
For RoutineLocalIdentifier values $00 / $20 / $40 / $60 refer to § 9.1.5.1.

Table 165 — Positive response message data parameter definition
Definition
routineExitStatus
The parameter is used by a response message to give additional information about the status following the
stop of the routine.
optionalParameter
The parameters are defined by the function manager to stop the ECU routines.
Table 166 — routineExitStatus parameter definition

Hex Description Cvt
$01 Routine in progress F
$02 Routine completed and OK M
$03 - $FF Routine completed and not OK C

RENAULT 36 - 00 - 013 / - - C
1. The ECU does not support the requested RoutineLocalIdentifier,
2. The user optional routineExitOption contains invalid data for the
requested StopRoutineByLocalIdentifier.
StopRoutineByLocalIdentifier are not met.
$7F ServiceNotSupportedInActiveSession U SNSIAS
See § 9.1.1.2.
When a Stop routine service is received, the ECU shall stop the routine when the current status is $01
and change the current status to $02 then send a positive response message with REXSTAT1 =
current status.
The ECU shall send a response message when the routine has been completely stopped.

RENAULT 36 - 00 - 013 / - - C
9.7. UPLOAD/DOWNLOAD FUNCTIONAL UNIT
Caution: These services are only applicable in BOOT software. There shall not be implemented in
any application software.
9.7.1. $34 - RequestDownLoad service
This service is used during reprogramming for the data transfer (see applicable Reprogramming
specification [REF 2]).

#1 RequestDownLoad resuest Service Id M $34 RD
#2 to #n Download parameters M $xx…$xx -
See applicable reprogramming specification [REF 2].


#1 RequestDownLoad ResponseService Id M $74 RDPR
#2 to #n Download response parameters M $xx ... $xx -

RENAULT 36 - 00 - 013 / - - C
9.7.2. $35 - RequestUpLoad service
This service is used during reprogramming for the data checking after a download (see applicable
Reprogramming specification [REF 2]).

Table 170 —Request message definition
#1 RequestUpLoad Request Service Id M $35 RU
#2 to #n Upload parameters M $xx…$xx -

#1 RequestUpLoad response Service Id M $75 RUPR
#2 to #n Upload response parameters M $xx ... $xx -

RENAULT 36 - 00 - 013 / - - C
9.7.3. $36 - TransferData service
See Reprogramming specification [REF 2] for applicability of this service.

#1 TransferData Request Service Id M $36 TD
#2 to #n TransferData parameters M $xx…$xx -

#1 TransferData Response Service Id M $76 TDPR
#2 to #n TransferData response parameters M $xx ... $xx -

RENAULT 36 - 00 - 013 / - - C
9.7.4. $37 - RequestTransferExit service
See Reprogramming specification [REF 2] for applicability of this service.

#1 RequestTransferExit Request Service Id M $37 RTE
#2 to #n RequestTransferExit parameters M $xx…$xx -

#1 RequestTransferExit Response Service Id M $77 RTEPR
#2 to #n RequestTransferExit response parameters M $xx ... $xx -

RENAULT 36 - 00 - 013 / - - C
ANNEXE A
DATA TRANSMISSION FUNCTIONAL UNIT DATA PARAMETER DEFINITIONS
A.1 Manufacturer specific dataIdentifier parameter definitions
Table 176 — A.1 Manufacturer specific dataIdentifier data parameter definitions
Hex Description
$0100 – $EFFF System specific allocation
$xx00, $xx20, …, $xxE0 where xx is in range [$01, $EF] Indicate values used in the
ranges $xx01-xx20, $xx21-xx40, …, $xxE1-xxFF. If $xxy0, where y is any even value
in range [0, E], is not supported, the whole range [$xxy0, $xxyF] is not supported.
Other values are System specific.
$FD00 - $FEFF Supplier specific data
$0000 - $00FF Reserved by ISO/SAE
$F000 - $FFFF

RENAULT 36 - 00 - 013 / - - C
ANNEXE A (continued)
A.2 ISO 14229-1 dataIdentifier parameter definitions
Refer to ISO14229-1 Annex C.1.
The parameter dataIdentifier (DID) is to identify an ECU specific local data record. This parameter
shall be available in the ECU's memory. The dataIdentifier value shall either exist in fixed memory or
temporarily stored in RAM if defined dynamically by the service dynamicallyDefineDataIdentifier.
Values are defined in Table 177 - dataIdentifier data parameter definitions
Table 177 — dataIdentifier data parameter definitions

$0000 - $00FF ISOSAEReserved M ISOSAERESR
VD
This range of values shall be reserved by this document for future
definition.
$0100 - $EFFF vehicleManufacturerSpecific U VMS
This range of values shall be used to reference vehicle manufacturer
specific record data identifiers and input/output identifiers within the
ECU.
$F000 - $F00F networkConfigurationDataForTractorTrailerApplication U NCDFTTA
This value shall be used to request the remote addresses of all trailer
systems independent of their functionality.
$F010 - $F0FF vehicleManufacturerSpecific U VMS
This range of values shall be used to reference vehicle manufacturer
ECU.
$F100 - $F17F identificationOptionVehicleManufacturerSpecific U IDOPTVMS
This range of values shall be used for vehicle manufacturer specific
ECU/vehicle identification options.
$F180 bootSoftwareIdentification U BSI
This value shall be used to reference the vehicle manufacturer specific
ECU boot software identification record. The first data byte of the
record data shall be the numberOfModules that are reported.
Following the numberOfModules the boot software identification(s) are
reported. The format of the boot software identification structure shall
be ECU specific and defined by the vehicle manufacturer.
$F181 applicationSoftwareIdentification U ASI
ECU application software number(s). The first data byte of the record
data shall be the numberOfModules that are reported. Following the
numberOfModules the application software identification(s) are
reported. The format of the application software identification structure
shall be ECU specific and defined by the vehicle manufacturer.
$F182 applicationDataIdentification U ADI
ECU application data identification record. The first data byte of the
record data shall be the numberOfModules that are reported.
Following the numberOfModules the application data identification(s)
are reported. The format of the application data identification structure
shall be ECU specific and defined by the vehicle manufacturer.

RENAULT 36 - 00 - 013 / - - C

$F183 bootSoftwareFingerprint U BSFP
ECU boot software fingerprint identification record. Record data
content and format shall be ECU specific and defined by the vehicle
manufacturer.
$F184 applicationSoftwareFingerprint U ASFP
ECU application software fingerprint identification record. Record data
manufacturer.
$F185 applicationDataFingerprint U ADFP
ECU application data fingerprint identification record. Record data
manufacturer.
$F186 ISOSAEReserved-Standardized M ISOSAERESR
VD
definition of standardized ECU/vehicleIdentification options.
$F187 vehicleManufacturerSparePartNumber U VMSPN
This value shall be used to reference the vehicle manufacturer spare
part number. Record data content and format shall be ECU specific
and defined by the vehicle manufacturer.
$F188 vehicleManufacturerECUSoftwareNumber U VMECUSN
This value shall be used to reference the vehicle manufacturer ECU
(ECU) software number. Record data content and format shall be ECU
specific and defined by the vehicle manufacturer.
$F189 vehicleManufacturerECUSoftwareVersionNumber U VMECUSVN
This value shall be used to reference the vehicle manufacturer ECU
(ECU) software version number. Record data content and format shall
be ECU specific and defined by the vehicle manufacturer.
$F18A systemSupplierIdentifier U SSID
This value shall be used to reference the system supplier name and
address information. Record data content and format shall be ECU
specific and defined by the system supplier.
$F18B ECUManufacturingData U ECUMD
This value shall be used to reference the ECU (ECU) manufacturing
date. Record data content and format shall be unsigned numeric,
ASCII or BCD, and shall be ordered as Year, Month, Day.
$F18C ECUSerialNumber U ECUSN
This value shall be used to reference the ECU (ECU) serial number.
Record data content and format shall be ECU specific.
$F18D supportedFunctionalUnits U SFU
This value shall be used to request the functional units implemented in
an ECU.

RENAULT 36 - 00 - 013 / - - C

$F18E- $F18F ISOSAEReservedStandardized M ISOSAERESR
VD
definition of standardized ECU/vehicleIdentification options.
$F190 VIN U VIN

This value shall be used to reference the VIN number. Record data
content and format shall be specified by the vehicle manufacturer.
$F191 vehicleManufacturerECUHardwareNumber U VMECUHN
This value shall be used by reading services to reference the vehicle
manufacturer specific ECU (ECU) hardware number. Record data
content and format shall be ECU specific and defined by vehicle
manufacturer.
$F192 systemSupplierECUHardwareNumber U SSECUHWN
This value shall be used to reference the system supplier specific ECU
(ECU) hardware number. Record data content and format shall be
ECU specific and defined by the system supplier.
$F193 systemSupplierECUHardwareVersionNumber U SSECUHWVN
(ECU) hardware version number. Record data content and format
shall be ECU specific and defined by the system supplier.
$F194 systemSupplierECUSoftwareNumber U SSECUSWN
(ECU) software number. Record data content and format shall be ECU
specific and defined by the system supplier.
$F195 systemSupplierECUSoftwareVersionNumber U SSECUSWVN
(ECU) software version number. Record data content and format shall
be ECU specific and defined by the system supplier.
$F196 exhaustRegulationOrTypeApprovalNumber U EROTAN
This value shall be used to reference the exhaust regulation or type
approval number (valid for those systems which require type
approval). Record data content and format shall be ECU specific and
defined by the vehicle manufacturer.
$F197 systemNameOrEngineType U SNOET
This value shall be used to reference the system name or engine type.
Record data content and format shall be ECU specific and defined by
the vehicle manufacturer.
$F198 repairShopCodeOrTesterSerialNumber U RSCOTSN
This value shall be used to reference the repair shop code or tester
(tool) serial number (e.g., to indicate the most recent service tool used
re-program ECU memory). Record data content and format shall be
ECU specific and defined by the vehicle manufacturer.

RENAULT 36 - 00 - 013 / - - C

$F199 programmingDate U PD
This value shall be used to reference the date when the ECU was last
programmed. Record data content and format shall be unsigned
numeric, ASCII or BCD, and shall be ordered as Year, Month, Day.
$F19A calibrationRepairShopCodeOrCalibrationEquipmentSerialNumber U CRSCOCESN
This value shall be used to reference the repair shop code or tool
serial number (e.g., to indicate the most recent service tool used re-
calibrate the ECU). Record data content and format shall be ECU
specific and defined by the vehicle manufacturer.
$F19B calibrationDate U CD
This value shall be used to reference the date when the ECU was last
calibrated. Record data content and format shall be unsigned numeric,
ASCII or BCD, and shall be ordered as Year, Month, Day.
$F19C calibrationEquipmentSoftwareNumber U CESWN
This value shall be used to reference software version within the tool
used to calibrate the ECU. Record data content and format shall be
ECU specific and defined by the vehicle manufacturer.
$F19D ECUInstallationDate U EID
This value shall be used to reference the date when the ECU (ECU)
was installed in the vehicle. Record data content and format shall be
either unsigned numeric, ASCII or BCD, and shall be ordered as Year,
Month, Day.
$F19E ODXFileIdentifier U ODXFID
This value shall be used to reference the ODX (Open Diagnostic Data
Exchange) file of the ECU to be used to interprete and scale the ECU
data.
$F19F EntityIdentifier U EID
This value shall be used to reference the entity identifier as defined in
ISO 15764 for a secured data transmission.
$F1A0 - $F1EF identificationOptionVehicleManufacturerSpecific U IDOPTVMS
This range of values shall be used for vehicle manufacturer specific
ECU/vehicle identification options.
$F1F0 - $F1FF identificationOptionSystemSupplierSpecific U IDOPTSSS
This range of values shall be used for system supplier specific
ECU/vehicle system identification options.
$F200 – $F2FF periodicDataIdentifier U PDID
This range of values shall be used to reference periodic record data
identifiers. Those can either be statically or dynamically defined.
$F300 – $F3FF dynamicallyDefinedDataIdentifier U DDDDI
This range of values shall be used for
dynamicallyDefinedDataIdentifiers.
$F400 – $F4FF OBDPids U OBDPID
This range of values is reserved for OBD/EOBD PIDs as defined in
ISO 15031-5.

RENAULT 36 - 00 - 013 / - - C

$F500 – $F5FF OBDPids U OBDPID
This range of values is reserved to represent future defined
OBD/EOBD PIDs.
$F600 – $F6FF OBDMonitorIds U OBDMID
This range of values is reserved for OBD/EOBD on-board monitoring
result values as defined in ISO 15031-5.
$F700 – $F7FF OBDMonitorIds U OBDMID
This range of values is reserved to represent future defined
OBD/EOBD on-board monitoring result values.
$F800 – $F8FF OBDInfoTypes U OBDINFTYP
This range of values is reserved for OBD/EOBD info type values as
defined in ISO 15031-5.
$F900 – $F9FF TachographPIds U TACHOPID
This range of values is reserved for Tachograph PIDs as defined in
ISO 16844-7.
$FA00 - $FAFF SafetySystemPIds U SSPID
This range of values is reserved to represent safety related PIDs.
$FB00 - $FCFF reservedForLegislativeUse U RFLU
This range of values is reserved for future legislative requirements.
$FD00 - $FEFF systemSupplierSpecific U SSS
This range of values shall be used to reference system supplier
ECU.
$FF00 - $FFFF ISOSAEReserved M ISOSAERESR
VD
definition.

RENAULT 36 - 00 - 013 / - - C
Annex B
Timing chart for DTC
Operation Cycle 1 Stop Start Operation Cycle 2

Operation Cycle 1
0
Test
passed
testResult no result
failed
Mileage is memorized at T3.
127 Mileage is updated at T9.
FaultDetection
0
Counter
Mileage is updated at T5.
-128
1
testFailed(Bit0) 0
testFailedThis 1
MonitoringCycle(Bit1) 0
testNotCompleted 1
ThisMonitoringCycle(Bit6) 0
1
pendingDTC(Bit2) 0
1
confirmedDTC(Bit3) 0
testNotCompleted 1
SinceLastClear(Bit4) 0
1
testFailed
SinceLastClear(Bit5) 0
2
TripCounter
1
0
0
T1 T2 T3 T4 T5 T6 T7 T8 T9
Time
Fig. 15 — Example of a one-operation cycle DTC

UDS Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UDS Document

Uploaded by

Copyright:

Available Formats

STANDARD

DIAGNOSTIC SERVICES IMPLEMENTATION

Normalisation Renault Automobiles

May 2010 ---

September 2002 --A

October 2004 - - B This issue originates from Draft NC 2004 0324 / - - A.

- DiagMux LID reserved

[REF 1] : [RENAULT] : 36-02-031

© RENAULT 2010 Page 2/128

3. TERMS AND DEFINITION 5

5. DIAGNOSTIC SERVICES APPLICABILITY TO O.S.I. LAYER MODEL 6

6. APPLICATION AND SESSION LAYER 7

6.1. APPLICATION LAYER SERVICES 7

6.2. APPLICATION LAYER PROTOCOL 7

6.3. APPLICATION LAYER AND DIAGNOSTIC SESSION MANAGEMENT TIMING 7

7. NETWORK LAYER INTERFACE 7

8. STANDARDISED DIAGNOSTIC CAN IDENTIFIERS 7

9. DIAGNOSTIC SERVICES IMPLEMENTATION 8

9.1. DIAGNOSTIC SERVICES OVERVIEW 8

9.1.1. Negative responses : Definitions and code table 11

9.1.2. Processing long execution time service 13

9.1.3. General diagnostic service implementation rules 16

9.1.4. Restrictions on concurrent services 21

9.1.5. Getting Identifiers supported by the ECU 23

9.2. DIAGNOSTIC AND COMMUNICATION CONTROL FUNCTIONAL UNIT 29

9.2.1. $10 - StartDiagnosticSession Service 29

9.2.2. $11 - ECUReset service 35

9.2.3. $27 - SecurityAccess service 38

9.2.4. $28 - CommunicationControl service 44

9.2.5. $3E - TesterPresent service 46

9.3. DATA TRANSMISSION FUNCTIONAL UNIT 48

9.3.1. $21 - ReadDataByLocalIdentifier service 48

9.3.2. $22 - ReadDataByIdentifier service 55

9.3.3. $23 - ReadMemoryByAddress service 58

9.3.4. $24 - ReadScalingDataByIdentifier service 61

© RENAULT 2010 Page 3/128

9.3.5. $2C - DynamicallyDefineLocalIdentifier service 63

9.3.6. $3B - WriteDataByLocalIdentifier service 70

9.3.7. $2E - WriteDataByIdentifier service 73

9.3.8. $3D - WriteMemoryByAddress service 76

9.4. STORED DATA TRANSMISSION FUNCTIONAL UNIT 79

9.4.1. $14 - ClearDiagnosticInformation Service 79

9.4.2. $19 – ReadDTCInformationService 81

9.5. INPUT/OUTPUT CONTROL FUNCTIONAL UNIT 105

9.5.1. $30 - InputOutputControlByLocalIdentifier service 105

9.6. REMOTE ACTIVATION OF ROUTINE FUNCTIONAL UNIT 110

9.6.1. $31 - StartRoutineByLocalIdentifier service 110

9.6.2. $32 - StopRoutineByLocalIdentifier service 115

9.7. UPLOAD/DOWNLOAD FUNCTIONAL UNIT 118

9.7.1. $34 - RequestDownLoad service 118

9.7.2. $35 - RequestUpLoad service 119

9.7.3. $36 - TransferData service 120

9.7.4. $37 - RequestTransferExit service 121

ANNEXE A DATA TRANSMISSION FUNCTIONAL UNIT DATA PARAMETER DEFINITIONS 122

ANNEX B TIMING CHART FOR DTC 128

© RENAULT 2010 Page 4/128

This document is identical to NISSAN document 25953 NDS 07.

When modified, a notice shall be given to NISSAN Secretariat.

This document is historically based on the following international standards :

- ISO 14230 - 3 : “Keyword Protocol 2000 - Part 3 : application layer,

- and [REF 1].

3. TERMS AND DEFINITION

RENAULT / NISSAN responsible departments for diagnostic services.

Electronic Control Unit referred to as Server in ISO documents