Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Road vehicles
Unified Diagnostic Services (UDS) -
Diagnostics Protocol (based on ISO 14229-1)
Foreword
This standard is based on ISO 14229-1 / ISO 15765-3 and defines the diagnostic application layer
protocol requirements, including protocol services, timings and behavior, for Electronic Control Units
(ECUs) and diagnostic test devices used in Daimler Corporation vehicles and test environments.
.
Protocol services allow the exchange of diagnostic data between off-board or on-board diagnostic
test devices and on-board Electronic Control Units.
This document provides recommended uniformity and guidance for incorporating diagnostic protocol
functionality, as well as requirements governing consistent methods for implementation.
Fulfillment of diagnostic application layer protocol requirements for engineering, manufacturing, and
service can only be achieved if this standard is strictly enforced.
Changes
In comparison with edition 2011-09, the following changes have been made:
Contents
1 Scope ............................................................................................................................................. 3
2 Normative References.................................................................................................................... 4
3 Terms and Definitions .................................................................................................................... 5
3.1 General Definitions ..................................................................................................................... 5
3.2 DTC Related Definitions ............................................................................................................. 6
3.3 Abbreviations and Acronyms ...................................................................................................... 7
4 General Requirements ................................................................................................................... 8
5 Communication between External Test Tool and ECU .................................................................. 9
5.1 Document conventions ............................................................................................................... 9
5.2 Diagnostic Service Request Message Format ......................................................................... 10
5.3 Diagnostic Service Response Message Format ...................................................................... 12
6 Application Layer and Diagnostic Session Management Timing ................................................. 14
6.1 Prerequisites ............................................................................................................................. 14
6.2 Application Layer Timing Parameter Definitions ...................................................................... 15
6.3 Minimum Time Between External Test Tool Request Messages ............................................. 17
6.4 Session Layer Timing Parameter Definitions ........................................................................... 18
6.5 External Test Tool and ECU Timer Resource Requirements .................................................. 20
6.6 Error Handling........................................................................................................................... 21
7 ECU Response Implementation Rules......................................................................................... 22
7.1 Request Messages with Sub-Function Parameter ................................................................... 22
7.2 Request Messages without Sub-Function Parameter .............................................................. 24
7.3 Request Correctly Received Response Pending [NRC 78 hex] .............................................. 25
7.4 Reaction regarding illegal SIDs ................................................................................................ 26
8 Diagnostic Services ...................................................................................................................... 27
8.1 Diagnostic Session Control - Service Identifier [10 hex] .......................................................... 27
8.2 ECU Reset - Service Identifier [11 hex] .................................................................................... 36
8.3 Clear Diagnostic Information - Service identifier [14 hex] ........................................................ 38
8.4 Read DTC Information - Service Identifier [19 hex].................................................................. 41
8.5 Read Data By Identifier - Service Identifier [22 hex] ................................................................ 63
8.6 Read Memory By Address - Service identifier [23 hex] ............................................................ 66
8.7 Security Access - Service Identifier [27 hex] ............................................................................ 69
8.8 Communication Control - Service Identifier [28 hex] ................................................................ 74
8.9 Dynamically Define Data Identifier - Service Identifier [2C hex] ............................................... 78
8.10 Write Data By Identifier - Service Identifier [2E hex]............................................................. 85
8.11 Input Output Control By Identifier- Service Identifier [2F hex] .............................................. 87
8.12 Routine Control - Service Identifier [31 hex] ......................................................................... 92
8.13 Request Download - Service Identifier [34 hex].................................................................... 97
8.14 Request Upload - Service Identifier [35 hex] ...................................................................... 100
8.15 Transfer Data - Service Identifier [36 hex] .......................................................................... 103
8.16 Request Transfer Exit - Service Identifier [37 hex] ............................................................. 108
8.17 Write Memory By Address - Service Identifier [3D hex]...................................................... 110
8.18 Tester Present - Service Identifier [3E hex] ........................................................................ 113
8.19 Removed ............................................................................................................................. 115
8.20 Control DTC Setting - Service Identifier [85 hex] ................................................................ 115
8.21 ECU Passive Mode - Service Identifier [A0 hex] ................................................................ 118
8.22 Removed ............................................................................................................................. 121
8.23 LinkControl - Service Identifier [87 hex] .............................................................................. 121
9 Negative Response Codes ........................................................................................................ 127
Annex A (normative) Diagnostic Service Support Conditions ......................................................... 135
Annex B (informative) List of Changes ............................................................................................ 139
1 Scope
The goal of this document is to specify the requirements for proper implementation of ISO 14229-1.
The transmission of diagnostic protocol messages is performed using the transport protocol as
defined in ISO 15765-2 and is not included in this document.
MBN 10747 was created to address the need for internal standardization of diagnostic protocol
according to ISO 14229-1 as applied to all diagnostic vehicle applications of all Daimler Corporation
business units. It is intended for use by electrical/electronic development engineers, system
engineers, and suppliers in the design, development and implementation of diagnostic protocol for
electronic control units (ECUs).
MBN 10747 details the diagnostic services which shall be supported by an ECU in order to provide
proper diagnostic functionality. Implementation of diagnostic functionality by a respective diagnostic
application is described in MBN 10746 and the respective model line specific diagnostic
requirements document.
2 Normative References
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
ISO 15765-2 Road vehicles - Diagnostics on Controller Area Networks (CAN) - Part 2:
Network layer services
ISO 14229-1 Road vehicles - Unified Diagnostics Services - Part 1 Specification and
requirements
ISO 15031-5 Road vehicles - Communication between vehicle and external test equipment
for emissions-related diagnostics - Part 5 Emissions-related diagnostic services
ISO 26021 all parts Road vehicles - EOL activation of onboard pyrotechnic devices
Diagnostic Data: Data that is located in the memory of an ECU which may be
inspected and/or possibly modified by the external test tool
(diagnostic data includes analog inputs and outputs, digital inputs
and outputs, intermediate values and various status information).
ECU Sleep Mode: A certain ECU mode, that is achieved when a battery fed ECU
operates with minimal electric power consumption,
Electronic Check out System: A test method to verify the correct function of electrical components
by their current consumption. Therefore the system is put into a
constant current consumption state and then the component to be
tested is activated and the increase in current consumption is
measured as an indication of the correct function of this component.
External Test Tool: The device that is used as an external or internal diagnostic test
device performing the client functionality defined in this protocol
standard.
Negative Response Code: This hexadecimal value identifies the specific condition the ECU was
not able to respond positively.
Service Identifier: The service identifier is the hexadecimal value, which identifies a
specific diagnostic service.
Sub-function: The first diagnostic service parameter, which allows the selection of
a specific functionality for the specific service.
Diagnostic Trouble Code: A unique numeric failure indicator used to direct repair personnel to
the most likely suspect circuit, component or system.
Driving cycle: A specific type of operation cycle used for emission related ECUs. For
further details see Operation Cycle or refer to MBN 10746.
Failure: Indicates the inability of a component or system to meet its intended function. A failure
occurs when fault conditions have been detected for a sufficient
period of time which warrants storage of a pending (for emission
related components only) or confirmed DTC implying that a test
returned a “Failed” result. The terms "failure" and "malfunction" are
interchangeable.
Monitor: A monitor consists of one or more tests used to determine the proper
functionality of a component or system.
Monitoring cycle: A monitoring cycle is the time in which a monitor runs to completion.
This is a manufacturer-defined set of conditions during which the tests
of a monitor can run. A monitoring cycle may be executed several
times during an operation cycle (Refer to MBN 10746 for further
details).
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 modules it is up to the
manufacturer to define an operation cycle (e.g. time between
powering up and powering down the module or between ignition on
and ignition off). For powertrain modules, there are additional criteria
defining an operation cycle. Emission related powertrain modules use
an engine-running or engine-off time period to define an operation
cycle which is referred to as driving cycle.
For emission related monitors the criteria for the beginning and the
end of an operation cycle are defined by legislation.
Test results: While a test runs or after it has completed it may indicate one of the
following results to the internal failure handler:
• Failed: This status is available after an ECU’s fault routine has run to
completion and indicates a completely matured failing condition.
4 General Requirements
For safety requirements, homologation (in particular, exhaust emissions) and quality, the existing
statutory requirements and laws shall be complied with. In addition, the relevant requirements of the
Daimler Group apply.
All materials, procedures, processes, components, and systems shall conform to the current
regulatory (governmental) requirements regarding regulated substances and recyclability.
For a complete listing of Diagnostic Services and Sub-functions please refer to Table 123.
Each Diagnostic Service or Sub-function specified in this document conforms to one of the message
description formats defined in Table 2 - Table 6. The meaning of the columns of these tables is
defined in Table 1.
Data Byte No. This column defines the byte number for each parameter in the data stream. No data link or transport layer
specific information is included. The numbering in this document starts with Byte 1 (one).
Data Value This column defines the hexadecimal data value for each parameter in the data stream.
Parameter Name This column defines the name of each message parameter. The meaning of the respective message
parameter is defined in the chapter data parameter / sub-function type description of each service. The
message parameter type is in bold text. The options that are available for each parameter appear directly
below the parameter name.
Message Usage This column defines whether or not a particular parameter must be used in the data stream. The
options are as follows:
Mandatory (M) – Each byte must appear in the message structure as specified. There are no exceptions.
Is does not reflect the service is mandatory for implementation.
Conditional (C) – Each byte can conditionally appear in the message structure based on the selection of
other parameters passed within the message or based upon implementation requirements. Each condition
is described in greater detail at the bottom of each table.
Optional (O) – Each byte can be optionally included in the message structure without an ECU or external
test tool “complaining” if the data is excluded.
NOTE – The Message Usage is not be confused with the implementation type. For example, a diagnostic
service of implementation type "Mandatory" may have parameters which are "Conditional".
Throughout this document several Sub-functions are referred to as Manufacturer Specific or Supplier
Specific. A description of these terms is as follows:
Message
Data Byte No. Parameter Name Data Value
Usage
Table 3 describes the structure of the Sub-function parameter byte included in the diagnostic service
request message as defined in Table 2. The Suppress Positive Response Message Indication Bit
(Bit 7) influences the ECU’s response behavior in accordance with the definitions given in
section 7.1.
UDS 86: An ECU shall support the Suppress Pos Rsp Msg Indication Bit for all supported diagnostic
service request messages which include a specific sub-function parameter.
NOTE: This specification will still list all sub-functions with the Suppress Pos Rsp Msg Indication Bit
set to one (1) for those sub-functions which will be used by an external test tool. That however does
not require a special negative response handling for those sub-functions which are required to be
supported without the Suppress Pos Rsp Msg Indication Bit but are not explicitly listed with the
Suppress Pos Rsp Msg Indication Bit set to one (1).
UDS 88: An ECU shall always mask out the Suppress Pos Rsp Msg Indication Bit before it
compares the sub-function against its internal list of supported sub-function.
NOTE: This is necessary to achieve a consistent implementation of the Suppress Positive Response
Message handling across all diagnostic service request messages which support a sub-function.
UDS 90: An ECU shall only use the Suppress Pos Rsp Msg Indication Bit to suppress a positive
response message to the diagnostic service request (see section 7.1 for further details).
Request
Service Id
1 Response Service Id M
value +
40
2 Request Sub Function Type or Data Parameter no. 1 M 00-FF
3 Data Parameter no. a O 00-FF
: : : :
n Data Parameter no. x O 00-FF
6.1 Prerequisites
This section specifies the required timing parameters for the application layer and the session layer.
Application layer timing parameters are separated into the following communication scenarios:
The interaction at the service access point between the diagnostic application layer protocol instance
and the network layer protocol instance on the sender or receiver side define a specific point in time
in the communication process between the external test tool and the ECU. Consequently, a specific
point in time is indicated when a selected service primitive is executed. Thus the service primitive
may be used to define the timing requirements of the communication process. The following timing
parameter definitions use the service primitives as defined in ISO 15765-2.
Figure 1 provides an overview of how the Network Layer services primitives are used.
Time t
N_USData.request 1)
N_USData.indication /
N_USData.confirm 2) N_USData_FF.indication
N_USData.request
N_USData.indication /
N_USData_FF.indication 3)
N_USData.confirm
1: This service is used to request the transfer of data. If necessary, the Network Layer segments the
data.
2: This service is used to confirm to the application layer that the data request service has been
carried out (successfully or not).
3: This service is either used to provide the received data (single frame or multi frame message) to
the application layer or to signal the beginning of a segmented message.
NOTE: Figure 1 does not take into consideration a specific underlying vehicle network topology and
is a simplified representation of the diagnostic message transmission process assuming that no
gateway device is located between transmitting external test tool and receiving ECU.
Timeout for the external test tool to wait after the successful transmission of a
request message (indicated via N_USData.con) for the start of related incoming Timer reload
P2CAN Tester response messages (N_USDataFF.ind for a multi-frame message or value
N_USData.ind for a Single Frame message).
Enhanced timeout for the external test tool to wait after the reception of a negative
response message with response code [78 hex] (indicated via N_USData.ind) for Timer reload
P2*CAN Tester the start of incoming response messages (N_USDataFF.ind for a multi-frame value
message or N_USData.ind for a Single Frame message).
Performance requirement for the ECU to start with the response message after the Performance
P2CAN ECU reception of a request message (indicated via N_USData.ind). requirement
Performance requirement for the ECU to start with a further response message
Performance
P2*CAN ECU after the transmission of a negative response message (indicated via
requirement
N_USData.con) with response code [78 hex] (enhanced response timing).
Minimum time for the external test tool to wait after the successful transmission of
a physically addressed request message (indicated via N_USData.con) with no Timer reload
P3CAN Tester Phys response required (Suppress Pos Rsp Msg Indication Bit = TRUE) before it is value
allowed to transmit the next physically addressed request message
Minimum time for the external test tool to wait after the successful transmission of
Timer reload
P3CAN Tester Func a functionally addressed request message (indicated via N_USData.con) before it
value
is allowed to transmit the next functionally addressed request message.
UDS 122: The application layer timing parameters shall be used according to the definitions given in
Table 7.
NOTE: For the actual P2 parameter values refer to MBN 10746. According to the requirements
itemized in section 6.3, the P3 value depends on the P2 value definition (i.e. usually equal or greater
than P2).
UDS 125: If the external test tool’s network layer has successfully transmitted a diagnostic service
request message onto the bus (signalized by N_USData.con) the external test tool application shall
start its P2CAN Tester timer, using the default reload value P2CAN Tester .
UDS 126: The ECU’s diagnostic application layer shall start with its response message within
P2CAN_ECU after the reception of N_USData.ind. In the event of a multi-frame response message,
the First Frame shall be sent within P2CAN_ECU and for single frame response messages, the
Single Frame shall be sent within P2CAN_ECU.
UDS 127: If the external test tool's application receives a N_USDataFF.ind or N_USData.ind from
its network layer it shall stop its P2CAN Tester (P2*CAN Tester) timer.
NOTE: In certain cases the ECU is not required to respond on a diagnostic request message sent by
the external test tool (for details please refer to chapter 7). Assuming the ECU does not respond the
requirements in section 6.3 shall apply.
UDS 129: If the ECU cannot provide the requested information within the P2CAN_ECU response
timing, it shall request an Enhanced Response Timing window by sending a negative response
message with NRC [78 hex] to the external test tool. The reception of a negative response message
with NRC [78 hex] causes the external test tool to restart its P2CAN_Tester timer, but using the
enhanced reload value P2*CAN_Tester.
UDS 130: The ECU shall start with its response message within the enhanced P2*CAN_ECU
following the N_USData.con of the previously transmitted negative response message with NRC [78
hex]. If the ECU’s diagnostic application cannot provide the requested information within the
enhanced P2*CAN_ECU then a further negative response message with NRC [78 hex] shall be sent
by the ECU.
UDS 131: As long as the external test tool receives negative response messages with NRC [78 hex]
it shall restart its P2CAN_Tester timer again using the enhanced reload value P2*CAN_Tester.
NOTE: The extended response timing is kept active in the external test tool as long as no final
response message was received or a P2*CAN_Tester Timeout occurred.
Compared to the physical communication timing behavior the functional communication timing
behavior only requires changes in the external test tool’s timing. The ECU’s timing behavior does not
differ. Therefore this section only describes the tool’s timing behavior.
UDS 135: If the external test tool’s network layer has successfully transmitted a service request
message on the bus (signalized by N_USData.con) the external test tool application shall start its
P2CAN Tester timer, using the default reload value P2CAN Tester as described already for
physical communication.
NOTE: The expiration of the P2CAN_Tester timer before a further N_USData.ind or N_USDataFF.ind is
received from the Network Layer indicates either at least one ECU that is expected to response has
not responded yet (external test tool knows the number of ECUs expected to respond) or all possible
responses were received (external test tool does not know the number of ECUs expected to
respond).
UDS 139: When receiving a negative response message with NRC [78 hex], the external test tool’s
application shall restart its P2CAN_Tester timer, using the enhanced reload value P2*CAN Tester. In
addition it has to store an ECU label in a list of ECUs which currently send negative response
messages with NRC [78 hex] (pending ECU). Every ECU that sends a negative response message
with NRC [78 hex] shall be stored in this list.
UDS 140: Once an ECU that is stored as pending starts with its final response message (positive
response message or negative response message including a response code other than NRC [78
hex]) it shall be deleted from the list of pending response messages. In case no further response
messages are pending the external test tool’s application re-uses the default reload value for its
P2CAN_Tester timer (enhanced response timing is no longer active). As long as there is at least one
ECU label stored in the list of pending response messages any start of a further response messages
from any ECU that was addressed by the preceding request will cause a restart of the
P2CAN_Tester timer using the enhanced reload value P2*CAN Tester.
UDS 143: The time for the diagnostic service data interpretation scheduler shall be less than the
performance requirement P2CAN_ECU in order to meet the ECU requirements specified in section
6.2.
UDS 144: The ECU shall be capable of receiving and processing a new diagnostic service request
immediately after having finished processing a previous diagnostic service request.
UDS 146: The value of P3CAN_Tester_Phys shall be equal to the ECU specific P2CAN_ECU_max
for the physically addressed ECU. This applies to any physically addressed request message in any
diagnostic session (default and non-default session) and when no response is required from the
ECU (Suppress Pos Rsp Msg Indication Bit = TRUE).
UDS 147: The P3CAN_Tester_Phys timer shall be started in the external test tool each time a
physically addressed request message with no response required is successfully transmitted onto
the bus indicated by N_USData.con.
UDS 148: An additional N_USData.req requesting the network layer to transmit a physically
addressed request message following the preceding request is only allowed if the
P3CAN_Tester_Phys timer is no longer active. If the P3CAN_Tester_Phys timer is active, the
transmission of any new physically addressed request messages (N_USData.req) shall be
postponed until P3CAN_Tester_Phys has timed out.
UDS 149: The value of P3CAN_Tester_Func shall be the maximum (worst-case) value of all
functionally addressed ECU’s P2CAN_ECU_max for any functionally addressed request message in
any diagnostic session (default and non-default session).
UDS 150: The P3CAN_Tester_Func timer shall be started in the external test tool each time a
functionally addressed request message with response required or with no response required is
successfully transmitted onto the bus indicated by N_USData.con.
UDS 151: An additional N_USData.req requesting the network layer to transmit a functionally
addressed request message following the preceding request is only allowed if the
P3CAN_Tester_Func timer is no longer active. If the P3CAN_Tester_Func timer is active, the
transmission of any new functionally addressed request messages (N_USData.req) shall be
postponed until P3CAN_Tester_Func has timed out.
UDS 152: In case the P3CAN_Tester_Func timer is active when the S3Tester timer expires (see
section 6.4) the functionally addressed Tester Present [3E 00/80 hex] request shall be postponed
until the P3CAN_Tester_Func expires.
Table 8 defines the session layer timing parameter values for session handling during non-default
sessions.
Timing
Description Type
Parameter
Time between functionally addressed Tester Present [3E hex] request messages
Timer
transmitted by the external test tool to keep a diagnostic session other than the Default
S3Tester reload
Session active in multiple ECUs (functional communication) or maximum time between
value
physically transmitted request messages to a single ECU (physical communication).
Timer
Time for the ECU to keep a diagnostic session other than the Default Session active
S3ECU reload
while not receiving any diagnostic request message.
value
UDS 159: After starting a specific diagnostic session other than the Default Session, the external
test tool is responsible to keep this non-default session active in the ECU. The session layer timing
parameters given in Table 8 shall be used in this case. The appropriate start and stop conditions for
the ECU session timer shall be implemented according to Table 9.
UDS 160: The session handling timing parameters in Table 9 shall be active until a transition to
default session takes place.
NOTE: This may be caused by the execution of a Diagnostic Session Control request including sub-
function [01 hex] - Default Session.
Table 9 : Session Layer Timing Start / Stop Conditions for the ECU
Timing
Action Physical and functional communication
Parameter
NOTE: The diagnostic test tool has to distinguish between a periodically transmitted functionally
addressed Tester Present [3E 00/80 hex] request message and a sequentially transmitted physically
addressed Tester Present [3E 00/80 hex] request message, which is only transmitted in case of the
absence of any other diagnostic request message. There is no need for the ECU to distinguish
between functionally and physically addressed Tester Present [3E 00/80 hex] for the purpose of
implementing the session timer correctly. Table 9 shows that the S3ECU timer handling is based on
the network layer service primitives, which means that the S3ECU timer is also restarted upon the
reception of a diagnostic request message that is not supported by the ECU.
UDS 166: The ECU shall provide the respective timer resources listed in Table 10 in order to meet
the application layer timing requirements given in section 6.2.
An optional timer might be required for the enhanced response timing in order to make sure that
P2CAN_ECU sub-sequent negative response messages with response code [78 hex] are transmitted prior to the
expiration of P2*CAN_ECU.
UDS 169: The ECU shall provide the respective timer resources listed in Table 11 in order to meet
the session handling timing requirements given in section 6.4.
A single timer is required in the ECU, because only a single diagnostic session can be active at a
S3ECU
time in a single ECU.
UDS 173: The ECU shall implement the error handling according Table 12.
N_USData.ind from Restart S3ECU timer (because it has been stopped based on the
Request
network layer with a previously received First Frame indication). The ECU shall ignore the
reception
negative result value. request.
N_USData.con from Restart S3ECU timer (because it has been stopped based on the
Response
network layer with a previously received request message). The ECU shall not perform a
transmission
negative result value. retransmission of the response message.
UDS 179: The ECU shall respond to external test tool requests in accordance with Table 13 if the
physically addressed request includes a sub-function parameter.
Table 13 : ECU Response Behavior - Physically Addressed (Uni-cast) Request Messages with
Sub-Function Parameter
NOTE: NRC = XX means that the ECU responds negatively with a particular negative response
code unequal to [11 hex] - Service Not Supported or [12 hex] - Sub-function Not Supported.
NOTE: For details regarding the handling of negative response codes other than the previously
defined, refer to section 9 figure 4
UDS 184: The ECU shall respond to external test tool requests in accordance with Table 14 if the
functionally addressed request includes a sub-function parameter.
ECU sends
6 YES YES Neg Rsp NRC=XX
negative response
TRUE (bit = 1)
ECU does NOT
7 NO --- No Rsp ---
send a response
NOTE: NRC = XX means that the ECU responds negatively with a particular negative response
code unequal to [11 hex] - Service Not Supported, [12 hex] - Sub-function Not Supported or [31 hex]
– requestOutOfRange
NOTE: For details regarding the handling of negative response codes other than the previously
defined, refer to section 9 figure 4.
UDS 190: The ECU shall respond to external test tool requests in accordance with Table 15 if the
physically addressed request does not include a sub-function parameter.
NOTE: NRC = XX means that the ECU responds negatively with a particular negative response
code unequal to [11 hex] - Service Not Supported or [31 hex] - Request Out Of Range.
NOTE: For details regarding the handling of negative response codes other than the previously
defined, refer to section 9 figure 4.
UDS 195: The ECU shall respond to external test tool requests in accordance with Table 16 if the
functionally addressed request does not include a sub-function parameter.xx
NOTE: NRC = XX means that the ECU responds negatively with a particular negative response
code unequal to [11 hex] - Service Not Supported or [31 hex] - Request Out Of Range.
NOTE: For details regarding the handling of negative response codes other than the previously
defined, refer to section 9 figure 4
UDS 200: Negative diagnostic response messages with NRCs [11 hex], [12 hex], and [31 hex] shall
always be transmitted onto the bus within the time P2CAN_ECU.
NOTE: This implies that no negative response messages with NRC [78 hex] - Request Correctly
Received Response Pending are transmitted first.
UDS 202: After a single negative response message with NRC [78 hex] or a sequence of negative
response messages with NRC [78 hex], a final response message (either negative or positive) shall
always be sent by the ECU. This means the Suppress Pos Rsp Msg Indication Bit shall be ignored if
the ECU is not able to provide the requested action (response) within P2CAN_ECU.
UDS 1400: Upon receiving a diagnostic request message including a service identifier value
between 40 hex - 7F hex each ECU shall not send any diagnostic response message.
UDS 1401: Upon receiving a diagnostic request message including a service identifier value
between C0 hex - FF hex each ECU shall not send any diagnostic response message.
NOTE: ECUs engineered for MBC /MB VANs may transmit a negative response or may transmit no
response on receiption of this kind of SIDs.
8 Diagnostic Services
UDS 204: Each individual service described in this chapter shall be supported according to the
conditions defined in Annex A.
UDS 205: Request message parameters (e.g. sub-functions) which are not defined for a specific
diagnostic service shall be considered as "reserved" and shall consequently not be implemented by
an ECU and not be requested by an external test tool.
This session type enables the default diagnostic session in the ECU(s) and does not support any
Default Session diagnostic application timeout handling provisions (e.g. no Tester Present service is necessary to
keep the session active).
This session type enables all diagnostic services and functionality required to support the
Programming Session
memory programming of an ECU.
Extended Diagnostic Session This session type enables all diagnostic services supported by an individual ECU.
Stand By Session Activation of this session type switches the ECU to a state of constant current consumption.
This diagnostic session enables all diagnostic services required to support safety system related
Safety System Diagnostic Session
functions e.g. airbag deployment (see reference ISO 26021 for details).
User Defined Specific session types may be defined additionally.
Diagnostic Session
Description
type
Default P2CAN_ECU_max timing parameter supported by the ECU for the activated diagnostic session.
P2CAN_ECU_max
(see definition in section 6.2)
Enhanced P2*CAN_ECU_max timing parameter supported by the ECU for the activated diagnostic session.
P2*CAN_ECU_max
(see definition in section 6.2)
When powered up, an ECU starts in the default diagnostic session and retains this session type as
long as it is powered up or until a request to enter a session type other than the default diagnostic
session is received (see section 8.1.3.4 for further details). A diagnostic test tool always assumes
that only one diagnostic session is active in an ECU at any given time.
UDS 219: All diagnostic sessions, except the Default Session, shall be tied to the diagnostic session
timer (refer to section 6.4 for detailed requirements).
UDS 220: Whenever the diagnostic test tool requests to enter a diagnostic session that is already
active, the ECU shall send a Diagnostic Session Control positive response message as if it would
normally enter the requested diagnostic session.
NOTE: For further details regarding the implementation of diagnostic session transition requirements
refer to section 8.1.3.5.
UDS 222: Whenever the external test tool requests to enter a new diagnostic session the ECU shall
first send a Diagnostic Session Control positive response message before the new diagnostic
session becomes active.
UDS 223: If the ECU is not able to start the requested new diagnostic session, then it shall respond
with a Start Diagnostic Session Control negative response message and the current session shall
continue.
UDS 225: Within one specific diagnostic session only a predefined set of diagnostic services,
functionality, and application layer timing parameters shall be active.
UDS 226: If a diagnostic service is supported by an ECU it shall be executable in the diagnostic
sessions as defined in Table 19.
NOTE: The ‘X’ indicates that a service identifier is supported while the ECU is running in the
specified Diagnostic Session, given that the particular service is implemented by an ECU. This
Copyright Daimler AG 2013
implies that a diagnostic service which is not marked with an 'X' in Table 19 shall consequently not
be executable (i.e. be rejected) in the associated diagnostic session. Table 19 does not specify
whether a specific diagnostic service has to be implemented in general. Refer to Annex A for details
which diagnostic services have to e implemented by an ECU.
Application Mode
Diagnostic
Diagnostic
Extended
Stand By
Session
Session
Session
Session
System
Default
Safety
Service
X
ISO 15031-5 service identifier [01 hex] – [09 hex] X (C1)
(C1)
C1: All services defined by ISO 15031-5 shall only be supported if the appropriate ECU shall comply
with OBD II / EOBD legislative requirements.
C2: An ECU only supports these services in default session if no security consideration prohibits the
use of this service in default session.
UDS 232: While in the Default Session, only the diagnostic service parameters that do not require
Security Access are allowed, as the Security Access service is not allowed during the Default
Session (see C2 above).
UDS 1446: Support of diagnostic services related to the programming session shall be implemented
as defined in MBN 10761.
UDS 234: If a session state transition takes place, the timing parameters P2CAN_ECU _and
P2*CAN_ECU as defined in MBN 10746 shall be reported via the positive response message to the
external test tool (refer to see section 8.1.4.2 for the message format).
NOTE: Each session type may support specific application layer timing parameters (P2CAN_ECU _and
P2*CAN_ECU). If for specific scenarios timing values are necessary which deviate from the values
defined in MBN 10746, these timing parameter values must be approved by the Diagnostic
Development Team.
A Default Session
UDS 238: An ECU shall always start in the Default Session when powered up.
UDS 239: If no other diagnostic session is requested, then the Default Session shall be running as
long as the ECU is powered.
B Programming Session
This session type provides the specific functionality required for ECU Flash Re-programming defined
in MBN 10761.
UDS 242: The Programming Session shall be implemented as defined in MBN 10761.
D Stand By Session
The implementation of this session type applies to ECUs, which automatically perform actuator
controls or calibrations without requiring a user interaction and thereby affect the overall vehicle
current consumption. If an ECU is put into this session all automatic controls are deactivated and
thereby grant that the ECU and its sub-systems have a constant current consumption (e.g. for ECOS
test)
UDS 1471: The ECU shall switch to a state of constant current (+/- 50 mA) consumption if this
session type is activated.
NOTE: The constant current consumption of an ECU ( Stand By Session) must be supported under
the following conditions:
- Ignition = "ON"
- Network communication of the ECU = running
- Diagnostic communication = active
- Environmental temperature between 20°C and 40°C
UDS 249: Once an ECU has entered Stand By Session, if a request is made that could damage an
ECU due to the constant level of current consumption, the request shall not be acted upon and the
appropriate negative response shall be sent.
NOTE: This document does not define how the deployment procedure itself needs to be
implemented. Please refer to ISO 26021 for further details.
Figure 2 shows a diagnostic session transition diagram. Each depicted state transition requires a
specific ECU behavior described in requirements UDS 8.1-17 - UDS 8.1-21.
Figure 2 shows a diagnostic session transition diagram. Each depicted state transition requires a
specific ECU behavior described in requirements UDS 1458, UDS1459 and UDS 1460.
Programming Yes
Request?
No
Yes Application No
valid?
a) SessionControl - ProgrammingSession
a) SessionControl - DefaultSession
b) SessionControl - SupplierSpecificSession
Application c) SessionControl - ManufacturerSpecificSession
Default Session
Flashloader
a) SessionControl - DefaultSession
Default Session
a) SessionControl - ExtendedDiagnosticSession
b) SessionControl - StandbySession
c) SessionControl - SafetySystemDiagnosticSession
d) SessionControl - SupplierSpecificSession
e) SessionControl - ManufacturerSpecificSession
a) SessionControl - ProgrammingSession
b) SessionControl - ExtendedDiagSession
a) SessionControl - DefaultSession
b) Communication Timeout S3
Application
Non-Default Session
Flashloader
a) SessionControl - ExtendedDiagnosticSession
b) SessionControl - StandbySession
Non-Default Session
c) SessionControl - SafetySystemDiagnosticSession
d) SessionControl - SupplierSpecificSession
e) SessionControl - ManufacturerSpecificSession
a) SessionControl - ProgrammingSession
b) SessionControl - ExtendedDiagSession
d) SessionControl - SupplierSpecificSession
e) SessionControl - ManufacturerSpecificSession
a) SessionControl - DefaultSession
a) SessionControl - ProgrammingSession b) ECUReset - HardReset
b) ECUReset - HardReset c) Communication Timeout S3
UDS 258: Only the following session state transitions shall be allowed:
• Default Session to any other session
• Default Session to Default Session
• Any other session to any other or the same session
• Any other session to Default Session
UDS 1464: Only the the session state transitions shown in figure 2 shall be allowed.
NOTE: The transition to the Programming Session and the related transition between application
and boot loader software are documented in MBN 10761.
UDS 1458: If the Default Session is active and the external test tool requests the ECU to enter the
Default Session, the ECU shall re-initialize the Default Session completely, meaning the ECU shall
reset all activated, initiated or changed settings, controls and routines during the activated session.
This does not include long term changes programmed into non-volatile memory.
UDS 1459: When the ECU transitions from any diagnostic session other than the Default Session to
another session other than the Default Session (including the currently active diagnostic session) the
ECU shall (re-) initialize the requested diagnostic session. This means the security feature shall be
enabled and routines as well as controls shall be reset. The states of the Communication Control
and Control DTC Setting services shall remain as they were prior to the transition to or re-
initialization of the requested diagnostic session.
UDS 1460: When the ECU transitions from any diagnostic session other than the Default Session to
the Default Session, the ECU shall initialize the Default Session. This means the security feature
shall be enabled, the states of the Communication Control and Control DTC Setting services shall be
reset and the ECU shall reset all activated, initiated or changed settings, controls and routines during
the activated non-default session. This does not include long term changes programmed into non-
volatile memory.
UDS 268: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 270: The Diagnostic Session Control request shall follow the format defined in Table 20.
Message
Data Byte No. Parameter Name Data Value
Usage
UDS 275: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 21.
Message
Data Byte No. Parameter Name Usage Data Value
UDS 278: If an ECU responds positively to a Diagnostic Session Control Request, the Diagnostic
Session Type in the response shall match the Diagnostic Session Type sent in the request.
UDS 279: The application layer timing parameters reported as Session Parameter Record shall
follow the scaling format defined in Table 22.
P2CAN_ECU_max 2 1 0 ms 65535 ms
P2*CAN_ECU_ma
2 10 0 ms 655350 ms
x
UDS 282: The negative response to a Diagnostic Session Control service request shall meet the
format defined in Table 23:
Message
Data Byte No. Parameter Name Data Value
Usage
1 Negative Response M 7F
2 Diagnostic Session Control M 10
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length Or Invalid Format 13
Conditions Not Correct 22
UDS 285: The negative response codes defined in Table 23 shall be supported by the ECU as a
minimum set. Additionally chapter 9 defines negative response codes, which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1461: If the Diagnostic Session Control type does not match any of those specified in
requirement UDS 270 the ECU shall respond with the negative response code [12 hex] - Sub
Function Not Supported
UDS 287: If the length of the message is wrong the ECU shall respond with the negative response
code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 288: If the criteria for the requested session state transition are not met, the ECU shall respond
with the negative response code [22 hex] - Conditions Not Correct.
This type 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).
Hard Reset This implies that memory (volatile and non-volatile) as well as electronic sub-components directly connected to
the ECU (e.g. smart sensors or LIN-components) are initialized upon request of this reset type which are also
initialized during the power-up sequence.
This type identifies a "soft reset" condition, which causes the ECU to immediately restart the application
program if applicable.
Soft Reset
Before restarting the application the ECU saves any data in non-volatile memory that might be lost during the
startup sequence.
UDS 296: The ECU Reset positive response message (if required) shall be sent before the reset is
executed by the ECU(s).
NOTE: After an ECU reset has been executed the default session is active.
UDS 299: The following actions shall be performed if an ECU Reset request with ECU Reset Type
"Hard Reset" is received:
• Immediately restart program execution
• Re-initialize volatile memory which is also initialized during the power-up sequence
• Re-initialize non-volatile memory which is also initialized during the power-up sequence
• Re-initialize electronic sub-components directly connected to the ECU which are also
initialized during the power-up sequence
UDS 304: The following actions shall be performed if an ECU Reset request with ECU Reset Type
"Soft Reset" is received:
• Save volatile data not to be lost during the ECU reset in non-volatile memory
(e.g. fault memory and variant coding parameters)
• Immediately restart application program
UDS 311: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 313: The ECU Reset request message shall follow the format defined in Table 25.
Message
Data byte no. Parameter name Data value
Usage
UDS 318: If an ECU is responding to a request with request type Hard Reset or Soft Reset and a
positive response is required in accordance with section 7.1, the response shall follow the format
defined in Table 26.
Table 26 : Positive Response Message Definition - ECU Reset (Hard Reset, Soft Reset)
Message
Data byte no. Parameter name Data value
Usage
UDS 328: If an ECU responds positively to an ECU Reset request, the ECU Reset Type in the
response shall match the ECU Reset Type sent in the request.
UDS 329: The negative response to an ECU Reset request shall meet the format defined in the
Table 27.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 ECU Reset M 11
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
UDS 1466: The negative response codes defined in Table 27 shall be supported by the ECU as a
minimum set. Additionally, section 9 defines negative response codes, which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 333: If the ECU Reset type does not match any of those specified in Table 24, the ECU shall
respond with the negative response code [12 hex] - Sub Function Not Supported
UDS 334: If the length of the ECU Reset message is wrong, the ECU shall respond with the
negative response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 335: If the criteria for the request ECU Reset are not met, the ECU shall respond with negative
response code [22 hex] - Conditions Not Correct.
NOTE: The criteria for an ECU reset to be performed are ECU specific.
This parameter contains a 3-byte value indicating the group of DTCs (e.g., Emission Related
Group Of DTC
Systems, All Groups / All DTCs) or the particular DTC to be cleared.
UDS 344: The ECU shall send a positive response when the Clear Diagnostic Information service is
completely processed.
NOTE: This implies that the requested DTC group (single DTC or all DTCs) could be deleted
successfully
UDS 345: The ECU shall send a positive response, if no DTCs are stored.
UDS 349: A Clear DTC information request shall reset/erase all DTC information (except mirror
memory) including the following:
• DTC
• DTC status byte
• Captured DTC snapshot data
• Captured DTC extended data
• Other DTC related data such flags, counters, timers, etc. specific to DTC
UDS 355: Any DTC information stored in the DTC mirror memory (also referred to as historical
stack) shall not be cleared by this service.
UDS 357: The ECU shall meet the request and response message behavior as specified in section
7.2.
UDS 359: The Clear Diagnostic Information request message shall follow the format defined in
Table 29.
Message
Data byte no. Parameter name Usage Data value
The range of [000000 - 0000FF] is reserved by ISO/SAE for future legislative requirements.
UDS 365: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 30.
Message
Data byte no. Parameter name Data value
Usage
UDS 368: The negative response to a Clear Diagnostic Information request shall follow the format
defined in Table 31.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Clear Diagnostic Information Request Service Id M 14
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
UDS 1467: The negative response codes defined in Table 31 shall be supported by the ECU as a
minimum set. Additionally, section 9 defines negative response codes, which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 372: If conditions prevent the clearing of DTC information, the ECU shall respond with the
negative response code [22 hex] - Conditions Not Correct.
UDS 373: If the length of the message is wrong, the ECU shall respond with the negative response
code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 374: If the specified Group Of DTC parameter is not supported, the ECU shall respond with the
negative response code [31 hex] - Request Out Of Range.
NOTE: Indivdual DTCs which are not supported by an ECU are also considered as an unsupported
Group Of DTC parameter.
UDS 376: If an external test tool requests to clear an individual DTC which is supported by an ECU
but the requested DTC is currently not stored in the chrono-stack then the ECU shall positively
respond and reset the DTC status information accordingly."
DTC Information
Description
request type
This type specifies that the ECU shall transmit to the external test tool the number of
Report Number Of
DTCs matching an external test tool defined status mask.
DTC By Status
This functionality applies its DTC status filtering to the current status of all DTCs incl.
Mask
those stored in the chrono-stack and excluding those in the historical stack. Refer to
[19 01 hex]
MBN-10746 for implementation details.
This type specifies that the ECU shall transmit to the test device a list of DTCs and
Report DTC By corresponding statuses matching an external test tool defined status mask.
Status Mask This functionality applies its DTC status filtering to the current status of all DTCs incl.
[19 02 hex] those stored in the chrono-stack and excluding those in the historical stack. Refer to
MBN-10746 for implementation details.
Report DTC This type specifies that the ECU shall transmit to the external test tool the
Snapshot Record DTC Snapshot record(s) associated with an external test tool defined DTC number and
By DTC Number DTC Snapshot record number ([FF hex] for all records).
[19 04 hex] This functionality is typically used to read freeze frame data from emissions related ECUs.
This parameter specifies that the server shall transmit to the client the DTCSnapshot
ReportDTCSnaps
record(s) associated with a client defined DTCSnapshot record number (FF hex for all
hotRecordBy
records).
RecordNumber
Note that this sub-function parameter can only be supported if the
[19 05] hex
DTCSnapshotRecordNumber is unique to the server (each record number exists only
once in the server) and not unique to a DTC.
Report DTC This type specifies that the ECU shall transmit to the external test tool the DTC Extended
Extended Data Data record(s) associated with an external test tool defined DTC number and DTC
Record By DTC Extended Data record number ([FF hex] for all records).
Number This functionality is used to read environmental data from chrono-stack. Refer to MBN-
[19 06 hex] 10746 for implementation details.
This parameter specifies that the ECU shall transmit to the external test tool a list of all
Report Supported
DTCs and corresponding statuses currently supported within the ECU.
DTCs
[19 0A hex]
Refer to MBN-10746 for implementation details.
This type specifies that the ECU shall transmit to the external test tool a list of DTCs out
Report Mirror
of the DTC mirror memory and corresponding statuses matching an external test tool
Memory DTC By
defined status mask.
Status Mask
This functionality is used to read the DTCs stored in the historical stack. Refer to MBN-
[19 0F hex]
10746 for implementation details.
Report Mirror This type specifies that the ECU shall transmit to the external test tool the
Memory DTC DTC Extended Data record(s) - out of the DTC mirror memory – associated with an
Extended Data external test tool defined DTC number and DTC Extended Data record number ([FF hex]
Record By DTC for all records) .
Number This functionality is used to read environmental data from historical-stack. Refer to MBN-
[19 10 hex] 10746 for implementation details.
Report Number Of
This parameter specifies that the ECU shall transmit to the external test tool the number
Mirror Memory
of DTCs out of mirror memory matching an external test tool defined status mask.
DTC By Status
This functionality is used to read the number of DTCs stored in the historical stack. Refer
Mask
to MBN-10746 for implementation details.
[19 11 hex]
This parameter specifies that the ECU shall transmit to the external test tool a list of
current "pre-failed" DTCs which have or have not yet been detected as "pending" or
Report DTC Fault
"confirmed".
Detection Counter
The intention of the DTC Fault Detection Counter is a simple method to identify a growing
[19 14 hex]
or intermittent problem which can not be identified / read by applying the DTC Status
Mask to a particular DTC.
This parameter specifies that the server shall transmit to the client a list of DTCs with
Report DTC With “permanentDTC” status. DTCs which have the status “permanentDTC” have been
Permanent Status previously cleared by the clearDiagnosticInformation service but remain in the non-volatile
[19 15 hex] memory of the server until the appropriate monitors for each DTC have successfully
passed
Request data
Description
parameter type
The DTC Status Mask contains eight (8) DTC status bits. Definitions for each can be found in
section 8.4.4. Status of DTC.
This byte is used in the request message to allow an external test tool to request DTC
information for the DTCs whose status matches the DTC Status Mask. A DTC’s status
matches the DTC Status Mask if any one of the DTC’s actual status bits is set to ‘1’ and the
DTC Status Mask
corresponding status bit in the DTC Status Mask is also set to ‘1’. (i.e., if the DTC Status Mask
is bit-wise logically ANDed with the DTC’s actual status and the result is non-zero, then a
match has occurred). If the external test 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.
DTC Record either contains DTC High Byte, DTC Middle Byte and DTC Low Byte or a DTC
according to SAEJ1939.
DTC High Byte, DTC Middle Byte and DTC Low Byte together represent a unique identification
number for a specific diagnostic trouble code supported by an ECU. The coding of the 3-byte
DTC number can either be done:
- by using the decoding of the DTC High Byte, DTC Middle Byte and DTC Low Byte according
to ISO 15031-6. This format is identified by the DTC Format Identifier = ISO15031-
DTC Mask Record
6DTCFormat, or
- by using the decoding of the DTC High Byte, DTC Middle Byte and DTC Low Byte according
to ISO 14229-1 specification which does not specify any decoding method and therefore allows
a vehicle manufacturer defined decoding method. This format is identified by the DTC Format
Identifier = ISO14229-1DTCFormat.
A DTC within the ECU matches the DTC Mask Record if the two values are identical (exact
match required).
DTC Extended Data Record Number is a 1-byte value indicating the number of the specific
DTC Extended Data record requested for an external test tool defined DTC Mask Record via
the Report DTC Extended Data Record By DTC Number sub-function.
- A value of [01 hex] – [8F hex] requests the ECU to report the vehicle manufacturer specific
stored DTCExtendedData records.
- A value of [90 hex] – [EF hex] requests the ECU to report legislated OBD stored
DTC Extended Data DTCExtendedData records.
Record Number
- Values [F0 hex] – [FD hex] are reserved by ISO/SAE for future reporting of groups in a single
response message.
- A value of [FE hex] requests the ECU to report all legislated OBD stored DTC Extended Data
records in a single response message.
- A value of [FF hex] requests the server to report all stored DTC Extended Data records in a
single response message.
DTC Snapshot Record Number is a single byte value indicating the number of the specific DTC
Snapshot Data Record either associated with one particular DTC or as global unique
identification of a Snapshot Data Record within the individual ECU.
DTC Snapshot For ECUs that do not support multiple DTC Snapshot Data Records for a single DTC, the
Record Number external test tool shall set this value to 0.
For ECUs that do support multiple DTC Snapshot Data Records for a single DTC, the
diagnostic shall set this to a value ranging from 1 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 DTC Snapshot data records at once.
UDS 388: All response parameters of the sub-functions of the diagnostic service Read DTC
Information shall be implemented according to the response data parameter type definitions in
Table 34.
Response data
Description
parameter type
The status of a particular DTC. The definition of the bits contained in the Status Of
Status Of DTC
DTC byte can be found in section 8.4.4. Status of DTC of this specification
This parameter indicates which bits of the Status of DTC byte are supported by an
DTC Status Availability individual ECU. Bits that are not supported by the ECU are returned as 0.
Mask The definition of the bits contained in the Status Of DTC byte can be found in section
8.4.4. Status of DTC of this specification.
This parameter record contains one or more groupings of DTC Record and Status Of
DTC And Status Record
DTC. (See DTC Record and Status Of DTC definition for further details.)
This 1-byte parameter value defines the format of a DTC reported by the ECU.
Either the echo of the DTC Extended Data Record Number parameter specified by
DTC Extended Data the external test tool in the Report DTC Extended Data Record By DTC Number
Record Number request, or the actual DTC Extended Data Record Number of a stored DTC
Extended Data record.
The DTC Extended Data Record is an ECU -specific block of information that may
contain extended status information associated with a DTC. DTC Extended Data
DTC Extended Data
contains DTC parameter values, which have been identified at the time of the
Record
request.
see SDD UDS for further details
This 2-byte parameter refers collectively to the DTC Count High Byte and
DTC Count DTC Count Low Byte parameters that are sent in response to a
Report Number Of DTC request.
Either the echo of the DTC Snapshot Record Number parameter specified by the
DTC Snapshot Record external test tool in the Report DTC Snapshot Record By Record Number request, or
Number
the actual DTC Snapshot Record Number of a stored DTC Snapshot Record.
The DTC Snapshot Record contains a snapshot of data values captured at the time
of the system malfunction occurrence.
The DTC Snapshot Data Record may contain one or multiple data records identified
DTC Snapshot Record
by the respective Data Identifier.
The number and the combination of Data Records within one individual DTC
Snapshot Record is defined within the application specific document.
DTC Snapshot Record This single byte parameter shows the number of Data Identifiers in the DTC
Number Of Identifiers Snapshot Record.
DTC Fault Detection This single byte parameter reports the number of fault detection counts of a DTC
Counter during its maturation phase. For implementation details refer to 8.4.6.15..
This section defines the DTC Status Information Byte representing the maturation and storage state
of an individual DTC. For detailed information concerning usage and implementation refer to
MBN 10746.
Table 35 defines the meaning of each individual bit included in the DTC status byte and the
respective conditions under which the particular bit is set or reset.
ECU Support
Mandatory / Option-
al
Bit Description
Emis- Non-
sion Emission
Related Related
0 Test Failed M M
This bit shall indicate the result of the most recently performed test.
A logical ‘1’ shall indicate that the last test failed meaning that the failure is completely ma-
tured (Active). A logical '0' shall indicate that the result of the most recently performed test
returns a “pass” result.
This bit shall indicate either that a diagnostic test has reported a Test Failed result at any
time during the current operation cycle.
Reset to 0 when a new operation cycle is initiated or after a call to Clear Diagnostic Infor-
mation.
Once this bit is set to 1, it shall remain a 1 until a new operation cycle is started.
1: Test Failed bit = 1 has failed at least once during the current operation cycle.
0: Test Failed bit = 0 has not failed during the current operation cycle or after a call was
made to Clear Diagnostic Information during the current operation cycle.
1: This bit shall be set to 1 and latched if a malfunction is detected during the current opera-
tion cycle.
0: This bit shall be set to 0 after completing an operation cycle during which the test com-
pleted and a malfunction was not detected or upon a call to the
Clear Diagnostic Information service.
ECU Support
Mandatory / Option-
al
Bit Description
Emis- Non-
sion Emission
Related Related
3 Confirmed DTC M M
This bit shall indicate whether a malfunction was detected enough times to warrant that the
DTC is stored in long-term memory (Pending DTC has been set = '1' one or more times for
emission relevant electronic control units). This information can be used by the external test
tool to request additional diagnostic information such as Extended Data Records or Snap-
shot Records.
A Confirmed DTC does not indicate that the malfunction is present at the time of the request
(Pending DTC or Test Failed can be used to determine if a malfunction is present at the time
of the request.).
Reset to logical '0' after a call to Clear Diagnostic Information or after self-healing criteria
have been satisfied (e.g. 40 engine warm-up cycles without another detected malfunction for
emissions-related ECUs, 100 ignition cycles without another detected malfunction for all
other ECUs). Furthermore this bit is reset when the fault record associated with this DTC is
overwritten by a newer DTC with higher priority due to a fault memory overflow.
Refer to MBN 10746 for definition of DTC confirmation and self-healing criteria.
1 : DTC has failed at least once since the last call to Clear Diagnostic Information and self-
healing criteria have not yet been satisfied and the DTC has not been removed from the
fault memory due to an overflow of the available fault records
0: DTC has not failed since the last call to Clear Diagnostic Information or after the self-
healing criteria have been satisfied for the DTC.
This bit shall indicate whether a DTC test has run to completion since the last time a call
was made to Clear Diagnostic Information.
One (1) shall indicate that the DTC test has not run to completion.
If the test runs and passes or fails (Test Failed This Operation Cycle = 1) then the bit shall
be set to a Zero (0) and latched.
Reset to One (1) after a call to Clear Diagnostic Information.
1: DTC test has not run to completion since the last time diagnostic information was cleared.
0: DTC test has returned either a passed or failed test result at least one time since the last
time diagnostic information was cleared.
1: DTC test returned a Test Failed This Operation Cycle = 1 result at least once since the
last time diagnostic information was cleared.
0: DTC test has not indicated a Test Failed This Operation Cycle = 1 result since the last
time diagnostic information was cleared.
6 Test Not Completed This Operation Cycle M O
This bit shall indicate whether a DTC test has ever run and completed during the current
operation cycle.
One (1) shall indicate that the DTC test has not run to completion during the current opera-
tion cycle. If the test runs and passes or fails then the bit shall be set (and latched) to 0 until
a new operation cycle is started.
Reset to 1 after a call to Clear Diagnostic Information.
1: DTC test has not run to completion this operation cycle (or since the last time diagnostic
information was cleared this operation cycle).
0: DTC test has returned either a passed or Test Failed This Operation Cycle = 1 result
during the current operation cycle or since a call was made to Clear Diagnostic Information
during the current operation cycle.
ECU Support
Mandatory / Option-
al
Bit Description
Emis- Non-
sion Emission
Related Related
C1: Bit 1 (Test Failed This Operation Cycle) is Mandatory if Bit 2 (Pending DTC) is supported.
Bit 1 (Test Failed This Operation Cycle) is Optional if Bit 2 (Pending DTC) is not supported.
M: Status bits marked as “M” - Mandatory shall be supported by each individual ECU (attention
should be paid to the difference between emission related and non-emission related ECUs).
O: Status bits marked as “O” - Optional may be supported by the ECU if applicable.
n/a: Status bits marked with "n/a" - Not applicable shall not be supported by the ECU (attention
should be paid to the difference between emission related and non-emission related ECUs).
For details regarding the status transitions for every individual bit described in Table 35 refer to MBN
10746 DPRS section “DTC Fault Status”.
8.4.5 Removed
UDS 410: Every ECU shall adhere to the convention for storing bit-packed DTC status information
as defined in Table 35.
UDS 411: If an ECU provides emissions-related functionality, all DTCs defined by legislated
emissions-related regulations shall support all eight (8) bits of the Status of DTC.
UDS 1443: All non-emissions-related DTCs shall at least support the following status bits:
• Test Failed (bit 0)
• Confirmed DTC (bit 3)
• Test Not Completed Since Last Clear (bit 4)
• Test Failed Since Last Clear (bit 5)
UDS 416: If an ECU is not required to support an optional status bit, this particular bit shall be set to
Zero (0)
UDS 1444: If an ECU is required to support a Warning Indicator by legislation specific requirements
it shall support the Warning Indicator Requested bit (bit 7).
UDS 1397: If the ECU is requested to Report Number Of DTC By Status Mask it shall at first scan
through its currently supported DTCs, based on its actual configuration, performing a bit-wise logical
AND operation between the mask specified by the external test tool and the current status of each
currently supported DTC. For each AND operation yielding a non-zero result, the ECU shall
increment the 2-byte DTC Count value by one (1). As soon as all currently supported DTCs have
been checked once, the ECU shall respond with the appropriate response message defined in
Table 42.
UDS 421: If no DTCs within the ECU match the masking criteria specified in the external test tool’s
request, the ECU shall respond with the appropriate response message defined in section 8.4.7.2
with the resulting 2-byte DTC Count equal to 0.
UDS 422: If the external test 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.
UDS 424: If the ECU is requested to Report DTC By Status Mask it shall at first scan through all
supported DTCs, performing a bit-wise logical AND-ing operation between the DTC Status Mask
specified by the external test tool and the present Status of DTC associated with each DTC
supported by the ECU.
UDS 425: As soon as all supported DTCs have been checked once, the ECU shall respond with the
appropriate response message defined in Table 41 that includes all DTCs for which the bit-wise
AND-ing operation has yielded a non-zero result. (Status Of DTC & DTC Status Mask! = 0).Thus the
response contains all DTCs for which the Status of DTC matches at least one of the requested bits
set to one (1) in the DTC Status Mask.
NOTE: This procedure allows for requesting the ECU to report all DTCs that are “Test Failed” OR
“Confirmed” OR “etc.” at once.
UDS 427: If the external test 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.
UDS 428: If no DTCs within the ECU match the masking criteria specified in the external test tool’s
request, no DTC or status information shall be provided within the positive response message.
UDS 430: If the ECU is requested to Report DTC Extended Data Record By DTC Number first of all
it shall detect the respective DTC.
UDS 431: If the ECU supports only one extended data record per DTC, it shall respond with the
appropriate response message defined in Table 43 including a single pre-defined extended data
record when requested to report this particular Extended Data Record or all Extended Data Records
[FF hex].
UDS 432: If the ECU supports multi extended data records per DTC it shall respond with the
appropriate response message defined in Table 43 include a single pre-defined extended data
record selected by the request specific DTC Extended Data Record Number value.
UDS 433: If the ECU supports multiple extended data records and receives a request with an
Extended Data Record Number value equal to [FF hex], the ECU shall respond with the appropriate
response message defined in Table 43 including all extended data records defined for the specific
DTC.
UDS 435: All requirements from section 8.4.6.2 apply to section 8.4.6.5; however the data shall be
reported from the historical stack of an ECU.
UDS 437: All requirements from section 8.4.6.3 apply to section 8.4.6.6; however the data shall be
reported from the historical stack of an ECU.
8.4.6.7 Report Mirror Memory DTC Extended Data Record By DTC Number
UDS 1287: All requirements from section 8.4.6.4 apply to section 8.4.6.7; however the data shall be
reported from historical stack of an ECU.
8.4.6.8 Removed
8.4.6.9 Removed
8.4.6.10 Removed
8.4.6.11 Removed
8.4.6.12 Report DTC Snapshot Record either By DTC Number or Snapshot Record Number
A DTC Snapshot record can contain multiple data parameters that can be used to reconstruct the
vehicle conditions (e.g. B+, RPM, time-stamp) at the time of the failure occurrence.
UDS 457: If the ECU is requested to Report DTC Snapshot Records by DTC Number it shall first
scan through its supported DTCs for an exact match with the DTC Mask Record specified by the
external test tool. When a match has occurred, along with the DTC and Status record, the ECU shall
report one or multiple Snapshot Record structures according to the definition in Table 44. If this sub-
function is used, the DTC Snapshot Record Number parameter provided in the request specifies a
particular occurrence of the respective DTC for which DTC Snapshot record data is being requested.
However, if the parameter value is equal to [FF hex] the ECU shall report all Snapshot Records
presently assigned to one specific DTC.
UDS 458: If the ECU is requested to Report DTC Snapshot Records By Record Number it shall at
first scan through its stored DTC Snapshot Records for an exact match with the Record Number
specified by the diagnostic tool. When a match has occurred the ECU shall report along with the
DTC And Status record the respective DTC Snapshot Record according to the definition in Table 45.
However, if the DTC Snapshot Record Number specified in the request is equal to FF hex, the ECU
shall report all stored DTC Snapshot Records with the respective DTC And Status record.
NOTE: If the DTC Snapshot Record Number is unique to the ECU (each record number exists only
once in the ECU ) then both sub-function parameters (Report DTC Snapshot Record By DTC
Number and Report DTC Snapshot Record By Record Number) to retrieve the DTC Snapshot
records may be used.
In case the DTC Snapshot Record Number is unique to a DTC then only the report DTC Snapshot
Record By DTC Number shall be used.
UDS 460: The ECU shall negatively respond if the DTC Mask record or DTC Number parameters
specified by the external test tool are invalid or not supported by the ECU.
UDS 461: If the DTC Mask Record or the DTC Number parameters specified by the external test
tool are indeed valid and supported by the ECU, but no DTC Snapshot data associated with it is
available, the ECU shall send a positive response containing only the DTC Number And Status
Record.
UDS 463: The data reported in the DTC Snapshot Record first of all shall contain a two (2) byte
Data Identifier to identify the data that follows. This Data Identifier - Data combination may be
repeated within the DTC Snapshot Record.
UDS 464: A parameter, which indicates the number of record Data Identifiers contained within each
DTC Snapshot Record, shall be provided with each DTC Snapshot Record to assist data retrieval.
8.4.6.13 Removed
UDS 469: The ECU shall support the ability to report all supported DTCs based on its current
configuration of supported DTCs and do so as defined in Table 41. In addition to the DTC Status
Availability Mask, the response message shall contain the list of DTC And Status Records, which
contains the DTC number and associated status for every DTC supported by the ECU.
UDS 471: If an ECU is requested to Report DTC Fault Detection Counter, all individual DTCs
implementing a Fault Detection Counter shall be reported if the value of the counter is greater than
zero (0) but less than 127 [7F hex].
UDS 472: The value of the counter reported in the response message shall be a scaled 1 byte
signed value.
UDS 473: A value equal to +127 [7F hex] shall represent a test result of “failed”. Any other non-zero
positive value shall represent a test result of “pre-failed”.
NOTE: A DTC Fault Detection Counter 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 pre-failed
at least in one condition or threshold.
UDS 475: The DTC Fault Detection Counter shall be incremented after a specified amount of time
(specified by the vehicle manufacturer) the test logic runs and indicates a fail for that test run.
Copyright Daimler AG 2013
UDS 476: The DTC Fault Detection Counter shall be decremented after a specified amount of
(specified by the vehicle manufacturer) the test logic runs and indicates a pass for that test run.
UDS 477: As soon as the ECU has determined that all DTCs having a DTC Fault Detection Counter
value equal to the criteria defined in UDS 8.4-85 the ECU shall respond with the appropriate
response message defined in Table 46 that includes the respective DTC number and DTC Fault
Detection Counter status.
DTCs which have the status "permanentDTC" may have been previously cleared by the
clearDiagnosticInformation service but still remain in the non-volatile memory of the ECU until the
appropriate monitors for each DTC have successfully passed.
Permanent DTCs cannot be cleared by any test equipment (e.g. on-board tester, off-board tester).
The OBD system shall clear these DTCs itself by completing and passing the on-board monitor. This
prevents clearing DTCs simply by disconnecting the battery.
A confirmed DTC is stored as a permanent DTC no later than the end of the ignition cycle and
subsequently at all times that the confirmed DTC is commanding the Malfunction Indicator on (e.g.
for currently failing systems, but not during the 40 warm-up cycle self-healing process).
Permanent DTCs are erasable if the engine control module is reprogrammed and the readiness
status for all monitored components and systems is set to “not complete.”
UDS 481: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 483: Requests to an ECU to report Number Of DTC By Status Mask, Number Of Mirror
Memory DTC By Status Mask, DTC By Status Mask and Mirror Memory DTC By Status Mask shall
follow the format defined in Table 36.
Table 36 : Request Message Definition - Read DTC Information (By Status Mask)
UDS 487: Requests to an ECU to report DTC Extended Data By DTC Number and Mirror Memory
DTC Extended Data By DTC Number shall follow the format defined in Table 37.
Table 37 : Request Message Definition - Read DTC Information (By DTC Number)
ISO/SAE reserved 00
ECU supports multi Extended Data Records per DTC - Report one specific record 01 - 8F
ECU supports multi Extended Data Records per DTC – Report all records FF
UDS 491: Requests to an ECU to report DTC Snapshot Record By DTC Number shall follow the
format defined in Table 38.
Table 38 : Request Message Definition - Read DTC Information (Report DTC Snapshot
Record By DTC Number)
ISO/SAE reserved 00
UDS 501: Requests to an ECU to report DTC Snapshot Record By Record Number shall follow the
format defined in Table 39.
Message
Data byte no. Parameter name Data value
Usage
UDS 504: A request to an ECU to report all Supported DTCs, DTC Fault Detection Counter or DTC
With Permanent Status shall follow the format defined in the Table 40.
Table 40 : Request Message Definition - Read DTC Information (Supported DTCs / DTC Fault
Detection Counter)
Message
Data byte no. Parameter name Data value
Usage
UDS 509: In the positive response to a Read DTC Information request, the Report Type in the
response shall echo the Request Type sent in the request.
Table 41 : Positive Response Message Definition - Read DTC Information (Report DTC by
Status / Report Mirror Memory DTC By Status Mask / Report Supported DTCs)
Message
Data byte no. Parameter name Data value
Usage
C1: This parameter is present if at least one DTC And Status record is available to be reported.
C2: This parameter is only present if more than one DTC And Status record is available to be
reported.
UDS 516: A positive response by an ECU to a Report Number Of DTC By Status Mask or Report
Number Of Mirror Memory DTC By Status Mask Type request shall follow the format defined in the
Table 42.
Table 42 : Positive Response Message Definition - Read DTC Information (Report Number Of
DTC By Status Mask / Report Number Of Mirror Memory DTC By Status Mask)
Message
Data byte no. Parameter name Data value
Usage
UDS 521: A positive response by an ECU to a Report Extended Data Record By DTC Number or
Report Mirror Memory Extended Data Record By DTC Number Report Type request shall follow the
format defined in Table 43.
Table 43 : Positive Response Message Definition - Read DTC Information (Report Extended
Data Record / Report Mirror Memory DTC Extended Data By DTC Number)
Message
Data byte no. Parameter name Data value
Usage
: : : :
no. t DTC Extended Data Record Number no. x C2 xx
C1: The DTC Extended Data Record Number and the Extended Data in the DTC Extended Data
Record parameter are only present if at least one DTC Extended Data Record is available to be
reported.
C2: The DTC Extended Data Record Number and the Extended Data in the DTC Extended Data
Record parameter are only present if all records are requested to be reported and more than one
record is available to be reported. (DTC Extended Data Record Number set to [FF hex] in the
request)
UDS 531: A positive response by an ECU to a Report DTC Snapshot Record By DTC Number
Report Type request shall follow the format defined in Table 44.
Table 44 : Positive Response Message Definition - Read DTC Information (Report DTC
Snapshot Record By DTC Number)
Message
Data byte no. Parameter name Data value
Usage
: : : :
t DTC Snapshot Record Number no. x C3 00-FF
t+1 DTC Snapshot Record Number Of Identifiers no x C3 00-FF
C1: The DTC Snapshot Record Number and the first Data Identifier/Snapshot Data combination in
the DTC Snapshot Record parameter is only present if at least one DTC Snapshot record is
available to be reported (DTC Snapshot Record Number unequal to [FF hex] in the request or only
one record is available to be reported if DTC Snapshot Record Number is set to [FF hex] in the
request).
C2/C4: There are multiple Data Identifier / Snapshot Data combinations allowed being present in a
single DTC Snapshot Record. E.g. this can be the case for the situation where a single Data
Identifier only references an integral part of data. When the Data Identifier references a block of data
then a single Data Identifier / Snapshot Data combination can be used.
C3: The DTC Snapshot Record Number and the first Data Identifier / Snapshot Data combination in
the DTC Snapshot Record parameter is only present if all records are requested to be reported.
Copyright Daimler AG 2013
UDS 545: A positive response by an ECU to a Report DTC Snapshot Record By Record Number
Report Type request shall follow the format defined in Table 45.
Table 45 : Positive Response Message Definition - Read DTC Information (Report DTC
Snapshot Record By Record Number)
Message
Data byte no. Parameter name Data value
Usage
DTCSnapshotRecord[] #1 = [
9 dataIdentifier#1 byte #1 (MSB) C1 00-FF
: : : :
9+k-1 dataIdentifier#1 byte #k C1 00-FF
9+k snapshotData#1 byte #1 C1 00-FF
: : : :
9+k+(p-1) snapshotData#1 byte #p C1 00-FF
: : : :
: dataIdentifier#w byte #1 (MSB) C2 00-FF
: : : :
r-(m-1)-1 dataIdentifier#w byte #k C2 00-FF
r-(m-1) snapshotData#w byte #1 C2 00-FF
: : : :
r snapshotData#w byte #m ] C2 00-FF
: : : :
t DTCSnapshotRecordNumber #x C2 00-FF
DTCAndStatusRecord[] #x = [
t+1 DTCHighByte C2 00-FF
t+2 DTCMiddleByte C2 00-FF
t+3 DTCLowByte C2 00-FF
t+4 statusOfDTC ] C2 00-FF
t+5 DTCSnapshotRecordNumberOfIdentifiers #x C2 00-FF
DTCSnapshotRecord[] #x = [
t+6 dataIdentifier#1 byte #1 (MSB) C3 00-FF
: : : :
t+6+k-1 dataIdentifier#1 byte #k C3 00-FF
t+6+k snapshotData#1 byte #1 C3 00-FF
: : : :
t+6+k+(p-1) snapshotData#1 byte #p C3 00-FF
: : : :
: dataIdentifier#w byte #1 (MSB) C4 00-FF
: : : :
n-(u-1)-1 dataIdentifier#w byte #k C4 00-FF
n-(u-1) snapshotData#w byte #1 C4 00-FF
: : : :
n snapshotData#w byte #u ] C4 00-FF
UDS 551: The positive response to a Report DTC Fault Detection Counter Report Type request
shall follow the format defined in Table 46.
Table 46 : Positive Response Message Definition - Read DTC Information (Report DTC Fault
Detection Counter)
Message
Data byte no. Parameter name Data value
Usage
C1: This parameter is only present if at least one DTC has a DTC Fault Detection Counter with a
positive value less than [7F hex].
C2: This parameter record is only present if more than one DTC has a DTC Fault Detection Counter
with a positive value less than [7F hex].
UDS 556: The negative response to a Read DTC Information request shall follow the format defined
in the Table 47.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Read DTC Information M 19
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Request Out Of Range 31
UDS 559: The negative response codes defined in Table 47 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 560: If the Request Type does not match any of those specified in section 8.4.7.1, the ECU
shall respond with the negative response code [12 hex] - Sub Function Not Supported
UDS 561: If the length of the Read DTC Information request message is incorrect, the ECU shall
respond with the negative response code [13 hex] Incorrect Message Length - Invalid Format.
UDS 562: The ECU shall negatively respond to a Read DTC Information request with negative
response code [31 hex] - Request Out Of Range if one of the following request message parameters
contains incorrect values (e.g. unsupported DTC):
• DTC Mask Record
• DTC Extended Data Record Number
This parameter identifies the ECU’s data record being requested by the external test tool (refer to SDD UDS for data
Data Identifier
identifier definition).
This parameter is used by the Read Data By Identifier positive response message to provide the requested data record
values to the external test tool.
Data Record The content of OEM predefined Data Records associated with a specific Data Identifier is defined in SDD UDS.
ECU specific Data Record contents are defined in the respective diagnostic requirement specification applicable to a
certain ECU.
UDS 572: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 574: The Read Data By Identifier request message shall follow the format defined in the
Table 49.
Message
Data byte no. Parameter name Data value
Usage
Data Identifier[]= [
2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF
UDS 577: The Data Identifier parameter shall be used according to the parameter definition in
Table 48.
UDS 579: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in the Table 50.
Message
Data byte no. Parameter name Data value
Usage
Data Identifier[]= [
2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF
Data Record [] = [
4 data no. 1 M 00-FF
: : : :
(k-1)+4 data no. k] O 00-FF
UDS 582: In the positive response to a Read Data By Identifier request, the Data Identifier
parameter value in the positive response message shall echo the Data Identifier parameter value
provided in the request message by the external test tool.
UDS 583: The Data Record parameter in the positive response message shall be used to provide
the requested data associated with the specified Data Identifier to the external test tool.
UDS 584: The negative response to a Read Data By Identifier request shall follow the format
defined in Table 51.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Read Data By Identifier M 22
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
UDS 587: The negative response codes defined in Table 51 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 588: If the length of the request message is incorrect, the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 589: If the ECU can not perform the required action due to operational conditions which were
not met when the Read Data By Identifier request message was processed, the ECU shall respond
with negative response code [22 hex] - Conditions Not Correct.
UDS 590: If the ECU does not support the requested Data Identifier, the ECU shall respond with
negative response code [31 hex] - Request Out Of Range.
UDS 591: If the requested Data Identifier is secured and the ECU is not in an unlocked state, the
ECU shall respond with negative response code [33 hex] - Security Access Denied.
This parameter is a one byte value with each nibble encoded separately:
Address And Length Format
Identifier bit 7 - 4: Length (number of bytes) of the Memory Size parameter
bit 3 - 0: Length (number of bytes) of the Memory Address parameter
The parameter Memory Address is the starting address of ECU’s memory where the data is to be written
or from which the data is to be read. The number of bytes used for this address is defined by the low
Memory Address nibble (bit 3 - 0) of the Address And Length Format Identifier. Byte m (see message description) in the
Memory Address 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 Memory Identifier.
The parameter Memory Size in the Read / Write Memory By Address request message specifies the
number of bytes to be read or written starting at the address specified by Memory Address in the ECU's
Memory Size
memory. The number of bytes used for this size is defined by the high nibble (bit 7 - 4) of the Address
And Length Format Identifier.
This parameter is used by the Read Memory By Address positive response message to provide the
Data Record requested data record values to the external test tool. The content of the Data Record is not defined in this
document and is vehicle manufacturer specific.
UDS 599: The ECU shall follow the request and response message behavior as specified in
section 7.2.
UDS 600: Each ECU shall support a length of 1 to 4 bytes for the Memory Size parameter.
UDS 601: Each ECU shall support a length of 1 to 4 bytes for the Memory Address parameter.
UDS 603: The Read Memory By Address request message shall follow the format defined in
Table 53.
Message
Data byte no. Parameter name Data value
Usage
: : M :
:
C1
(m-1)+3 byte m] 00-FF
: : M :
:
C2
n byte k] 00-FF
C1: The presence of this parameter depends on the address length information parameter of the
Address And Length Format Identifier (m equals the decimal value of the low nibble).
C2: The presence of this parameter depends on the memory size length information of the
Address And Length Format Identifier (k equals the decimal value of the high nibble).
UDS 608: The Address And Length Format Identifier, Memory Address and Memory Size
parameters shall be used according the parameter definition in Table 52.
NOTE: It is also possible to use a fixed Address And Length Format Identifier and unused bytes
within the Memory Address or Memory Size parameter are padded with the value [00 hex] in the
higher range address locations. In case of overlapping memory areas it is possible to use an
additional Memory Address byte as a memory Identifier (e.g. use of internal and external flash).
UDS 611: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 54.
Data Record [] = [
2 data no. 1 M 00-FF
: : : :
(k-1)+2 data no. k] O 00-FF
UDS 614: The Data Record parameter shall be used to provide the requested data associated with
the specified Memory Address to the external test tool according to the definition in Table 52.
UDS 615: The negative response to a Read Memory By Address request shall follow the format
defined in Table 55.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Read Data By Identifier M 23
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
UDS 618: The negative response codes defined in Table 55 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 619: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 620: If the ECU can not perform the required action due to operational conditions which were
not met when the Read Memory By Address request message was processed, the ECU shall
respond with negative response code [22 hex] - Conditions Not Correct.
UDS 621: The ECU shall respond with the negative response code [31 hex] - Request Out Of
Range if the values of the Memory Address (MA), Memory Size (MS) or Address And Length Format
Identifier parameters do not meet the following conditions:
• Each memory address within the specified interval [MA, MA + (MS -1)] is valid.
• The specified memory size is within the ECU’s given limits.
• The specified memory address and length format is valid according to UDS 8.6-14 and
UDS 8.6-15.
UDS 625: The ECU shall respond with the negative response code [33 hex] - Security Access
Denied if the Read Memory By Address service accesses at least one secured memory address
within the interval [MA, MA + (MS -1)] while the security feature of the ECU is active.
This type specifies that the ECU shall transmit to the test device the so called seed value with a
Request Seed defined security level for calculating an appropriate key value to unlock the ECU. Different
request type values represent different security levels and formats.
This type signalizes to the ECU that the external test tool transmits now the appropriate key value
Send Key associated with the seed requested before. Different request type values represent different
security levels and formats.
The seed parameter is a data value sent by the ECU and is used by the external test tool when
Security Seed calculating the key needed to disable (unlock) an ECU’s security feature. The usage of individual
Security Seed parameter values is defined in MBN 10746
The “Key” parameter in the request message is the value generated by the security algorithm
Security Key corresponding to a specific “Seed” value. The usage of the individual Security Key parameter
values is defined in MBN 10746
UDS 637: The ECU shall allow the disabling of its security feature while in any Diagnostic Session
Type with the exception of the Default Session.
UDS 638: The ECU shall enable its security feature if a transition to a new Diagnostic Session or to
the same Diagnostic Session has occurred if the security feature was disabled during the previous
Diagnostic Session.
UDS 640: The specific Security Access Type values shall be used as follows:
• The range of odd numbers out of the interval [01 hex]- [7D hex] is reserved for the Security
Access Type Request Seed
• The range of even numbers out of the interval [02 hex - 7E hex]is reserved for the Security
Access Type Send Key
• One odd number and the proceeding even number out of the specified ranges represent one
applicable pair of Security Access request types, which specify one specific level of security
access; disabling the ECU’s security feature principally requires one of those specific
Security Access request type pairs.
UDS 646: After having received the Security Access Request [27 hex] service requesting the Seed
parameter (sub-function: Request Seed) the ECU shall respond by sending the Security Seed
parameter value using the Security Access Positive Response [67 hex] service (This was
requirement 8.7-A3 in Rev A).
UDS 648: After receiving the calculated Security Key value via the Security Access Request [27
hex] service (sub-function: Send Key) the ECU shall compare this Key value to the one internally
calculated. If the two numbers match, then the ECU shall enable ("unlock") the external test tool's
access to specific services. This shall be indicated to the external test tool via the Security Access
Positive Response [67 hex] service. (This was requirement 8.7-A5 in Rev A)
UDS 649: If an ECU is already unlocked when a Security Access (sub-function: Request Seed)
message is received, the ECU shall respond with a Security Access Positive Response message
service with a seed value equal to zero (0).
UDS 655: If an ECU receives a subsequent Request Seed diagnostic request directly after already
having positively responded to the previous Request Seed diagnostic service, the ECU shall send a
positive response and not respond with an NRC [24 hex] - Request Sequence Error or NRC [35 hex]
- Invalid Key.
UDS 658: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 660: The Security Access request message shall follow the format defined in Table 58.
Message
Data byte no. Parameter name Data value
Usage
ISO/SAE reserved 7F
Security Key [] = [
3 key byte no. 1 (high byte) C1 00-FF
: : : :
n key byte no. m (low byte)] C1 00-FF
C1: The presence of this parameter depends on the sub-function parameter. It is mandatory to be
present if the Security Access type parameter indicates that the external test tool transmits a key
value to the ECU.
UDS 664: Only the Security Access type values defined in Table 58 may be requested when
unlocking an ECU.
UDS 665: The Send Key parameter in the Security Access Request message shall be used to
provide the requested key value according to the parameter definition in Table 57.
UDS 667: If a positive response is allowed in accordance with section 7.1, the response shall follow
the format defined in Table 59.
Message
Data byte no. Parameter name Data value
Usage
Security Seed [] = [
3 seed byte no. 1 (high byte) C 00-FF
: : : :
n seed byte no. m (low byte)] C/O 00-FF
C: The presence of this parameter depends on the Security Access Type parameter. It is mandatory
to be present if Security Access Type parameter indicates that the ECU transmits a seed value to the
external test tool.
UDS 671: In the positive response to a Security Access request, the Security Access type in the
response shall echo the Security Access type sent in the request.
UDS 672: The Security Seed parameter shall be used to provide the requested seed value as
defined in Table 57.
UDS 673: The negative response to a Security Access request shall follow the format defined in
Table 60.
1 Negative Response M 7F
2 Security Access M 27
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub-Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Sequence Error 24
Invalid Key 35
Required Time Delay Not Expired 37
UDS 676: The negative response codes defined in Table 60 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 677: If an ECU receives a Security Access request including a Security Key parameter value
or Security Seed parameter value which is not supported by the actual implementation, the ECU
shall respond with the negative response code [12 hex] - Sub Function Not Supported.
UDS 678: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 679: If the ECU can not perform the required action due to operational conditions which were
not met when the Security Access request message was processed, the ECU shall respond with
negative response code [22 hex] - Conditions Not Correct.
UDS 680: If the ECU receives a Security Access request with type Send Key without first receiving
a Security Access Request - Request Seed, the ECU shall respond with the negative response code
[24 hex] - Request Sequence Error.
UDS 681: If the ECU receives an invalid key value, it shall respond with the negative response code
[35 hex] - Invalid Key.
UDS 683: If the ECU receives a Security Access request before the delay time is expired it shall
respond with the negative response code [37 hex] - Required Time Delay Not Expired.
Enable Rx And Tx This type indicates that the ECU shall enable reception and transmission of messages.
This type indicates that the ECU shall enable reception of messages and disable
Enable Rx And Disable Tx
transmission of messages.
Table 62 defines the possible Communication types. The Communication Type is a 1-byte value.
The bit-encoded low nibble of this byte represents the Communication Types, which can be
controlled via the Communication Control [28 hex] service. The high nibble of the Communication
Type 1-byte value is referred to as Subnet Number and defines which of the subnets connected to
the receiving node shall be disabled or enabled when a corresponding Communication Control
service is received.
UDS 695: The ECU shall perform the requested communication type control after sending the
Communication Control positive response message to the external test tool if a positive response is
requested (Suppress Pos Rsp Msg Indication Bit = FALSE). When no response is requested from
the external test tool (Suppress Pos Rsp Msg Indication Bit = TRUE) then the ECU shall perform the
requested communication type control immediately after the successful evaluation of the request
message.
UDS 696: Communication Control adjustments preventing an ECU to take part in the intended bus
communication are only revoked by following measures:
• Request ECU to switch on transmission again by Communication Control service
• Loss of ECU supply voltage down event (normal ECU power down event)
• Transition from non-default session to Default Session according to the requirements itemized in
section 8.1.
UDS 701: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 703: The Communication Control request message shall follow the format defined in Table 63.
Message
Data byte no. Parameter name Data value
Usage
UDS 706: Only the Control Types and Communication Types defined in Table 63 shall be requested
when controlling communication in an ECU.
UDS 1484: When disabling of communication on an individual subnet is required, the subnet
number shall be encoded as described in Table 64.
Data bit
Description Data value
number
Communication type
Reserved
2 -3 Default 0
Reserved 1-3
Subnet Number
All networks 0
Disable/Enable the specified Communication Type in the receiving node and all
4–7 connected subnets. This only disables the node's communication into the subnets but
not the communication of other nodes on the subnet. A receiving node is not
responsible to disable communication in each node of the connected subnets.
Individual network 1–E
Disable/Enable a specific subnet identified by subnet number (subnet number 1 – 14)
Receiving network F
Disable/Enable network on which the request is received on
NOTE: Subnet Numbers shall be defined individually in the diagnostic documentation of the
respective ECU.
NOTE: Normal Communication Messages do not include messages used for network management
purpose. Therefore network management messages shall still be transmitted even if the
transmission of "Normal Communication Messages" is disabled.
UDS 713: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 65.
Message
Data byte no. Parameter name Data value
Usage
UDS 716: In the positive response to a Communication Control request, the Control Type in the
response shall echo the Control Type sent in the request.
UDS 717: The negative response to a Communication Control request shall follow the format
defined in Table 66.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Communication Control M 28
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub-Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
UDS 720: The negative response codes defined in the Table 66 shall be supported by the ECU as a
minimum set. Chapter 9 further defines negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 721: If the Control Type does not match any of those specified in requirement UDS 8.8-6, the
ECU shall respond with the negative response code [12 hex] - Sub Function Not Supported.
UDS 722: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 723: If the ECU is in a critical normal mode activity and therefore cannot disable/enable the
requested communication type it shall respond with the negative response code [22 hex] -
Conditions Not Correct.
UDS 724: The ECU shall respond with the negative response code [31 hex] - Request Out Of
Range if an error in the Communication Type parameter was detected.
This type shall be used to specify to the ECU that the definition of the Dynamic Data Identifier takes place by
Define By Identifier
means of a Data Identifier reference.
This type shall be used to specify to the ECU that the definition of the Dynamic Data Identifier takes place by
Define By Memory means of an address reference.
Address
This type shall only be used during the development phase of the ECU.
Clear Dynamically
This type requests the ECU to clear the specified Dynamic Data Identifier.
Defined Data Identifier
This parameter specifies how the dynamic data record, which is being defined by the
external test tool, will be referenced in future calls to by the service Read Data By
Dynamically Defined Data Identifier Identifier.
The Dynamically Defined Data Identifier shall be handled just as a Data Identifier in the
Read Data By Identifier service.
This parameter logically specifies the source of information to be included into the
Source Data Identifier
dynamic data record. (refer to SDD UDS for detailed data identifier definition)
This 1-byte parameter is used to specify the starting position of the excerpt of the source
Position In Source Data Record data record to be included in the dynamic data record. A position of one (1) shall
reference the first byte of the data record referenced by the Source Data Identifier.
This parameter is a one byte value with each nibble encoded separately:
Address And Length Format
Identifier bit 7 - 4: Length (number of bytes) of the Memory Size parameter(s)
bit 3 - 0: Length (number of bytes) of the Memory Address parameter(s)
This parameter specifies the memory source address of information to be included into
Memory Address the dynamic data record. The number of bytes used for this address is defined by the
low nibble (bit 3 - 0) of the Address Format Identifier.
This parameter is used to specify the total number of bytes from the source data
record/memory address that are to be included in the dynamic data record.
In case of sub-function = Define By Memory Address [02 hex] this parameter reflects the
number of bytes to be included in the Dynamically Defined Data Identifier starting at the
specified Memory Address. The number of bytes used for this size is defined by the high
nibble (bit 7 - 4) of the Address Format Identifier.
The definition of the dynamically defined data identifier can either be done via a single request
message or via multiple request messages.
Multiple requests allow for the definition of a single dynamically defined data record referencing data
records or elements associated with one or multiple source identifier(s) and memory addresses. In
this case the ECU has to concatenate the source data definitions for the respective dynamically
defined data identifier.
UDS 737: Requests to clear a data record shall be positively responded to if the specified data
record identifier exists at the time of the request, and is within the range of valid dynamic data
identifiers supported by the ECU.
UDS 738: The ECU shall maintain the dynamically defined data identifier and the associated
dynamically defined data records until it is cleared by receiving a Dynamic Data Identifier request
including sub-function Clear Dynamically Defined Data Identifier [03 hex].
UDS 739: The redefinition of a dynamically defined data identifier shall be achieved by clearing the
current definition and start over with the new definition.
UDS 740: Requests defining new dynamic data identifiers are not allowed to partially reference a
parameter (e.g. only the upper 4 bits of 1 byte parameter) as source data. The ECU shall reject such
requests as defined in UDS 8.9-24.
UDS 741: The ordering of the data within the dynamically defined data record shall be of the same
order as it was specified in the external test tool request message(s). The requests defining the order
of the data identifiers within the dynamic data identifier shall follow a sequential order starting at byte
1 of the request message.
NOTE: Although this service does not prohibit such functionality, it is not recommended for the
external test tool to reference one dynamically defined data record from another, because deletion of
the referenced record could create data consistency problems within the referencing record.
UDS 744: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 746: The request message defining a Dynamically Defined Data Identifier by using the sub-
function Define By Identifier shall follow the format defined in Table 69.
Message
Data byte no. Parameter name Data value
Usage
UDS 749: The request message defining a Dynamically Defined Data Identifier by using the sub-
function Define By Memory Address Identifier shall follow the format defined in Table 70.
Message
Data byte no. Parameter name Data value
Usage
C: The presence of these parameters depends on the format information provided by the
Address And Length Format Identifier.
UDS 753: The request message clearing a Dynamically Defined Data Identifier by using the sub-
function Clear Dynamically Defined Identifier shall follow the format defined in Table 71.
Message
Data byte no. Parameter name Data value
Usage
UDS 756: Only the Dynamic Data Identifier Definition types defined in Table 69 - Table 71 shall be
requested when defining or clearing dynamically defined data identifiers.
UDS 757: The respective message parameters shall be used according to definition in Table 68.
UDS 759: If a positive response is allowed in accordance with section 7.1, the response shall follow
the format defined in Table 72.
Message
Data byte no. Parameter name Data value
Usage
UDS 762: In the positive response message to a Dynamically Define Data Identifier request, the
Data Identifier Definition Type in the response shall echo the Dynamic Data Identifier Definition Type
sent in the request.
UDS 763: In the positive response message to a Dynamically Defined Data Identifier request, the
Dynamically Defined Data Identifier value in the response shall echo the Dynamically Defined Data
Identifier value sent in the request.
UDS 764: The negative response to a Dynamically Define Data Identifier request shall follow the
format defined in Table 73:
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Dynamically Define Data Identifier M 2C
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub-Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
UDS 767: The negative response codes defined in the Table 73 must be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 768: If the sub-function parameter included in any of request message defined above does not
match any of the Dynamic Data Identifier Definition Types defined in Table 67, the ECU shall
respond with the negative response code [12 hex] - Sub Function Not Supported.
UDS 769: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 770: If the ECU can not perform the required action due to operational conditions which were
not met when the Dynamically Define Data Identifier request message was processed, the ECU shall
respond with negative response code [22 hex] - Conditions Not Correct.
UDS 771: The ECU shall respond with the negative response code [31 hex] - Request Out Of
Range if one of the following conditions is met:
• Any data identifier (Dynamically Defined Data Identifier or Source Data Identifier) in the
request message is not supported or invalid.
• The Position in Source Data Record is incorrect (less than 1, or greater than maximum
allowed by the ECU).
• Any memory address in the request message is not supported in the ECU.
• The specified Memory Size is invalid.
• One or many of the specified data elements to be included in the Dynamically Defined Data
Identifier only references a portion of an elemental data record.
• The requests defining the order of the data identifiers within the dynamic data identifier do
not follow a sequential order starting at byte 1 of the request message.
• The amount of data to be packed into the dynamic data identifier exceeds the maximum
allowed by ECU.
• The specified Address And Length Format Identifier is not valid.
Copyright Daimler AG 2013
UDS 780: If any Data Identifier (Dynamically Defined Data Identifier or Source Data Identifier) or
Memory Address is secured and the ECU is not in an unlocked state the ECU shall respond with
negative response code [33 hex] - Security Access Denied.
This parameter identifies the ECU’s data record that the external test tool is requesting to write to.
Data Identifier
(Refer to SDD UDS for detailed data identifier definition)
This parameter provides the data record associated with the Data Identifier that the external test tool is requesting to
Data Record
write to.
UDS 788: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 790: The Write Data By Identifier request message shall follow the format defined in Table 75.
Message
Data byte no. Parameter name Data value
Usage
Data Identifier[]= [
2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF
Data Record [] = [
4 data no. 1 M 00-FF
: : : :
(k-1)+4 data no. k] O 00-FF
UDS 793: The Data Identifier parameter shall be used according to the parameter definition in
Table 74.
UDS 795: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 76.
Message
Data byte no. Parameter name Data value
Usage
Data Identifier[]= [
2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF
UDS 798: In the positive response message to a Write Data By Identifier request the Data Identifier
parameter value in the response message shall be echo of the Data Identifier value in the request
message.
UDS 799: The negative response to a Write Data By Identifier request shall follow the format
defined in Table 77:
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Write Data By Identifier M 2E
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
UDS 802: The negative response codes defined in the Table 77 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 803: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 804: If the ECU can not perform the required action due to operational conditions which were
not met when the Write Data By Identifier request message was processed, the ECU shall respond
with negative response code [22 hex] - Conditions Not Correct.
UDS 805: The ECU shall respond with the negative response code [31 hex] - Request Out Of
Range if one of the following conditions is met:
• The Data Identifier included in the request message is not supported or only supported for
read purposes.
• The data included in the request message’s data record parameter is invalid.
UDS 808: The ECU shall respond with negative response code [33 hex] - Security Access Denied if
one of the Data Identifiers is secured and the ECU are not in an unlocked state at the time the
request is received.
This parameter identifies either a group of an ECU’s local input signal (s), internal parameter(s) and / or
Data Identifier output signal(s) or one individual input signal, internal parameter or output signal.
(Refer to SDD UDS for detailed data identifier definition)
This type determines the kind of control operation that shall take place. Following types are applicable:
Return Control To ECU: This type shall indicate to the ECU that the external test tool does no longer
have control about the input signal, internal parameter or output signal
referenced by the Data Identifier.
Number of Control State bytes in request: 0
Reset To Default: This type shall indicate to the ECU that it is requested to reset the input signal,
internal parameter or output signal referenced by the Data Identifier to its
default state.
Number of Control State bytes in request: 0
Input Output
Control Type
Freeze Current State: This type shall indicate to the ECU that it is requested to freeze the current
state of the input signal, internal parameter or output signal referenced by the
Data Identifier.
Number of Control State bytes in request: 0
Short Term Adjustment: This type shall indicate to the ECU that it is requested to set the input signal,
internal parameter or output signal, referenced by the Data Identifier, in RAM
to the value(s) included in the Control Option parameter(s).
Number of Control State bytes in the request: depends on the number of
parameters grouped together in one data record referenced by a particular
Data Identifier
The Control Option Record of each Data Identifier consists of one or multiple bytes
(Control State no. 1 to Control State no. m) with each byte or bit representing the respective adjustment
value associated with one individual input signal, internal parameter or output signal out of the group of
parameters
Control Option
(or one individual parameter ) referenced by the particular Data Identifier. The byte number (bit number
Record
respectively) complies with the order of parameters grouped together within one data record referenced by
the Data Identifier.
In the case of bit value adjustments the assignment of adjustment values always starts with the MSB of
Control State no. 1.
The Control Enable Mask of each Data Identifier consists of one or multiple bytes
(Control Mask no. 1 to Control Mask no. r).
There shall be one bit in the Control Enable Mask corresponding to each individual parameter defined within
the Data Identifier (Note: the parameter could be any number of bits.). The value of each bit shall determine
whether the corresponding parameter in the Data Identifier will be affected by the request. A bit value of '0' in
the Control Enable Mask shall represent that the corresponding parameter is not affected by this request
and a bit value of '1' shall represent that the corresponding parameter is affected by this request.
The most significant bit of Control Mask no. 1 shall correspond to the first parameter in the Control State
starting at the most significant bit of Control State no. 1. The second most significant bit of Control Mask no.
Control Enable
1 shall correspond to the second parameter in the Control State, and continuing in this fashion utilizing as
Mask Record
many Control Mask bytes as necessary to mask all parameters. For example, the least significant bit of
Control Mask no. 2 would correspond to the 16th parameter in the Control State.
For bitmapped Data Identifiers, unsupported bits shall also have a corresponding bit in the
Control Enable Mask so that the position of the mask bit of every parameter in the Control Enable Mask shall
exactly match the position of the corresponding parameter in the Control State.
If a Control Option Record consists of only one parameter the Control Enable Mask is not necessary.
If a Control Option Record references more than one Control State the Control Enable Mask can optionally
be used to determine which of the adjustments included in the Control Option Record of the ongoing request
shall be actually carried out.
The Control State parameter of each Data Identifier record consists of one or multiple bytes
(Input Output Control Type, Control State no. 1 to Control State no. m) which include the current parameter
Control Status
values of the controlled Inputs and/or Outputs.
Record
The Input Output Control Type in the response message is the echo of the Input Output Control Type value
given in the request message.
UDS 817: The ECU shall send a positive response message if the requested control operation was
successfully executed.
UDS 818: After an ECU returns a positive response to this service, the external test tool shall
assume control over the inputs/outputs specified by the Input Output Data Identifier.
UDS 819: The ECU shall return to normal operation (ECU re-assumes control over the I/O
previously under control of the external test tool) if one of the following conditions is met:
• A request to Return Control to ECU [2F XX XX 00 hex] is received.
• A transition to Default Session occurs.
• An ECU Reset occurs.
• Internal disable conditions (e.g. to prevent damage to the ECU or for security reasons).
UDS 1435: Each data record associated with an Input Output Data Identifier shall also be
accessible via diagnostic service [22 hex] using the same Data Identifier.
UDS 1437: The Control Status Record associated with the response of an Input Output Data
Identifier and reported via diagnostic service [22 hex] shall have the identical structure as defined for
the response of diagnostic service [2F hex].
UDS 827: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 829: The Input Output Control By Identifier request message shall follow the format defined in
Table 79.
Message
Data byte no. Parameter name Data value
Usage
C1: Control Option Record parameter is only used when Input/Output Control Type [03 hex] (Short
Term Adjustment) is used.
C2: The presence of those parameters depends on the number of Input / Output parameters
identified by one individual Data Identifier.
C3: Control Enable Mask Record parameter is only used when Input/Output Control Type equals [03
hex] AND the Data Identifier contains more than 1 (one) parameter (packeted data identifier).
UDS 835: The Data Identifier, Control Option Record and Enable Mask Record parameters shall be
used according to the parameter definition in Table 78.
UDS 836: Only the Input Output Control Parameter types defined in Table 78 shall be used when
controlling an ECU’s Input and Output states.
UDS 838: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 80.
Message
Data byte no. Parameter name Data value
Usage
C: The presence of those parameters depends on the number of Input / Output parameters identified
by one individual Data Identifier.
UDS 842: In the positive response to an Input Output Control By Identifier request, the Data
Identifier parameter values and the Input Output Control Type values in the response message shall
echo the values in the request message.
UDS 843: The Control Status parameter record shall be used according to the parameter definition
in Table 78.
UDS 844: The negative response to a Input Output Control By Identifier request shall follow the
format defined in Table 81:
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Input Output Control By Identifier M 2F
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
UDS 847: The negative response codes defined in Table 81 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 848: If the length of the request message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 849: If the ECU can not perform the required action due to operational conditions which were
not met when the Input Output Control by Identifier request message was processed, the ECU shall
respond with negative response code [22 hex] - Conditions Not Correct.
UDS 850: The ECU shall respond with the negative response code [31 hex] - Request Out Of
Range if one of the following conditions is met:
UDS 854: The ECU shall respond with negative response code [33 hex] - Security Access Denied if
the Data Identifier is secured and the ECU is not in an unlocked state at the time the request is
received.
8.12.1.1 General
UDS 864: The ECU shall exit any routine following a reset or power down event.
UDS 866: The routine shall be started in the ECU's memory some time between the completion of
the Routine Control request message with sub-function parameter Start Routine [31 X1 hex] and the
positive response message [71 XX XX ... hex] or the Negative Response with NRC 78 hex (if the
routine cannot respond positively within the appropriate timing).
UDS 869: The routine shall be stopped in the ECU's memory some time between the completion of
the Routine Control request message with sub-function parameter Stop Routine [31 X2 hex] and the
positive response message [71 XX XX ... hex].
NOTE: This requirement only applies to ECUs implementing the Routine Control service and being
not able to stop the started routine on its own accord.
UDS 872: This sub-function shall be used by the external test tool to request routine results (e.g.
exit status information) referenced by a Routine Identifier and generated by the routine which was
executed in the ECU's memory.
NOTE: Either the positive response on a Routine Control request with sub-function parameter Start
Routine provides already the routine results or this sub-function shall be implemented.
The ECU shall only overwrite the routine results if the routine is re-run.
UDS 875: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 1448: The Routine Control request message shall follow the format defined in Table 82 and
Table 125
Data
Data byte no. Parameter name Message Usage
value
Table 125 : Request Message Definition - Routine Control - Request Routine Results
Data
Data byte no. Parameter name Message Usage
value
UDS 881: Only the Routine Control Types defined in Table 82 may be requested when controlling
routines in the ECU’s memory and shall be supported by all ECU’s.
UDS 882: The user optional Routine Control Option Record shall be used for those requests where
additional entry/exit option parameters are needed (e.g. Time To Run or Time To Expire Before
Routine Stops parameter).
UDS 1452: If a positive response is allowed in accordance with 7.1 Request Messages with Sub-
Function Parameter, the response shall follow the format defined in Table 83 and Table 126.
Message
Data byte no. Parameter name Data value
Usage
Table 126 : Positive Response Message Definition- Routine Control - Request RoutineResults
Message
Data byte no. Parameter name Data value
Usage
UDS 887: In the positive response to a Routine Control request, the Routine Control Type and the
Routine Identifier in the response shall echo the Routine Control Type and the Routine Identifier sent
in the request.x
UDS 888: The user optional Routine Status Record shall be used for requests where additional
status information is needed.
UDS 889: The negative response to a Routine Control request shall meet the format defined in.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Routine Control M 31
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
General Programming Failure 72
UDS 892: The negative response codes defined in Table 84 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 893: If the Routine Control Type does not match any of those specified in Table 83 the ECU
shall respond with the negative response code [12 hex] - Sub Function Not Supported.
UDS 894: If the length of the message is incorrect, the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 895: If the ECU cannot perform the required action due to operational conditions which were
not met when the Routine Control request message was processed, the ECU shall respond with
negative response code [22 hex] - Conditions Not Correct.
UDS 896: If the specified Routine Identifier parameter or the optional Routine Control Option
parameter record is sent by the external test tool but is not supported, the ECU shall respond with
the negative response code [31 hex]- Request Out Of Range.
UDS 897: The ECU shall respond with negative response code [33 hex] - Security Access Denied if
the Routine Identifier is secured and the ECU is not in an unlocked state at the time the request is
received.
UDS 898: If the ECU detects an error while performing a routine, which accesses ECU internal
memory, the ECU shall respond with the negative response code [72 hex] - General Programming
Failure.
Request Download
/ Upload Description
parameter
This data parameter is a one-byte value with each nibble encoded separately. The high nibble specifies the
"compression method, and the low nibble specifies the "encrypting method".
Data Format The value [x0 hex] specifies that no compression is used. ".
Identifier The value [0x hex] specifies that no encrypting method is used.
The value [1x hex] specifies that Data compression with LZSS algorithm is used.
If no specific requirements regarding compression or encryption exist, the value [00 hex] shall be used as a default.
Address And This parameter is a one byte value with each nibble encoded separately:
Length Format bit 7 - 4: Length (number of bytes) of the Memory Size parameter
Identifier
bit 3 - 0: Length (number of bytes) of the Memory Address parameter
The parameter Memory Address is the starting address of ECU’s memory where the transmitted data is to be stored
or from which the data is to be retrieved. The number of bytes used for this address is defined by the low nibble (bit 3
Memory Address - 0) of the Address Format Identifier. Byte m (see message description) in the Memory Address 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 Memory Identifier.
Memory Size This parameter determines the amount of uncompressed data which will be transferred during Download / Upload.
(Uncompressed) The number of bytes used for this size is defined by the high nibble (bit 7 - 4) of the Address Format Identifier.
Positive Response
Description
parameter
This parameter is a one byte value with each nibble encoded separately:
Length Format
Identifier bit 7 - 4: Length (number of bytes) of the Max Number Of Block Length parameter.
bit 3 - 0: reserved by document, to be set to 0
This parameter is used by the Request Download / Upload positive response message to inform the external test tool
how many data bytes shall be included either in each Transfer Data request message from the external test tool during
Max Number Of one complete download process or in each Transfer Data positive response message from the ECU during one
Block Length complete upload process. This length reflects the complete message length, including the service identifier and the
data parameters present in the Transfer Data request message. This parameter allows the external test tool to adapt to
the buffer size of the ECU when transferring data.
UDS 909: After the ECU has received the Request Download request message, the ECU shall take
all the necessary actions (check memory address and size, prepare download process etc.) to
receive data before it sends a positive response message.
UDS 914: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 916: The Download request message shall follow the format defined in Table 87.
Message
Data byte no. Parameter name Data value
Usage
C1: The presence of this parameter depends on address length information parameter of the
Address And Length Format Identifier
C2: The presence of this parameter depends on the memory size length information of the Address
And Length Format Identifier
n: n= 4+m and depends on the amount of databytes m required for the memory address parameter
length.
UDS 924: Only the request message parameters defined in Table 87 shall be used when requesting
a download to ECU’s memory and shall be supported by all re-programmable ECUs.
UDS 926: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 88.
Message
Data byte no. Parameter name Data value
Usage
UDS 929: Only the positive response parameters defined in Table 88 shall be used when positively
responding.
UDS 930: The negative response to a Download request shall follow the format defined in Table 89.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Request Download M 34
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
Upload Download Not Accepted 70
UDS 933: The negative response codes defined in Table 89 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 934: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 935: If the ECU receives a Download Request service while in the process of receiving a
download of a software or calibration module, the ECU shall respond with the negative response
code [22 hex] - Conditions Not Correct.
UDS 936: If the Data Format Identifier, Address And Length Format Identifier, Memory Address or
Memory Size parameters are not valid the ECU shall respond with the negative response code
[31hex] - Request Out Of Range.
UDS 937: If the ECU receives a Download Request and the ECU’s security feature is currently
active the ECU shall respond with the negative response code [33 hex] - Security Access Denied.
UDS 938: If an attempt to download to an ECU’s memory cannot be accomplished due to some
fault conditions the ECU shall respond with the negative respond code [70 hex] - Upload Download
Not Accepted.
UDS 945: After the ECU has received the Request Upload request message, the ECU shall take all
the necessary actions (check memory address and size, prepare upload process etc.) to send data
before it sends a positive response message.
UDS 947: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 949: The Upload request message shall follow the format defined in Table 90.
Message
Data byte no. Parameter name Data value
Usage
C1: The presence of this parameter depends on address length information parameter of the
Address And Length Format Identifier
C2: The presence of this parameter depends on the memory size length information of the Address
And Length Format Identifier
UDS 954: Only the request message parameters defined in Table 90 shall be used when requesting
an upload from ECU’s memory and shall be supported by all re-programmable ECUs.
UDS 956: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 91.
Message
Data byte no. Parameter name Data value
Usage
UDS 959: Only the positive response parameters defined in Table 91 shall be used when positively
responding.
UDS 960: The negative response to a Request Upload request shall follow the format defined in
Table 92.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Request Upload M 35
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
Upload Download Not Accepted 70
UDS 963: The negative response codes defined in Table 92 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 964: If the length of the Request Upload message is incorrect, the ECU shall respond with the
negative response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 965: If the ECU receives a Request Upload request while in the process of performing an
upload of data, the ECU shall respond with the negative response code [22 hex] - Conditions Not
Correct.
UDS 966: If the Data Format Identifier, Address And Length Format Identifier, Memory Address or
Memory Size parameters are not valid the ECU shall respond with the negative response code [31
hex] - Request Out Of Range.
UDS 967: If the ECU receives a Request Upload request and the ECU’s security feature is currently
active the ECU shall respond with the negative response code [33 hex] - Security Access Denied.
UDS 968: If an attempt to upload an ECU’s memory cannot be accomplished due to some fault
conditions the ECU shall respond with the negative respond code [70 hex] - Upload Download Not
Accepted.
Transfer Data
Description
parameter
The Block Sequence Counter parameter value starts at [01 hex] with the first Transfer Data request that follows
Block Sequence the Request Download [34 hex] or Request Upload [35 hex] service. Its value is incremented by 1 for each
Counter subsequent Transfer Data request. At the value of [FF hex] the Block Sequence Counter rolls over and starts at
[00 hex] with the next Transfer Data request message.
Transfer
This parameter record contains parameter(s), which are required by the ECU to support the transfer of data.
Request / Response
Format and length of this parameter(s) are application specific.
Parameter Record
UDS 976: If the external test tool sends a Request Download request message, the data to be
downloaded shall be included in the Transfer Request Parameter(s) in the Transfer Data request
message(s).
UDS 977: If the external test tool sends a Request Upload request message, the data to be
uploaded shall be included in the Transfer Response Parameter(s) in the Transfer Data response
message(s).
UDS 978: The Transfer Data request message shall include a Block Sequence Counter to allow for
improved error handling in case a Transfer Data service fails during a sequence of multiple Transfer
Data requests.
UDS 979: The ECU shall initialize the Block Sequence Counter to one (1) when a Request
Download [34 hex] or Request Upload [35 hex] request message is received.
NOTE: The first Transfer Data [36 hex] request message from the external test tool following the
Request Download [34 hex] or Request Upload [35 hex] request message starts with a Block
Sequence Counter of one (1).
The ECU shall behave as follows when a Transfer Data request message is received during the on-
going download / upload process:
UDS 983: The ECU shall check the Block Sequence Counter value included in every received
Transfer Data request message during an on-going download data process. If the value is either
equal to the previously received Block Sequence Counter value or incremented by one the ECU
shall process the request as described in UDS 8.15-22 and UDS 8.15-23 Otherwise the ECU shall
respond negatively with the negative response Wrong Block Sequence Counter [NRC 73 hex] and
discard all download data.
UDS 984: When the ECU receives a complete and correct Transfer Data request with a Block
Sequence Counter value identical to the value received with the request processed directly before, it
shall discard the download data included in the current request and respond positively including the
received Block Sequence Counter value. When the Transfer Data request is repeated more than 5
times with an identical Block Sequence Counter value the ECU shall abort the on-going download
process and respond negatively with negative response Transfer Data Suspended [NRC 71 hex].
UDS 985: When the ECU receives a complete and correct Transfer Data request with a Block
Sequence Counter value incremented by one compared to the value received with the request
processed directly before, it shall process the included download data and respond positively.-
NOTE: The external test tool normally repeats a Transfer Data request service due to an application
layer timeout (Timeout P2CAN_ECU). Such a timeout may occur either if the respective ECU has sent a
response but the response was lost during transmission or the reception of a request message sent
by the external test tool has failed due to a transmission failure.
UDS 988: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 990: The Transfer Data request message shall follow the format defined in Table 94 in case of
a download to the ECU.
UDS 991: The Transfer Data request message shall follow the format defined in Table 95 in case of
an upload from the ECU.
Message
Data Byte no. Parameter name Data value
Usage
C: The presence of this parameter depends on the availability of more than one data byte to
download to the ECUs memory.
Message
Data Byte no. Parameter name Data value
Usage
UDS 996: Only the request message parameters defined in Table 94 and Table 95 may be
requested when transferring data between external test tool and ECU.
UDS 998: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined inTable 96 in case of a download to the ECU.
UDS 999: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined inTable 97 in case of an upload to the ECU.
Message
Data Byte no. Parameter name Data value
Usage
Message
Data Byte no. Parameter name Data value
Usage
C: The presence of this parameter depends on the availability of more than one data byte to upload
from the ECUs memory
UDS 1004: Only the positive response parameters defined in Table 96 and Table 97 shall be used
when positively responding.
UDS 1005: The Block Sequence Counter parameter value in the positive response message shall
echo the Block Sequence Counter parameter sent in the request message.
UDS 1006: The negative response to a Transfer Data request shall follow the format defined in
Table 98.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Transfer Data M 36
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Request Sequence Error 24
Request Out Of Range 31
Security Access Denied 33
Transfer Data Suspended 71
General Programming Failure 72
Wrong Block Sequence Counter 73
Voltage Too High / Voltage Too Low 92 / 93
UDS 1009: The negative response codes defined in Table 98 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1010: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1011: If the ECU receives a Transfer Data request service before a preceding Download /
Upload Request service was received (download / upload is not active) the ECU shall respond with
the negative response code [22 hex] - Conditions Not Correct.
UDS 1012: If the value of the Transfer Data Request parameter specified in the Transfer Data
request message is invalid, the ECU shall respond with the negative response code [31 hex] -
Request Out Of Range.
UDS 1013: If the data transfer operation was halted due to some default conditions the ECU shall
respond with the negative response code [71 hex] - Transfer Data Suspended.
UDS 1014: If the ECU detects an error when erasing or programming a memory location in the
permanent memory device during download of data, the ECU shall respond with the negative
response code [72 hex] - General Programming Failure.
UDS 1015: If the ECU detects an error in the transferred data block sequence by evaluating the
value of the Block Sequence Counter parameter, the ECU shall respond with the negative response
code [73 hex] - Wrong Block Sequence Counter.
Copyright Daimler AG 2013
UDS 1016: If the voltage measured at the primary power pin of the ECU is out of range for
downloading data into ECU’s permanent memory, the ECU shall respond with negative respond
code [92 / 93 hex] - Voltage Too High / Low.
UDS 1020: If the ECU receives a Request Transfer Exit request while a Download or Upload is
active and the programming process is complete, the ECU shall terminate the data transfer.
UDS 1022: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 1024: The Transfer Exit request message shall meet the format defined in Table 99.
Message
Data byte no. Parameter name Data value
Usage
UDS 1029: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 100.
Message
Data byte no. Parameter name Data value
Usage
UDS 1033: The negative response to a Transfer Exit request shall follow the format defined in
Table 101.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Request Transfer Exit M 37
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Sequence Error 24
UDS 1036: The negative response codes defined in Table 101 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1037: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1038: If the ECU receives a Request Transfer Exit message before the programming process
is completed (i.e. the number of data bytes transferred via diagnostic service [36 hex] does not
match the number of data bytes indicated in diagnostic service [34 hex] or [35 hex]) the ECU shall
respond with negative response code [24 hex] - Request Sequence Error.
NOTE: Depending on the data transfer scenario (e.g. flash reprogramming or personal data backup
from infotainment ECU) the ECU may either remain in the currently active transfer session or abort
the transfer.
UDS 1040: If the ECU receives a Request Transfer Exit message when an Upload or Download
session is not active, the ECU shall respond with the negative response code [24 hex] - Request
Sequence Error.
The Write Memory By Address request and response message parameters are defined in Table 52.
UDS 1046: The Write Memory by Address service shall be used for engineering development only
(pls. refer to MBN 10746 for further details).
UDS 1047: The Write Memory by Address service shall only be available after being unlocked by
the appropriate Security Access type.
UDS 1048: The ECU shall send a positive response message after the write process initiated by the
Write Memory By Address request service has been completed.
UDS 1050: The ECU shall meet the request and response message behavior as specified in
section 7.2.
UDS 1052: The Write Memory By Address request message shall follow the format defined in
Table 102.
Message
Data byte no. Parameter name Data value
Usage
C1: The presence of this parameter depends on address length information parameter of the
Address And Length Format Identifier.
C2: The presence of this parameter depends on the memory size length information of the Address
And Length Format Identifier.
UDS 1057: The Data Record parameter in the request message shall include the data to be written
to the ECU’s memory.
UDS 1059: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 103.
Message
Data byte no. Parameter name Data value
Usage
C1: The presence of this parameter depends on address length information parameter of the
Address And Length Format Identifier.
C2: The presence of this parameter depends on the memory size length information of the Address
And Length Format Identifier.
UDS 1064: Only the positive response parameters defined in Table 103 shall be used when
positively responding.
UDS 1065: The negative response to a Write Memory By Address request shall follow the format
defined in Table 104.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Write Memory By Address M 3D
3 sub-function = [Negative Response Trouble Code] M 00-FF
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
Request Out Of Range 31
Security Access Denied 33
General Programming Failure 72
UDS 1068: The negative response codes defined in Table 104 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1069: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1070: If the ECU cannot perform the required action due to operational conditions which were
not met when the Write Memory by Address request message was processed, the ECU shall
respond with negative response code [22 hex] - Conditions Not Correct..
UDS 1071: The ECU shall respond with negative response code [31 hex] - Request Out of Range if
the values of the Memory Address (MA), Memory Size (MS) or Address And Length Format Identifier
parameters in the request message do not meet any of the following requirements:
• Every memory address within the specified interval [MA, MA + (MS -1)] is valid.
• The specified memory size keeps the ECU given limits.
• The specified address and length format is valid.
UDS 1075: The ECU shall respond with negative response code [33 hex] - Security Access Denied
if the Write Memory By Address service accesses at least one secured memory address within the
interval [MA, MA + (MS -1)] while the security feature of the ECU is active.
UDS 1076: If the ECU detects an error while writing data to a memory location the ECU shall
respond with the negative response code [72 hex] - General Programming Failure.
UDS 1080: This service shall be used to keep one or multiple ECU(s) in a non-default session
according to the detailed session requirements in chapter 6.
UDS 1082: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 1084: The Tester Present request message shall follow the format defined in Table 105.
Message
Data byte no. Parameter name Data value
Usage
NOTE: The Zero Sub Function is used only to implement the Suppress Positive Response Message
Indication bit, which indicates whether the ECU is required to send a positive response or not.
UDS 1089: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 106.
Message
Data byte no. Parameter name Data value
Usage
UDS 1092: The negative response to a Tester Present request shall follow the format defined in
Table 107.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 Tester Present M 3E
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
UDS 1095: The negative response codes defined in Table 107 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1096: The ECU shall respond with negative response code [12 hex] - Sub Function Not
Supported if the Tester Present service request message received includes a Zero sub-function
parameter not defined in Table 107.
UDS 1097: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
8.19 Removed
Refer to MBN 10746 for definition of enabling and disabling storage of DTCs.
UDS 1107: The storage of DTCs within an individual ECU or group of ECUs shall be stopped, if a
request with DTC Setting type “off” is received by one or more ECUs.
UDS 1108: The storage of DTCs within an individual ECU or group of ECUs shall be resumed, if a
request with DTC Setting type “on” is received by one or more ECUs.
UDS 1111: The DTC storage within an ECU shall be resumed when an ECU Reset is performed.
UDS 1112: The following services regarding error memory shall still be supported when DTC
storage is switched off using Control DTC Setting [85 hex]:
• Read DTC Information [19 hex]
• Clear Diagnostic Information [14 hex]
NOTE: This does not imply that other services shall be affected by the Control DTC Setting.
UDS 1116: Only the conditions specified in section 8.20.2 and 8.1.3.5 shall resume DTC storage in
an ECU.
UDS 1118: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 1120: The Control DTC Setting request message shall follow the format defined in Table 109.
Message
Data byte no. Parameter name Data value
Usage
NOTE: Only the DTC Setting types defined in Table 109 may be requested when requesting an ECU
to stop or resume DTC setting.
UDS 1126: If a positive response is allowed in accordance with section 7.1, the response shall
follow the format defined in Table 110.
Message
Data byte no. Parameter name Data value
Usage
UDS 1129: If an ECU responds positively to a Control DTC Setting request message, the DTC
Setting type in the positive response message shall echo the DTC Setting type parameter sent in the
request message.
UDS 1130: The negative response to an ECU Reset request shall follow the format defined in
Table 111.
1 Negative Response M 7F
2 Control DTC Setting M 85
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
UDS 1133: The negative response codes defined in Table 111 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1134: The ECU shall response with negative response code [12 hex] - Sub Function Not
Supported if the DTC Setting Type parameter in the request message does not match any of those
specified in Table 109.
UDS 1135: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1136: If the ECU cannot perform the required action due to operational conditions which were
not met when the Routine Control request message was processed, the ECU shall respond with
negative response code [22 hex] - Conditions Not Correct.
Table 112 defines the possible Control types applicable for ECU Passive Mode requests:
Enable Passive
This value indicates that the transmission of messages shall be disabled
Mode
Disable Passive
This value indicates that the transmission of messages shall be enabled
Mode
UDS 1145: The ECU shall accept this service while Default session or Extended Diagnostic session
is active. Otherwise a negative response with negative response code [7F hex] - Service Not
Supported in Active Session shall be sent.
UDS 1146: The ECU shall perform the following actions when an ECU Passive Mode Request with
Control Type parameter equal to Enable Passive Mode [A0 01/81 hex] is received:
• The ECU’s CAN controller transmit channel shall be switched off.
• The ECU’s CAN controller receive channel shall remain active.
• ECU internally remains active.
Furthermore if the ECU receives this request while Extended Diagnostic Session is active it shall
switch to Default session before enabling Passive Mode.
UDS 1151: Diagnostic Session Control [10 XX hex] services shall be ignored while the ECU Passive
operation mode is active.
UDS 1152: If the Control Type parameter in the ECU Passive Mode request message requires a
positive response from the ECU, the ECU shall immediately return the positive response before
enabling ECU Passive Mode. In the case where no response is requested from the external test tool,
the ECU shall perform the requested action immediately after the successful evaluation of the
request message.
UDS 1153: If the ECU non-diagnostic application requires message transmission while transmit
channel is switched off in ECU Passive operation mode, all transmit status signals shall indicate to
the application that transmission was successful. In other words the application shall not notice that
the transmit channel is switched off.
UDS 1154: When the bus system switches into sleep mode (network management functionality), an
ECU in ECU Passive mode shall also invoke sleep mode. When the bus system wakes-up again, the
ECU shall continue the ECU Passive operation mode.
UDS 1155: ECU Passive Mode shall be disabled under the following conditions:
• ECU Passive Mode with Control Type “Disable ECU Passive operation mode”
[A0 02/82 hex] is received
• ECU Reset with Reset Type “Hard Reset” [11 01/81 hex] is received
• Safety critical situation arises
NOTE: The deactivation of ECU Passive Mode via a diagnostic request shall not depend on the
addressing type. (i.e. either uni-cast (physical) or broadcast (functional) shall behave the same)
UDS 1490: The execution of the manufacturer specific service ECU Passive Mode shall only be
allowed after a successful security access sequence with Security Access Type [01 hex] - Protected
Engineering Access.
NOTE: Application of this service is only recommended if the user is familiar with the requested
functionality and the effect of this service request.
UDS 1163: The ECU shall meet the request and response message behavior as specified in
section 7.1.
UDS 1165: The ECU Passive Mode request message shall follow the format defined in Table 113.
Message
Data byte no. Parameter name Data value
Usage
UDS 1168: Only the Control types defined in Table 113 may be requested when enabling or
disabling ECU Passive Mode within an individual ECU.
UDS 1170: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 114.
Message Data
Data byte no. Parameter name
Usage value
UDS 1173: In the positive response to an ECU Passive Mode request, the Control type shall be
echoed in the response.
UDS 1174: The negative response to an ECU Passive Mode request shall follow the format defined
in Table 115.
Message
Data byte no. Parameter name Data value
Usage
1 Negative Response M 7F
2 ECU Passive Mode M A0
3 sub-function = [Negative Response Trouble Code] M 00-FF
Sub Function Not Supported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22
UDS 1177: The negative response codes defined in Table 115 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1178: The ECU shall respond with negative response code [12 hex] Sub Function Not
Supported if the Control type parameter in the ECU Passive Mode request does not match any of
those specified in requirement Table 113,
UDS 1179: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1180: If the ECU cannot perform the required action due to operational conditions which were
not met when the ECU Passive Mode request message was processed, the ECU shall respond with
negative response code [22 hex] - Conditions Not Correct.
8.22 Removed
linkBaudrateRecord This conditional parameter record contains a specific baud rate ([bit/s]) in cases where the sub-function parameter
indicates that a specific baud rate is used.
Link Control Type This parameter is an echo of bits 6 - 0 of the linkControlType sub-function parameter from the request message.
(Response)
This service is used to transition the baud rate of the data link layer. To overcome functional
communication, where the baud rate must be transitioned in multiple ECUs at the same time, the
baud rate transition is split into two steps:
Step #1:
The external Test tool verifies if the transition can be performed and informs the ECU(s) about the
baud rate to be used.
UDS 1312: Each ECU shall respond positively (suppressPosRspMsgIndicationBit = FALSE) before
the external Test tool performs step #2.
NOTE: This step does not actually perform the baud rate transition
Step #2:
The external Test tool actually requests the transition of the baud rate.
UDS 1316: This step shall only be performed if it is verified that the baud rate transition can be
performed (step #1 performed).
NOTE: In case of functional communication, it is recommended that there should not be any
response from an ECU when the baud rate is transitioned (suppressPosRspMsgIndicationBit =
TRUE) because one ECU might already have been transitioned to the new baud rate while others
still need to transmit their response message(s) (baud rate mismatch avoidance).
The linkControlType parameter in the request message, in conjunction with the conditional
baudrateIdentifier/linkBaudrateRecord parameter, provides a mechanism to transition to a predefined
or specifically defined baud rate.
UDS 1342: A session layer timer timeout shall transition the ECU(s) back to its (their) normal speed
of operation.
UDS 1343: Receiption of an ECUReset service (11 hex) shall transition the ECU(s) back to its
(their) normal speed of operation.
UDS 1344: The transition into another non-defaultSession shall not influence the baud rate.
UDS 1345: The LinkControl service (SID 0x87) shall not be supported when the Passive Session
(SID 0xA0) is active.
UDS 1346: If the Passive Session (SID 0xA0) is active, the ECU shall respond with NRC "Service
not supported in active session in case of receiving a LinkControl service (SID0x87).
UDS 1347: The ECU shall reset the baudrate to the default value when entering the Passive
Session (SID 0xA0).
UDS 1353: The ECU shall meet the request and response message behavior as specified in
section 7.1.
NOTE: Only the LinkControlTypes defined in Table 117, Table 118 and Table 119 may be requested
when requestiing an ECU to transition the baud rate of the data link layer.
Message
Data byte no. Parameter name Data value
Usage
verifyBaudrateTransitionWithFixedBaudrate 01
3 BaudrateIdentifier C1 E0-FE
C1: This parameter is present if the sub-function parameter indicates that a verification of a fixed
baud rate (verifyBaudrateTransitionWithFixedBaudrate) is done.
Message
Data byte no. Parameter name Data value
Usage
C2: This parameter is present if the sub-function parameter indicates that a verification of a specific
baud rate (verifyBaudrateTransitionWithSpecificBaudrate) is done.
UDS 1363: The Link Control request message (linkControlType = TransitionBaudrate) shall follow
the format defined in Table 119.
Message
Data byte no. Parameter name Data value
Usage
UDS 1371: If a positive response is allowed in accordance with with section 7.1, the response shall
follow the format defined in Table 120
Message
Data byte no. Parameter name Data value
Usage
UDS 1373: The negative response to a Link Control service request shall follow the format defined
in Table 121
Message
Data byte no. Parameter name Data value
Usage
RequestSequence 24
UDS 1376: The negative response codes defined in Table 121 shall be supported by the ECU as a
minimum set. Chapter 9 further defines the negative response codes which may be used to report
specific conditions preventing the ECU from responding positively.
UDS 1377: The ECU shall respond with negative response code [12 hex] Sub Function Not
Supported if the Link Control type parameter in the Link Control service request does not match any
of those specified in Table 117, Table 118 and Table 119,
UDS 1378: If the length of the message is incorrect the ECU shall respond with the negative
response code [13 hex] - Incorrect Message Length / Invalid Format.
UDS 1380: If the ECU can not perform the required action due to operational conditions which were
not met when the Link Control request message was processed, the ECU shall respond with
negative response code [22 hex] - Conditions Not Correct.
UDS 1381: If the ECU receives a Link Control request with type TransitionBaudrate without first
receiving a Link Control Request - verifyBaudrateTransitionWithFixedBaudrate or Link Control
Request - verifyBaudrateTransitionWithSpecificBaudrate, the ECU shall respond with the negative
response code [24 hex] - Request Sequence Error.
UDS 1383: If the ECU detects an error in the linkBaudrateRecord or the baudrateIdentifier, the ECU
shall respond with negative response code [31 hex] - Request Out Of Range.
The negative response code range [00 hex] - [FF hex] is divided into the following ranges:
• [00 hex]: positive response parameter value for ECU internal implementation,
• [01 hex] - [7F hex]: communication related negative response codes,
• [80 hex] - [FF hex]: negative response codes for specific conditions that are not correct
at the point in time the request is received by the ECU.
UDS 1189: All negative response codes listed in Table 122 shall be used in conjunction with the
negative response codes defined per diagnostic service in this document when a negative response
must be sent and the negative response codes of the diagnostic service do not apply.
UDS 1190: ECUs, which implement service [27 hex] - Security Access, shall support the negative
response code [33 hex] - Security Access Denied if a secured service is requested while the ECU is
locked.
Example: In a multi-external test tool environment the diagnostic request of one external test tool
might be blocked temporarily by a NRC [21 hex] while a different external test tool finishes a
diagnostic task.
22 Conditions Not Correct
This response code indicates that the requested action will not be taken because the ECU pre-
requisite conditions are not met.
23 ISO/SAE Reserved
This value is reserved by ISO/SAE for future definition.
24 Request Sequence Error
This response code indicates that the requested action will not be taken because the ECU ex-
pects a different sequence of request messages or message as send by the external test tool.
This may occur when sequence sensitive requests are issued in the wrong order.
Example: A successful Security Access service specifies a sequence of Request Seed and Send
Key as sub-functions in the request messages. If the sequence is sent different by the external
test tool the ECU shall send a negative response message with the negative response code [24
hex] - Request Sequence Error.
25 No Response From Subnet Component
This response code indicates that the ECU has received the request but the requested action
could not be performed by the ECU as a subnet component which is necessary to supply the
requested information did not respond within the specified time.
The No Response From Subnet Component negative response shall be implemented by gateways
in electronic systems which contain electronic subnet components and which do not directly
respond to the external test tool's request. The gateway may receive the request for the subnet
component and then request the necessary information from the subnet component. If the sub-
net component fails to respond, the ECU shall use this negative response to inform the diagnostic
test tool about the failure of the subnet component.
26 Failure Prevents Execution Of Requested Action
This response code indicates that the requested action will not be taken because a failure condi-
tion, identified by a DTC (with at least one DTC status bit for Test Failed, Pending, Confirmed or
Test Failed Since Last Clear set to 1), has occurred and that this failure condition prevents the
ECU from performing the requested action.
This NRC can, for example, direct the technician to read DTCs in order to identify and fix the
problem.
NOTE: This implies that diagnostic services used to access DTCs shall not implement this NRC
as an external test tool may check for the above NRC and automatically request DTCs whenever
the above NRC has been received.
27-30 ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition.
31 Request Out Of Range
This response code indicates that the requested action will not be taken because the server has
detected that the request message contains a parameter which attempts to substitute a value
beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is
only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not
supported or not supported in active session.
This response code shall be implemented for all services which allow the external test tool to
read data, write data or adjust functions by data in the ECU.
32 ISO/SAE Reserved
Copyright Daimler AG 2013
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.
34 ISO/SAE Reserved
This value is reserved by ISO/SAE for future definition.
35 Invalid Key
This response code indicates that the ECU has not given security access because the key sent by
the external test tool did not match with the key in the ECU's memory. This counts as an attempt
to gain security. The ECU shall remain locked and increment is internal Security Access Failed
counter.
This response code shall only be implemented for the Security Access Service - [27 hex].
36 Exceed Number Of Attempts
This response code indicates that the requested action will not be taken because the external
test tool has unsuccessfully attempted to gain security access more times than the ECU's securi-
ty strategy will allow.
This response code shall only be implemented for the Security Access Service - [27 hex].
37 Required Time Delay Not Expired
This response code indicates that the requested action will not be taken because the external
test tool's latest attempt to gain security access was initiated before the ECU's required timeout
period had elapsed.
This response code shall only be implemented for the Security Access Service - [27 hex].
38-4F Reserved By Extended Data Link Security Document
This range of values is reserved by ISO 15764 Extended data link security.
50-6F ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition.
70 Upload Download Not Accepted
This response code indicates that an attempt to upload/download to an ECU's memory cannot
be accomplished due to some fault conditions.
This response shall only be implemented for services which handle upload / download functional-
ity -
[34 hex] / [35 hex].
71 Transfer Data Suspended
This response code indicates that a data transfer operation was halted due to some fault.
72 General Programming Failure
This response code indicates that the ECU detected an error when erasing or programming a
memory location in the permanent memory device (e.g. Flash Memory).
73 Wrong Block Sequence Counter
This response code indicates that the ECU detected an error in the sequence of Block Sequence
Counter values. The repetition of a Transfer Data request message with a Block Sequence Coun-
ter equal to the one included in the previous Transfer Data request message shall be accepted by
the ECU.
This response code shall only be implemented for the Transfer Data service - [36 hex].
74-77 ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition.
78 Request Correctly Received-Response Pending
This response code indicates that the request message was received correctly, and that all pa-
rameters in the request message were valid, but the action to be performed is not yet completed
and the ECU is not yet ready to receive another request. As soon as the requested service has
been completed, the ECU shall send a positive response message or negative response message
with a response code different from this.
The negative response message with this response code may be repeated by the ECU until the
requested service is completed and the final response message is sent. This response code might
impact the application layer timing parameter values.
Copyright Daimler AG 2013
NOTE: It is recommended to implement the negative response code logic according to Figure 4
when determining the applicable positive or negative response code. Additional requirements for the
usage of the individual NRCs are defined in chapter 7 and chapter 8.
Evaluation Start
No
Requested SID
No
supported ?
Yes
SID No
supported in active
Session ?
Yes
Min Service No
Length Check
Correct ?
Yes
Sub-Function No
supported ?
No
Yes
Sub-function No
supported in active
Session ?
Yes
Service Yes
uses DID/RID ?
No DID/RID No
supported?
Yes
DID/RID
Yes supported in active
Session ?
No Parameter* No
Neg.
used? Neg. Neg.
Response:
Response: Response:
NRC = $7F
Yes NRC = $12 NRC = $21
„Service Not
„Subfunction „Busy -
Supported
Yes Parameter* Not Repeat
Within Active
supported ? Supported“ Request“
Session“
No
Service
Length Check
Correct ?
Neg. Neg.
Yes Neg. Response: Response: Neg.
Response: NRC = $7E NRC = $13 Response:
NRC = $31 „Subfunction „Incorrect NRC = $11
„Request out Not Sup. in Msg. Length „Service Not
of Range“ Active Or Invalid supported“
Session“ Format“
B A
Security No
Condition
Correct ?
Yes
Sequence No
Correct ?
Yes
Yes No
Yes No
Yes Sup. Pos. Specific
Response & no NRC defined ?
extended P2 timing
window?
No
No ECU failure?
Neg.
Neg. Neg.
Yes Response:
Response: Response:
No NRC = $33
NRC = $xx NRC = $78
Response „Security
„individual „Response
Access
NRC“ Pending“
Denied“
Neg.
Neg.
Neg. Response: Response:
Response: NRC = $26
Positive NRC = $24
NRC = $22 „Failure
Response „Conditions prevents „Request
Sequence
not correct“ exec. of req.
Error“
action“
Evaluation End
NOTE: When using Standard Software modules, (e.g. Flash Bootloader Module and Diagnostic
Communication Module) services supported by one module might be unknown for the other module.
Due to that ECUs might report wrong NRCs (e.g. Service not supported instead of Service not
supported in active diagnostic session). In this case figure 4 can be interpreted by every module
individually.
Annex A (normative)
Diagnostic Service Support Conditions
This annex lists the applicability of each diagnostic service (including sub-functions) for the individual
business units. Furthermore it defines the conditions under which a specific diagnostic service or
sub-function needs to be implemented by an ECU. Therefore each diagnostic service and its sub-
functions are associated with a support type attribute.
The support type of a sub-function shall only be considered when the associated diagnostic service
is required. For example a specific sub-function may be mandatory if the associated diagnostic
service is supported, but the diagnostic service itself may be optional. In the latter case the sub-
function can not be implemented.
For description of the various support types (Mandatory, Conditional, and Optional) please refer to
section 5.1.
Table 123: Overview of diagnostic services and sub-functions and business unit applicability
Condition Description
R Required
O Optional
If an ECU supports centralized de-bounce counters for fault maturation as described in
ISO14229-1, it may report the fault maturation counters. If the FRFM software
O1
component is used, this feature will automatically be available when the de-bouncing
option is selected.
C1 Removed
C2 For emissions-related ECUs
C3 Flash reprogrammable ECUs only.
For End of Life activation of on-board pyrotechnic devices (according to ISO 26021)
C4
only
If ECOS is used and ECU cannot maintain constant current consumption during
C5
normal operation.
C6 Not for emissions related ECUs
If an ECU is reprogrammable or certain diagnostic services have to be protected
C7
against unauthorized access.
C8 Shall be supported when actuators are supported by the ECU.
Either one or both sub-functions to define a dynamic data identifier must be
C9
implemented when the service is implemented.
Shall be implemented if the ECU supports asynchronous routines according to the
C10
definition in MBN-10746.
Only needs to be implemented when transfer of large amount of data (e.g. address
C11
books from infotainment) from ECU to diagnostic tool is necessary.
C12 When C3 or C11 apply.
Mandatory during development phase for network testing. Shall be removed before
C13
series production.
Shall be implemented by ECUs which implement an extra delay before going to
C14
minimum power consumption even when already in network sleep-mode.
Shall be implemented by ECUs which implement Dynamically Define Data Identifier
C15
Service
C16 Shall be supported when routines are supported by the ECU.
Annex B (informative)
List of Changes
155 Modified "Figure 2: ECU Diagnostic Session State Diagram" to show also manfacturer and RP
supplier specific sessions
162 Modified "Table 58 : Request Message Definition - Security Access" to meet ISO and RP
DPRS requirements