Sei sulla pagina 1di 139

Mercedes-Benz MBN 10747

Company Standard Date published: 2013-02


Supersedes: MBN 10747: 2011-09
Transitional period: 0 months
Total no. of pages (incl. Annex): 139
Person in charge: Ralf Pfaff
Email: ralf.pfaff@daimler.com
Plant: 059, Dept.: GSP/OVE
Phone: +49 (0) 151 586 11969

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:

- Refer to Annex B (informative) for detailed change list

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 2

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 3

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 4

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

MBN 10746 Diagnostic Performance Requirements Standard

MBN 10761 Flash Re-programming Requirements Definition based on UDS

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 5

3 Terms and Definitions

3.1 General Definitions


Data Identifier: A number uniquely identifying a group of data elements (e.g. sensor
values and actuator states).

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

Diagnostic Service: An information exchange initiated by an external test tool in order to


acquire diagnostic information from an ECU or/and to modify its
behavior for diagnostic purposes.

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.

Record: A grouping of diagnostic data elements referenced by a single


means of identification (e.g. Data Identifier).

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.

Suppress Positive Response


Message Indication Bit: The seventh bit of the first diagnostic service parameter, which
represents a sub-function, indicates whether an ECU shall respond
in the event of a positive response or not.

Tester: see External Test Tool

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 6

3.2 DTC Related Definitions


Complete: Indicates that an ECU’s on-board fault routine has been performed
and was able to determine whether a malfunction exists or does not
exist for the current operation cycle (complete does not imply failed).
For further details refer to MBN 10746.

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.

Pending: The pending status of a failure is defined as a Test Result having


reported a “Failed” for this failure during the current and/or the last
completed driving cycle. Once the test has reported a “Passed”
condition for a complete operation cycle of this failure the pending
status is reset.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 7

Test: An on-board diagnostic software algorithm that determines the


malfunction status of a component or system. Some tests (non-
continuous) run only once during an operation cycle. Other tests
(continuous tests) can run every program loop, as often as every few
milliseconds. The result of a test represents a completely matured /
qualified failure condition. That means a test which needs a failing
condition over a specific time or evaluation of additional plausibility
checks before a component is considered to be failing will return a
“Failed” condition after all maturation criteria have been fulfilled. Each
test is associated with a unique DTC representing the root failure and
detectable fault symptom.

Test results: While a test runs or after it has completed it may indicate one of the
following results to the internal failure handler:

• Pre-failed: This status may be used by tests in ECUs to indicate that


the test is currently maturing a failure condition. One use case for this
information is in manufacturing to speed up failure detection for
optimised workflow while maintaining fault tolerance in the field.

• Failed: This status is available after an ECU’s fault routine has run to
completion and indicates a completely matured failing condition.

• Passed: This status is available after an ECU’s fault routine run to


completion and indicates that the system or component is not failing.

3.3 Abbreviations and Acronyms

CGW Central Gateway


C Conditional
CAN Controller Area Network
DTC Diagnostic Trouble Code
ECOS Electronic Check Out System
ECU Electronic Control Unit
M Mandatory
NRC Negative Response Code
Neg Rsp Negative Response message
O Optional
Pos Rsp Positive Response message
SID Service Identifier
Suppress Pos Rsp Msg Indication Bit Suppress Positive Response Message Indication Bit
C, C1, C2 … Conditional Note

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 8

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 9

5 Communication between External Test Tool and ECU


On the communication protocol level, the description of the communication process utilizes “service
primitives” as defined in ISO 14229-1. In order to describe the diagnostic application data exchange
between the external test tool and an ECU located on a vehicle’s network, this specification applies
the primitives “service request” and “service response”. This section depicts the service message
format to be used when invoking these service primitives at the diagnostic application layer service
access point.

5.1 Document conventions


For each individual Diagnostic Service and sub-function described in this document it is explicitly
stated under which condition it shall be supported. Possible implementation types are:
• Mandatory (M):
The respective Diagnostic Service or Sub-function shall be supported by all ECUs.
• Conditional (C):
The respective Diagnostic Service or Sub-function shall only be supported if the described
conditions apply.
• Optional (O):
It is up to the ECU supplier's discretion whether or not to implement the specified Diagnostic
Service or Sub-function however; if it is implemented, the message structure shall follow the
definitions provided in this document.

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 10

Table 1: Column Descriptions

Column Heading Description

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:

• Manufacturer Specific: Defines a Sub-function or range of Sub-functions which are defined by


the Manufacturer to be implemented by the supplier.
• Supplier Specific: Defines a Sub-function or range of Sub-functions that are to be defined by
the supplier for use only by the supplier.

5.2 Diagnostic Service Request Message Format


A service request message is sent by the external test tool when requesting an ECU to perform a
specific action (e.g. report diagnostic data or execute diagnostic test procedures). The two different
types of request messages are depicted in Table 2 and Table 4.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 11

5.2.1 Diagnostic Service Request Message with Sub-function

Table 2 : Diagnostic Service Request Message Definition (with Sub-function)

Message
Data Byte No. Parameter Name Data Value
Usage

1 Request Service Id M 00-FF

2 Sub Function Parameter M

Option 1: Sub-Function Type No. 1 XX


: :
Option n: Sub-Function Type No. n YY
3 Data Parameter no. 1 O 00-FF
: : : :
n Data Parameter no. n O 00-FF

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.

Table 3 : Sub-Function Parameter Byte Structure

Sub-function parameter byte

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Suppress Pos Rsp


Sub-function type as specified in the sub-function type description of the
Msg
service
Indication Bit

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 12

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

5.2.2 Diagnostic Service Request Message without Sub-function

Table 4 : Diagnostic Service Request Message Definition (without Sub-function)

Data Byte No. Parameter Name Message Usage Data Value

1 Request Service Id M 00-FF

2 Data Parameter no. 1 M 00-FF


: : : :
n Data Parameter no. n O 00-FF

5.3 Diagnostic Service Response Message Format


If the response behavior defined in chapter 7 allows, the ECU shall send either a positive or negative
service diagnostic response message confirming the reception of a diagnostic service request
message. Table 5 and Table 6 depict the diagnostic positive and negative response message
structure.

5.3.1 Diagnostic Positive Response Message

Table 5 : Positive Response Message Definition

Data Byte No. Parameter Name Message Usage Data Value

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

5.3.2 Diagnostic Negative Response Message

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 13

Table 6 : Negative Response Message Definition

Data Byte No. Parameter Name Message Usage Data Value

1 Negative Response Service Id M 7F

2 Request Service Id M 00-FF

3 Negative Response Code M 00-FF

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 14

6 Application Layer and Diagnostic Session Management Timing

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:

• Physical communication (uni-cast)


• During default session
• During non-default session (session handling required)
• Functional communication (Broadcast / Multi-cast)
• During default session
• During non-default session (session handling required)

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

Diagnostic Tool Diagnostic Tool ECU Network ECU Application


Application Layer Network Layer Layer Layer

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

Figure 1: Network Layer Service Primitives

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 15

6.2 Application Layer Timing Parameter Definitions


Table 7 defines the application layer timing parameters for the diagnostic data exchange between an
external test tool and either an individual ECU or a group of ECUs.

Table 7 : Application Layer Timing Parameter Definitions

Timing Parameters Description Type

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

6.2.1 Physical Communication Timing Behavior (Uni-cast)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 16

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.

6.2.2 Functional Communication Timing Behavior (Broadcast / Multi-cast)

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.

UDS 136: When receiving N_USDataFF.ind or N_USData.ind of an incoming response message,


the external test tool’s application shall stop its P2CAN_Tester timer if the number of ECUs expected
to respond is known and all of the expected ECUs have responded.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 17

UDS 137: When receiving N_USDataFF.ind or N_USData.ind of an incoming response message,


the external test tool’s application shall restart its P2CAN_Tester timer if all of the expected ECUs
have not responded yet or when the number of ECUs expected to respond is not known.

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.

6.3 Minimum Time Between External Test Tool Request Messages


A minimum time between request messages transmitted by the external test tool is required in order
to allow for diagnostic service data interpretation by the ECU, because an ECU's application might
process the diagnostic request messages at a certain scheduling rate (e.g. 10 ms).

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.

NOTE: In case of physical communication requiring an ECU’s response or in case a response is


received independent of the Suppress Pos Rsp Msg Indication Bit value, the external test tool is
allowed to transmit the next request immediately after the complete reception of the final response
message. Receiving a final response means the external test tool’s request was completely
executed by the addressed ECU. In certain cases, the external test tool will receive a response from
an ECU even though the physically addressed request message requires no positive response (see
section 7.3 for details). Considering this communication behaviour, requirement UDS 6.3-2 applies.
Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 18

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.

6.4 Session Layer Timing Parameter Definitions


A specific diagnostic session enables a certain set of services, functionality and timing within the
ECU. The external test tool starts the respective diagnostic session by means of the Diagnostic
Session Control service (see section 8.1) in an individual ECU or a group of ECUs. This section
describes how the external test tool can maintain a previously activated non-default diagnostic
session.
Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 19

Table 8 defines the session layer timing parameter values for session handling during non-default
sessions.

Table 8 : Session Layer Timing Parameter Definitions

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

NOTE: For the actual parameter values refer to MBN 10746.

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 20

Table 9 : Session Layer Timing Start / Stop Conditions for the ECU

Timing
Action Physical and functional communication
Parameter

N_USData.con that indicates the completion of the transmission of a


Diagnostic Session Control positive response message for a transition from the Default
Initial Session to a non-default session, in case a response message is required.
start
Successful completion of the requested action of the service
Diagnostic Session Control [10 hex] for a transition from the default session to a non-default
session, in case no response message is required/allowed.
Sub-
N_USDataFirstFrame.ind that indicates the start of a multi-frame request message or
sequent
N_USData.ind that indicates the reception of any Single Frame request message.
stop
N_USData.con that indicates the completion of any response message that concludes a
S3ECU service execution (final response message) in case a response message is required/allowed to
be transmitted (this includes positive and negative response messages). A negative response
Sub-
with response code [78 hex] does not restart the S3ECU timer.
sequent
start Completion of the requested action (service conclusion) in case no response message
(positive and negative) is required/allowed.
N_USData.ind that indicates an error during the reception of a multi-frame request message.
N_USData.con that indicates the completion of the transmission of a
Diagnostic Session Control positive response message for a transition from any non-default
session to Default Session, in case a response message is required.
Stop
Successful completion of the requested action of the service
Diagnostic Session Control (10 hex) for a transition from any non-default session to Default
Session, in case no positive response message is required/allowed.

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.

6.5 External Test Tool and ECU Timer Resource Requirements

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.

Table 10 : Application Layer Timer Resources Requirements

Timing Parameter ECU

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 21

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.

Table 11 : Additional Timer Resources Requirements During Non-Default Session

Timing Parameter ECU

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.

6.6 Error Handling

UDS 173: The ECU shall implement the error handling according Table 12.

Table 12 : ECU Error Handling

Communicatio ECU error type ECU handling


nsphase

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.

P2CAN_ECU Timeout N/A

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 22

7 ECU Response Implementation Rules

7.1 Request Messages with Sub-Function Parameter

7.1.1 Physically Addressed (Uni-cast) Diagnostic Request Messages

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

External test tool Request


ECU Capability ECU Response
Message
ECU
Comments to ECU
Case Sub-Function
Sub- Response
No. Addressing (Suppress Pos Service ID NRC
function Message
Scheme Rsp Msg Supported [Hex value]
supported
Indication Bit)

ECU sends positive


1 YES YES Pos Rsp ---
response
ECU sends
2 YES YES Neg Rsp NRC=XX
negative response
Negative response
FALSE (bit = 0) with NRC [11 hex] –
3 NO --- Neg Rsp NRC=11
service not
supported
Negative response
with NRC [12 hex] –
4 YES NO Neg Rsp NRC=12
sub-function not
physical supported
(uni-cast) ECU does NOT
5 YES YES No Rsp ---
send a response
ECU sends
6 YES YES Neg Rsp NRC=XX
negative response
Negative response
TRUE (bit = 1) with NRC [11 hex] –
7 NO --- Neg Rsp NRC=11
service not
supported
Negative response
with NRC [12 hex] -
8 YES NO Neg Rsp NRC=12
sub-function not
supported

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 23

7.1.2 Functionally Addressed (Broadcast/Multi-cast) Diagnostic Request Messages

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.

Table 14 : ECU Response Behavior - Functionally Addressed (Broadcast / Multi-cast) Request


Messages with Sub-Function Parameter

External test tool Request


ECU Capability ECU Response
Message
ECU
Comments to ECU
Case Sub-Function
Sub- Response
No. Addressing (Suppress Pos Service ID NRC
function Message
Scheme Rsp Msg Supported [Hex value]
supported
Indication Bit)

ECU sends positive


1 YES YES Pos Rsp ---
response
ECU sends
2 YES YES Neg Rsp NRC=XX
negative response
FALSE (bit = 0)
ECU does NOT
3 NO --- No Rsp ---
send a response
ECU does NOT
4 YES NO No Rsp ---
functional send a response
(broadcast /
ECU does NOT
5 multi-cast) YES YES No Rsp ---
send a response

ECU sends
6 YES YES Neg Rsp NRC=XX
negative response
TRUE (bit = 1)
ECU does NOT
7 NO --- No Rsp ---
send a response

ECU does NOT


8 YES 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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 24

7.2 Request Messages without Sub-Function Parameter

7.2.1 Physically Addressed (Uni-cast) Diagnostic Request Messages

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.

Table 15 : ECU Response Behavior - Physically Addressed (Uni-cast) Request Messages


without Sub-Function Parameter

External test tool ECU Capability ECU Response


ECU Request Message Comments to ECU
Case
Addressing Message Response
No. Service ID NRC
Scheme Parameter Message
Supported [Hex Value]
Supported

ECU sends positive


1 ALL Pos Rsp ---
response
ECU sends positive
2 At least 1 Pos Rsp ---
response
ECU sends negative
YES At least 1, response because error
3 more than Neg Rsp NRC=XX occurred reading data
physical (uni-cast) 1, or ALL parameters of request
message
Negative response with
4 NONE Neg Rsp NRC=31 NRC [31 hex] – request
out of range
Negative response with
5 NO --- Neg Rsp NRC=11 NRC [11 hex]– service
not supported

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.

7.2.2 Functionally Addressed Diagnostic Request Messages

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 25

Table 16 : ECU Response Behavior - Functionally Addressed (Broadcast / Multi-cast) Request


Messages without Sub-Function Parameter

External test tool ECU Capability ECU Response


ECU Request Message Comments to ECU
Case
Addressing Message Response
No. Service ID NRC
Scheme Parameter Message
Supported [Hex Value]
Supported

ECU sends positive


1 ALL Pos Rsp ---
response
ECU sends positive
2 at least 1 Pos Rsp ---
response
ECU sends negative
YES At least 1, response because error
3 functional (broadcast / more than Neg Rsp NRC=XX occurred reading data
multi-cast) 1, or ALL parameters of request
message
ECU does NOT send a
4 NONE No Rsp ---
response

ECU does NOT send a


5 NO --- No Rsp ---
response

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

7.3 Request Correctly Received Response Pending [NRC 78 hex]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 26

7.4 Reaction regarding illegal SIDs

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 27

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.

8.1 Diagnostic Session Control - Service Identifier [10 hex]


The Diagnostic Session Control service shall be used to enable different diagnostic sessions in one
ECU or a group of ECUs. A diagnostic session defines a specific set of applicable diagnostic
services, amount of functionality, and application layer timing parameter values (P2CAN_ECU /
P2*CAN_ECU).

8.1.1 Diagnostic Session Type Description

Table 17 defines the possible Diagnostic Session types:

Table 17 : Diagnostic Session Types

Diagnostic Session type Description

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.

8.1.2 Application Layer Timing Parameter Description

Table 18 defines the possible application layer parameter types:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 28

Table 18 : Application Layer Timing Parameter

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)

8.1.3 Behavior Requirement(s)

8.1.3.1 General Behavior Requirements

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.

8.1.3.2 Support of Diagnostic Services

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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 29

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.

Table 19: Diagnostic Sessions Supporting Specific Sets Of Diagnostic Services

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)

Diagnostic Session Control – [10 hex] X X X X

ECU Reset – [11 hex] X X X X

Security Access – [27 hex] X X X

Communication Control – [28 hex] X

Tester Present – [3E hex] X X X X

Control DTC Setting –[85 hex] X X

Link Control - [87 hex] X


X
Read Data By Identifier – [22 hex] X X X
(C2)
X
Read Memory By Address – [23 hex] X
C2)
X
Dynamically Define Data Identifier – [2C hex] X
(C2)
X
Write Data By Identifier – [2E hex] X X X
(C2)
X
Write Memory By Address – [3D hex] X
(C2)
Clear Diagnostic Information – [14 hex] X X

Read DTC Information – [19 hex] X X

Input Output Control By Identifier – [2F hex] X X


X
Routine Control – [31 hex] X X X
(C2)
Request Download - 34 hex] X

Request Upload – [35 hex] X

Transfer Data –[36 hex] X

Request Transfer Exit – [37 hex] X

ECU Passive Mode – [A0 hex] X X

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 30

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.

8.1.3.3 Application Layer Timing Parameter Adaptation

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.

8.1.3.4 Session Types

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.

C Extended Diagnostic Session


This session type provides a timer controlled environment for an ECU in which all of the supported
diagnostic services can be executed. Those diagnostic services which temporarily alter the default
behavior of an ECU are reset when the Extended Diagnostic Session is left (either by diagnostic
service request or via a timeout condition). As all diagnostic services are supported in the Extended
Diagnostic Session (given that security access protected diagnostic services are properly unlocked
before usage) this session is usually entered before any diagnostics are performed in engineering,
manufacturing and service.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 31

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 absolute value of current consumption is not regulated.

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.

E Safety System Diagnostic Session


This session is intended to be used if an ECU installed in any vehicle is subject to market specific
legislative requirements demanding an end of life activation of pyrotechnic devices.
When activating this session type, per the appropriate diagnostic session control service, the
receiving ECU shall enable all diagnostic services necessary for executing a deployment procedure
according to ISO 26021.

NOTE: This document does not define how the deployment procedure itself needs to be
implemented. Please refer to ISO 26021 for further details.

8.1.3.5 Session transition requirements

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 32

Boot Manager Power On

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

Application Software Flashloader Software


(Application Mode) (Boot Mode)

Figure 2: ECU Diagnostic Session State Diagram

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 33

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.

8.1.4 Protocol Requirement(s)

UDS 268: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.1.4.1 Diagnostic Request

UDS 270: The Diagnostic Session Control request shall follow the format defined in Table 20.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 34

Table 20 : Request Message Definition - Diagnostic Session Control

Message
Data Byte No. Parameter Name Data Value
Usage

1 Diagnostic Session Control Request Service Id M 10


2 Sub Function = [Diagnostic Session Type] M
Default Session – Positive Response Required 01
Programming Session – Positive Response Required 02
Extended Diagnostic Session – Positive Response Required 03
Safety System Diagnostic Session – Positive Response Required 04
Stand By Session – Positive Response Required 49
Manufacturer Specific – Positive Response Required 40-48
Supplier Specific – Positive Response Required 60-68
Default Session – No Positive Response Required 81
Programming Session – No Positive Response Required 82
Extended Diagnostic Session – No Positive Response Required 83
Safety System Diagnostic Session – No Positive Response Required 84
Stand By Session – No Positive Response Required C9
Manufacturer Specific – No Positive Response Required C0-C8
Supplier Specific – No Positive Response Required E0-E8

8.1.4.2 Diagnostic Response(s)

UDS 275: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 21.

Table 21 : Positive Response Message Definition - Diagnostic Session Control

Message
Data Byte No. Parameter Name Usage Data Value

1 Diagnostic Session Control Response Service Id M 50


2 Sub Function = [Diagnostic Session Type] M 00-FF

Session Parameter Record[] = [


3 P2CAN_ECU_max (high byte) M 00-FF
4 P2CAN_ECU_max (low byte) : :
5 P2*CAN_ECU_ max (high byte) : :
6 M 00-FF
P2*CAN_ECU_ max (low byte)
]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 35

UDS 279: The application layer timing parameters reported as Session Parameter Record shall
follow the scaling format defined in Table 22.

Table 22 : Scaling Application Layer Timing Parameter

Parameter No. Of Bytes Resolution (ms/bit) Min Value Max Value

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:

Table 23 : Negative Response Message Definition - Diagnostic Session Control

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 36

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.

8.2 ECU Reset - Service Identifier [11 hex]


The ECU Reset service is used by an external test tool to request an ECU reset based on content of
the ECU Reset type parameter included in the ECU Reset request message.

8.2.1 ECU Reset Type Description

Table 24 defines the possible ECU Reset types:

Table 24 : ECU Reset Types

ECU Reset Type Description

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.

8.2.2 Behavior Requirement(s)

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 37

8.2.3 Protocol Requirement(s)

UDS 311: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.2.3.1 Diagnostic Request

UDS 313: The ECU Reset request message shall follow the format defined in Table 25.

Table 25 : Request Message Definition - ECU Reset

Message
Data byte no. Parameter name Data value
Usage

1 ECU Reset Request Service Id M 11


2 Sub Function = [Reset type] M
Hard Reset – Positive Response Required 01
Soft Reset – Positive Response Required 03
Supplier Specific – Positive Response Required 60-7E
Hard Reset – No Positive Response Required 81
Soft Reset – No Positive Response Required 83
Supplier Specific – No Positive Response Required E0-FE

8.2.3.2 Diagnostic Response(s)

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

1 ECU Reset Response Service Id M 51


01, 03,
2 Sub Function = [Reset type] M
60-7E

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 38

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.

Table 27 : Negative Response Message Definition - ECU Reset

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.

8.3 Clear Diagnostic Information - Service identifier [14 hex]


The Clear Diagnostic Information service is used by an external test tool to clear diagnostic
information in one or multiple ECUs’ memory.

8.3.1 Clear Diagnostic Information Request Parameter Description

Table 28 defines the possible Clear DTC Information request types:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 39

Table 28 : Clear Diagnostic Information Request Parameter

Clear DTC Information


Description
request parameter

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.

8.3.2 Behavior requirement(s)

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.

8.3.3 Protocol Requirement(s)

UDS 357: The ECU shall meet the request and response message behavior as specified in section
7.2.

8.3.3.1 Diagnostic Request

UDS 359: The Clear Diagnostic Information request message shall follow the format defined in
Table 29.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 40

Table 29 : Request Message Definition - Clear DTC Information

Message
Data byte no. Parameter name Usage Data value

1 Clear Diagnostic Information Request Service Id M 14


Group Of DTC [] = [ M
2 Group Of DTC High Byte 00-FF
3 Group Of DTC Middle Byte 00-FF
4 Group Of DTC Low Byte 00-FF
]
This range of values is reserved for future legislative requirements. 000000 –
reserved
[000000 – 0000FF] 0000FF
All Groups / All DTCs [FFFFFF hex] M FFFFFF
Individual DTC 000100 -
M
[000100 – FFFFFE hex] FFFFFE

The range of [000000 - 0000FF] is reserved by ISO/SAE for future legislative requirements.

8.3.3.2 Diagnostic Response(s)

UDS 365: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 30.

Table 30 : Positive Response Message Definition - Clear DTC Information

Message
Data byte no. Parameter name Data value
Usage

1 Clear Diagnostic Information Positive Response Service Id M 54

UDS 368: The negative response to a Clear Diagnostic Information request shall follow the format
defined in Table 31.

Table 31 : Negative Response Message Definition - Clear DTC Information

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 41

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

8.4 Read DTC Information - Service Identifier [19 hex]


This service allows an external test tool to read the Diagnostic Trouble Codes (DTCs) and related
information stored in any ECU or group of ECU’s within a vehicle.

8.4.1 DTC Information Request Type Description

Table 32 defines the possible DTC Information request types:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 42

Table 32 : DTC Information Request Types

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 43

8.4.2 Request Data Parameter Type Description

Table 33 defines the possible Request data parameter types.

Table 33 : Request Data Parameter Types

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 [00 hex] is reserved by ISO/SAE.

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 44

8.4.3 Response Data Parameter Description

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 45

Table 34 : Response Data Parameter Types

Response data
Description
parameter type

This parameter is an echo of the sub-function parameter provided in the request


Report Type
message from the external test tool.
This parameter record contains either one or more groupings of DTC High Byte,
DTC Middle Byte and DTC Low Byte or one or more DTCs according to SAEJ1939
DTC Record
Format (for further details concerning DTC formats see DTC Mask Record
description in Table 35).

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.

⎯ ISO15031-6DTCFormat: This parameter value identifies the DTC format


reported by the ECU as defined in ISO 15031-6.
⎯ ISO14229-1DTCFormat: This parameter value identifies the DTC format
reported by the ECU as defined in this table by the parameter DTC Record.
DTC Format Identifier ⎯ SAEJ1939-73DTCFormat: This parameter value identifies the DTC format
reported by the ECU as defined in SAE J1939-73.
⎯ ISO11992-4DTCFormat: This parameter value identifies the DTC format
reported by the server as defined in ISO 11992-4.
Refer to Annex A for the applicability of the DTC Format identifier for each business
unit.

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 46

8.4.4 Status of DTC

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.

Table 35: Status of DTC Bit Definition

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.

1: most recent result from DTC test indicated a failed result.


0: most recent result from DTC test indicated no failure detected.

1 Test Failed This Operation Cycle M O / C1

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.

2 Pending DTC M n/a


This bit shall indicate whether or not a diagnostic test has reported a Test Failed result at
any time during the current or last completed operation cycle. The status shall only be up-
dated if the test runs and completes. The criteria to set the Pending DTC bit and the Test
Failed This Operation Cycle bit are the same. The difference is that the Test Failed This
Operation Cycle is cleared at the end of the current operation cycle and the Pending DTC bit
is not cleared until an operation cycle has completed where the test has passed at least
once and never failed.
If the test did not complete during the current operation cycle, the status bit shall not be
changed. For example, if a monitor stops running after a confirmed DTC is set, the Pending
DTC must remain set = ‘1’. For an OBD DTC, a pending DTC is required to be stored after a
malfunction is detected during the first driving 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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 47

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.

4 Test Not Completed Since Last Clear M M

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.

5 Test Failed Since Last Clear M M


This bit shall indicate whether a DTC test has ever returned a Test Failed = 1 result since
the last time a call was made to Clear Diagnostic Information (latched Test Failed This Moni-
toring Cycle =1).
Zero (0) shall indicate that the test has not run or that the DTC test ran and passed (but
never failed). If the test runs and fails then the bit shall remain latched at a 1.
Reset to Zero (0) after a call to Clear Diagnostic Information. In contradiction to the Con-
firmed DTC this bit is not reset by self-healing criteria or when it was overwritten due to an
overflow of the fault memory.

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 48

ECU Support
Mandatory / Option-
al
Bit Description
Emis- Non-
sion Emission
Related Related

7 Warning Indicator Requested M n/a


This bit shall report the status of any warning indicators associated with a particular DTC.
Warning outputs may consist of indicator lamp(s), displayed text information, etc. If no
warning indicators exist for a given system or particular DTC, this status shall default to a
logic”0” state.
Conditions for activating and deactivating the warning indicator are defined by the applica-
tion specific document.
Reset to a logical ‘0’ after a call to Clear Diagnostic Information.

1: Warning indicator requested to be ON.


0: Warning indicator requested to be OFF or functionality isn’t applicable.
If the warning indicator is on for a given DTC, then Confirmed DTC shall be also be set to 1.

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

8.4.6 Behavior Requirement(s)

8.4.6.1 DTC Status Information Byte

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)

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 49

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

8.4.6.2 Report Number Of DTCs By Status Mask

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.

8.4.6.3 Report DTC By Status Mask

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 50

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.

8.4.6.4 Report DTC Extended Data Record By DTC Number

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.

8.4.6.5 Report Number Of Mirror Memory Of DTC By Status Mask

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.

8.4.6.6 Report Mirror Memory DTC By Status Mask

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 51

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 52

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

8.4.6.14 Report Supported DTCs

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.

8.4.6.15 Report DTC Fault Detection Counter

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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 53

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.

8.4.6.16 Report DTC With Permanent 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.”

8.4.7 Protocol Requirement(s)

UDS 481: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.4.7.1 Diagnostic Requests

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 54

Table 36 : Request Message Definition - Read DTC Information (By Status Mask)

Data byte no. Parameter name Message Usage Data value

1 Read DTC Information request Service Id M 19


2 sub-function = [Request type] M 00-FF

Report Number Of DTC By Status Mask -


01
Positive Response Required (response see Table 44)

Report Number Of Mirror Memory DTC By Status Mask -


11
Positive Response Required (response see Table 44)

Report DTC By Status Mask -


02
Positive Response Required (response see Table 43)
Report Mirror Memory DTC By Status Mask -
0F
Positive Response Required (response see Table 43)
3 DTC Status Mask M 00-FF

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)

Data byte no. Parameter name Message Data value


Usage

1 Read DTC Information request Service Id M 19

2 sub-function = [Request type] M 00-FF


Report DTC Extended Data By DTC Number -
06
Positive Response Required (response see Table 4 5)

Report Mirror Memory DTC Extended Data By DTC Number -


Positive Response Required (response see Table 4 5) 10

DTC Mask Record [] = [ M


3 DTC High Byte 00–FF
4 DTC Middle Byte 00–FF
5 DTC Low Byte 00–FF
]

6 DTC Extended Data Record Number M

ISO/SAE reserved 00

ECU supports multi Extended Data Records per DTC - Report one specific record 01 - 8F

Reserved to report legislated OBD stored DTCExtendedData records 90 - EF


ISO/SAE reserved F0 - FD
Reserved to report all legislated OBD stored DTCExtendedData records in a
single response message FE

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 55

Table 38 : Request Message Definition - Read DTC Information (Report DTC Snapshot
Record By DTC Number)

Data byte no. Parameter name Message Usage Data value

1 Read DTC Information request Service Id M 19


2 sub-function = [Request type] M 00-FF

Report DTC Snapshot Record By DTC Number -


04
Positive Response Required (response see Table 46)

DTC Mask Record [] = [ M


3 DTC High Byte 00 – FF
4 DTC Middle Byte 00 – FF
5 DTC Low Byte 00 – FF
]
6 DTC Snapshot Record Number M

ISO/SAE reserved 00

ECU supports multi Snapshot Data Records per DTC -


01 - FE
Report one specific record
ECU supports multi Snapshot Data Records per DTC – Report all records FF

UDS 501: Requests to an ECU to report DTC Snapshot Record By Record Number shall follow the
format defined in Table 39.

Table 39 - Request message definition - sub-function = reportDTCSnapshotByRecordNumber

Message
Data byte no. Parameter name Data value
Usage

1 Read DTC Information request Service Id M 19


2 sub-function = [Request type] M 00-FF
Report DTC Snapshot Record By Record Number 05
Positive Response Required (response see Table 47)
3 DTC Snapshot Record Number M 00-FF

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 56

Table 40 : Request Message Definition - Read DTC Information (Supported DTCs / DTC Fault
Detection Counter)

Message
Data byte no. Parameter name Data value
Usage

1 Read DTC Information request Service Id M 19


2 sub-function = [Request type] M 00-FF
Report Supported DTCs -
0A
Positive Response Required (response see Table 43)
Report DTC Fault Detection Counter -
14
Positive Response Required (response see Table 48)

Report DTC With Permanent Status -


15
Positive Response Required (response se ee Table 43)

8.4.7.2 Diagnostic response(s)

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.

UDS 510: A positive response by an ECU to a Report DTC By Status Mask,


Report Supported DTCs, Report Mirror Memory DTC By Status Mask or
ReportDTCWithPermanentStatus shall follow the format defined in Table 41.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 57

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

1 Read DTC Information response Service Id M 59


2 Report Type M
Report DTC By Status Mask 02
Report Supported DTCs 0A
Report Mirror Memory DTC By Status Mask 0F
Report DTC With Permanent Status 15
3 DTC Status Availability Mask M 00-FF

DTC And Status Record [] = [


4 DTC High Byte no. 1 C1 00-FF
5 DTC Middle Byte no. 1 C1 00-FF
6 DTC Low Byte no. 1 C1 00-FF
7 Status Of DTC no. 1 C1 00-FF
8 DTC High Byte no. 2 C2 00-FF
9 DTC Middle Byte no. 2 C2 00-FF
10 DTC Low Byte no. 2 C2 00-FF
11 Status Of DTC no. 2 C2 00-FF
: : : :
n-3 DTC High Byte no. m C2 00-FF
n-2 DTC Middle Byte no. m C2 00-FF
n-1 DTC Low Byte no. m C2 00-FF
n Status Of DTC no. m C2 00-FF
]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 58

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

1 Read DTC Information response Service Id M 59


2 Report Type M 00-FF
Report Number Of DTC By Status Mask 01
Report Number Of Mirror Memory DTC By Status Mask 11
3 DTC Status Availability Mask M 00-FF
4 DTC Format Identifier M 00-FF
ISO15031-6DTCFormat 00
ISO14229-1DTCFormat 01
SAEJ1939/73DTCFormat 02
ISO11992-4DTCFormat 03
DTC Count [] = [
DTC Count High Byte
5 M 00-FF
DTC Count Low Byte
6 M 00-FF
]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 59

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

1 Read DTC Information response Service Id M 59


2 Report Type M 00-FF
Report Extended Data Record By DTC Number 06
Report Mirror Memory DTC Extended Data By DTC Number 10

DTC And Status Record [] = [


3 DTC High Byte M 00-FF
4 DTC Middle Byte M 00-FF
5 DTC Low Byte M 00-FF
6 Status Of DTC M 00-FF
]

7 DTC Extended Data Record Number no. 1 C1 xx

DTC Extended Data Record [] no. 1 = [


8 Extended Data no. 1 byte no. 1 C1 00-FF
: : C1 :
8+(p-1) Extended Data no. 1 byte no. p C1 00-FF
]

: : : :
no. t DTC Extended Data Record Number no. x C2 xx

DTC Extended Data Record [] no. x = [


no. t+1 Extended Data no. x byte no. 1 C2 00-FF
: : C2 00-FF
no. t+1+(q-1) Extended Data no. x byte no. q C2 00-FF
]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 60

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

1 Read DTC Information response Service Id M 59


2 Report Type M 00-FF
Report DTC Snapshot Record By DTC Number 04

DTC And Status Record no.1 [] = [


3 DTC High Byte M 00-FF
4 DTC Middle Byte M 00-FF
5 DTC Low Byte M 00-FF
6 Status Of DTC M 00-FF
]

7 DTC Snapshot Record Number no. 1 C1 00-FF


8 DTC Snapshot Record Number Of Identifiers no 1 C1 00-FF

DTC Snapshot Record [] no. 1 = [


9 Data Identifier no. 1 [High Byte] C1 00-FF
10 Data Identifier no. 1 [Low Byte] C1 00-FF
11 Snapshot Data no. 1 Byte no. 1 C1 00-FF
: : C1 :
11+(p-1) Snapshot Data no. 1 Byte no. p C1 00-FF
: : : :
r-(m-1)-2 Data Identifier no. w [High Byte] C2 00-FF
r-(m-1)-1 Data Identifier no. w [Low Byte] C2 00-FF
r-(m-1) Snapshot Data no. w Byte no. 1 C2 00-FF
: : C2 :
r Snapshot Data no. w Byte no. m] C2 00-FF

: : : :
t DTC Snapshot Record Number no. x C3 00-FF
t+1 DTC Snapshot Record Number Of Identifiers no x C3 00-FF

DTC Snapshot Record [] no. x = [


t+2 Data Identifier no. 1 [High Byte] C3 00-FF
t+3 Data Identifier no. 1 [Low Byte] C3 00-FF
t+4 Snapshot Data no. 1 Byte no. 1 C3 00-FF
: : C3 :
t+4+(p-1) Snapshot Data no. 1 Byte no. p C3 00-FF
: : : :
n-(u-1)-2 Data Identifier no. v [High Byte] C4 00-FF
n-(u-1)-1 Data Identifier no. v [Low Byte] C4 00-FF
n-(u-1) Snapshot Data no. v Byte no. 1 C4 00-FF
: : C4 :
n Snapshot Data no. v Byte no. u] C4 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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 61

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

1 Read DTC Information response Service Id M 59


2 Report Type M 00-FF
Report DTC Snapshot Record By Record Number 05
3 DTCSnapshotRecordNumber #1 M 00-FF
DTCAndStatusRecord[] #1 = [
4 DTCHighByte C1 00-FF
5 DTCMiddleByte C1 00-FF
6 DTCLowByte C1 00-FF
7 statusOfDTC ] C1 00-FF
8 DTCSnapshotRecordNumberOfIdentifiers #1 C1 00-FF

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

C1: The DTCAndStatusRecord and the first dataIdentifier/snapshotData combination in the


DTCSnapshotRecord parameter is only present if at least one DTCSnapshot record is available to
be reported (DTCSnapshotRecordNumber unequal to FF hex in the request or only one record is
available to be reported if DTCSnapshotRecordNumber is set to FF hex in the request).

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 62

C2/C4: There are multiple dataIdentifier/snapshotData combinations allowed to be present in a


single DTCSnapshotRecord. This can e.g. be the case for the situation where a single dataIdentifier
only references an integral part of data. When the dataIdentifier references a block of data then a
single dataIdentifier/snapshotData combination can be used.

C3: The DTCSnapshotRecordNumber, DTCAndStatusRecord, and the first


dataIdentifier/snapshotData combination in the DTCSnapshotRecord parameter is only present if all
records are requested to be reported (DTCSnapshotRecordNumber set to FF hex in the request)
and more than one record is available to be reported.

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

1 Read DTC Information response Service Id M 59


2 Report Type M
Report DTC Fault Detection Counter 14

DTC Fault Detection Counter Record [] = [


3 DTC High Byte no. 1 C1 00-FF
4 DTC Middle Byte no. 1 C1 00-FF
5 DTC Low Byte no. 1 C1 00-FF
6 DTC Fault Detection Counter no. 1 C1 00-FF
7 DTC High Byte no. 2 C2 00-FF
8 DTC Low Byte no. 2 C2 00-FF
9 DTC Low Byte no. 2 C2 00-FF
10 DTC Fault Detection Counter no. 2 C2 00-FF
: : : :
n-3 DTC High Byte no. m C2 00-FF
n-2 DTC Low Byte no. m C2 00-FF
n-1 DTC Low Byte no. m C2 00-FF
n DTC Fault Detection Counter no. m C2 00-FF
]

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 63

Table 47 : Negative Response Message Definition - Read DTC Information

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

8.5 Read Data By Identifier - Service Identifier [22 hex]


The Read Data By Identifier service allows the external test tool to request data record values from
the ECU identified by Record Data Identifiers.

8.5.1 Request And Response Parameter Description

Table 48 defines the possible request and response parameter types:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 64

Table 48 : Request and Response Parameter Types

Parameter type Description

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.

8.5.2 Protocol Requirement(s)

UDS 572: The ECU shall meet the request and response message behavior as specified in
section 7.2.

8.5.2.1 Diagnostic Request

UDS 574: The Read Data By Identifier request message shall follow the format defined in the
Table 49.

Table 49 : Request Message Definition - Read Data By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Read Data By Identifier Request Service Id M 22

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.

8.5.2.2 Diagnostic Response(s)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 65

Table 50 : Positive Response Message Definition - Read Data By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Read Data By Identifier Response Service Id M 62

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.

Table 51 : Negative Response Message Definition - Read Data By Identifier

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 66

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.

8.6 Read Memory By Address - Service identifier [23 hex]


The Read Memory By Address service allows the external test tool to request memory data from the
ECU by providing the starting address and memory size parameters in the request message.

8.6.1 Request and Response Parameter Description

Table 52 defines the Read / Write Memory By Address service parameters.

Table 52 : Read / Write Memory By Address Request Parameters

Read / Write Memory By


Description
Address Parameter

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 67

8.6.2 Protocol Requirement(s)

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.

8.6.2.1 Diagnostic Request

UDS 603: The Read Memory By Address request message shall follow the format defined in
Table 53.

Table 53 : Request Message Definition - Read Memory By Address

Message
Data byte no. Parameter name Data value
Usage

1 Read Memory By Address Request Service Id M 23

2 Address And Length Format Identifier M


Bit 7…4: Length (number of bytes) of the Memory Size parameter 1-4
0: reserved
1-4: Memory Size parameter length of 1 to 4 bytes
5-F: reserved
Bit 3…0: Length (number of bytes) of the Memory Address parameter 1-4
0: reserved
1-4: Memory Address parameter length of 1 to 4 bytes
5-F: reserved

3 Memory Address [] = [ byte 1 (MSB) 00-FF

: : M :
:
C1
(m-1)+3 byte m] 00-FF

n-(k-1) Memory Size [] = [ byte 1 (MSB) 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).

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 68

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

8.6.2.2 Diagnostic Response(s)

UDS 611: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 54.

Table 54 : Positive Response Message Definition - Read Memory By Address

Data byte Message


Parameter name Data value
Usage
no.

1 Read Memory By Address Response Service Id M 63

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.

Table 55 : Negative Response Message Definition - Read Memory By Address

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 69

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.

8.7 Security Access - Service Identifier [27 hex]


The purpose of this service is to provide a means to access data and/or diagnostic services, which
have restricted access for security, emissions, or safety reasons. The security concept uses a seed
and key relationship.

8.7.1 Security Access Request Type Description

Table 56 defines the possible request types.

Table 56 : Security Access Types

Security Access type Description

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 70

8.7.2 Request and Response Data Parameter Type Description

Table 57 defines the possible Request data parameter types.

Table 57 : Request and Response Parameter Types

Request and response data


Description
parameter type

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

8.7.3 Behavior Requirement(s)

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 71

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.

8.7.4 Protocol Requirement(s)

UDS 658: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.7.4.1 Diagnostic Request

UDS 660: The Security Access request message shall follow the format defined in Table 58.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 72

Table 58 : Request Message Definition - Security Access

Message
Data byte no. Parameter name Data value
Usage

1 Security Access Request Service Id M 27


2 Sub Function = [Security Access Type] M 00 – 7E
Odd Nos.
Request Seed – Positive Response Required 01 – 0B
(Vehicle Manufacturer Specific Range) 11
31- 3D
Even Nos.
Send Key – Positive Response Required 02 -0C
(Vehicle Manufacturer Specific Range) 12
32-3E
Odd Nos.
Request Seed – Positive Response Required 0D - 0F
(Vehicle Manufacturer Specific Range) - RESERVED 13 – 2F
3F - 41
Even Nos.
Send Key – Positive Response Required 0E - 10
(Vehicle Manufacturer Specific Range) - RESERVED 14 - 30
40 - 42
Request Seed – Positive Response Required Odd Nos.
(ISO 26021-2– End of Life activation of on-board pyrotechnic devices) 5F
Send Key – Positive Response Required Even Nos.
ISO 26021-2– End of Life activation of on-board pyrotechnic devices) 60
Request Seed – Positive Response Required Odd Nos.
(ISO/SAE reserved 43 – 5D
Send Key – Positive Response Required Even Nos.
(ISO/SAE reserved) 44 – 5E
Odd Nos.
Request Seed – Positive Response Required (Supplier Specific Range)
61 – 7D
Even Nos.
Send Key – Positive Response Required (Supplier Specific Range)
62 – 7E

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 73

8.7.4.2 Diagnostic Response(s)

UDS 667: If a positive response is allowed in accordance with section 7.1, the response shall follow
the format defined in Table 59.

Table 59 : Positive Response Message Definition - Security Access

Message
Data byte no. Parameter name Data value
Usage

1 Security Access Response Service Id M 67


2 Security Access Type M 00-FF

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.

Table 60 : Negative Response Message Definition - Security Access

Data byte no. Parameter name Message Data value


Usage

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 74

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.

8.8 Communication Control - Service Identifier [28 hex]


The purpose of this service is to switch on and off the transmission of certain ECU messages (e.g.
normal communication messages).

8.8.1 Control Type description

Table 61 defines the possible Communication Control types.

Table 61 : Control Types

Control Type Description

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 75

8.8.2 Communication Type description

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.

Table 62 : Communication Type

Communication Type Description

This type references all application-related communication


Normal Communication Messages
(inter-application signal exchange between multiple in-vehicle ECUs)

8.8.3 Behavior Requirements

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.

8.8.4 Protocol Requirement(s)

UDS 701: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.8.4.1 Diagnostic Request

UDS 703: The Communication Control request message shall follow the format defined in Table 63.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 76

Table 63 : Request Message Definition - Communication Control

Message
Data byte no. Parameter name Data value
Usage

1 Communication Control Request Service Id M 28


2 Sub Function = [Control Type] M 00-FF
Enable Rx And Tx – Positive Response Required 00
Enable Rx And Disable Tx – Positive Response Required 01
Enable Rx And Tx – No Positive Response Required 80
Enable Rx And Disable Tx – No Positive Response Required 81
3 Communication Type M 00-FF
The communication type encoding is defined in Table 64

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.

Table 64 : Definition of Communication Type and Subnet Number

Data bit
Description Data value
number

Communication type

Normal Communication Messages 1


0 -1 This value references all application-related communication (inter-application signal
exchange between multiple in-vehicle servers).
Reserved
0, 2, 3

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 77

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.

8.8.4.2 Diagnostic Response(s)

UDS 713: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 65.

Table 65 : Positive Response Message Definition - Communication Control

Message
Data byte no. Parameter name Data value
Usage

1 Communication Control Response Service Id M 68


2 Control Type M 00-FF

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.

Table 66 : Negative Response Message Definition - Communication Control

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 78

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.

8.9 Dynamically Define Data Identifier - Service Identifier [2C hex]


The Dynamically Define Data Identifier service allows the external test tool to dynamically define a
Data Identifier with in an ECU which can be read via the Read Data By Identifier service at a later
time. Consequently the external test tool is able to group one or more data elements into a data
superset that can be requested at once via the Read Data By Identifier

8.9.1 Dynamic Data Identifier Definition Type Description

Table 67 defines the possible Data Identifier Definition types.

Table 67 : Dynamic Data Identifier Definition Types

Dynamic Data Identifier


Description
Definition Type

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 79

8.9.2 Request and Response Data Parameter Type Description

Table 68 defines the possible Request data parameter types.

Table 68 : Request and Response Parameter Types

Request and response data


Description
parameter type

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 Identifier [01 hex] the


Position In Source Data Record parameter is used in addition to specify the starting
position in the source data identifier from where the Memory Size applies. The number
Memory Size
of bytes used for this size is one (1) byte.

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.

8.9.3 Behavior requirement(s)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 80

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.

8.9.4 Protocol Requirement(s)

UDS 744: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.9.4.1 Diagnostic Request(s)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 81

Table 69 : Request Message Definition - Dynamically Define Identifier (Define By Identifier)

Message
Data byte no. Parameter name Data value
Usage

1 Dynamically Define Data Identifier Request Service Id M 2C


2 Sub-function = [Define By Identifier – Positive Response Required] M 01

Dynamically Defined Data Identifier [] = [


3 byte 1 (MSB) M F3
4 byte 2 (LSB)] M 00-FF

Source Data Identifier [] no. 1 = [


5 byte 1 (MSB) M 00-FF
6 byte 2 (LSB)] M 00-FF

7 Position In Source Data Record no. 1 M 00-FF


8 Memory Size no. 1 M 00-FF
: : : :

Source Data Identifier [] no. m = [


n-3 byte 1 (MSB) O 00-FF
n-2 byte 2 (LSB)] O 00-FF

n-1 Position In Source Data Record no. m O 00-FF


n Memory Size no. m O 00-FF

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 82

Table 70 : Request Message Definition - Dynamically Define Identifier (Define By Address)

Message
Data byte no. Parameter name Data value
Usage

1 Dynamically Define Data Identifier Request Service Id M 2C


2 Sub-function = [Define By Address – Positive Response Required] M 02

Dynamically Defined Data Identifier [] = [


3 byte 1 (MSB) M F3
4 byte 2 (LSB)] M 00-FF

Address And Length Format Identifier M


Bit 7…4: Length (number of bytes) of the Memory Size parameter 1-4
0: reserved
1-4: Memory Size parameter length of 1 to 4 bytes
5 5-F: reserved
Bit 3…0: Length (number of bytes) of the Memory Address parameter 1-4
0: reserved
1-4: Memory Address parameter length of 1 to 4 bytes
5-F: reserved
Memory Address no 1.[] = [
6 byte 1 (MSB) M 00-FF
: : : :
(m-1)+6 byte m] C 00-FF
Memory Size no. 1 [] = [
m+6 byte 1 (MSB) M 00-FF
: : : :
m+6+(k-1) byte k] C 00-FF

Memory Address no. x [] = [


n-k-(m-1) byte 1 (MSB) O 00-FF
: : : :
n-k byte m] C 00-FF

Memory Size no. x [] = [


n-(k-1) byte 1 (MSB) O 00-FF
: : : :
n byte k] C 00-FF

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.

Table 71 : Request Message Definition - Dynamically Define Identifier (Clear Dynamic


Identifier)

Message
Data byte no. Parameter name Data value
Usage

1 Dynamically Define Data Identifier Request Service Id M 2C


2 Sub-function = [Clear Dynamic Identifier – Positive Response Required] M 03

Dynamically Defined Data Identifier [] = [


3 byte 1 (MSB) M F3
4 byte 2 (LSB)] M 00-FF

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 83

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.

8.9.4.2 Diagnostic Response(s)

UDS 759: If a positive response is allowed in accordance with section 7.1, the response shall follow
the format defined in Table 72.

Table 72 : Positive response message definition - Dynamically Defined Data Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Dynamically Define Data Identifier Response Service Id M 6C


2 Dynamic Data Identifier Definition Type M 01-03

Dynamically Defined Data Identifier [] = [


3 byte no. 1 (high byte) M F3
4 byte no. m (low byte)] M 00-FF

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:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 84

Table 73 : Negative Response Message Definition - Dynamically Defined Data Identifier

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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 85

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.

8.10 Write Data By Identifier - Service Identifier [2E hex]


The Write Data By Identifier service allows the external test tool to write information into the ECU to
a location specified by the provided data identifier.

8.10.1 Request And Response Parameter Description

Table 74 defines the possible request and response parameter types:

Table 74 : Request And Response Parameter Types

Parameter type Description

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.

8.10.2 Protocol Requirement(s)

UDS 788: The ECU shall meet the request and response message behavior as specified in
section 7.2.

8.10.2.1 Diagnostic Request

UDS 790: The Write Data By Identifier request message shall follow the format defined in Table 75.

Table 75 : Request Message Definition - Write Data By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Write Data By Identifier Request Service Id M 2E

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 86

UDS 793: The Data Identifier parameter shall be used according to the parameter definition in
Table 74.

8.10.2.2 Diagnostic Response(s)

UDS 795: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 76.

Table 76 : Positive Response Message Definition - Write Data By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Write Data By Identifier Response Service Id M 6E

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:

Table 77 : Negative Response Message Definition - Write Data By Identifier

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 87

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.

8.11 Input Output Control By Identifier- Service Identifier [2F hex]


The Input Output Control By Identifier service is used by the external test tool to substitute a value
for an input signal, internal ECU function and/or control an output (actuator) of an electronic system.
It is strongly recommended to always use a separate Input Output Control Identifier per parameter
(respectively the represented actuator or input). Only parameters which require to be controlled at
the same time or bit-encoded parameters of the same functional group (e.g. exterior lighting) should
be combined into a single Input Output Control Identifier and consequently require a Control Enable
mask Record. Grouping of parameters in a single Input Output Control Identifier must be decided on
a case by case basis in close discussion with the diagnostic development team.

8.11.1 Request and Response Parameter Description

Table 78 defines the possible request and response parameter types.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 88

Table 78 : Request and Response Parameter Types

Parameter type Description

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 89

8.11.2 Behavior Requirements

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.

8.11.2.1 Diagnostic Request

UDS 829: The Input Output Control By Identifier request message shall follow the format defined in
Table 79.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 90

Table 79 : Request Message Definition - Input Output Control By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Input Output Control By Identifier Request Service Id M 2F

Data Identifier []= [


2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF

4 Input Output Control Type M 00-FF


Return Control To ECU 00
Reset To Default 01
Freeze Current State 02
Short Term Adjustment 03

Control Option Record [] = [


5 control state no. 1 C1 00-FF
: : : :
4+(m-1) control state no. m] C2 00-FF

Control Enable Mask Record no. 1 [] = [


4+m control mask no. 1 C3 00-FF
: : : :
4+m+(r-1) control mask no. r] C3 00-FF

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.

8.11.2.2 Diagnostic Response(s)

UDS 838: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 80.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 91

Table 80 : Positive response message definition - Input Output Control By Identifier

Message
Data byte no. Parameter name Data value
Usage

1 Input Output Control By Identifier Response Service Id M 6F

Data Identifier no 1 []= [


2 byte 1 (MSB) M 00-FF
3 byte 2] M 00-FF

4 Input Output Control Type M 00-03

Control Status Record [] = [


5 control state no. 1 M 00-FF
: : : :
4+(m-1) control state no. m] C 00-FF

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:

Table 81 : Negative Response Message Definition - Input Output Control By Identifier

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 92

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:

• The requested Data Identifier value is not supported by the ECU.


• The Input Output Control Parameter value is invalid.
• One or more of the applicable Control States of the Control Option Record are invalid.

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 Routine Control - Service Identifier [31 hex]


The Routine Control service is used to initialize routines which could either be tests that run instead
of normal operating code or could be routines that are enabled and executed with the normal
operating code running. It may be necessary to switch the ECU into a specific diagnostic session
using the Diagnostic Session Control service or to unlock the ECU using the Security Access service
prior to using the Routine Control service.
The Routine Control service is used by the external test tool to:
• Start a routine
• Stop a routine
• Request routine results
Routine Identifiers are referenced by a 2-byte routine identifier within the ECU.
Routines are not intended to be used in place of Read Data, I/O-Control, or Variant Coding.

8.12.1 Behavior Requirement(s)

8.12.1.1 General

UDS 864: The ECU shall exit any routine following a reset or power down event.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 93

8.12.1.2 Start Routine

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

8.12.1.3 Stop Routine

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.

8.12.1.4 Request Routine Results

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.

8.12.2 Protocol Requirement(s)

UDS 875: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.12.2.1 Diagnostic Request

UDS 1448: The Routine Control request message shall follow the format defined in Table 82 and
Table 125

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 94

Table 82 : Request Message Definition - Routine Control - Start/Stop Routine

Data
Data byte no. Parameter name Message Usage
value

1 Routine Control Request Service Id M 31


2 sub-function = [ Routine Control Type] M 00-FF
Start Routine – Positive Response Required 01
Stop Routine – Positive Response Required 02
Start Routine – No Positive Response Required 81
Stop Routine – No Positive Response Required 82
3 Routine Identifier [] = [ byte 1 (MSB) M 00-FF
4 byte 2] M 00-FF

5 Routine Control Option Record [] = [routine control option no. 1 O 00-FF


: : : :
n routine control option no. m] O 00-FF

Table 125 : Request Message Definition - Routine Control - Request Routine Results

Data
Data byte no. Parameter name Message Usage
value

1 Routine Control Request Service Id M 31


2 sub-function = [ Routine Control Type] M 00-FF
Request Routine Results – Positive Response Required 03

3 Routine Identifier [] = [ byte 1 (MSB) M 00-FF


4 byte 2] M 00-FF

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

8.12.2.2 Diagnostic Response(s)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 95

Table 83 : Positive Response Message Definition- Routine Control - Start/Stop Routine

Message
Data byte no. Parameter name Data value
Usage

1 Routine Control Response Service Id M 71


2 Routine Control Type M 00-FF

Start Routine – Positive Response Required 01

Stop Routine – Positive Response Required 02

3 Routine Identifier [] = [ byte 1 (MSB) M 00-FF


4 byte 2] M 00-FF

5 Routine Status Record [] = [ routine status no. 1 O 00-FF


: : : :
n routine status no. m] O 00-FF

Table 126 : Positive Response Message Definition- Routine Control - Request RoutineResults

Message
Data byte no. Parameter name Data value
Usage

1 Routine Control Response Service Id M 71


2 Routine Control Type M 00-FF

Request Routine Results – Positive Response Required 03

3 Routine Identifier [] = [ byte 1 (MSB) M 00-FF


4 byte 2] M 00-FF
Routine Status Record [] =
5 [routine status no. 1 M 00-FF
6 routine status no. 2 O :
: : : :
n routine status no. m] O 00-FF

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 96

Table 84 : Negative response message definition- Routine Control

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 97

8.13 Request Download - Service Identifier [34 hex]


The Request Download service is used by the external test tool to initiate a data transfer from the
external test tool to the ECU (download).

8.13.1 Service parameter description

Table 85 defines the Request Download / Upload service parameters.

Table 85 : Request Download / Upload Parameters

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.

Table 86 defines the Request Download / Upload service parameters.

Table 86 : Request Download / Upload Positive Response Parameters

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 98

8.13.2 Behavior Requirement(s)

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.

8.13.3 Protocol Requirement(s)

UDS 914: The ECU shall meet the request and response message behavior as specified in
section 7.2.

8.13.3.1 Diagnostic Request

UDS 916: The Download request message shall follow the format defined in Table 87.

Table 87 : Request Message Definition - Request Download

Message
Data byte no. Parameter name Data value
Usage

1 Request Download Request Service Id M 34


2 Data Format Identifier M 00-FF
3 Address And Length Format Identifier M
Bit 7…4: Length (number of bytes) of the Memory Size parameter 1-4
0: reserved
1-4: Memory Size parameter length of 1 to 4 bytes
5-F: reserved
Bit 3…0: Length (number of bytes) of the Memory Address parameter 1-4
0: reserved
1-4: Memory Address parameter length of 1 to 4 bytes
5-F: reserved

4 Memory Address[] = [ byte 1 (MSB) M 00-FF


: : : :
(m-1)+4 byte m] C1 00-FF

n-(k-1) Memory Size[] = [byte 1 (MSB) M 00-FF


: : : :
n byte k] C2 00-FF

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

m: Required memory address parameter length

k: Required memory size parameter length

n: n= 4+m and depends on the amount of databytes m required for the memory address parameter
length.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 99

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.

8.13.3.2 Diagnostic Response(s)

UDS 926: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 88.

Table 88 : Positive Response Message Definition - Request Download

Message
Data byte no. Parameter name Data value
Usage

1 Request Download Response Service Id M 74


2 Length Format Identifier M 00-F0

Max Number Of Block Length = [


3 byte 1 (MSB) M 00-FF
: : : :
n byte m] M 00-FF

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.

Table 89 : Negative Response Message Definition- Request Download

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 100

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.

8.14 Request Upload - Service Identifier [35 hex]


The Request Upload service is used by the external test tool to initiate a data transfer from the ECU
to the external test tool (upload).

8.14.1 Service Parameter Description

The Request Upload service parameters are defined in Table 85.


The Request Upload positive response parameters are defined in Table 86.

8.14.2 Behavior Requirement(s)

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.

8.14.3 Protocol Requirement(s)

UDS 947: The ECU shall meet the request and response message behavior as specified in
section 7.2.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 101

8.14.3.1 Diagnostic Request

UDS 949: The Upload request message shall follow the format defined in Table 90.

Table 90 : Request Message Definition - Request Upload

Message
Data byte no. Parameter name Data value
Usage

1 Request Upload Request Service Id M 35

2 Data Format Identifier M 00-FF

Address And Length Format Identifier M


Bit 7…4: Length (number of bytes) of the Memory Size parameter 1-4
0: reserved
1-4: Memory Size parameter length of 1 to 4 bytes
3 5-F: reserved
Bit 3…0: Length (number of bytes) of the Memory Address parameter 1-4
0: reserved
1-4: Memory Address parameter length of 1 to 4 bytes
5-F: reserved
4 Memory Address[] = [byte 1 (MSB) M 00-FF
: : : :
(m-1)+4 byte m] C1 00-FF
n-(k-1) Memory Size[] = [byte 1 (MSB) M 00-FF
: : : :
n byte k] C2 00-FF

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.

8.14.3.2 Diagnostic Response(s)

UDS 956: If a positive response is allowed in accordance with section 7.2, the response shall follow
the format defined in Table 91.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 102

Table 91 : Positive Response Message Definition - Request Upload

Message
Data byte no. Parameter name Data value
Usage

1 Request Upload Response Service Id M 75


2 Length Format Identifier M 00-F0

Max Number Of Block Length = [


3 byte 1 (MSB) M 00-FF
: : : :
n byte m] M 00-FF

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.

Table 92 : Negative response message definition- Request Upload

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 103

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.

8.15 Transfer Data - Service Identifier [36 hex]


The Transfer Data service is used by the external test tool to transfer data either from the external
test tool to the ECU (download) or from the ECU to the external test tool (upload).

8.15.1 Service parameter description

Table 93 defines the Transfer Data service parameters.

Table 93 : Transfer Data service parameters

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

8.15.2 Behavior Requirement(s)

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 104

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.

8.15.3 Protocol Requirement(s)

UDS 988: The ECU shall meet the request and response message behavior as specified in
section 7.2.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 105

8.15.3.1 Diagnostic Request

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.

Table 94 : Request Message Definition - Transfer Data (Download type)

Message
Data Byte no. Parameter name Data value
Usage

1 Transfer Data Request Service Id M 36


2 Block Sequence Counter M 00-FF

3 Transfer Request Parameter Record [] = [transfer request parameter no. 1 M 00-FF


: : : :
n transfer request parameter no. m] C 00-FF

C: The presence of this parameter depends on the availability of more than one data byte to
download to the ECUs memory.

Table 95 : Request Message Definition - Transfer Data (Upload type)

Message
Data Byte no. Parameter name Data value
Usage

1 Transfer Data Request Service Id M 36


2 Block Sequence Counter M 00-FF

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.

8.15.3.2 Diagnostic Response(s)

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 106

Table 96 : Positive Response Message Definition - Transfer Data (Download type)

Message
Data Byte no. Parameter name Data value
Usage

1 Transfer Data Response Service Id M 76


2 Block Sequence Counter M 00-FF

Table 97 : Positive Response Message Definition - Transfer Data (Upload type)

Message
Data Byte no. Parameter name Data value
Usage

1 Transfer Data Response Service Id M 76


2 Block Sequence Counter M 00-FF

3 Transfer Response Parameter Record []=[transfer response parameter no.1 M 00-FF


: : : :
n transfer response parameter no. m] C 00-FF

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 107

Table 98 : Negative Response Message Definition- Transfer Data

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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 108

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.

8.16 Request Transfer Exit - Service Identifier [37 hex]


This service is used by the external test tool to terminate a data transfer between the external test
tool and ECU (Upload or Download).

8.16.1 Behavior Requirements

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.

8.16.2 Protocol Requirements

UDS 1022: The ECU shall meet the request and response message behavior as specified in
section 7.2.

8.16.2.1 Diagnostic Request

UDS 1024: The Transfer Exit request message shall meet the format defined in Table 99.

Table 99 : Request Message Definition - Request Transfer Exit

Message
Data byte no. Parameter name Data value
Usage

1 Request Transfer Exit Request Service Id M 37

UDS 1027: Removed

8.16.2.2 Diagnostic Response(s)

UDS 1029: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 100.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 109

Table 100 : Positive Response Message Definition - Request Transfer Exit

Message
Data byte no. Parameter name Data value
Usage

1 Request Transfer Exit Response Service Id M 77

UDS 1032: Removed

UDS 1033: The negative response to a Transfer Exit request shall follow the format defined in
Table 101.

Table 101 : Negative Response Message Definition- Request Transfer Exit

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 110

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.

8.17 Write Memory By Address - Service Identifier [3D hex]


The Write Memory By Address service allows the external test tool to write information into the ECU
at one or more contiguous memory locations.

8.17.1 Request And Response Message Parameter Description

The Write Memory By Address request and response message parameters are defined in Table 52.

8.17.2 Behavior Requirements

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.

8.17.3 Protocol Requirements

UDS 1050: The ECU shall meet the request and response message behavior as specified in
section 7.2.

8.17.3.1 Diagnostic Request

UDS 1052: The Write Memory By Address request message shall follow the format defined in
Table 102.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 111

Table 102 : Request Message Definition - Write Memory By Address

Message
Data byte no. Parameter name Data value
Usage

1 Write Memory By Address Request Service Id M 3D


2 Address And Length Format Identifier M
Bit 7…4: Length (number of bytes) of the Memory Size parameter 1-4
0: reserved
1-4: Memory Size parameter length of 1 to 4 bytes
5-F: reserved
Bit 3…0: Length (number of bytes) of the Memory Address parameter 1-4
0: reserved
1-4: Memory Address parameter length of 1 to 4 bytes
5-F: reserved
3 Memory Address[] = [ byte 1 (MSB) M 00-FF
: : : :
m+2 byte m] C1 00-FF
n-r-2-(k-1) Memory Size[] = [byte 1 (MSB) M 00-FF
: : : :
n-r-2 byte k] C2 00-FF
n-(r-1) Data Record[] = [ data byte no. 1 M 00-FF
: : : :
n data byte no. r] O 00-FF

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.

8.17.3.2 Diagnostic Response(s)

UDS 1059: If a positive response is allowed in accordance with section 7.2, the response shall meet
the format defined in Table 103.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 112

Table 103 : Positive Response Message Definition - Write Memory By Address

Message
Data byte no. Parameter name Data value
Usage

1 Write Memory By Address Response Service Id M 7D


2 Address And Length Format Identifier M 00-FF

3 Memory Address[] = [byte 1 (MSB) M 00-FF


: : : :
(m-1)+3 byte m] C1 00-FF

n-(k-1) Memory Size[] = [byte 1 (MSB) M 00-FF


: : : :
n byte k] C2 00-FF

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.

Table 104 : Negative Response Message Definition - Write Memory By Address

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 113

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.

8.18 Tester Present - Service Identifier [3E hex]


This service is used to indicate to an ECU or a group of ECU’s that an external test tool is still
connected to the vehicle and that certain diagnostic services and/or communication that have been
previously activated are to remain active.

8.18.1 Behavior Requirement(s)

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.

8.18.2 Protocol Requirement(s)

UDS 1082: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.18.2.1 Diagnostic Request

UDS 1084: The Tester Present request message shall follow the format defined in Table 105.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 114

Table 105 : Request Message Definition - Tester Present

Message
Data byte no. Parameter name Data value
Usage

1 Tester Present Request Service Id M 3E


2 Sub Function = [Zero Sub-Function] M
Positive Response Required 00
No Positive Response Required 80

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.

8.18.2.2 Diagnostic Response

UDS 1089: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 106.

Table 106 : Positive Response Message Definition - Tester Present

Message
Data byte no. Parameter name Data value
Usage

1 Tester Present Response Service Id M 7E


2 Sub Function = [Zero Sub-Function] M 00

UDS 1092: The negative response to a Tester Present request shall follow the format defined in
Table 107.

Table 107 : Negative Response Message Definition - Tester Present

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

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 115

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

8.20 Control DTC Setting - Service Identifier [85 hex]


The Control DTC Setting service is used by an external test tool to stop or resume the setting of
diagnostic trouble codes (DTCs) in the ECU(s).

8.20.1 DTC Setting Type description

Table 108 defines the possible DTC Setting Types:

Table 108 : DTC Setting Types

DTC Setting Type Description

On This type requires the ECU to enable storage of DTCs.

Off This type requires the ECU to disable storage of DTCs.

Refer to MBN 10746 for definition of enabling and disabling storage of DTCs.

8.20.2 Behavior Requirements

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 116

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.

8.20.3 Protocol Requirements

UDS 1118: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.20.3.1 Diagnostic Request

UDS 1120: The Control DTC Setting request message shall follow the format defined in Table 109.

Table 109 : Request Message Definition - Control DTC Setting

Message
Data byte no. Parameter name Data value
Usage

1 Control DTC Setting Request Service Id M 85


2 Sub Function = [DTC Setting Type] M 00-FF
On – Positive Response Required 01
Off – Positive Response Required 02
Supplier Specific – Positive Response Required 60-7E
On – No Positive Response Required 81
Off – No Positive Response Required 82
Supplier Specific – No Positive Response Required E0-FE

NOTE: Only the DTC Setting types defined in Table 109 may be requested when requesting an ECU
to stop or resume DTC setting.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 117

8.20.3.2 Diagnostic response(s)

UDS 1126: If a positive response is allowed in accordance with section 7.1, the response shall
follow the format defined in Table 110.

Table 110 : Positive Response Message Definition - Control DTC Setting

Message
Data byte no. Parameter name Data value
Usage

1 Control DTC Setting Positive Response Service Id M C5


2 Sub Function = [DTC Setting type] M XX

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.

Table 111 : Negative Response Message Definition - Control DTC Setting

Data byte no. Parameter name Message Data value


Usage

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 118

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.

8.21 ECU Passive Mode - Service Identifier [A0 hex]


The purpose of this service is to switch on/off the transmission of certain diagnostic and inter-ECU
messages of an ECU. This service is similar to the Communication Control diagnostic service [28
XX hex] with the additional functionality with regards to sleep mode.

8.21.1 Description Parameter Types

Table 112 defines the possible Control types applicable for ECU Passive Mode requests:

Table 112 : Control Types

Control type Description

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

8.21.2 Behavior Requirements

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 119

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.

8.21.3 Protocol Requirements

UDS 1163: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.21.3.1 Diagnostic Request

UDS 1165: The ECU Passive Mode request message shall follow the format defined in Table 113.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 120

Table 113 : Request Message Definition - ECU Passive Mode

Message
Data byte no. Parameter name Data value
Usage

1 ECU Passive Mode Request Service ID M A0


2 sub-function = [Control Type] M 00-FF
Enable Passive Mode – Positive Response Required 01
Disable Passive Mode – Positive Response Required 02
Enable Passive Mode – No Positive Response Required 81
Disable Passive Mode – No Positive Response Required 82

UDS 1168: Only the Control types defined in Table 113 may be requested when enabling or
disabling ECU Passive Mode within an individual ECU.

8.21.3.2 Diagnostic Response(s)

UDS 1170: If a positive response is allowed in accordance with section 7.1, the response shall meet
the format defined in Table 114.

Table 114 : Positive Response Message Definition - ECU Passive Mode

Message Data
Data byte no. Parameter name
Usage value

1 ECU Passive Mode Positive Response Service Id M E0


2 Control Type M 00-FF

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 121

Table 115 : Negative Response Message Definition - ECU Passive Mode

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

8.23 LinkControl - Service Identifier [87 hex]


The LinkControl service is used to control the communication link baud rate between an external
Test tool and the ECU(s) for the exchange of diagnostic data.

8.23.1 Request and Response Parameter Description

Table 116 defines the possible request and response parameters

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 122

Table 116 Parameter Definition

Parameter Type Description


Link Control Type The sub-function parameter linkControlType is used by the LinkControl request message to describe the action to be
(Request) performed in the server.
verifyBaudrateTransitionWithFixedBaudrate: This parameter is used to verify if a transition to a predefined baud
rate, which is specified by the baudrateIdentifier data parameter, can
be performed.
verifyBaudrateTransitionWithSpecificBaudrate: This parameter is used to verify if a transition to a specifically
defined baud rate, which is specified by the linkBaudrateRecord
data parameter, can be performed.
transitionBaudrate: This sub-function parameter requests the server(s) to transition the
baud rate to the one that was specified in the preceding verification
message.
baudrateIdentifier This conditional parameter references a fixed defined baud rate to transition to (see annex B.3).

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)

8.23.2 Behavior Requirements

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.

Any baud rate transition shall occur as follows:

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 123

UDS 1339: • suppressPosRspMsgIndicationBit = TRUE: after the successful


transmission/reception of the external Test tool request message, which requests the baud rate
transition.

UDS 1340: • suppressPosRspMsgIndicationBit = FALSE: after the successful


transmission/reception of the ECUs positive response message, which confirms the successful
reception of the request, which requests the baud rate transition.

NOTE: This service is tied to a non-defaultSession.

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

8.23.3 Protocol Requirements

UDS 1353: The ECU shall meet the request and response message behavior as specified in
section 7.1.

8.23.3.1 Diagnostic Request

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 124

8.23.3.1.1 Diagnostic Request (linkControlType = verifyBaudrateTransitionWithFixed


Baudrate)

UDS 1357: The Link Control request message (linkControlType =


verifyBaudrateTransitionWithFixedBaudrate) shall follow the format defined in Table 117.

Table 117 : Request Message Definition - Link Control (linkControlType =


verifyBaudrateTransitionWithFixedBaudrate)

Message
Data byte no. Parameter name Data value
Usage

1 Link Control Request Service Id M 87

2 Sub Function = [Link Control Type] M 00-FF

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.

8.23.3.1.2 Diagnostic Request (linkControlType = verifyBaudrateTransitionWithSpecificBau-


drate)

UDS 1360: The Link Control request message (linkControlType =


verifyBaudrateTransitionWithFixedBaudrate) shall follow the format defined in Table 118.

Table 118 : Request Message Definition - Link Control (linkControlType =


verifyBaudrateTransitionWithSpecificBaudrate)

Message
Data byte no. Parameter name Data value
Usage

1 Link Control Request Service Id M 87

2 Sub Function = [Link Control Type] M 00-FF


verifyBaudrateTransitionWithSpecificBaudrate – Positive Response Required 02
linkBaudrateRecord[] = [
3 C2
baudrateHighByte
4 C2 E0-FE
baudrateMiddleByte
5 C2
baudrateLowByte ]

C2: This parameter is present if the sub-function parameter indicates that a verification of a specific
baud rate (verifyBaudrateTransitionWithSpecificBaudrate) is done.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 125

8.23.3.1.3 Diagnostic Request (linkControlType = TransitionBaudrate)

UDS 1363: The Link Control request message (linkControlType = TransitionBaudrate) shall follow
the format defined in Table 119.

Table 119 : Request Message Definition - Link Control (linkControlType =


TransitionBaudrate)

Message
Data byte no. Parameter name Data value
Usage

1 Link Control Request Service Id M 87

2 Sub Function = [Link Control Type] M 00-FF


TransitionBaudrate – Positive Response Required 03
TransitionBaudrate – No Positive Response Required 83

8.23.3.2 Diagnostic Response

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

Table 120: Positive response message definition - Link Control

Message
Data byte no. Parameter name Data value
Usage

1 Link Control Response Service Id M C7

2 Link Control Type M 00-7F

UDS 1373: The negative response to a Link Control service request shall follow the format defined
in Table 121

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 126

Table 121 : Negative Response Message Definition - Link Control

Message
Data byte no. Parameter name Data value
Usage

1 Negative Response Service ID M 7F


2 Link Control M 87

3 Sub Function = [Negative Response Trouble Code] M 00-FF


SubFunctionNotSupported 12
Incorrect Message Length – Invalid Format 13
Conditions Not Correct 22

RequestSequence 24

Request Out Of Range 31

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 127

9 Negative Response Codes


Table 122 defines all the negative response codes used within this document. Each diagnostic
service specifies the minimum set of negative response codes required to be supported but the
diagnostic service implementation in the ECU may also utilize additional and applicable negative
response codes specified in this chapter.

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.

Table 122 : Definition of Negative Response Code Values

HexValue Table of Negative Response Code Values


01 - 0F ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition
10 General Reject
This response code indicates that the requested action has been rejected by the ECU.
The General Reject response code shall only be implemented in the ECU if none of the negative
response codes defined in this document meet the needs of the implementation. This response
code shall not be used as a general replacement for the response codes defined in this docu-
ment.
11 Sevice Not Supported
This response code indicates that the requested action will not be taken because the ECU does
not support the requested service.
The ECU shall send this response code in case the external test tool has sent a request message
with a service identifier, which is either unknown or not supported by the ECU. Therefore this
negative response code is not shown in the list of negative response codes to be supported for a
diagnostic service, because this negative response code is not applicable for supported services.
12 Sub Function Not Supported
This response code indicates that the requested action will not be taken because the ECU does
not support the service specific parameters of the request message.
The ECU shall send this response code in case the external test tool has sent a request message
with a known and supported service identifier but with "sub function“ which are either unknown
or not supported
13 Incorrect Message Length Or Invalid Format
This response code indicates that the requested action will not be taken because the length of
the received request message does not match the prescribed length for the specified service or
the format of the parameters do not match the prescribed format for the specified service.
14 Response Too Long
This response code shall be reported by the ECU if the response to be generated exceeds the
maximum number of bytes available by the underlying network layer.
EXAMPLE: This problem may occur when several DIDs at a time are requested and the combina-
Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 128

HexValue Table of Negative Response Code Values


tion of all DIDs in the response exceeds the limit of the underlying transport protocol.
15-20 ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition
21 Busy Repeat Request
This response code indicates that the ECU is temporarily too busy to perform the requested op-
eration. In this circumstance the external test tool shall perform repetition of the "identical re-
quest message" or "another request message". The repetition of the request shall be delayed by a
defined amount of time.
If the ECU is able to perform the diagnostic task but needs additional time to finish the task and
prepare the response, the NRC [78 hex] shall be used instead of NRC [21 hex].

This response code is in general supported by each diagnostic service.

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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 129

HexValue Table of Negative Response Code Values


This value is reserved by ISO/SAE for future definition.
33 Security Access Denied
This response code indicates that the requested action will not be taken because the ECU's secu-
rity strategy has not been satisfied by the external test tool.
The ECU shall send this response code if one of the following cases occur:
- The test conditions of the ECU are not met,
- The external test tool has sent a request message which requires an unlocked ECU.

Beside the mandatory use of this negative response code as specified in the applicable services
within this standard, this negative response code can also be used for any case where security is
required and is not yet granted to perform the required service.
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

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 130

HexValue Table of Negative Response Code Values


This response code shall only be used in a negative response message if the ECU will not be able
to receive further request messages from the external test tool while completing the requested
diagnostic service.
This response code is supported by each diagnostic service; therefore it is not listed in the list of
applicable response codes of the diagnostic services.
79-7D ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition.
7E Sub Function Not Supported In Active Session
This response code indicates that the requested action will not be taken because the ECU does
not support the requested sub-function in the session currently active.
This response code is supported by each diagnostic service with a sub-function parameter, as not
otherwise stated in the data link specific implementation document; therefore it is not listed in
the list of applicable response codes of the diagnostic services.
7F Service Not Supported In Active Session
This response code indicates that the requested action will not be taken because the ECU does
not support the requested service in the session currently active.
This response code is by each diagnostic service; therefore it is not listed in the list of applicable
response codes of the diagnostic services.
80 ISO/SAE Reserved
This value is reserved by ISO/SAE for future definition.
81 RPM Too High
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for RPM is not met (current RPM is above a pre-programmed maximum
threshold).
82 RPM Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for RPM is not met (current RPM is below a pre-programmed minimum
threshold).
83 Engine Is Running
This response code is required for those actuator tests, which cannot be actuated while the En-
gine is running.
84 Engine Is Not Running
This response code is required for those actuator tests, which cannot be actuated unless the
Engine is running. This is different from RPM too low negative response, and needs to be allowed.
85 Engine Run Time Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for engine run time is not met (current engine run time is below a pre-
programmed limit).
86 Temperature Too High
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for temperature is not met (current temperature is above a pre-programmed
maximum threshold).
87 Temperature Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for temperature is not met (current temperature is below a pre-programmed
minimum threshold).
88 Vehicle Speed Too High
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for vehicle speed is not met (current VS is above a pre-programmed maximum
threshold).
89 Vehicle Speed Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for vehicle speed is not met (current VS is below a pre-programmed minimum
threshold).
8A Throttle/Pedal Too High
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for throttle/pedal position is not met (current TP/APP is above a pre-
programmed maximum threshold).
8B Throttle/Pedal Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for throttle/pedal position is not met (current TP/APP is below a pre-
Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 131

HexValue Table of Negative Response Code Values


programmed minimum threshold).
8C Transmission Range Not In Neutral
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for being in neutral is not met (current transmission range is not in neutral).
8D Transmission Range Not In Gear
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for being in gear is not met (current transmission range is not in gear).
8F Brake Switch(es) Not Closed (Brake Pedal not pressed or not applied)
For safety reasons, this is required for certain tests before it begins, and must be maintained for
the entire duration of the test.
90 Shifter Lever Not In Park
For safety reasons, this is required for certain tests before it begins, and must be maintained for
the entire duration of the test.
91 Torque Converter Clutch Locked
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for torque converter clutch is not met (current TCC status above a pre-
programmed limit or locked).
92 Voltage Too High
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for voltage at the primary pin of the ECU (ECU) is not met (current voltage is
above a pre-programmed maximum threshold).
93 Voltage Too Low
This response code indicates that the requested action will not be taken because the ECU pre-
requisite condition for voltage at the primary pin of the ECU (ECU) is not met (current voltage is
below a pre-programmed maximum threshold).
94-FE Reserved For Specific Conditions Not Correct
This range of values is reserved by ISO/SAE for future definition.
FF ISO/SAE Reserved
This range of values is reserved by ISO/SAE for future definition.

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 132

Evaluation Start

* Only if ECU implements multi-channel transport protocol


and is already processing a request from a different client
Yes
Server busy * ?

No

Requested SID
No
supported ?

Yes

SID No
supported in active
Session ?

Yes

Min Service No
Length Check
Correct ?

Yes

Service uses Yes


Sub-Function ?

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“

* Possible Parameters are:


Service 19: Group of DTC, DTC Status Mask, DTC Mask Record, DTC Extended Data Record
A B
Number, DTC Snapshot Record Number, DTC Severity Mask Record
Service 23: Address and Length Format Identifier, Memory Address, Memory Size
Service 28: Communication Type
Service 2C: Position in Source Data Record, Memory Size, Memory Address
Service 2E: Data Record
Service 2F: IO-Control Type, Control Option Record, Control Enable Mask Record
Service 31: Routine Control Option Record
Service 3D: Address and Length Format Identifier, Memory Address, Memory Size, Data Record

Figure 4a: Positive and Negative Response Message Determination

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 133

B A

Security No
Condition
Correct ?

Yes

Sequence No
Correct ?

Yes

Positive No Extend Yes


Response P2 timing
ready ? window ?

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

Figure 4b: Positive and Negative Response Message Determination

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 134

End of Main Document


#####

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 135

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

SID Sub Type Description BU BU BU


(hex) Func- Use Use Use
tion MBC Trucks VAN
(hex)
10 -- -- Diagnostic Session Control n/a n/a n/a
10 01 -- Default Session - Positive Response Required R R R
10 02 -- Programming Session - Positive Response Required C3 C3 C3
10 03 -- Extended Diagnostic Session - Positive Response Re- R R R
quired
10 04 -- Safety System Diagnostic Session - Positive Response C4 C4 C4
Required
10 49 -- Stand By Session - Positive Response Required C5 C5 O
10 40-48 -- Manufacturer Specific - Positive Response Required O O O
10 60-68 -- Supplier Specific - Positive Response Required O O O
10 81 -- Default Session - No Positive Response Required R R R
10 82 -- Programming Session - No Positive Response Required C3 C3 C3
10 83 -- Extended Diagnostic Session - No Positive Response Re- R R R
quired
10 84 -- Safety System Diagnostic Session - No Positive Response C4 C4 C4
Required
10 C9 -- Stand By Session - No Positive Response Required C5 C5 O
10 C0-C8 -- Manufacturer Specific - No Positive Response Required O O O
10 E0-E8 -- Supplier Specific - No Positive Response Required O O O
11 -- -- ECU Reset n/a n/a n/a
11 01 Hard Reset - Positive Response Required R R O
11 03 Soft Reset - Positive Response Required O O O
11 60-7E Supplier Specific - Positive Response Required O O O
11 81 Hard Reset - No Positive Response Required R R O
11 83 Soft Reset - No Positive Response Required O O O
11 E0-FE -- Supplier Specific - No Positive Response Required O O O

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 136

SID Sub Type Description BU BU BU


(hex) Func- Use Use Use
tion MBC Trucks VAN
(hex)
14 -- -- Clear Diagnostic Information n/a n/a n/a

14 FFFFFF -- All Groups/All DTCs R R R


14 000100- -- Individual DTC Number R R R
FFFFFE
14 000000- -- Reserved by ISO/SAE for future legislative requirements. n/a n/a n/a
0000FF
19 -- -- Read DTC Information n/a n/a n/a
19 01 -- Report Number Of DTC By Status Mask R R R
19 02 -- Report DTC By Status Mask R R R
19 04 -- Report DTC Snapshot Record By DTC Number C2 C2 C2
19 05 -- Report DTC Snapshot Record By Record Number C2 C2 C2
19 06 -- Report DTC Extended Data By DTC Number R R R
19 0A -- Report Supported DTCs R R R
19 0F -- Report Mirror Memory DTC By Status Mask O R O
19 10 -- Report Mirror Memory DTC Extended Data By DTC Num- O R O
ber
19 11 -- Report Number Of Mirror Memory DTC By Status Mask O R O
19 14 -- Report DTC Fault Detection Counter O1 O1 O1
19 15 -- Report DTC With Permanent Status C2 C2 C2
22 -- -- Read Data by Identifier R R R
23 -- -- Read Memory by Address O O O
27 -- -- Security Access C7 C7 C7
28 -- Comm Communication Control n/a n/a n/a
Type
28 00 x1 Enable Rx And Tx - Positive Response Required R R R
- Normal Communication Messages
28 01 x1 Enable Rx And Disable Tx - Positive Response Required R R R
- Normal Communication Messages
28 80 x1 Enable Rx And Tx - No Positive Response Required R R R
- Normal Communication Messages
28 81 x1 Enable Rx And Disable Tx - No Positive Response Re- R R R
quired
- Normal Communication Messages
2C -- -- Dynamically Define Data Identifier O O O
2C 01 -- Define by Identifier C9 C9 O
2C 02 -- Define by Address C9 C9 O
2C 03 -- Clear Dynamic Identifier C15 C15 O
2E -- -- Write Data By Identifier R R R
2F -- Con- Input/Output Control by Identifier n/a n/a n/a
trol
Type
2F -- 00 Return Control to ECU C8 C8 C8
2F -- 01 Reset to Default O O O
2F -- 02 Freeze Current State O O O
2F -- 03 Short Term Adjustment C8 C8 C8

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 137

SID Sub Type Description BU BU BU


(hex) Func- Use Use Use
tion MBC Trucks VAN
(hex)
31 -- -- Routine Control n/a n/a n/a
31 01 -- Start Routine - Positive Response Required C16 C16 C16
31 02 -- Stop Routine - Positive Response Required C10 C10 C10
31 03 -- Request Routine Results C10 C10 C10
31 81 -- Start Routine - No Positive Response RequiredStop Rou- C16 C16 C16
tine - No Positive Response Required
31 82 -- Stop Routine - No Positive Response Required C10 C10 C10
34 -- -- Request Download C3 C3 C3
35 -- -- Request Upload C11 C11 C11
36 -- -- Transfer Data C12 C12 C12
37 -- -- Request Transfer Exit C12 C12 C12
3D -- -- Write Memory by Address O O O
3E -- -- Tester Present n/a n/a n/a
3E 00 - Positive Response Required R R R
3E 80 - No Positive Response Required R R R
85 -- -- Control DTC Setting n/a n/a n/a
85 01 -- On - Positive Response Required R R R
85 02 -- Off - Positive Response Required R R R
85 60-7E -- Supplier Specific - Positive Response Required O O O
85 81 -- On - No Positive Response Required R R R
85 82 -- Off - No Positive Response Required R R R
85 E0-FE -- Supplier Specific - No Positive Response Required O O O
87 -- -- Link Control n/a n/a n/a

87 01 -- verifyBaudrateTransitionWithFixedBaudrate - Positive O n/a n/a


Response Required
87 02 -- verifyBaudrateTransitionWithSpecificBaudrate - Positive O n/a n/a
Response Required
87 83 -- TransitionBaudrate - Positive Response Required O n/a n/a

A0 -- -- ECU Passive Mode n/a n/a n/a


A0 01 -- Enable Passive Mode - Positive Response Required R O R
A0 02 -- Disable Passive Mode - Positive Response Required R O R
A0 81 -- Enable Passive Mode - No Positive Response Required R O R
A0 82 -- Disable Passive Mode - No Positive Response Required R O R

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 138

Table 124: Diagnostic services and sub-functions Support Conditions

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.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)


MBN 10747: 2013-02, page 139

Annex B (informative)
List of Changes

Jira Issue Change Log Description Author


159 Replaced UDS-708 with "When disabling of communication on an individual subnet is RP
required, the subnet number shall be encoded as described in Table 64."

160 Removed UDS-346 (already included in MBN 10746) RP

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

163 Removed restriction to development phase for ECU Passive Mode: RP


The execution of the manufacturer specific service ECU Passive Mode shall only be al-
lowed after a successful security access sequence with Security Access Type [01 hex] -
Protected Engineering Access.

Copyright Daimler AG 2013

Uncontrolled copy when printed (: Kilian Deffner, 2013-04-02)

Potrebbero piacerti anche