Foreword
 
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
 
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
 
The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
 
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
 
ISO 14229 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment.
 
This second edition of ISO 14229 cancels and replaces the first edition (ISO 14229:1998), which has been technically revised.
 
Introduction
 
ISO 14229 has been established in order to define common requirements for diagnostic systems, whatever the serial data link is.
 
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU, server) are broken into:
 


unified diagnostic services (layer 7); and
 


communication services (layers 1 to 6).
 
NOTE The diagnostic services in ISO 14229 are implemented in various applications, e.g. ISO 16844 (all parts), ISO 11992 (all parts), ISO 9141 (all parts), ISO 14230 (all parts), etc. Future modifications to this International Standard will provide long-term backward compatibility with the implementation standards as described above.
 
Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers
 




Applicability


OSI layer


Enhanced diagnostics services (non-emissions-related)




 
Seven layers according to ISO/IEC 7498-1
and ISO/IEC 10731


Application (layer 7)


ISO 14229/ISO 15765-3/ISO 11992-4


ISO 14229/further standards




Presentation (layer 6)


—


—




Session (layer 5)


ISO 15765-3/ISO 11992-4


further standards




Transport (layer 4)


ISO 15765-2/ISO 11992-4


further standards




Network (layer 3)


ISO 15765-2/ISO 11992-4


further standards




Data link (layer 2)


ISO 11898/ISO 11992-1/SAE J1939-15


further standards




Physical (layer 1)


ISO 11898/ISO 11992-1/SAE J1939-15


further standards




 
 
Figure 1 shows an example of the possible future implementation of ISO 14229 onto various data links.
 
  
Figure 1 — Available International Standards and possible future implementations of ISO 14229
 
 
Road vehicles — Unified diagnostic services (UDS) — Specification and requirements
 


Scope
 
ISO 14229 specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (server) such as an electronic fuel injection, automatic gear box, anti-lock braking system, etc. connected on a serial data link embedded in a road vehicle. It specifies generic services which allow the diagnostic tester (client) to stop or to resume non- diagnostic message transmission on the data link. ISO 14229 does not apply to non-diagnostic message transmission or to use of the communication data link between two Electronic Control Units. It does not specify any implementation requirements.
 
The vehicle diagnostic architecture of ISO 14229 applies to:
 



a single tester (client) that may be temporarily or permanently connected to the on-vehicle diagnostic data link; and
 


several on-vehicle Electronic Control Units (servers) connected directly or indirectly.
  
 
Figure 2 — Vehicle diagnostic architecture
In Figure 2:
 


For vehicle 1, the servers are connected over an internal data link and indirectly connected to the diagnostic data link through a gateway. ISO 14229 applies to the diagnostic communications over the diagnostic data link; the diagnostic communications over the internal data link may conform to ISO 14229 or to another protocol.
 


For vehicle 2, the servers are directly connected to the diagnostic data link.
 


For vehicle 3, the servers are directly connected to the diagnostic data link through a gateway (same as vehicle 2) and vehicle 4 connects its server/gateway directly to the vehicle 3 server/gateway.
 


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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
 
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
 
ISO 11898 (all parts), Road vehicles — Controller area network (CAN)
 
ISO 11992-1, Road vehicles — Interchange of digital information on electrical connections between towing and towed vehicles — Part 1: Physical and data-link layers
 
ISO 11992-4, Road vehicles — Interchange of digital information on electrical connections between towing and towed vehicles — Part 4: Diagnostics
 
ISO 14230 (all parts), Road vehicles — Diagnostic systems — Keyword Protocol 2000
 
ISO 15765-2, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2: Network layer services
 
ISO 15765-3, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 3: Implementation of unified diagnostic services (UDS on CAN)
 
ISO/TR 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions- related diagnostics — Part 2: Terms, definitions, abbreviations and acronyms
 
ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services
 
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 6: Diagnostic trouble code definitions
 
ISO 15031-7, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 7: Data link security
 
ISO 15764, Road vehicles — Extended data link security


Terms and definitions
 
For the purposes of this document, the following terms and definitions apply.
 
3.1
integer type
simple type with distinguished values which are the positive and the negative whole numbers
 
NOTE The range of integer type is not specified within this document.
 
3.2
diagnostic trouble code
numerical common identifier for a fault condition identified by the on-board diagnostic system
 
3.3
diagnostic service
information exchange initiated by a client in order to require diagnostic information from a server and/or to modify its behaviour for diagnostic purposes
 
3.4
client
function that is part of the tester and that makes use of the diagnostic services
 
NOTE A tester normally makes use of other functions such as database management, specific interpretation, human- machine interface.
 
3.5
server
function that is part of an electronic control unit and that provides the diagnostic services
 
NOTE ISO 14229 differentiates between the server (i.e. the function) and the electronic control unit so that this International Standard remains independent from the implementation.
 
3.6
tester
system that controls functions such as test, inspection, monitoring or diagnosis of an on-vehicle electronic control unit and which may be dedicated to a specific type of operator (e.g. a scan tool dedicated to garage mechanics or a test tool dedicated to assembly plant agents)
 
NOTE The tester is also referenced as the client.
 
3.7
diagnostic data
data that is located in the memory of an electronic control unit which may be inspected and/or possibly modified by the tester (diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate values and various status information)
 
EXAMPLES Examples of diagnostic data include vehicle speed, throttle angle, mirror position, system status, etc. Three types of values are defined for diagnostic data:
 



the current value: the value currently used by (or resulting from) the normal operation of the electronic control unit;
 


a stored value: an internal copy of the current value made at specific moments, e.g. when a malfunction occurs or periodically (this copy is made under the control of the electronic control unit);
 


a static value: e.g. VIN; the server is not obliged to keep internal copies of its data for diagnostic purposes, in which case the tester may only request the current value.
3.8
diagnostic session
current mode of the server, which affects the level of diagnostic functionality
 
NOTE Defining a repair shop or development testing session selects different server functionality (e.g. access to all memory locations may only be allowed in the development testing session).
 
3.9
diagnostic routine
routine that is embedded in an electronic control unit and that may be started by a server upon a request from the client
 
NOTE It could either run instead of a normal operating program or run concurrently to the normal operating program. In the first case, normal operation of the ECU is not possible. In the second case, multiple diagnostic routines may be enabled that run while all other parts of the electronic control unit are functioning normally.
 
3.10
record
one or more diagnostic data elements that are referred to together by a single means of identification
 
NOTE A snapshot including various input/output data and trouble codes is an example of a record.
 
3.11
security
as used in ISO 14229, security access method that satisfies the requirements for tamper protection as specified in ISO 15031-7
 
3.12
functional unit
set of functionally close or complementary diagnostic services
 
3.13
local server
server that is connected to the same local network as the client and is part of the same address space as the client
 
3.14
local client
client that is connected to the same local network as the server and is part of the same address space as the server
 
3.15
remote server
server that is not directly connected to the main diagnostic network
 
NOTE 1 A remote server is identified by means of a remote network address. Remote network addresses represent an own network address space that is independent from the addresses on the main network.
 
NOTE 2 A remote server is reached via a local server on the main network. Each local server on the main network can act as a gate to one independent set of remote servers. A pair of addresses will therefore always identify a remote server: a local address that identifies the gate to the remote network and a remote address identifying the remote server itself.
 
3.16
remote client
client that is not directly connected to the main diagnostic network
 
NOTE A remote client is identified by means of a remote network address. Remote network addresses represent an own address space that is independent from the addresses on the main network.
3.17
permanent DTC
stored in NVRAM and not erasable by any test equipment command or by disconnecting power to the on-board computer
 


Symbols and abbreviated terms
 
A_PCI Application layer Protocol Control Information A_PDU Application layer Protocol Data Unit
A_SDU Application layer Service Data Unit ECU Electronic Control Unit
NOTE An ECU contains at least one server. Systems considered as Electronic Control Units include anti-lock braking system (ABS), engine management system, etc.
 
NR_SI Negative Response Service Identifier OBD On-Board Diagnostic
OSI Open Systems Interconnection
 
RA Remote Address
 
SA Source Address
 
SI Service Identifier
 
TA Target Address TA_type Target Address type
 


Conventions
 
ISO 14229 is guided by the conventions discussed in the OSI Service Conventions (ISO 10731) as they apply to diagnostic services. These conventions specify the interactions between the service user and the service provider. Information is passed between the service user and the service provider by service primitives, which may convey parameters.
 
The distinction between service and protocol is summarized in Figure 3. ISO 14229 defines both, confirmed and unconfirmed services.



Confirmed services use the six (6) service primitives, request, req_confirm, indication, response, rsp_confirm and confirmation.
 


Unconfirmed services use only the request, req_confirm and indication service primitives.
 
For all services defined in ISO 14229, the request and indication service primitives always have the same format and parameters. Consequently, for all services the response and confirmation service primitives (except req_confirm and rsp_confirm) always have the same format and parameters. When the service primitives are defined in this International Standard, only the request and response service primitives are listed.
 
 
Figure 3 — The services and the protocol
 


Application layer services
 


General
 
Application layer services are usually referred to as diagnostic services. The application layer services are used in client-server-based systems to perform functions such as test, inspection, monitoring or diagnosis of on-board vehicle servers. The client, usually referred to as an External Test Equipment, uses the application layer services to request diagnostic functions to be performed in one or more servers. The server, usually a function that is part of an ECU, uses the application layer services to send response data, provided by the requested diagnostic service, back to the client. The client is usually an off-board tester but can, in some systems, also be an on-board tester. The usage of application layer services is independent from the client being an off-board or on-board tester. It is possible to have more than one client in the same vehicle system.
 
The service access point of the diagnostics application layer provides a number of services that all have the same general structure. For each service, six (6) service primitives are specified:
 




a service request primitive, used by the client function in the diagnostic tester application to pass data about a requested diagnostic service to the diagnostics application layer;
 


a service request-confirmation primitive, used by the client function in the diagnostic tester application to indicate that the data passed in the service request primitive is completely transferred to the server;
 


a service indication primitive, used by the diagnostics application layer to pass data to the server function of the ECU diagnostic application;
 


a service response primitive, used by the server function in the ECU diagnostic application to pass response data provided by the requested diagnostic service to the diagnostics application layer;


a service response-confirmation primitive, used by the server function in the ECU diagnostic application to indicate that the data passed in the service response primitive is completely transferred to the client;
 



a service confirmation primitive, used by the diagnostics application layer to pass data to the client function in the diagnostic tester application.
 
 
Figure 4 — Application layer service primitives — confirmed service
 

 
Figure 5 — Application layer service primitives — unconfirmed service
 
For a given service, the request primitive and the indication primitive always have the same service data unit. ISO 14229 will only list and specify the parameters of the service data unit belonging to each service request primitive. The user shall assume exactly the same parameters for each corresponding service indication primitive.
 
For a given service, the response primitive and the confirmation primitive always have the same service data unit. ISO 14229 only lists and specifies the parameters of the service data unit belonging to each service response primitive. The user shall assume exactly the same parameters for each corresponding service confirmation primitive.
For each service response primitive (and corresponding service confirmation primitive), two different service data units (two sets of parameters) will be specified. One set of parameters shall be used in a positive service response primitive if the requested diagnostic service can be successfully performed by the server function in the ECU diagnostic application. The other set of parameters (the negative response service data unit) shall be used if the requested diagnostic service fails or cannot be completed in time by the server function in the ECU diagnostic application.
 
For a given service, the request-confirmation primitive and the response-confirmation primitive always have the same service data unit. The purpose of these service primitives is to indicate the completion of an earlier request or response service primitive invocation. The service descriptions in ISO 14229 do not make use of those service primitives, but the data link specific implementation documents might use them to define e.g. service execution reference points (e.g. the ECUReset service would reset the ECU after the response has been completely transmitted to the client, which is indicated in the server by the service response-confirm primitive).
 


Format description of application layer services
 
Application layer services can have two different formats depending on how the vehicle diagnostic system is configured.
 
If the vehicle system is configured as a single (one logical) diagnostic network where all clients and servers are connected directly, then the default (also called normal or standard) format of application layer services shall be used. This format is compatible with the diagnostic system formats used on data links such as K- and L-lines. The default application layer services format is specified in 6.3.
 
The remote format of application layer services shall be used in vehicle systems implementing the concept of local servers and remote servers. The remote format has one additional address parameter called remote address. The remote format is used to access servers that are not directly connected to the main diagnostic network in the vehicle. The remote format for application layer services is specified in 6.4.
 


Format description of standard service primitives
 


General definition
 
All application layer services have the same general format. Service primitives are written in the form:
 
service_name.type (
parameter A, parameter B, parameter C
,parameter 1, ...
)
 
where:
 




“service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl);
 


“type” indicates the type of the service primitive (e.g. request);
 


“parameter A, ...” is the A_SDU as a list of values passed by the service primitive (addressing information);
 


“parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service calls;
 


“,parameter 1, ...” are parameters that depend on the specific service (e.g. parameter 1 can be the diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the parameter list may be empty.


Service request and service indication primitives
 
For each application layer service, service request and service indication primitives are specified according to the following general format:
 
service_name.request (
SA,
TA,
TA_type
,parameter 1, ...
)
 
The request primitive is used by the client function in the diagnostic tester application to initiate the service and pass data about the requested diagnostic service to the application layer.
 
service_name.indication (
SA,
TA,
TA_type
,parameter 1, ...
)
 
The indication primitive is used by the application layer to indicate an internal event which is significant to the ECU diagnostic application and to pass data about the requested diagnostic service to the server function of the ECU diagnostic application.
 
The request and indication primitives of a specific application layer service always have the same parameters and parameter values. This means that the values of individual parameters shall not be changed by the communicating peer protocol entities of the application layer when the data is transmitted from the client to the server. The same values that are passed by the client function in the client application to the application layer in the service request call shall be received by the server function of the diagnostic application from the service indication of the peer application layer.
 


Service response and service confirm primitives
 
For each confirmed application layer service, service response and service confirm primitives are specified according to the following general format:
 
service_name.response (
SA,
TA,
TA_type, Result
,parameter 1, ...
)
 
The response primitive is used by the server function in the ECU diagnostic application, to initiate the service and pass response data provided by the requested diagnostic service to the application layer.
 
service_name.confirm (
SA,
TA,
TA_type, Result
,parameter 1, ...
)
The confirm primitive is used by the application layer to indicate an internal event which is significant to the client application and to pass results of an associated previous service request to the client function in the diagnostic tester application. It does not necessarily indicate any activity at the remote peer interface, e.g. if the requested service is not supported by the server or if the communication is broken.
 
The response and confirm primitives of a specific application layer service always have the same parameters and parameter values. This means that the values of individual parameters shall not be changed by the communicating peer protocol entities of the application layer when the data is transmitted from the server to the client. The same values that are passed by the server function of the ECU diagnostic application to the application layer in the service response call shall be received by the client function in the diagnostic tester application from the service confirmation of the peer application layer.
 
For each response and confirm primitive two different service data units (two sets of parameters) will be specified.
 



A positive response and positive confirm primitive shall be used with the first service data unit if the requested diagnostic service could be successfully performed by the server function in the ECU.
 


A negative response and confirm primitive shall be used with the second service data unit if the requested diagnostic service failed or could not be completed in time by the server function in the ECU.
 


Service request-confirm and service response-confirm primitives


 
For each application layer service, service request-confirm and service response-confirm primitives are specified according to the following general format:
 
service_name.req_confirm(
SA,
TA,
TA_type, Result
)
 
The request-confirm primitive is used by the application layer to indicate an internal event, which is significant to the client application, and pass results of an associated previous service request to the client function in the diagnostic tester application.
 
service_name.rsp_confirm(
SA,
TA,
TA_type, Result
)
 
The response-confirm primitive is used by the application layer to indicate an internal event, which is significant to the server application, and pass results of an associated previous service response to the server function in the ECU application.
 


Format description of remote service primitives
 


General definition
 
Diagnostic communication between a local client and a remote server can take place if the remote format of application layer services is used. All definitions made for the default format of application layer services shall be applicable also for the remote format of application layer services with the addition of one more addressing parameter.
Diagnostic communication can take place between a local client on the main network and one or more remote servers on a remote network. Communication can also take place between a remote client on a remote network and one or more local servers on the main network.
 
Diagnostic communication cannot take place between any combination of clients and servers on two different remote networks.
 
All remote format application layer services have the same general format. Service primitives are written in the form:
 
service_name.type (
parameter A, parameter B, parameter C, parameter D
,parameter 1, ...
)
 
where:
 




“service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl);
 


“type” indicates the type of the service primitive (e.g. request);
 


“parameter A, ...” is the A_SDU as a list of values passed by the service primitive (addressing information);
 


“parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service calls;
 


“parameter D” is an additional parameter that is only used in vehicles implementing the concept of remote servers (remote address);
 


“,parameter 1, ...” are parameters that depend on the specific service (e.g. parameter 1 can be the diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the parameter list may be empty.
 


Remote service request and service indication primitives
 
For each remote format application layer service, service request and service indication primitives are specified according to the following general format:
 
service_name.request (
SA,
TA,
TA_type [,RA]
,parameter 1, ...
)
 
The request primitive is used by the local client function in the client application, to initiate the service and pass data about the requested diagnostic service to the application layer.
 
service_name.indication (
SA,
TA,
TA_type [,RA]
,parameter 1, ...
)
The indication primitive is used by the remote application layer to indicate an internal event which is significant to the ECU diagnostic application and to pass data about the requested diagnostic service to the remote server function of the ECU diagnostic application.
 
The request and indication primitive of a specific application layer service always have the same parameters and parameter values. This means that the values of individual parameters shall not be changed by the communicating peer protocol entities of the application layer when the data is transmitted from the client to the server. The same values that are passed by the client function in the diagnostic tester application to the application layer in the service request call shall be received by the server function of the ECU application from the service indication of the peer application layer.
 
NOTE For clarity, the text assumes communication between a local client and one or more remote server. The protocol also supports communication between a remote client and one or more local servers using the same remote format application layer services.
 


Remote service response and service confirm primitives
 
For each remote format application layer service, service response and service confirm primitives are specified according to the following general format:
 
service_name.response (
SA,
TA,
TA_type, [RA,]
Result
,parameter 1, ...
)
 
The response primitive is used by the remote server function in the ECU diagnostic application, to initiate the service and pass response data provided by the requested diagnostic service to the application layer.
 
service_name.confirm (
SA,
TA,
TA_type, [RA,]
Result
,parameter 1, ...
)
 
The confirm primitive is used by the local application layer to indicate an internal event which is significant to the client application and to pass results of an associated previous service request to the client function in the ECU application. It does not necessarily indicate any activity at the remote peer interface, e.g. if the requested service is not supported by the server or if the communication is broken.
 
The response and confirm primitive of a specific application layer service always has the same parameters and parameter values. This means that the values of individual parameters shall not be changed by the communicating peer protocol entities of the application layer when the data is transmitted from the server to the client. The same values that are passed by the server function of the ECU diagnostic application to the application layer in the service response call shall be received by the client function in the diagnostic tester application from the service confirmation of the peer application layer.
 
For each response and confirm primitive, two different service data units (two sets of parameters) will be specified.
 



A positive response and positive confirm primitive shall be used with the first service data unit if the requested diagnostic service could be successfully performed by the server function in the ECU.


A negative response and confirm primitive shall be used with the second service data unit if the requested diagnostic service failed or could not be completed in time by the server function in the ECU.
 
NOTE For clarity, the text assumes communication between a local client and one or more remote server. The protocol also supports communication between a remote client and one or more local servers using the same remote format application layer services.
 


Remote service request-confirm and service response-confirm primitives
 
For each application layer service, service request-confirm and service response-confirm primitives are specified according to the following general format:
 
service_name.req_confirm(
SA,
TA,
TA_type, [RA,]
Result
)
 
The request-confirm primitive is used by the client application layer to indicate an internal event which is significant to the client application and to pass results of an associated previous service request to the client function in the ECU application.
 
service_name.rsp_confirm(
SA,
TA, [RA,]
TA_type, Result,
)
 
The response-confirm primitive is used by the server application layer to indicate an internal event which is significant to the server application and to pass results of an associated previous service response to the server function in the ECU application.
 



Service data unit specification
 


Mandatory parameters
 


General definition
 
The application layer services contain three (3) mandatory parameters. The following parameter definitions are applicable to all application layer services specified in this International Standard (standard and remote format).
 


Source address (SA) Type: 1 byte unsigned integer value Range: 00-FF hex
Description:
 
The parameter SA shall be used to encode client and server identifiers, and it shall be used to represent the physical location of a client or server.
For service requests (and service indications), SA represents the client identifier for the client function that has requested the diagnostic service. The client shall always be located in one diagnostic tester only. There shall be a strict, one-to-one relation between client identifiers and source addresses. Each client identifier shall be encoded with one SA value. If more than one client is implemented in the same diagnostic tester, then each client shall have its own client identifier and corresponding SA value.
 
For service responses (and service confirmations), SA represents the physical location of the server that has performed the requested diagnostic service. A server may be implemented in one ECU only or be distributed and implemented in several ECUs. If a server is implemented in one ECU only, then it shall be encoded with one SA value only. If a server is distributed and implemented in several ECUs, then the server identifier shall be encoded with one SA value for each physical location of the server.
 
If a remote client or server is the original source for a message, then SA represents the local server that is the gate from the remote network to the main network.
 
NOTE The SA value in a response message will be the same as the TA value in the corresponding request message if physical addressing was used for the request message.
 


Target address (TA)
 
Type: 1 byte unsigned integer value Range: 00-FF hex
Description:
 
The parameter TA shall be used to encode client and server identifiers.
 
Two different addressing methods, called physical addressing and functional addressing, are specified for diagnostics. Therefore, two independent sets of target addresses can be defined for a vehicle system (one for each addressing method).
 
Physical addressing shall always be a dedicated message to a server implemented in one ECU. When physical addressing is used, the communication is a point-to-point communication between the client and the server.
 
Functional addressing is used by the client if it does not know the physical address of the server that will respond to a service request or if the server is implemented as a distributed server in several ECUs. When functional addressing is used, the communication is a broadcast communication from the client to a server implemented in one or more ECUs.
 
For service requests (and service indications), TA represents the server identifier for the server that will perform the requested diagnostic service. If a remote server is being addressed, then TA represents the local server that is the gate from the main network to the remote network.
 
For service responses (and service confirmations), TA represents the client identifier for the client that originally requested the diagnostic service and will receive the requested data. Service responses (and service confirmations) shall always use physical addressing. If a remote client is being addressed, then TA represents the local server that is the gate from the main network to the remote network.
 
NOTE The TA value of a response message will always be the same as the SA value of the corresponding request message.
 


TA_Type, Target Address type
 
Type: enumeration Range: physical, functional
Description:
 
The parameter TA_type is an extension to the TA parameter. It is used to represent the addressing method chosen for a message transmission.
 


Result Type: enumeration Range: positive, negative Description:
The parameter “Result” is used by the response and confirm primitives to indicate if a message is a positive response/positive confirm message or a negative response/negative confirm message. The service-specific parameters in the message are different depending on the value of the Result parameter.
 



Vehicle system requirements
 
The vehicle manufacturer shall ensure that each server in the system has a unique server identifier. The vehicle manufacturer shall also ensure that each client in the system has a unique client identifier.
 
All client and server identifiers for the main diagnostic network in a vehicle system shall be encoded into the same range of source addresses. This means that a client and a server shall not be represented by the same SA value in a given vehicle system.
 
The physical target address for a server shall always be the same as the source address for the server.
 
Remote server identifiers can be assigned independently from client and server identifiers on the main network.
 
In general only the server(s) addressed shall respond to the client request message.
 


Optional parameters
 


Remote address (RA) Type: 1 byte unsigned integer value Range: 00-FF hex
Description:
 
RA is used to extend the available address range to encode client and server identifiers. RA shall only be used in vehicles that implement the concept of local servers and remote servers. Remote addresses represent their own address range and are independent from the addresses on the main network.
 
The parameter RA shall be used to encode remote client and server identifiers. RA can represent either a remote target address or a remote source address, depending on the direction of the message carrying the RA.
 
For service requests (and service indications) sent by a client on the main network, RA represents the remote server identifier (remote target address) for the server that will perform the requested diagnostic service.
 
RA can be used both as a physical and a functional address. For each value of RA, the system builder shall specify if that value represents a physical or functional address.
NOTE There is no special parameter that represents physical or functional remote addresses in the way TA_type specifies the addressing method for TA. Physical and functional remote addresses share the same 1 byte range of values and the meaning of each value shall be defined by the system builder.
 
For service responses (and service confirmations) sent by a remote server, RA represents the physical location (remote source address) of the remote server that has performed the requested diagnostic service.
 
A remote server may be implemented in one ECU only or be distributed and implemented in several ECUs. If a remote server is implemented in one ECU only, then it shall be encoded with one RA value only. If a remote server is distributed and implemented in several ECUs, then the remote server identifier shall be encoded with one RA value for each physical location of the remote server.
 
For service requests (and service indications) sent by a remote client, RA represents the remote server identifier (remote source address) for the client function that has requested the diagnostic service.
 
For service responses (and service confirmations) sent by a local server, RA represents the remote client identifier (remote target address) for the client that originally requested the diagnostic service and shall receive the requested data.
 


Remote server example with remote network
 
In some systems, the remote server is connected to a remote network separated from the main diagnostic network by a gateway. The following is an example showing how the parameters SA, TA and RA shall be used for proper communication between a local client on the main network and a remote server via a gateway. In the example, it is assumed that the same type of addressing is used on the remote network as on the main network.
 
The external test equipment is connected to the main network and has client identifier 241 (F1 hex). The gateway is connected to both the main network and the remote network. On the main network the gateway has client identifier 200 (C8 hex). On the remote network, the gateway has client identifier 10 (0A hex). The remote server is connected to the remote network and has client identifier 62 (3E hex). The configuration is described in Figure 6.
 
 
Figure 6 — Remote server system example 1
 
The external test equipment sends a remote diagnostic request message with
 
⎯ SA = 241 (F1 hex),
 





TA = 200 (C8 hex), and
 
⎯ RA = 62 (3E hex).
 
The gateway receives the message and sends it out on the remote network with
 
⎯ SA = 10 (0A hex),
 


TA = 62 (3E hex), and
 
⎯ RA = 241 (F1 hex).
 
The remote server receives the message.
The remote server sends back a remote diagnostic response message with
 
⎯ SA = 62 (3E hex),
 


TA = 10 (0A hex), and
 
⎯ RA = 241 (F1 hex).
 
The gateway receives the message and sends it out on the main network with
 
⎯ SA = 200 (C8 hex),
 


TA = 241 (F1 hex), and
 
⎯ RA = 62 (3E hex).
 
The external test equipment receives the message.
 


Remote server example without remote network
 
In some systems, the remote server is a functional part of a server belonging to the main network. The server has been given a remote server identifier in order to extend the available address range to encode client and server identifiers. In such systems the remote server is logically separated from the main network even if the ECU, of which the remote server is a part, is connected to the main diagnostic network. To get a working system, the server must also have a gateway function that is part of the main diagnostic network and can serve as a gate to the remote server. The following is an example showing how the parameters SA, TA and RA are used for proper communication between a local client on the main network and a remote server via a gateway.
 
The external test equipment is connected to the main network and has client identifier 241 (F1 hex). The gateway is connected to the same main network. The gateway has client identifier 200 (C8 hex). The remote server has client identifier 62 (3E hex). The configuration is described in Figure 7.
 
 
Figure 7 — Remote server system example 2
 
The external test equipment sends a remote diagnostic request message with
⎯ SA = 241 (F1 hex),



TA = 200 (C8 hex), and
⎯ RA = 62 (3E hex).
 
The gateway receives the message and passes it over to the remote server function. The remote server receives the message.
The remote server sends back a remote diagnostic response message by passing it to the gateway function. The gateway receives the message and sends it out on the main network with
 
⎯ SA = 200 (C8 hex),
 


TA = 241 (F1 hex), and
 
⎯ RA = 62 (3E hex).
 
The external test equipment receives the message.
 


Remote client example with remote network


 
In some systems, the client is connected to a remote network separated from the main diagnostic network by a gateway. The following is an example showing how the parameters SA, TA and RA are used for proper communication between a remote client on a remote network and a local server on the main network via a gateway. In the example, it is assumed that the same type of addressing is used on the remote network as on the main network.
 
The external test equipment is connected to the remote network and has client identifier 242 (F2 hex). The gateway is connected to both the main network and the remote network. On the main network, the gateway has client identifier 200 (C8 hex). On the remote network, the gateway has client identifier 10 (0A hex). The local server is connected to the main network and has client identifier 18 (12 hex). The configuration is described in Figure 8.
 
 
Figure 8 — Remote client example
 
The external test equipment sends a remote diagnostic request message with
 
⎯ SA = 242 (F1 hex),
 


TA = 10 (0A hex), and
 
⎯ RA = 18 (12 hex).
 
The gateway receives the message and sends it out on the main network with
 


SA = 200 dec,
 


TA = 18 dec, and
 


RA = 242 dec.
 
The local server receives the message.
 
The local server sends back a remote diagnostic response message with
 
⎯ SA = 18 (12 hex),
 


TA = 200 (C8 hex), and
 
⎯ RA = 242 (F1 hex).
The gateway receives the message and sends it out on the remote network with
⎯ SA = 10 (0A hex),


TA = 242 (F1 hex), and
⎯ RA = 18 (12 hex).
The external test equipment receives the message.
 


Application layer protocol
 


General definition
 
The application layer protocol shall always be a confirmed message transmission, meaning that for each service request sent from the client, there shall be one or more corresponding responses sent from the server.
 
The only exception to this rule shall be a few cases when e.g. functional addressing is used or the request/indication specifies that no response/confirmation shall be generated. In order not to burden the system with many unnecessary messages, there are a few cases when negative response messages shall not be sent even if the server failed to complete the requested diagnostic service.
 
The application layer protocol shall be handled in parallel with the session layer protocol. This means that, even if the client is waiting for a response to a previous request, it shall maintain proper session layer timing (e.g. sending a TesterPresent request if that is needed to keep a diagnostic session going in other servers; the implementation depends on the data link layer used).
 


Protocol data unit specification
 
The A_PDU is directly constructed from the A_SDU and the layer-specific control information A_PCI (Application layer Protocol Control Information). The A_PDU shall have the following general format:
 
A_PDU (
SA,
TA,
TA_type, [RA,]
A_Data = A_PCI + parameter 1, ...
)
 
where:
 




“SA, TA, TA_type, RA” are the same parameters as used in the A_SDU;
 


“A_Data” is a string of byte data defined for each individual application layer service. The A_Data string shall start with the A_PCI followed by all service-specific parameters from the A_SDU as specified for each service. The brackets indicate that this part of the parameter list may be empty.
 


Application protocol control information
 
The A_PCI shall have two alternative formats depending on which type of service primitive that has been called and the value of the Result parameter. For all service requests and for service responses/service confirmations with Result = positive, the following definition shall apply:
 
A_PCI (
SI
)
 
where “SI” is the parameter service identifier.
 

 19
For service responses/service confirmations with Result = negative, the following definition shall apply:
 
A_PCI (
NR_SI, SI
)
 
where:
 



“NR_SI” is the special parameter identifying negative service responses/confirmations;
 


“SI” is the parameter service identifier.


 
NOTE For the transmission of periodic messages utilizing response message type #2 as defined in the service ReadDataByPeriodicIdentifier (2A hex, see 10.5) no A_PCI is present in the application layer protocol data unit (A_PDU).
 


Service identifier (SI)
 
Type: 1 byte unsigned integer value
 
Range: 00-FF hex according to definitions in Table 2
 
Table 2 — Service identifier (SI) values
 




Service identifier (hex value)


Service type (bit 6)


 
Where defined




00 – 0F


OBD service requests


ISO 15031-5




10 – 3E


ISO 14229 service requests


ISO 14229




3F


Not applicable


Reserved by document




40 – 4F


OBD service responses


ISO 15031-5




50 – 7E


ISO 14229 positive service responses


ISO 14229




7F


Negative response service identifier


ISO 14229




80


Not applicable


Reserved by ISO 14229




81 – 82


Not applicable


Reserved by ISO 14230




83 – 88


ISO 14229 service requests


ISO 14229




89 – 9F


Service requests


Reserved for future expansion as needed




A0 – B9


Service requests


Defined by vehicle manufacturer




BA – BE


Service requests


Defined by system supplier




BF


Not applicable


Reserved by document




C0


Not applicable


Reserved by ISO 14229




C1 – C2


Not applicable


Reserved by ISO 14230




C3 – C8


ISO 14229 positive service responses


ISO 14229




C9 – DF


Positive service responses


Reserved for future expansion as needed




E0 – F9


Positive service responses


Defined by vehicle manufacturer




FA – FE


Positive service responses


Defined by system supplier




FF


Not applicable


Reserved by document




NOTE There is a one-to-one correspondence between service identifiers for request messages and service identifiers for positive response messages, with bit 6 of the SI hex value indicating the service type. All request messages have SI bit 6 = 0. All positive response messages have SI bit 6 = 1, except response message type #2 of the ReadDataByPeriodicIdentifier (2A hex, see section 10.5) service.
 
Description:
 
The SI shall be used to encode the specific service that has been called in the service primitive. Each request service shall be assigned a unique SI value. Each positive response service shall be assigned a corresponding unique SI value.
 
The service identifier is used to represent the service in the A_Data data string that is passed from the application layer to lower layers (and returned from lower layers).
 


Negative response service identifier (NR_SI)


 
Type: 1 byte unsigned integer value Fixed value: 7F hex
Description:
 
The parameter NR_SI is a special parameter identifying negative service responses/confirmations. It shall be part of the A_PCI for negative response/confirm messages.
 
NOTE The NR_SI value is coordinated with the SI values. The NR_SI value is not used as an SI value in order to make A_Data coding and decoding easier.
 


Negative response/confirmation service primitive
 
Each diagnostic service has a negative response/negative confirmation message specified with message A_Data bytes according to Table 3. The first A_Data byte (A_PCI.NR_SI) is always the specific negative response service identifier. The second A_Data byte (A_PCI.SI) shall be a copy of the service identifier value from the service request/indication message to which the negative response message corresponds.
 
Table 3 — Negative response A_PDU
 




A_PDU parameter


Parameter name


Cvt


Hex value


Mnemonic




SA


Source Address


Ma


xx


SA




TA


Target Address


M


xx


TA




TA_type


Target Address type


M


xx


TA_type




RA


Remote Address (optional)


Cb


xx


RA



 



A_Data.A_PCI.NR_SI


Negative Response Service Id


M


7F


SIDNR




A_Data.A_PCI.SI


Request Service Id


M


xx


SIDRQ




A_Data.Parameter 1


responseCode


M


xx


NRC_



 





M (Mandatory): In case the negative response A_PDU is issued then those A_PDU parameters shall be present.


C (Conditional): The RA (Remote Address) PDU parameter is only present in case of remote addressing.


 
 
NOTE A_Data represents the message data bytes of the negative response message.
 
The parameter responseCode is used in the negative response message to indicate why the diagnostic service failed or could not be completed in time. Values are defined in A.1.


Server response implementation rules
 


General definitions
 
The following subclauses specify the behaviour of the server when executing a service. The server and the client shall follow these implementation rules.
 
Legend for subclauses 7.5.2, 7.5.3 and 7.5.4
 
Abbreviation Description
suppressPosRspMsgIndicationBit TRUE = server shall NOT send a positive response message
FALSE = server shall send a positive or negative response message
PosRsp Abbreviation for positive response message
NegRsp Abbreviation for negative response message
NoRsp Abbreviation for NOT sending a positive or negative response message
NRC Abbreviation for negative response code
ALL All of the requested data parameters (service without sub-function parameter) of the client request message are supported by the server
at least 1 At least 1 data parameter (service without sub-function parameter) of the client request message must be supported by the server
NONE None of the requested data parameters (service without sub-function parameter) of the client request message is supported by the server
 
The server shall support its list of diagnostic services regardless of addressing mode (physical, functional addressing type).
 
IMPORTANT — As required by the tables in the following subclauses, negative response messages with negative response codes of SNS (serviceNotSupported), SFNS (subFunctionNotSupported) and ROOR (requestOutOfRange) shall never be transmitted when functional addressing was used for the request message.
 


Request message with sub-function parameter and server response behaviour
 


Physically addressed client request message
 
The server response behaviour specified in this subclause is referenced in the service description of each service, which supports a sub-function parameter in the physically addressed request message received from the client.
 
Table 4 shows possible communication schemes with physical addressing.
Table 4 — Physically addressed request message with sub-function parameter and server response behaviour
 




 
Server case #


Client request message


Server capability


Server response


 
Comments on server response




 
Addressin g
scheme


subFunction (suppress- PosRspMsg- Indication- Bit)


 
Service ID supported


 
Sub- function supported


Data parameter supported (only if applicable)


 
Message


 
Negative: NRC/
section




 
1


 
physical


 
FALSE
(bit = 0)


 
YES


 
YES


 
At least 1


 
PosRsp


 
—


Server sends positive response




 
2


 
—


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading the data parameters of the request message




 
3


 
NO


 
—


 
—


 
NRC=SNS


Negative response with NRC 11 hex




 
4


 
YES


 
NO


 
—


 
NRC=SFNS


Negative response with NRC 12 hex




 
5


 
TRUE
(bit = 1)


 
YES


 
YES


 
At least 1


 
NoRsp


 
—


Server does NOT send a response




 
6


 
—


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading the data parameters of the request message




 
7


 
NO


 
—


 
—


 
NRC=SNS


Negative response with NRC 11 hex




 
8


 
YES


 
NO


 
—


 
NRC=SFNS


Negative response with NRC 12 hex




 
 
The following is a description of server response cases on physically addressed client request messages with subFunction.
 


Server sends a positive response message because the service identifier and sub-function parameter is supported by the client’s request with indication for a response message.
 


Server sends a negative response message (e.g. IMLOIF: incorrectMessageLengthOrIncorrectFormat) because the service identifier and sub-function parameter of the client's request is supported but some other error appeared (e.g. wrong PDU length according to service identifier and sub-function parameter in the request message) during processing of the sub-function.
 


Server sends a negative response message with the negative response code SNS (service not supported) because the service identifier of the client’s request is not supported with indication for a response message.
 


Server sends a negative response message with the negative response code SFNS (sub-function not supported) because the service identifier is supported and the sub-function parameter of the client's request is not supported with indication for a response message.
 


Server sends no response message because the service identifier and sub-function parameter is supported by the client’s request with indication for no response message. If a negative response code RCRRP (requestCorrectlyReceivedResponsePending) is used, a final response shall be given independent of the suppressPosRspMsgIndicationBit value.


Same effect as in 2) (e.g. a negative response message is sent) because the suppressPosRspMsgIndicationBit is ignored for any negative response that needs to be sent upon receipt of a physically addressed request message.
 


Same effect as in 3) (e.g. the negative response message is sent) because the suppressPosRspMsgIndicationBit is ignored for any negative response that needs to be sent upon receipt of a physically addressed request message.
 


Same effect as in 4) (e.g. the negative response message is sent) because the suppressPosRspMsgIndicationBit is ignored for any negative response that needs to be sent upon receipt of a physically addressed request message.


 


Functionally addressed client request message
 
The server response behaviour specified in this subclause is referenced in the service description of each service which supports a sub-function parameter in the functionally addressed request message received from the client.
 
Table 5 shows possible communication schemes with functional addressing.
 
Table 5 — Functionally addressed request message with sub-function parameter and server response behaviour
 




 
Server case #


Client request message


Server capability


Server response


 
Comments on server response




 
Addressing scheme


subFunction (suppress- PosRspMsg- Indication- Bit)


 
Service ID supported


 
Sub- function supported


Data parameter supported (only if applicable)


 
Message


 
Negative: NRC/
section




1


 
functional


 
FALSE
(bit = 0)


 
YES


 
YES


At least 1


PosRsp


—


Server sends positive response




 
2


 
At least 1


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading the data parameters of the request message




3


None


 
NoRsp


—


Server does NOT send a response




4


NO


—


—


—


Server does NOT send a response




5


YES


NO


—


—


Server does NOT send a response




6


 
TRUE
(bit = 1)


 
YES


 
YES


At least 1


NoRsp


—


Server does NOT send a response




 
7


 
At least 1


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading the data parameters of the request message




8


None


 
NoRsp


—


Server does NOT send a response




9


NO


—


—


—


Server does NOT send a response




10


YES


NO


—


—


Server does NOT send a response




Description of server response cases on functionally addressed client request messages with subFunction:
 


Server sends a positive response message because the service identifier and sub-function parameter is supported by the client's request with indication for a response message.
 


Server sends a negative response message (e.g. IMLOIF: incorrectMessageLengthOrIncorrectFormat) because the service identifier and sub-function parameter is supported by the client's request, but some other error appeared (e.g. wrong PDU length according to service identifier and sub-function parameter in the request message) during processing of the sub-function.
 


Server sends no response message because the negative response code ROOR (requestOutOfRange, which is identified by the server because the service identifier and sub-function parameter are supported but a required data parameter is not supported by the client's request) is always suppressed in case of a functionally addressed request message. The suppressPosRspMsgIndicationBit does not matter in such cases.
 


Server sends no response message because the negative response code SNS (serviceNotSupported, which is identified by the server because the service identifier is not supported by the client's request) is always suppressed in case of a functionally addressed request message. The suppressPosRspMsgIndicationBit does not matter in such cases.
 


Server sends no response message because the negative response code SFNS (subFunctionNotSupported, which is identified by the server because the service identifier is supported and the sub-function parameter is not supported by the client's request) is always suppressed in case of a functionally addressed request. The suppressPosRspMsgIndicationBit does not matter in such cases.
 


Server sends no response message because the service identifier and sub-function parameter is supported by the client's request with indication for no response message.
 
NOTE If a negative response code RCRRP (requestCorrectlyReceivedResponsePending) is used, a final response shall be given independent of the suppressPosRspMsgIndicationBit value.
 


Same effect as in 2) (e.g. a negative response message is sent) because the suppressPosRspMsgIndicationBit is ignored for any negative response. This is also true if the request message is functionally addressed.
 


Same effect as in 3) (e.g. no response message is sent) because the negative response code ROOR (requestOutOfRange, which is identified by the server because the service identifier and sub-function parameter are supported but a required data parameter is not supported by the client's request) is always suppressed in case of a functionally addressed request message. The suppressPosRspMsgIndicationBit does not matter in such a case.
 


Same effect as in 4) (e.g. no response message is sent) because the negative response code SNS (serviceNotSupported, which is identified by the server because the service identifier is not supported by the client's request) is always suppressed in case of a functionally addressed request message. The suppressPosRspMsgIndicationBit does not matter in such a case.
 


Same effect as in 5) (e.g. no response message is sent) because the negative response code SFNS (subFunctionNotSupported, which is identified by the server because the service identifier is supported and the sub-function parameter is not supported by the client's request) is always suppressed in case of a functionally addressed request message. The suppressPosRspMsgIndicationBit does not matter in such a case.




Request message without sub-function parameter and server response behaviour
 


Physically addressed client request message
 
The server response behaviour specified in this subclause is referenced in the service description of each service which does not support a sub-function parameter but a data parameter in the physically addressed request message received from the client.
 
Table 6 shows possible communication schemes with physical addressing.
 
Table 6 — Physically addressed request message without sub-function parameter and server response behaviour
 




 
Server case #


Client request message


Server capability


Server response


 
Comments on server response




Addressing scheme


Service ID supported


Parameter supported


 
Message


Negative: NRC/section




1


 
physical


 
YES


ALL


 
PosRsp


—


Server sends positive response




2


At least 1


—


Server sends positive response




 
3


At least 1, more than 1, or ALL


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading data parameters of request message




 
4


 
NONE


 
NRC=ROOR


Negative response with NRC 31 hex




 
5


 
NO


 
—


 
NRC=SNS


Negative response with NRC 11 hex




 
 
The following is a description of server response cases on physically addressed client request messages without sub-function (data parameter follows service identifier).
 


Server sends a positive response message because the service identifier and all data parameters are supported by the client's request message.
 


Server sends a positive response message because the service identifier and a single data parameter is supported by the client's request message.
 


Server sends a negative response message (e.g. IMLOIF: incorrectMessageLengthOrIncorrectFormat) because the service identifier is supported and at least one, more than one or all data parameters are supported by the client's request message, but some other error occurred (e.g. wrong length of the request message) during processing of the service.
 


Server sends a negative response message with the negative response code ROOR (requestOutOfRange) because the service identifier is supported but none of the requested data parameters are supported by the client's request message.
 


Server sends a negative response message with the negative response code SNS (serviceNotSupported) because the service identifier is not supported by the client's request message.


 


Functionally addressed client request message




 
The server response behaviour specified in this subclause is referenced in the service description of each service which does not support a sub-function parameter but a data parameter in the functionally addressed request message received from the client.
 
Table 7 shows possible communication schemes with functional addressing.
Table 7 — Functionally addressed request message without sub-function parameter and server response behaviour
 




 
Server case #


Client request message


Server capability


Server response


 
Comments on server response




Addressing scheme


Service ID supported


Parameter supported


 
Message


Negative: NRC/section




1


 
functional


 
YES


YES


 
PosRsp


—


Server sends positive response




2


at least 1


—


Server sends positive response




 
3


 
At least 1,
more than 1, or ALL


 
NegRsp


 
NRC=xx


Server sends negative response because error occurred reading data parameters of request message




 
4


 
NONE


 
NoRsp


 
—


Server does NOT send a response




 
5


 
NO


 
—


 
—


Server does NOT send a response




 
 
The following is a description of server response cases on functionally addressed client request messages without sub-function (data parameter follows service identifier).
 


Server sends a positive response message because the service identifier and single data parameter is supported by the client's request message.
 


Server sends a positive response message because the service identifier and at least one data parameter is supported by the client's request message.
 


Server sends a negative response message (e.g. IMLOIF: incorrectMessageLengthOrIncorrectFormat) because the service identifier is supported and at least one, more than one or all data parameters are supported by the client's request message, but some other error occurred (e.g. wrong length of the request message) during processing of the service.
 


Server sends no response message because the negative response code ROOR (request out of range, which would occur because the service identifier is supported, but none of the requested data parameters is supported by the client's request) is always suppressed in case of a functionally addressed request.
 


Server sends no response message because the negative response code SNS (serviceNotSupported, which is identified by the server because the service identifier is not supported by the client's request) is always suppressed in case of a functionally addressed request.


 


Pseudo code example of server response behaviour
 
The following is a server pseudo code example to describe the logical steps a server shall perform when receiving a request from the client.
 
SWITCH (A_PDU.A_Data.A_PCI.SI)
{
CASE Service_with_subFunction: /* test if service with subFunction is supported */
SWITCH (A_PDU.A_Data.A_Data.Parameter1 & 0x7F) /* get subFunction parameter value without bit 7 */
{
CASE subFunction_00: /* test if subFunction parameter value is supported */
IF (message_length == expected_subFunction_message_length) THEN
: /* prepare response message */
responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */
ELSE
responseCode = IMLOIF; /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
ENDIF BREAK;
CASE subFunction_01: /* test if subFunction parameter value is supported */
: /* prepare response message */
responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */
:
:
:
CASE subFunction_127: /* test if subFunction parameter value is supported */
: /* prepare response message */
responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */
BREAK; DEFAULT:
responseCode = SFNS; /* NRC 0x12: subFunctionNotSupported */
}
suppressPosRspMsgIndicationBit = (A_PDU.A_Data.Parameter1 & 0x80); /* results in either 0x00 or 0x80 */
IF ( (suppressPosRspMsgIndicationBit) && (responseCode == positiveResponse) ) THEN
/* test if positive response is required and if responseCode is positive 0x00 */
suppressResponse = TRUE; /* flag to NOT send a positive response message */
ELSE
suppressResponse = FALSE; /* flag to send the response message */
ENDIF BREAK;
 
CASE Service_without_subFunction: /* test if service without subFunction is supported */ suppressResponse = FALSE; /* flag to send the response message */
IF (message_length == expected_message_length) THEN
IF (A_PDU.A_Data.Parameter1 == supported) THEN /* test if data parameter following the SID is supported*/
: /* read data and prepare response message */
responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */
ELSE
responseCode = ROOR; /* NRC 0x31: requestOutOfRange */
ENDIF ELSE
responseCode = IMLOIF; /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
ENDIF BREAK;
DEFAULT:
responseCode = SNS; /* NRC 0x11: serviceNotSupported */
}
IF (A_PDU.TA_type == functional && ((responseCode == SNS) ¦¦ (responseCode == SFNS) ¦¦ (responseCode == ROOR))) THEN
/* suppress negative response message */
ELSE
IF (suppressResponse == TRUE) THEN
/* suppress positive response message */
ELSE
/* send negative or positive response */
ENDIF ENDIF
 
When functional addressing is used for the request message, the negative response message with the negative response code (NRC) 78 hex, requestCorrectlyReceivedResponsePending (RCRRP), shall not be implemented if a negative response message with NRC=SNS (serviceNotSupported), NRC=SFNS (subFunctionNotSupported) or NRC=ROOR (requestOutOfRange) is the result of the PDU analysis of the received request message.
 


Multiple concurrent request messages with physical and functional addressing
 
A common server implementation has only one diagnostic protocol instance available in the server which can only handle one request at a time. The rule is that any received message (regardless of whether the addressing mode is physical or functional) occupies this resource until the request message is processed (with final response sent or application call without response).
There are only two (2) exceptions which have to be treated separately.
 


The keep-alive logic is used by a client to keep a previously enabled session active in one or multiple servers. Keep-Alive-Logic is defined as the functionally addressed valid TesterPresent message with SPRMIB=true and has to be processed by a bypass logic. It is up to the server to make sure that this specific message can not “block” the server’s application layer and that an immediately following addressed message can be processed.
 


If a server supports one or more legislated diagnostic requests and one of these requests is received while a non-legislated service (e.g. enhanced diagnostics) is active, then the active service shall be aborted, the default session shall be started and the legislated diagnostic service shall be processed. This requirement does not apply if the programming session is active.


 


Size of dataIdentifier (DID)


 
The dataIdentifier (DID) parameter has a size of two (2) bytes in all services throughout ISO 14229.
 
An implementation standard based on ISO 14229 shall specify the size of the dataIdentifier (DID) parameter if it does not match this International Standard.
 


Service description conventions
 


Service description
 
This clause defines how each diagnostic service is described in ISO 14229. It defines the general service description format of each diagnostic service.
 
This clause gives a brief outline of the functionality of the service. Each diagnostic service specification starts with a description of the actions performed by the client and the server(s) which are specific to each service. The description of each service includes a table which lists the parameters of its primitives: request/indication, response/confirmation for a positive or negative result. All have the same structure.
 
For a given request/indication and response/confirmation A_PDU definition, the presence of each parameter is described by one of the following convention (Cvt) values given in Table 8.
 
Table 8 — A_PDU parameter conventions
 




Type


Name


Description




M


Mandatory


The parameter shall be present in the A_PDU.




 
C


 
Conditional


The parameter can be present in the A_PDU, based on certain criteria (e.g. sub- function/parameters within the A_PDU).




 
S


 
Selection


Indicates that the parameter is mandatory (unless otherwise specified) and is a selection from a parameter list.




U


User option


The parameter may or may not be present, depending on dynamic usage by the user.




NOTE The “ Request Service Id” marked as “M” (Mandatory) shall not imply that this service must be supported by the server. The “M” only indicates the mandatory presence of this parameter in the request A_PDU if the server supports the service.






Request message
 


Request message definition
 
This subclause includes multiple tables which define the A_PDU (see Clause 7) parameters for the service request/indication. There might be a separate table for each sub-function parameter ($Level) if the request messages of the different sub-function parameters ($Level) differ in the structure of the A_Data parameters and cannot be specified clearly in one table.
 
Table 9 — Request A_PDU definition with sub-function
 




A_PDU parameter


Parameter name


Cvt


Hex value


Mnemonic




SA


Source Address


M


xx


SA




TA


Target Address


M


xx


TA




TA_type


Target Address type


M


xx


TAT




RA


Remote Address


C


xx


RA



 



A_Data.A_PCI.SI


Request Service Id


M


xx


SIDRQ




A_Data. Parameter 1


sub-function = [
parameter]


S


 
xx


LEV_ PARAM




Parameter 2
:
Parameter k


data-parameter#1
:
data-parameter#k-1


U
: U


xx
:
xx


DP_…#1
:
DP_…#k-1




C: The RA (Remote Address) PDU parameter is only present in case of remote addressing.




 
Table 10 — Request A_PDU definition without sub-function
 




A_PDU parameter


Parameter name


Cvt


Hex value


Mnemonic




SA


Source Address


M


xx


SA




TA


Target Address


M


xx


TA




TA_type


Target Address type


M


xx


TAT




RA


Remote Address


C


xx


RA



 



A_Data.A_PCI.SI


Request Service Id


M


xx


SIDRQ




A_Data. Parameter 1
:
Parameter k


 
data-parameter#1
:
data-parameter#k


 
U
: U


 
xx
:
xx


 
DP_…#1
:
DP_…#k




C: The RA (Remote Address) PDU parameter is only present in case of remote addressing.




 
 
In all requests/indications, the addressing information TA, SA, and TA_type is mandatory. The addressing information RA may optionally be present.
 
NOTE The addressing information is shown in the table above for definition purposes. Further service request/indication definitions only specify the A_Data A_PDU parameter because the A_Data A_PDU parameter represents the message data bytes of the service request/indication.


Request message sub-function parameter $Level (LEV_) definition
 
This subclause defines the sub-function $levels (LEV_) parameter(s) defined for the request/indication of the service .
 
This subclause does not contain any definition for cases where the described service does not use a sub- function parameter value and does not utilize the suppressPosRspMsgIndicationBit (this implicitly indicates that a response is required).
 
The sub-function parameter byte is divided into two parts (on bit-level) as defined in Table 11.
 
Table 11 — Sub-function parameter structure
 




Bit position


 
Description




 
7


suppressPosRspMsgIndicationBit
This bit indicates if a positive response message shall be suppressed by the server.
'0' = FALSE, do not suppress a positive response message (a positive response message is required).
'1' = TRUE, suppress response message (a positive response message shall not be sent; the server being addressed shall not send a positive response message).
Independent of the suppressPosRspMsgIndicationBit, negative response messages are sent by the server(s) according to the restrictions specified in 7.5.




 
6-0


sub-function parameter value
The bits 0-6 of the sub-function parameter contain the sub-function parameter value of the service (00 - 7F hex).
Each service utilizing the sub-function parameter byte, but only supporting the suppressPosRspMsgIndicationBit has to support the zeroSubFunction sub-function parameter value (00 hex).




 
 
The sub-function parameter value is a 7-bit value (bits 6-0 of the sub-function parameter byte) that can have multiple values to further specify the service behaviour.
 
Each service only supporting the suppressPosRspMsgIndicationBit has to support the zeroSubFunction (00 hex).
 
Services supporting sub-function parameter values in addition to the suppressPosRspMsgIndicationBit shall support the sub-function parameter values as defined in the sub-function parameter value table.
 
Each service contains a table that defines values for the sub-function parameter values, taking into account only the bits 0-6.
 
Table 12 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




xx


sub-function#1
description of sub-function parameter#1


M/U


SUBFUNC1




:


:


:


:




xx


sub-function#m
description of sub-function parameter#m


M/U


SUBFUNCm




The convention (Cvt) column in the table above shall be interpreted as follows.
 
Table 13 — Sub-function parameter conventions
 




Type


Name


Description




M


Mandatory


The sub-function parameter has to be supported by the server if the service is supported.




 
U


 
User option


The sub-function parameter may or may not be supported by the server, depending on the usage of the service.




 
 
The complete sub-function parameter byte value is calculated based on the value of the suppressPosRspMsgIndicationBit and the sub-function parameter value chosen.
 
Table 14 — Calculation of the sub-function byte value
 




Bit 7


Bit 6


Bit 5


Bit 4


Bit 3


Bit 2


Bit 1


Bit 0




SuppressPosRspMsg- IndicationBit


Sub-function parameter value as specified in the sub-function parameter value table of the service




Resulting sub-function parameter byte value (bit 7 - 0)




 


Request message data parameter definition




 
This subclause defines the data-parameter(s) $DataParam (DP_) for the request/indication of the service
. This subclause does not contain any definition if the described service does not use any data parameter. The data parameter portion can contain multiple bytes. This subclause provides a generic description of each data parameter; detailed definitions can be found in the annexes of this document. The annexes also specify whether a data parameter shall be supported or is user-optional to be supported if the server supports the service.
 
Table 15 — Request message data parameter definition
 




Definition




data-parameter#1
description of data-parameter#1




:




data-parameter#n
description of data-parameter#n




 


Positive response message
 


Positive response message definition
 
This section includes multiple tables that define the A_PDU parameters for the service response/confirmation (see Clause 7 for a detailed description of the application layer protocol data unit A_PDU). There might be a separate table for each sub-function parameter $Level when the response messages of the different sub- function parameters $Level differ in the structure of the A_Data parameters.
 
The positive response message of a diagnostic service (if required) shall be sent after the execution of the diagnostic service. If a diagnostic service requires different handling (e.g. ECUReset service), the appropriate
description when to sent the positive response message can be found in the service description of the diagnostic service.
 
Table 16 — Positive response A_PDU
 




A_PDU parameter


Parameter name


Cvt


Hex value


Mnemonic




SA


Source Address


M


xx


SA




TA


Target Address


M


xx


TA




TA_type


Target Address type


M


xx


TAT




RA


Remote Address


C


xx


RA



 



A_Data.A_PCI.SI


Response Service Id


S


xx


SIDPR




A_Data.Parameter 1
:
A_Data.Parameter n


data-parameter#1
:
data-parameter#n


 
U


xx
:
xx


DP_…#1
:
DP_…#n




C: The RA (Remote Address) PDU parameter is only present in case of remote addressing.




 
 
In all responses/confirmations, the addressing information TA, SA, and TA_type is mandatory. The addressing information RA is used if and only if remote addressing is used.
 
NOTE The addressing information is shown in Table 16 for definition purposes. Further service request/indication definitions only specify the A_Data A_PDU parameter because the A_Data A_PDU parameter represents the message data bytes of the service response/confirmation.
 


Positive response message data parameter definition



 
This subclause defines the data parameter(s) for the response/confirmation of the service . It does not contain any definition if the described service does not use any data parameter. The data parameter portion can contain multiple bytes. This subclause provides a generic description of each data parameter. Detailed definitions can be found in the annexes of this document. The annexes also specify whether a data parameter will be supported or is user-optional to be supported if the server supports the service.
 
Table 17 — Response data parameter definition
 




Definition




data-parameter#1
description of data-parameter#1. If the request supports a sub-function parameter byte then this parameter is an echo of the 7-bit sub-function parameter value contained within the sub-function parameter byte from the request message with bit 7 set to zero. The suppressPosRspMsgIndicationBit from the sub-function parameter byte is not echoed.



 



data-parameter#m
description of data-parameter#m






Supported negative response codes (NRC_)
 
This subclause defines the negative response codes that will be implemented for this service. The circumstances under which each response code would occur are documented in Tables 18 and 19. The definition of the negative response message can be found in section 7.4. The server shall use the negative response A_PDU for the indication of an identified error condition.
 
The negative response codes listed in A.1 shall be used in addition to the negative response codes specified in each service description if applicable. Details can be found in A.1.
 
Table 18 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




xx


NegativeResponseCode#1
1. condition#1
:
m. condition #m


M


NRC_




:


:


U


NRC_




xx


NegativeResponseCode#n
1. condition#1
:
k. condition #k


U


NRC_




 
 
The convention (Cvt) column in Table 18 shall be interpreted as follows:
 
Table 19 — Sub-function parameter conventions
 




Type


Name


Description




M


Mandatory


The negative response code shall be supported by the server if the service is supported.




 
U


 
User option


The negative response code may or may not be supported by the server, depending on the usage of the service.




 


Message flow examples


 
This subclause contains message flow examples for the service . All examples are shown on a message level (without addressing information).
 
Table 20 — Request message flow example
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1 (A_PCI)


request Service Id


xx


SIDRQ




#2
:
#n


sub-function/data-parameter#1
:
data-parameter#m


xx xx
xx


LEV_/DP_ DP_
DP_




Table 21 — Positive response message flow example
 




Message direction:


server  client




Message type:


Response




A_Data


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1 (A_PCI)


response Service Id


xx


SIDPR




#2
:
#n


data-parameter#1
:
data-parameter#n-1


xx
:
xx


DP_
:
DP_




 
 
There might be multiple examples applicable to the service (e.g. one for each sub-function parameter $Level).
 
Table 22 shows a message flow example for a negative response message.
 
Table 22 — Negative response message flow example
 




Message direction:


server  client




Message type:


Response




A_Data


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1 (A_PCI.NR_SI)


Negative Response Service Id


7F


SIDRSIDNRQ




#2 (A_PCI.SI)


request Service Id


xx


SIDRQ




#3


responseCode


xx


NRC_






Diagnostic and communication management functional unit
 


Overview
 
Table 23 — Diagnostic and communication management functional unit
 




Service


Description




DiagnosticSessionControl


The client requests to control a diagnostic session with a server(s).




ECUReset


The client forces the server(s) to perform a reset.




SecurityAccess


The client requests to unlock a secured server(s).




CommunicationControl


The client requests the server to control its communication.




TesterPresent


The client indicates to the server(s) that it is still present.




 
AccessTimingParameter


The client uses this service to read/modify the timing parameters for an active communication.




 
SecuredDataTransmission


The client uses this service to perform data transmission with an extended data link security.




ControlDTCSetting


The client controls the setting of DTCs in the server.




ResponseOnEvent


The client requests to start an event mechanism in the server.




LinkControl


The client requests control of the communication baud rate.




 


DiagnosticSessionControl (10 hex) service
 


Service description
 
The DiagnosticSessionControl service is used to enable different diagnostic sessions in the server(s).
 
A diagnostic session enables a specific set of diagnostic services and/or functionality in the server(s). It can, furthermore, enable a data link layer dependent set of timing parameters applicable for the started session. This service provides the capability that the server(s) can report data link layer specific parameter values valid for the enabled diagnostic session (e.g. timing parameter values). The data link layer specific implementation document defines the structure and content of the optional parameter record contained in the response message of this service. The user of this International Standard shall define the exact set of services and/or functionality enabled in each diagnostic session (superset of functionality that is available in the defaultSession).
 
There shall always be exactly one diagnostic session active in a server. A server shall always start the default diagnostic session when powered up. If no other diagnostic session is started, then the default diagnostic session shall be running as long as the server is powered.
 
A server shall be capable of providing diagnostic functionality under normal operating conditions and in other operating conditions defined by the vehicle manufacturer, e.g. limp home operation condition.
 
If the client has requested a diagnostic session which is already running, then the server shall send a positive response message and behave as shown in Figure 9, which describes the server internal behaviour when transitioning between sessions.
 
Whenever the client requests a new diagnostic session, the server shall send the DiagnosticSessionControl positive response message before the timings of the new session become active in the server. Some situations may require that the new session must be entered before the positive response is sent while maintaining the old protocol timings for sending the response. If the server is not able to start the requested new diagnostic session, then it shall respond with a DiagnosticSessionControl negative response message and the current session shall continue (see diagnosticSession parameter definitions for further information on
how the server and client shall behave). There shall be only one session active at a time. A diagnostic session enables a specific set of diagnostic services and functions, which shall be defined by the vehicle manufacturer. The set of diagnostic services and diagnostic functionality in a non-default diagnostic session (excluding the programmingSession) is a superset of the functionality provided in the defaultSession, which means that the diagnostic functionality of the defaultSession is also available when switching to any non-default diagnostic session. A session can enable vehicle-manufacturer-specific services and functions which are not part of ISO 14229.
 
To start a new diagnostic session, a server may request that certain conditions be fulfilled. All such conditions are user-defined. An example of such a condition is the following.
 


The server may only allow a client with a certain client identifier (client diagnostic address) to start a specific new diagnostic session (e.g. a server may require that only a client having the client identifier F4 hex may start the extendedDiagnosticSession).
 


In some systems, it is desirable to change communication-timing parameters when a new diagnostic session is started. The DiagnosticSessionControl service entity can use the appropriate service primitives to change the timing parameters as specified for the underlying layers to change communication timing in the local node and potentially in the nodes the client wants to communicate with.
 
Figure 9 provides an overview about the diagnostic session transition and what the server will do when it transitions to another session.
 
Key


default session


other session


same or other session


default session


 
Figure 9 — Server diagnostic session state diagram
 
The following is a description of diagnostic session transition:


When the server is in the defaultSession and the client requests to start the defaultSession, then the server shall re-initialize the defaultSession completely. The server shall reset all activated/initiated/changed settings/controls during the activated session. This does not include long-term changes programmed into non-volatile memory.


When the server transitions from the defaultSession to any other session than the defaultSession, then the server shall only reset the events that have been configured in the server via the ResponseOnEvent (86 hex) service during the defaultSession.


When the server transitions from any diagnostic session other than the defaultSession to another session other than the defaultSession (including the currently active diagnostic session), then the server shall (re-) initialize the diagnostic session, which means that each event that has been configured in the server via the ResponseOnEvent (86 hex) service shall be reset and that security shall be enabled. Any
configured periodic scheduler shall remain active when transitioning from one non-defaultSession to another or the same non-defaultSession. The states of the CommunicationControl and ControlDTCSetting services shall not be affected, which means, for example, that normal communication shall remain disabled when it is disabled at the point in time at which the session is switched.


When the server transitions from any diagnostic session other than the defaultSession to the defaultSession, then the server shall reset each event that has been configured in the server via the ResponseOnEvent (86 hex) service and security shall be enabled. Any configured periodic scheduler shall be disabled. Furthermore, the states of the CommunicationControl and ControlDTCSetting services shall be reset, which means, for example, that normal communication shall be re-enabled when it was disabled at the point in time the session is switched to the defaultSession. The server shall reset all activated/initiated/changed settings/controls during the activated session. This does not include long-term changes programmed into non-volatile memory.


 
Table 24 shows the services which are allowed during the defaultSession and the non-defaultSession (timed services). Any non-defaultSession is tied to a diagnostic session timer that has to be kept active by the client.
 
Table 24 — Services allowed during default and non-default diagnostic sessions
 




Service


defaultSession


non-defaultSession




DiagnosticSessionControl - 10 hex


x


x




ECUReset - 11 hex


x


x




SecurityAccess - 27 hex


N/A


x




CommunicationControl - 28 hex


N/A


x




TesterPresent - 3E hex


x


x




AccessTimingParameter - 83 hex


N/A


x




SecuredDataTransmission - 84 hex


N/A

 



ControlDTCSetting - 85 hex


N/A


x




ResponseOnEvent - 86 hex


xa


x




LinkControl - 87 hex


N/A


x




ReadDataByIdentifier - 22 hex


xb


x




ReadMemoryByAddress - 23 hex


xc


x




ReadScalingDataByIdentifier - 24 hex


xb


x




ReadDataByPeriodicIdentifier - 2A hex


N/A


x




DynamicallyDefineDataIdentifier - 2C hex


xd


x




WriteDataByIdentifier - 2E hex


xb


x




WriteMemoryByAddress - 3D hex


xc


x




ClearDiagnosticInformation - 14 hex


x


x




ReadDTCInformation - 19 hex


x


x




InputOutputControlByIdentifier - 2F hex


N/A


x




RoutineControl - 31 hex


xe


x




RequestDownload - 34 hex


N/A


x




RequestUpload - 35 hex


N/A


x




TransferData - 36 hex


N/A


x




RequestTransferExit - 37 hex


N/A


x




e Secured routines require a SecurityAccess service and therefore a non-default diagnostic session. A routine that needs to be stopped actively by the client also requires a non-default session.






It is implementation-specific whether the ResponseOnEvent service is also allowed during the defaultSession.


Secured dataIdentifiers require a SecurityAccess service and therefore a non-default diagnostic session. c Secured memory areas require a SecurityAccess service and therefore a non-default diagnostic session. d A dataIdentifier can be defined dynamically in the default and non-default diagnostic session.


IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.
 




Request message
 


Request message definition
 
Table 25 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


DiagnosticSessionControl Request Service Id


M


10


DSC




#2


sub-function = [
diagnosticSessionType ]


M


00-FF


LEV_
DS_




 


Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter diagnosticSessionType is used by the DiagnosticSessionControl service to select the specific behaviour of the server. Explanations and usage of the possible diagnostic sessions are detailed below. The following sub-function values are specified [suppressPosRspMsgIndicationBit (bit 7) not shown]:
 
Table 26 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


ISOSAEReserved
This value is reserved by ISO 14229.


M


ISOSAERESRVD




01


defaultSession
This diagnostic session enables the default diagnostic session in the server(s) and does not support any diagnostic application timeout handling provisions (e.g. no TesterPresent service is necessary to keep the session active).
If any other session than the defaultSession has been active in the server and the defaultSession is once again started, then the following implementation rules shall be followed (see also Figure 9).
If the used data link requires an initialization step, then the initialized server(s) shall start the default diagnostic session by default. No DiagnosticSessionControl with diagnosticSession set to defaultSession shall be required after the initialization step.


M


DS






The server shall stop the current diagnostic session when it has sent the DiagnosticSessionControl positive response message and shall start the newly requested diagnostic session afterwards.


If the server has sent a DiagnosticSessionControl positive response message, it shall have re-locked the server if the client unlocked it during the diagnostic session.


If the server sends a negative response message with the DiagnosticSessionControl request service identifier, the active session shall be continued.


Table 26 (continued)
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




02


programmingSession
This diagnosticSession enables all diagnostic services required to support the memory programming of a server.
If the server runs the programmingSession in the boot software, the programmingSession shall only be left via an ECUReset (11 hex) service initiated by the client, a DiagnosticSessionControl (10 hex) service with sessionType equal to defaultSession, or a session layer timeout in the server.
If the server runs in the boot software when it receives the DiagnosticSessionControl (10 hex) service with sessionType equal to defaultSession, or a session layer timeout occurs and a valid application software is present for both cases, then the server shall restart the application software. ISO 14229 does not specify the various implementation methods of how to achieve the restart of the valid application software (e.g. a valid application software can be determined directly in the boot software, during the ECU startup phase when performing an ECUReset, etc.).


U


PRGS




03


extendedDiagnosticSession
This diagnosticSession can e.g. be used to enable all diagnostic services required to support the adjustment of functions such as “Idle Speed”, “CO Value”, etc. in the server's memory. It can also be used to enable diagnostic services, which are not specifically tied to the adjustment of functions.


U


EXTDS




04


safetySystemDiagnosticSession
This diagnosticSession enables all diagnostic services required to support safety- system-related functions e.g. airbag deployment.


U


SSDS




05 - 3F


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD




40 - 5F


vehicleManufacturerSpecific
This range of values is reserved for vehicle-manufacturer-specific use.


U


VMS




60 - 7E


systemSupplierSpecific
This range of values is reserved for system-supplier-specific use.


U


SSS




7F


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD




 


Request message data parameter definition





 
This service does not support data parameters in the request message.


Positive response message
 


Positive response message definition
 
Table 27 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


DiagnosticSessionControl Response Service Id


S


50


DSCPR




#2


diagnosticSessionType


M


00-7F


DS_




 
#3
:
#n


sessionParameterRecord[] #1 = [
data#1
:
data#m ]


 
Ca
: C


 
00-FF
: 00-FF


SPREC_ DATA_1
:
DATA_m




a C is the presence, structure and content of the sessionParameterRecord and is data-link-layer-dependant and therefore defined in the implementation specification(s) of ISO 14229.




 


Positive response message data parameter definition
 
Table 28 — Response message data parameter definition
 




Definition




diagnosticSessionType
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.




sessionParameterRecord
This parameter record contains session-specific parameter values reported by the server. The content and structure of this parameter record is data-link-layer-specific and can be found in the implementation specification(s) of ISO 14229.




 



Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code occurs are documented in Table 29.
 
Table 29 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
This code shall be returned if the criteria for the request DiagnosticSessionControl are not met.


M


CNC






Message flow example(s) DiagnosticSessionControl
 


Example #1 — Start programmingSession



 
This message flow shows how to enable the diagnostic session “programmingSession” in a server. The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) to “FALSE” (‘0’). For the given example, it is assumed that the sessionParameterRecord is supported for the data link layer for which the service is implemented.
 
Table 30 — DiagnosticSessionControl request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


DiagnosticSessionControl request SID


10


DSC




#2


diagnosticSessionType = programmingSession, suppressPosRspMsgIndicationBit = FALSE


02


DS_ECUPRGS




 
Table 31 — DiagnosticSessionControl positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


DiagnosticSessionControl response SID


50


DSCPR




#2


diagnosticSessionType = programmingSession


02


DS_ECUPRGS




 


ECUReset (11 hex) service
 


Service description
 
The ECUReset service is used by the client to request a server reset.
 
This service requests the server to effectively perform a server reset based on the content of the resetType parameter value embedded in the ECUReset request message. The ECUReset positive response message (if required) shall be sent before the reset is executed in the server(s). After a successful server reset, the server shall activate the defaultSession.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.
 


Request message
 


Request message definition
 
Table 32 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ECUReset Request Service Id


M


11


ER




#2


sub-function = [
resetType ]


M


 
00-FF


LEV_
RT_






Request message sub-function Parameter $Level (LEV_) definition
 
The sub-function parameter resetType used by the ECUReset request message to describe how the server will perform the reset [suppressPosRspMsgIndicationBit (bit 7) is not shown].
 
Table 33 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


ISOSAEReserved
This value is reserved by ISO 14229.


M


ISOSAERESRVD




01


hardReset
This value identifies a “hard reset” condition which simulates the power-on/start-up sequence typically performed after a server has been previously disconnected from its power supply (i.e. battery). The performed action is implementation specific and not defined by ISO 14229. It might result in the re-initialization of both volatile memory and non-volatile memory locations to predetermined values.


U


HR




02


keyOffOnReset
This value identifies a condition similar to the driver turning the ignition key off and back on. This reset condition should simulate a key-off-on sequence (i.e. interrupting the switched power supply). The performed action is implementation specific and not defined by ISO 14229. Typically, the values of non-volatile memory locations are preserved; volatile memory will be initialized.


U


KOFFONR




03


softReset
This value identifies a “soft reset” condition, which causes the server to immediately restart the application program if applicable. The performed action is implementation specific and not defined by ISO 14229. A typical action is to restart the application without re-initializing of previously learned configuration data, adaptive factors and other long-term adjustments.


U


SR




04


enableRapidPowerShutDown
This value requests the server to enable and perform a “rapid power shut down” function. The server shall execute the function immediately after “key/ignition” is switched off. While the server executes the power down function, it shall transition either directly or after a defined stand-by time to sleep mode. If the client requires a response message and the server is already prepared to execute the “rapid power shut down” function, the server shall send the positive response message prior to the start of the “rapid power shut down” function. The next occurrence of a “key on” or “ignition on” signal terminates the “rapid power shut down” function.
The client shall not send any request messages other than the ECUReset with the sub-function disableRapidPowerShutDown in order to not disturb the rapid power shut down function.
NOTE This sub-function is only applicable to a server supporting a stand-by mode!


U


ERPSD




05


disableRapidPowerShutDown
This value requests the server to disable the previously enabled “rapid power shut down” function.


U


DRPSD




06 - 3F


ISOSAEReserved
This range of values is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD




40 - 5F


vehicleManufacturerSpecific
This range of values is reserved for vehicle-manufacturer-specific use.


U


VMS




60 - 7E


systemSupplierSpecific
This range of values is reserved for system-supplier-specific use.


U


SSS




7F


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD






Request message data parameter definition
 
This service does not support data parameters in the request message.



Positive response message
 


Positive response message definition
 
Table 34 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ECUReset Response Service Id


S


51


ERPR




#2


resetType


M


00-7F


RT_




#3


powerDownTime


Ca


00-FF


PDT




a C: This parameter is present if the sub-function parameter is set to the enableRapidPowerShutDown value (04hex).




 


Positive response message data parameter definition




 
Table 35 — Response message data parameter definition
 




Definition




resetType
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.




powerDownTime
This parameter indicates to the client the minimum time of the stand-by sequence the server will remain in the power-down sequence.
The resolution of this parameter is one (1) second per count. The following values are valid:


00 – FE hex: 0 – 254 s powerDownTime;


FF hex: indicates a failure or time not available.






 


Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 36.
 
Table 36 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
This code shall be returned if the criteria for the ECUReset request is not met.


M


CNC




33


securityAccessDenied
This code shall be sent if the requested reset is secured and the server is not in an unlocked state.


M


SAD






Message flow example ECUReset


 
This subclause specifies the conditions for the example to be fulfilled to successfully perform an ECUReset service in the server.
 
If the condition of server is ignition = on, the system shall not be in an operational mode (e.g. if the system is an engine management, the engine shall be off).
 
The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub- function parameter) to ‘FALSE’.
 
The server shall send an ECUReset positive response message before the server performs the resetType.
 
Table 37 — ECUReset request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ECUReset request SID


11


ER




#2


ResetType = hardReset, suppressPosRspMsgIndicationBit = FALSE


01


RT_HR




 
Table 38 — ECUReset positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ECUReset response SID


51


ERPR




#2


resetType = hardReset


01


RT_HR




 


SecurityAccess (27 hex) service
 


Service description
 
The purpose of this service is to provide a means to access data and/or diagnostic services which have restricted access for security, emissions or safety reasons. Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where security access may be required. Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emissions, safety or security standards. The security concept uses a seed and key relationship.
 
A typical example of the use of this service is as follows:
 


client requests the “seed”;
 


server sends the “seed”;
 


client sends the “key” (appropriate for the Seed received);
 


server responds that the “key” was valid and that it will unlock itself.
A vehicle-manufacturer-specific time delay may be required before the server can positively respond to a service SecurityAccess “requestSeed” message from the client after server power up/reset and after a certain number of false access attempts (see further description below). If this delay timer is supported, then the delay shall be activated after a vehicle-manufacturer-specified number of false access attempts has been reached or when the server is powered up/reset and a previously performed SecurityAccess service has failed due to a single false access attempt. If the server supports this delay timer, then after a successful SecurityAccess service “sendKey” execution the server internal indication information for a delay timer invocation on a power up/reset shall be cleared by the server. If the server supports this delay timer, and cannot determine if a previously performed SecurityAccess service prior to the power up/reset has failed, then the delay timer shall always be active after power up/reset. The delay is only required if the server is locked when powered up/reset. The vehicle manufacturer shall select if the delay timer is supported.
 
The client shall request the server to “unlock” by sending the service SecurityAccess “requestSeed” message. The server shall respond by sending a “seed” using the service SecurityAccess “requestSeed” positive response message. The client shall then respond by returning a “key” number back to the server using the appropriate service SecurityAccess “sendKey” request message. The server shall compare this “key” to one internally stored/calculated. If the two numbers match, then the server shall enable (“unlock”) the client’s access to specific services/data and indicate that with the service SecurityAccess “sendKey” positive response message. If the two numbers do not match, this shall be considered a false access attempt. If access is rejected for any other reason, it shall not be considered a false access attempt. An invalid key requires the client to start over from the beginning with a SecurityAccess “requestSeed” message.
 
If a server supports security, but the requested security level is already unlocked when a SecurityAccess “requestSeed” message is received, that server shall respond with a SecurityAccess “requestSeed” positive response message service with a seed value equal to zero (0). The server shall never send an all zero seed for a given security level that is currently locked. The client shall use this method to determine if a server is locked for a particular security level by checking for a non-zero seed.
 
There shall always be a fixed relationship for each level of security supported so that the sendKey sub-function parameter value used for any given security level shall be equal to the requestSeed sub-function parameter value used for that security level plus one.
 
Only one security level shall be active at any instant of time. For example, if the security level associated with requestSeed 03 hex is active, and a tester request is successful in unlocking the security level associated with requestSeed 01 hex, then only the secured functionality supported by the security level associated with requestSeed 01 hex shall be unlocked at that time. Any additional secured functionality that was previously unlocked by the security level associated with requestSeed 03 hex shall no longer be active. The security levels numbering is arbitrary and does not imply any relationship between the levels.
 
Attempts to access security shall not prevent normal vehicle communications or other diagnostic communication.
 
Servers which provide security shall support reject messages if a secure service is requested while the server is locked.
 
Some diagnostic functions/services requested during a specific diagnostic session may require a successful security access sequence. In such a case, the following sequence of services shall be required:
 


DiagnosticSessionControl service;
 


SecurityAccess service;
 


secured diagnostic service.
 
There are different accessModes allowed for an enabled diagnosticSession (session started) in the server.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.




Request message
 


Request message definition
 
Table 39 — Request message definition — sub-function = requestSeed
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


SecurityAcces Request Service Id


M


27


SA




#2


sub-function = [
securityAccessType = requestSeed ]


M


 
01, 03, 05,
07-7D


LEV_ SAT_RSD




 
#3
:
#n


securityAccessDataRecord[] = [
parameter#1
:
parameter#m ]


 
U
: U


 
00-FF
: 00-FF


SECACCDR_ PARA1
: PARAm




 
Table 40 — Request message definition — sub-function = sendKey
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


SecurityAcces Request Service Id


M


27


SA




#2


sub-function = [
securityAccessType = sendKey ]


M


 
02, 04, 06,
08-7E


LEV_ SAT_SK




 
#3
:
#n


securityKey[] = [
key#1 (high byte)
:
key#m (low byte) ]


 
M
: U


 
00-FF
: 00-FF


SECKEY_ KEY1HB
: KEYmLB




 


Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter securityAccessType indicates to the server the step in progress for this service, the level of security the client wants to access and the format of seed and key. If a server supports different levels of security each level shall be identified by the requestSeed value, which has a fixed relationship to the sendKey value.
 
EXAMPLES:


“requestSeed=01 hex” identifies a fixed relationship between “requestSeed=01 hex” and “sendKey=02 hex”;


“requestSeed=03 hex” identifies a fixed relationship between “requestSeed=03 hex” and “sendKey=04 hex”.
 
Values are defined in Table 41 for requestSeed and sendKey [suppressPosRspMsgIndicationBit (bit 7) not shown].
Table 41 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


ISOSAEReserved
This value is reserved by ISO 14229.


M


ISOSAERESRVD




01


requestSeed
RequestSeed with the level of security defined by the vehicle manufacturer.


U


RSD




02


sendKey
SendKey with the level of security defined by the vehicle manufacturer.


U


SK




03, 05,
07-41


requestSeed
RequestSeed with different levels of security defined by the vehicle manufacturer.


U


RSD




04, 06,
08-42


sendKey
SendKey with different levels of security defined by the vehicle manufacturer.


U


SK




43-5D


ISOSAEReserved requestSeed values
RequestSeed with different levels of security defined by ISO airbag deployment implementation standard.


M


RSD




44-5E


ISOSAEReserved sendKey values
SendKey with different levels of security defined by ISO airbag deployment implementation standard.


M


SK




5F


requestSeed value
RequestSeed security level defined in ISO Road vehicles — End of life activation of on-board pyrotechnic devices — Part 2: Communication requirements standard.


M


RSD




44-60


sendKey value
SendKey security level defined in ISO Road vehicles — End of life activation of on-board pyrotechnic devices — Part 2: Communication requirements standard.


M


SK




61 - 7E


systemSupplierSpecific
This range of values is reserved for system-supplier-specific use.


U


SSS




7F


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD




 




Request message data parameter definition




 
The following data parameters are defined for this service:
 
Table 42 — Request message data parameter definition
 




Definition




securityKey (high and low bytes)
The “key” parameter in the request message is the value generated by the security algorithm corresponding to a specific “seed” value.




securityAccessDataRecord
This parameter record is user optionally to transmit data to a server when requesting the seed information. It can e.g. contain identification of the client that is verified in the server.






Positive response message
 


Positive response message definition
 
Table 43 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


SecurityAccess Response Service Id


S


67


SAPR




#2


securityAccessType


M


00-7F


SAT_




 
#3


securityS


eed[] = [
seed#1 (high byte)
:
seed#m (low byte) ]


 
Ca


 
00-FF


SECSEED_




SEED1HB




:


:


:


:




#n


C


00-FF


SEEDmLB




a C: The presence of this parameter depends on the securityAccessType parameter. It is mandatory that it be present if the securityAccessType parameter indicates that the client wants to retrieve the seed from the server.




 


Positive response message data parameter definition



 
Table 44 — Response message data parameter definition
 




Definition




securityAccessType
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.




securitySeed (high and low bytes)
The seed parameter is a data value sent by the server and is used by the client when calculating the key needed to access security. The securitySeed data bytes are only present in the response message if the request message was sent with the sub-function set to a value which requests the seed of the server.






Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 45.
 
Table 45 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
This code shall be returned if the criteria for the request SecurityAccess are not met.


M


CNC




24


requestSequenceError
Send if the “sendKey” sub-function is received without first receiving a “requestSeed” request message.


M


RSE




31


requestOutOfRange
This code shall be sent if the user-optional securityAccessDataRecord contains invalid data.


M


ROOR




35


invalidKey
Send if an expected “sendKey” sub-function value is received and the value of the key does not match the server's internally stored/calculated key.


M


IK




36


exceededNumberOfAttempts
Send if the delay timer is active due to exceeding the maximum number of allowed false access attempts.


M


ENOA




37


requiredTimeDelayNotExpired
Send if the delay timer is active and a request is transmitted.


M


RTDNE




 


Message flow example(s) SecurityAccess
 


Assumptions
 
For the message flow examples given below, the following conditions shall be fulfilled to successfully unlock the server if it is in a “locked” state:
 


sub-function to request the seed: 01 hex (requestSeed);
 


sub-function to send the key: 02 hex (sendKey);
 


seed of the server (2 bytes): 3657 hex;
 


key of the server (2 bytes): C9A9 hex (e.g. 2’s complement of the seed value).
 
The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub- function parameter) to “FALSE” (‘0’).




Example #1 — server is in a “locked” state
 


Step #1: Request the seed
 
Table 46 — SecurityAccess request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess request SID


27


SA




#2


SecurityAccessType = requestSeed, suppressPosRspMsgIndicationBit = FALSE


01


SAT_RSD




 
Table 47 — SecurityAccess positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess response SID


67


SAPR




#2


securityAccessType = requestSeed


01


SAT_RSD




#3
#4


securitySeed [ byte#1 ] = seed #1 (high byte)
securitySeed [ byte#2 ] = seed #2 (low byte)


36
57


SECHB
SECLB




 


Step #2: Send the Key
 
Table 48 — SecurityAccess request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess request SID


27


SA




#2


securityAccessType = sendKey, suppressPosRspMsgIndicationBit = FALSE


02


SAT_SK




#3
#4


securityKey [ byte#1 ] = key #1 (high byte)
securityKey [ byte#2 ] = key #2 (low byte)


C9
A9


SECKEY_HB
SECKEY_LB




 
 
Table 49 — SecurityAccess positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess response SID


67


SAPR




#2


securityAccessType = sendKey


02


SAT_SK







Example #2 — server is in an “unlocked” state
 


Step #1: Request the seed




 
Table 50 — SecurityAccess request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess request SID


27


SA




#2


securityAccessType = requestSeed, suppressPosRspMsgIndicationBit = FALSE


01


SAT_RSD




 
Table 51 — SecurityAccess positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


SecurityAccess response SID


67


SAPR




#2


securityAccessType = requestSeed


01


SAT_RSD




#3
#4


securitySeed [ byte#1 ] = seed #1 (high byte)
securitySeed [ byte#2 ] = seed #2 (low byte)


00
00


SECHB
SECLB




 


CommunicationControl (28 hex) service
 


Service description
 
The purpose of this service is to switch on/off the transmission and/or the reception of certain messages of (a) server(s) (e.g. application communication messages).
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.
 


Request message
 


Request message definition
 
Table 52 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


CommunicationControl Request Service Id


M


28


CC




#2


sub-function = [
controlType ]


M


 
00-FF


LEV_ CTRLTP




#3


communicationType


M


00-FF


CTP






Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter controlType contains information on how the server shall modify the communication type referenced in the communicationType parameter [suppressPosRspMsgIndicationBit (bit 7) not shown in Table 53].
 
Table 53 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


enableRxAndTx
This value indicates that the reception and transmission of messages shall be enabled for the specified communicationType.


U


ERXTX




01


enableRxAndDisableTx
This value indicates that the reception of messages shall be enabled and the transmission shall be disabled for the specified communicationType.


U


ERXDTX




02


disableRxAndEnableTx
This value indicates that the reception of messages shall be disabled and the transmission shall be enabled for the specified communicationType.


U


DRXETX




03


disableRxAndTx
This value indicates that the reception and transmission of messages shall be disabled for the specified communicationType.


U


DRXTX




04 - 3F


ISOSAEReserved
This range of values is reserved by ISO 14229 for future definition.


U


ISOSAERESRVD




40 - 5F


vehicleManufacturerSpecific
This range of values is reserved for vehicle-manufacturer-specific use.


U


VMS




60 - 7E


systemSupplierSpecific
This range of values is reserved for system-supplier-specific use.


U


SSS




7F


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD




 


Request message data parameter definition




 
The following data-parameters are defined for this service:
 
Table 54 — Request message data parameter definition
 
communicationType
This parameter is used to reference the kind of communication to be controlled. The communicationType parameter is a bit-code value which allows control of multiple communication types at the same time (see B.1 for the coding of the communicationType data parameter).


Positive response message
 


Positive response message definition
 
Table 55 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


CommunicationControl Response Service Id


S


68


CCPR




#2


controlType


M


00-7F


CTRLTP




 


Positive response message data parameter definition



 
Table 56 — Response message data parameter definition
 
 
controlType

Definition
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.
 


Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 57.
 
Table 57 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
Used when the server is in a critical normal mode activity and therefore cannot disable/enable the requested communication type.


M


CNC




31


requestOutOfRange
The server shall use this response code if it detects an error in the communicationType parameter.


M


ROOR






Message flow example CommunicationControl (disable transmission of network management messages)


 
The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub- function parameter) to “FALSE” (‘0’).
 
Table 58 — CommunicationControl request message flow example
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


CommunicationControl request SID


28


CC




#2


controlType = enableRxAndDisableTx, suppressPosRspMsgIndicationBit = FALSE


01


ERXDTX




#3


communicationType = network management


02


NWMCP




 
Table 59 — CommunicationControl positive response message flow example
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


CommunicationControl response SID


68


CCPR




#2


ControlType


01


CTRLTP




 


TesterPresent (3E hex) service
 


Service description
 
This service is used to indicate to a server (or servers) that a client is still connected to the vehicle and that certain diagnostic services and/or communications that have been previously activated are to remain active.
 
This service is used to keep one or multiple servers in a diagnostic session other than the defaultSession. This can either be done by transmitting the TesterPresent request message periodically or, in case of the absence of other diagnostic services, preventing the server(s) from automatically returning to the defaultSession. The detailed session requirements that apply to the use of this service when keeping a single server or multiple servers in a diagnostic session other than the defaultSession can be found in the implementation specifications of ISO 14229.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.


Request message
 


Request message definition
 
Table 60 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


TesterPresent Request Service Id


M


3E


TP




#2


sub-function = [
zeroSubFunction ]


M


 
00/80


LEV_ ZSUBF




 


Request message sub-function parameter $Level (LEV_) definition
 
Table 61 specifies the sub-function parameter values defined for this service [suppressPosRspMsgIndicationBit (bit 7) not shown].
 
Table 61 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


zeroSubFunction
This parameter value is used to indicate that no sub-function value beside the suppressPosRspMsgIndicationBit is supported by this service.


M


ZSUBF




01 - 7F


ISOSAEReserved
This range of values is reserved by ISO 14229.


M


ISOSAERESRVD




 


Request message data parameter definition




 
This service does not support data parameters in the request message.
 


Positive response message
 


Positive response message definition
 
Table 62 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


TesterPresent Response Service Id


S


7E


TPPR




#2


zeroSubFunction


M


00


ZSUBF




 


Positive response message data parameter definition



 
Table 63 — Response message data parameter definition
 
 
zeroSubFunction

Definition
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.


Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 64.
 
Table 64 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




 


Message flow example(s) TesterPresent
 




Message direction:


client server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


TesterPresent request SID


3E


TP




#2


zeroSubFunction, suppressPosRspMsgIndicationBit = FALSE


00


ZSUBF






Example #1 — TesterPresent (suppressPosRspMsgIndicationBit = FALSE) Table 65 — TesterPresent request message flow example #1
 
Table 66 — TesterPresent positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


TesterPresent response SID


7E


TPPR




#2


zeroSubFunction


00


ZSUBF




 




Message direction:


client server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


TesterPresent request SID


3E


TP




#2


zeroSubFunction, suppressPosRspMsgIndicationBit = TRUE


80


ZSUBF






Example #2 — TesterPresent (suppressPosRspMsgIndicationBit = TRUE) Table 67 — TesterPresent request message flow example #1



 
There is no response sent by the server(s).


AccessTimingParameter (83 hex) service
 


Service description
 
The AccessTimingParameter service is used to read and change the default timing parameters of a communication link for the duration that this communication link is active.
 
The use of this service is complex and depends on the server’s capability and the data link topology. Only one extended timing parameter set will be supported per diagnostic session. It is recommended to use this service only with physical addressing because of the different sets of extended timing parameters supported by the servers.
 
It is recommended to use the following sequence of services:
 


DiagnosticSessionControl (diagnosticSessionType) service;
 


AccessTimingParameter (readExtendedTimingParameterSet) service;
 


AccessTimingParameter (setTimingParametersToGivenValues) service.
 
If a response is required to be sent by the server, the client and server shall activate the new timing parameter settings after the server has sent the AccessTimingParameter positive response message. If no response message is allowed, the client and the server shall activate the new timing parameter after the transmission/reception of the request message.
 
The server and the client shall reset their timing parameters to the default values after a successful switching to another or the same diagnostic session (e.g. via DiagnosticSessionControl, ECUReset service or a session timing timeout).
 
The AccessTimingParameter service provides four (4) different modes for the access to the server timing parameters:
 


readExtendedTimingParameterSet;
 


setTimingParametersToDefaultValues;
 


readCurrentlyActiveTimingParameters;
 


setTimingParametersToGivenValues.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.




Request message
 


Request message definition
 
Table 68 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


AccessTimingParameter Request Service Id


M


83


ATP




#2


sub-func


tion = [
timingParameterAccessType ]


M


00-FF


LEV_ TPAT_




 
#3


TimingParameterRequestRecord [
byte #1
:
byte #m ]


 
Ca


 
00-FF


TPREQR_




B1




:


:


:


:




#n


C


00-FF


Bm




aC: The TimingParameterRequestRecord is only present if timingParameterAccessType = setTimingParametersToGivenValues. The structure and content of the TimingParameterRequestRecord is data-link-layer-dependent and therefore defined in the implementation specification(s) of ISO 14229.




 


Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter timingParameterAccessType is used by the AccessTimingParameter service to select the specific behaviour of the server. Explanations and usage of the possible timingParameterIdentifiers are detailed below. The following sub-function values are specified [suppressPosRspMsgIndicationBit (bit 7) not shown]:
 
Table 69 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


ISOSAEReserved
This value is reserved by ISO 14229.


M


ISOSAERESRVD




01


readExtendedTimingParameterSet
Upon receiving an AccessTimingParameter indication primitive with timingParameterAccessType = readExtendedTimingParameterSet, the server shall read the extended timing parameter set, i.e. the values that the server is capable of supporting.
If the read access to the timing parameter set is successful, the server shall send an AccessTimingParameter response primitive with the positive response parameters.
If the read access to the timing parameters set is not successful, the server shall send a negative response message with the appropriate negative response code.
This sub-function is used to provide an extra set of timing parameters for the currently active diagnostic session.
With the timingParameterAccessType = setTimingParametersToGivenValues only, this set (read by timingParameterAccessType = readExtendedTimingParameterSet) of timing parameters can be set.


U


RETPS




Table 69 (continued)
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




02


setTimingParametersToDefaultValues
Upon receiving an AccessTimingParameter indication primitive with timingParameterAccessType = setTimingParametersToDefaultValues, the server shall change all timing parameters to the default values and send an AccessTimingParameter response primitive with the positive response parameters before the default timing parameters become active (if suppressPosRspMsgIndicationBit is set to 'FALSE', otherwise the timing parameters shall become active after the successful evaluation of the request message).
If the timing parameters cannot be changed to default values for any reason, the server shall maintain the currently active timing parameters and send a negative response message with the appropriate negative response code.
The definition of the default timing values depends on the used data link and is specified in the implementation specification(s) of ISO 14229.


U


STPTDV




03


readCurrentlyActiveTimingParameters
Upon receiving an AccessTimingParameter indication primitive with timingParameterAccessType = readCurrentlyActiveTimingParameters, the server shall read the currently used timing parameters.
If the read access to the timing parameters is successful, the server shall send an AccessTimingParameter response primitive with the positive response parameters.
If the read access to the currently used timing parameters is impossible for any reason, the server shall send a negative response message with the appropriate negative response code.


U


RCATP




04


setTimingParametersToGivenValues
Upon receiving an AccessTimingParameter indication primitive with timingParameterAccessType = setTimingParametersToGivenValues, the server shall check if the timing parameters can be changed under the present conditions.
If the conditions are valid, the server shall perform all actions necessary to change the timing parameters and send an AccessTimingParameter response primitive with the positive response parameters before the new timing parameter values become active (suppressPosRspMsgIndicationBit is set to 'FALSE', otherwise the timing parameters shall become active after the successful evaluation of the request message).
If the timing parameters cannot be changed for any reason, the server shall maintain the currently active timing parameters and send a negative response message with the appropriate negative response code.
It is not possible to set the timing parameters of the server to any set of values between the minimum and maximum values read via timingParameterAccessType
= readExtendedTimingParameterSet. The timing parameters of the server can only be set to exactly the timing parameters read via timingParameterAccessType = readExtendedTimingParameterSet. A request to do so shall be rejected by the server.


U


STPTGV




05-FF


ISOSAEReserved
This value is reserved by ISO 14229 for future definition.


M


ISOSAERESRVD






Request message data parameter definition




 
The following data parameters are defined for the request message:
 
Table 70 — Request message data parameter definition
 

Definition
TimingParameterRequestRecord
This parameter record contains the timing parameter values to be set in the server via timingParameterAccessType = setTimingParametersToGivenValues. The content and structure of this parameter record is data-link-layer-specific and can be found in the implementation specification(s) of ISO 14229.
 


Positive response message
 


Positive response message definition
 
Table 71 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


AccessTimingParameter Response Service Id


S


C3


ATPPR




#2


timingParameterAccessType


M


00-7F


TPAT_




 
#3
:
#n


TimingParameterResponseRecord [
byte #1
:
byte #m ]


 
C
: C


 
00-FF
: 00-FF


TPRSPR_ B1
:
Bm




C: The TimingParameterResponseRecord is only present if timingParameterAccessType = readExtendedTimingParameterSet or readCurrentlyActiveTimingParameters. The structure and content of the TimingParameterResponseRecord is data-link-layer-dependent and therefore defined in the implementation specification(s) of ISO 14229.




 


Positive response message data parameter definition



 
Table 72 — Response message data parameter definition
 




Definition




timingParameterAccessType
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.




TimingParameterResponseRecord
This parameter record contains the timing parameter values read from the server via timingParameterAccessType = readExtendedTimingParameterSet or readCurrentlyActiveTimingParameters. The content and structure of this parameter record is data-link-layer-specific and can be found in the implementation specification(s) of ISO 14229.






Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 73.
 
Table 73 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if selected timingParameterAccessType is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message or the format is wrong.


M


IMLOIF




22


conditionsNotCorrect
This code shall be returned if the criteria for the request AccessTimingParameter are not met.


M


CNC




31


requestOutOfRange
This code shall be sent if the TimingParameterRequestRecord contains invalid timing parameter values.


M


ROOR




 


Message flow example(s) AccessTimingParameter


 
9.7.5.1 Example #1 — set timing parameters to default values
 
This message flow shows how to set the default timing parameters in a server. The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).
 
Table 74 — AccessTimingParameter request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


AccessTimingParameter request SID


83


ATP




#2


timingParameterAccessType = setTimingParametersToDefaultValues, suppressPosRspMsgIndicationBit = FALSE


02


TPAT_STPTDV




 
Table 75 — AccessTimingParameter positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


AccessTimingParameter response SID


C3


ATPPR




#2


timingParameterAccessType = setTimingParametersToDefaultValues


02


TPAT_STPTDV




 
Further examples for the usage of this service can be found in the implementation specifications of ISO 14229.


SecuredDataTransmission (84 hex) service
 


Service description
 


Purpose
 
The purpose of this service is to transmit data that is protected against attacks from third parties, which could endanger data security, according to ISO 15764.
 
The SecuredDataTransmission service is applicable if a client intends to use diagnostic services defined in this document in a secured mode. It may also be used to transmit external data which conform to some other application protocol, in a secured mode between a client and a server. A secured mode in this context means that the data transmitted is protected by cryptographic methods.
 


Security sub-layer
 
This subclause briefly describes the security sub-layer as defined in ISO 15764.
 
Figure 10 illustrates the security sub-layer as defined in ISO 15764. The security sub-layer shall be added in the server and client application for the purpose of performing diagnostic services in a secured mode.
 
 

 
Figure 10 — Security sub-layer implementation
There are two (2) methods to perform diagnostic service data transfer between the client and server(s).
 


Unsecured data transmission mode:
 
The application uses the diagnostic services and application layer service primitives defined in this document to exchange data between a client and a server. The security sub-layer performs a "pass-thru" of data between "application" and "application layer" in the client and the server.
 


Secured data transmission mode:
 
The application uses the diagnostic services or external services and the security sub-layer service primitives defined in ISO 15764 to exchange data between a client and a server. The security sub-layer uses the SecuredDataTransmission service for the transmission/reception of the secured data. Secured links must be point-to-point communication. Therefore, only physical addressing is allowed, which means that only one server is involved.
 
The interface of the security sub-layer to the application is according to the ISO/OSI model conventions and therefore provides the following four (4) security sub-layer (SS_) service primitives:
 


SS_SecuredMode.req: Security sub-layer request;
 


SS_SecuredMode.ind: Security sub-layer indication;
 


SS_SecuredMode.resp: Security sub-layer response;
 


SS_SecuredMode.conf: Security sub-layer confirmation.
 
ISO 14229 defines both confirmed and unconfirmed services. In a secured mode, only confirmed services are allowed (suppressPosRspMsgIndicationBit = FALSE). Based on this requirement, the following services are not allowed to be executed in a secured mode:
 


ResponseOnEvent (86 hex);
 


ReadDataByPeriodicIdentifier (2A hex); and
 


TesterPresent (3E hex).
 
The confirmed services (suppressPosRspMsgIndicationBit = FALSE) use the four (4) application layer service primitives, request, indication, response and confirmation. Those are mapped onto the four (4) security sub-layer service primitives and vice versa when executing a confirmed diagnostic service in a secured mode.
 
The task of the security sub-layer when performing a diagnostic service in a secured mode is to encrypt data provided by the "application", to decrypt data provided by the "application layer" and to add, check and remove security-specific data elements. The security sub-layer uses the SecuredDataTransmission (84 hex) service of the application layer to transmit and receive the entire diagnostic message or message according to an external protocol (request and response), which shall be exchanged in a secured mode.
 
The security sub-layer provides the service "SecuredServiceExecution" to the application for the purpose of a secured execution of diagnostic services.
The security sub-layer request and indication primitive of the "SecuredServiceExecution" service are specified in ISO 15764 according to the following general format:
 
SS_SecuredMode.request (
SA,
TA,
TA_type, [RA,]
,parameter 1, ...
)
 
SS_SecuredMode.indication (
SA,
TA,
TA_type, [RA,]
,parameter 1, ...
)
 
The security sub-layer response and confirm primitive of the SecuredServiceExecution service are specified in ISO 15764 according to the following general format:
 
SS_SecuredMode.response (
SA,
TA,
TA_type,
RA (optional) Result,
parameter 1, ...
)
 
SS_SecuredMode.confirm (
SA,
TA,
TA_type,
RA (optional) Result,
parameter 1, ...
)
 
Detailed information can be found in ISO 15764 about:
 


the security sub-layer service primitives (Service Data Units (SDU), parameter 1, ...);
 


the security sub-layer protocol data units (PDU); and
 


the tasks to be performed by the security sub-layer for a secured data transmission.
 
The addressing information shown in the security sub-layer service primitives is mapped directly onto the addressing information of the application layer and vice versa.




Security sub-layer access




 
The concept of accessing the security sub-layer for a secured service execution is similar to the application layer interface as described in this document. The security sub-layer makes use of the application layer service primitives.
 
The following describes the execution of confirmed diagnostic service in a secured mode.
 


The client application uses the security sub-layer SecuredServiceExecution service request to perform a diagnostic service in a secured mode. The security sub-layer performs the required action to establish a link with the server(s), adds the specific security-related parameters, encrypts the service data of the diagnostic service to be executed in a secured mode if needed and uses the application layer SecuredDataTransmission service request to transmit the secured data to the server.
 


The server receives an application layer SecuredDataTransmission service indication, which is handled by the security sub-layer of the server. The security sub-layer of the server checks the security-specific parameters, decrypts encrypted data and presents the data of the service to be executed in a secured mode to the application via the security sub-layer SecuredServiceExecution service indication. The application executes the service and uses the security sub-layer SecuredServiceExecution service response to respond to the service in a secured mode. The security sub-layer of the server adds the specific security-related parameters, encrypts the response message data if needed and uses the application layer SecuredDataTransmission service response to transmit the response data to the client.
 


The client receives an application layer SecuredDataTransmission service confirmation primitive, which is handled by the security sub-layer of the client. The security sub-layer of the client checks the security-specific parameters, decrypts encrypted response data and presents the data via the security sub-layer SecuredServiceExecution confirmation to the application.
 
Figure 11 graphically shows the interaction of the security sub-layer, the application layer and the application when executing a confirmed diagnostic service in a secured mode.
 

 
Figure 11 — Security sub-layer, application layer and application interaction
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.3 in the event that those addressing methods are implemented for this service.
 


Request message
 


Request message definition
 
The security sub-layer generates the application layer SecuredDataTransmission request message parameters according to the rules defined in ISO 15764.
Table 76 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


SecuredDataTransmission Request Service Id


M


84


SDT




 
#2
:
#n


securityDataRequestRecord[] = [
securityDataParameter#1
:
securityDataParameter#m ]


 
M
: M


 
00-FF
: 00-FF


SECDRQR_ SDP_
: SDP_




 


Request message sub-function parameter $Level (LEV_) definition
 
This service does not use a sub-function parameter.
 


Request message data parameter definition



 
The following data-parameters are defined for the request message:
 
Table 77 — Request message data parameter definition
 
 
securityDataRequestRecord



     Definition      



securityDataRequestRecord
  This parameter contains the data as processed by the Security Sub-Layer and is defined in ISO 15764.




 
Definition
This parameter contains the data as processed by the Security Sub-Layer and is defined in ISO 15764.
 


Positive response message
 


Positive response message definition
 
Table 78 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




1


SecuredDataTransmission Response Service Id


M


C4


SDTPR




 
2
:
n


securityDataResponseRecord[] = [
securityDataParameter#1
:
securityDataParameter#m ]


 
M
: M


 
00-FF
: 00-FF


SECDRQR_ SDP_
: SDP_




 


Positive response message data parameter definition



 
The following data parameters are defined for the positive response message:
 
Table 79 — Response message data parameter definition
 
 
securityDataResponseRecord



      Definition 



securityDataResponseRecord
This parameter contains the data as processed by the Security Sub-Layer and is defined in ISO 15764.




 
Definition
This parameter contains the data as processed by the Security Sub-Layer and is defined in ISO 15764.
9.8.4 Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 80. The response codes are always sent without encryption, even if according to the configurationProfile in the request A_PDU the response A_PDU must be encrypted.
 
Table 80 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




13


incorrectMessageLengthOrInvalidFormat
The server shall use this response code if the length of the request A_PDU is not correct.


M


IMLOIF




38 - 4F


reservedByExtendedDataLinkSecurityDocument
This range of values is reserved by ISO 15764. Applicable negative response codes are defined in ISO 15764.


M


RBEDLSD




 
NOTE The response codes listed above apply to the SecuredDataTransmission (84 hex) service. If the diagnostic service performed in a secured mode requires a negative response, then this negative response is sent to the client in a secured mode via a SecuredDataTransmission positive response message.
 


ControlDTCSetting (85 hex) service
 


Service description
 
The ControlDTCSetting service shall be used by a client to stop or resume the setting of diagnostic trouble codes (DTCs) in the server(s).
 
The ControlDTCSetting request message can be used to stop the setting of diagnostic trouble codes in an individual server or a group of servers. If the server being addressed is not able to stop the setting of diagnostic trouble codes, it shall respond with a ControlDTCSetting negative response message indicating the reason for the rejection.
 
The update of the DTC status bit information shall continue once a ControlDTCSetting request is performed with sub-function set to “on” or a session layer timeout occurs (server transitions to defaultSession). The server shall still send a positive response if the service is supported in the active session with a requested sub-function set to either “on” or “off” even if the requested DTC setting state is already active.
 
If a clearDiagnosticInformation (14 hex) service is sent by the client, the ControlDTCSetting shall not prohibit resetting the server's DTC memory.
 
If a successful ECUReset is performed, then this re-enables the setting of DTCs.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in section 7.5.2 in the event that those addressing methods are implemented for this service.


Request message
 


Request message definition
 
Table 81 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ControlDTCSetting Request Service Id


M


85


CDTCS




#2


sub-func


tion = [
DTCSettingType ]


M


 
00-FF


LEV_ DTCSTP_




 
#3
:
#n


DTCSetti


ngControlOptionRecord [] =


[
parameter#1
:
parameter#m


 
U
: U


 
00-FF
: 00-FF


DTCSCOR_ PARA1
: PARAm




 


Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter DTCSettingType is used by the ControlDTCSetting request message to indicate to the server(s) whether diagnostic trouble code setting shall stop or start again [suppressPosRspMsgIndicationBit (bit 7) not shown in Table 82].
 
Table 82 — Request message sub-function parameter definition
 




Hex (bit 6-0)


 
Description


 
Cvt


 
Mnemonic




00


ISOSAEReserved
This value is reserved by this document.


M


ISOSAERESRVD




01


on
The server(s) shall resume the setting of diagnostic trouble codes according to normal operating conditions.


M


ON




02


off
The server(s) shall stop the setting of diagnostic trouble codes.


M


OFF




03 - 3F


ISOSAEReserved
This range of values is reserved by this document for future definition.


M


ISOSAERESRVD




40 - 5F


vehicleManufacturerSpecific
This range of values is reserved for vehicle-manufacturer-specific use.


U


VMS




60 - 7E


systemSupplierSpecific
This range of values is reserved for system-supplier-specific use.


U


SSS




7F


ISOSAEReserved
This value is reserved by this document for future definition.


M


ISOSAERESRVD






Request message data parameter definition




 
The following data parameters are defined for this service:
 
Table 83 — Request message data parameter definition
 



     Definition



DTCSettingControlOptionRecord
This parameter record is user-optional and transmits data to a server when controlling the DTC setting. It can contain a
list of DTCs to be turned on or off.




 
Definition
DTCSettingControlOptionRecord
This parameter record is user-optional and transmits data to a server when controlling the DTC setting. It can contain a list of DTCs to be turned on or off.
 


Positive response message
 


Positive response message definition
 
Table 84 — Positive response message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ControlDTCSetting Response Service Id


S


C5


CDTCSPR




#2


DTCSettingType


M


00-7F


DTCSTP




 


Positive response message data parameter definition



 
Table 85 — Response message data parameter definition
 
 
DTCSettingType



     Definition



DTCSettingType 
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.




 
Definition
This parameter is an echo of bits 6 - 0 of the sub-function parameter from the request message.
 


Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 86.
 
Table 86 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
Used when the server is in a critical normal mode activity and therefore cannot perform the requested DTC control functionality.


U


CNC




31


requestOutOfRange
The server shall use this response DTCSettingControlOptionRecord.


 
code


 
if


 
it


 
detects


 
an


 
error


 
in


 
the


M


ROOR






Message flow example(s) ControlDTCSetting
 


Example #1 — ControlDTCSetting (DTCSettingType = off)
 
Note that this example does not use the capability of the service to transfer additional data to the server. The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).
 
Table 87 — ControlDTCSetting request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ControlDTCSetting request SID


85


RDTCS




#2


DTCSettingType = off, suppressPosRspMsgIndicationBit = FALSE


02


DTCSTP_OFF




 
Table 88 — ControlDTCSetting positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ControlDTCSetting response SID


C5


RDTCSPR




#2


DTCSettingType = off


02


DTCSTP_OFF




 


Example #2 — ControlDTCSetting(suppressPosRspMsgIndicationBit= FALSE)



 
This example does not use the capability of the service to transfer additional data to the server. The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).
 
Table 89 — ControlDTCSetting request message flow example #2
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ControlDTCSetting request SID


85


ENC




#2


DTCSettingType = on, suppressPosRspMsgIndicationBit = FALSE


01


DTCSTP_ON




 
Table 90 — ControlDTCSetting positive response message flow example #2
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ControlDTCSetting response SID


C5


RDTCSPR




#2


DTCSettingType = on


01


DTCSTP_ON






ResponseOnEvent (86 hex) service
 


Service description
 
The ResponseOnEvent service requests a server to start or stop transmission of responses on a specified event.
 
This service provides the possibility of automatically executing a diagnostic service in the event that a specified event occurs in the server. The client specifies the event (including optional event parameters) and the service (including service parameters) to be executed if the event occurs. See Figure 12 for a brief overview of client and server behaviour.
 

 

 
Figure 12 — ResponseOnEvent service — Client and server behaviour
 
NOTE Figure 12 above assumes that the event window timer is configured to timeout prior to the power down of the server, therefore the final ResponseOnEvent positive response message is shown at the end of the event timing window.
 
The server shall evaluate the sub-function and data content of the ResponseOnEvent request message at the time of the reception. This includes the following sub-function and parameters:
 




eventType,
 


eventWindowTime, and
 


eventTypeRecord (eventTypeParameter #1-#m).
In case of invalid data in the ResponseOnEvent request message, a negative response with the negative response code 31 hex shall be sent. The serviceToRespondToRecord is not part of this evaluation. The serviceToRespondToRecord parameter will be evaluated when the specified event occurs, which triggers the execution of the service contained in the serviceToRespondToRecord. At the time the event occurs, the serviceToRespondToRecord (diagnostic service request message) shall be executed. If conditions are not correct, a negative response message with the appropriate negative response code shall be sent. Multiple events shall be signalled in the order of their occurrence.
 
The following implementation rules shall apply.
 


The ResponseOnEvent service can be set up and activated in any session, including the defaultSession. TesterPresent service is not necessarily required to keep the ResponseOnEvent service active.
 


If the specified event occurs when a diagnostic service is in progress, which means that either a request message is in progress to be received, or a request is executed, or a response message is in progress (this includes the negative response message handling with response code 78 hex) to be transmitted (if suppressPosRspMsgIndicationBit = FALSE), then the execution of the request message contained in the serviceToRespondToRecord shall be postponed until the completion of the diagnostic service in progress.
 
If the specified event is accepted by the server, the client shall not request the following diagnostic services until the event window is passed:
 


CommunicationControl;
 


DynamicallyDefineDataIdentifier;
 


RequestDownload;
 


RequestUpload;
 


TransferData;
 


RequestTransferExit;
 


RoutineControl.




 
The server is not executing any diagnostic service at the point in time the specified event occurs, the server executes the service contained in the serviceToRespondToRecord.
 
Once the ResponseOnEvent service is initiated, the server shall support the data link where this service has been submitted while the ResponseOnEvent service is active.
 
A DiagnosticSessionControl service shall stop the ResponseOnEvent service regardless of whether a different session than the current session or the same session is activated
 
It is recommended to use only the services listed in Table 91 for the service to be performed if the specified event occurs (serviceToRespondTo request service Identifier).
 
Table 91 — Recommended services to be used with the ResponseOnEvent service
 




Recommended services (ServiceToRespondTo)


Request Service Identifier (SId)


Response Service Identifier (SId)




ReadDataByIdentifier


22


62




ReadDTCInformation


19


59




RoutineControl


31


71




InputOutputControlByIdentifier


2F


6F




It is allowed to run different multiple ResponseOnEvent services at a time and to stop individual serviceToRespondTo services. While no serviceToRespondTo is currently in progress, running the server shall handle any additional diagnostic service request.
 
IMPORTANT — The server and the client shall meet the request and response message behaviour as specified in 7.5.2 in the event that those addressing methods are implemented for this service.
 


Request message
 


Request message definition
 
Table 92 — Request message definition
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ResponseOnEvent Request Service Id


M


86


ROE




#2


sub-function = [
eventType ]


M


 
00-FF


LEV_ ETP




#3


eventWindowTime


M


00-FF


EWT




 
#4
:
#(m-1)+4


eventTypeRecord[] = [
eventTypeParameter 1
:
eventTypeParameter m ]


 
Ca 1
: C1


 
00-FF
: 00-FF


ETR_ ETP1
: ETPm




 
#n-(r-1)-1
#n-(r-1)
:
#n


serviceToRespondToRecord[] = [
serviceId serviceParameter 1
:
serviceParameter r ]


 
Cb 2
c
C3
: C3


 
00-FF
00-FF
: 00-FF


STRTR_ SI SP1
:
SPr



 





C1 is present if the eventType requires additional parameters to be specified for the event to respond to.


C2 shall be present if the sub-function parameter is not equal to reportActivatedEvents, stopResponseOnEvent, startResponseOnEvent, ClearResponseOnEvent.


C3 is present if the service request of the service to respond to requires additional service parameters.


 


Request message sub-function parameter $Level (LEV_) definition
 
The sub-function parameter eventType is used by the ResponseOnEvent request message to specify the event to be configured in the server and to control the ResponseOnEvent set up. Each sub-function parameter value given in Table 94 also specifies the length of the applicable eventTypeRecord [suppressPosRspMsgIndicationBit (bit 7) not shown in Table 94].
 
Bit 6 of the eventType sub-function parameter is used to indicate whether the event will be stored in non-volatile memory in the server and re-activated upon the next power-up of the server or if it shall terminate once the server powers down (storageState parameter).
Table 93 — eventType sub-function bit 6 definition — storageState
 




Bit 6 value


 
Description


 
Cvt


 
Mnemonic




0


doNotStoreEvent
This value indicates that the event shall terminate when the server powers down and the server shall not continue a ResponseOnEvent diagnostic service after a reset or power on (i.e. the ResponseOnEvent service is terminated).


M


DNSE




1


storeEvent
This value indicates that the event shall resume sending serviceToRespondTo responses according to the ResponseOnEvent set-up after a power cycle of the server.


U


SE




 
Table 94 — Request message sub-function parameter definition
 




Hex (bit 5-0)


 
Description


 
Cvt


 
Mnemonic




00


stopResponseOnEvent
This value is used to stop the server sending responses on event. The event logic that has been set up is not cleared but can be restarted with the startResponseOnEvent sub-function parameter.
Length of eventTypeRecord: 0 byte.


U


STPROE




01


onDTCStatusChange
This value identifies the event as a new DTC detected matching the DTCStatusMask specified for this event.
Length of eventTypeRecord: 1 byte.
Implementation hint: A server resident DTC count algorithm shall count the number of DTCs satisfying the client-defined DTCStatusMask at a certain periodic rate (e.g. approximately 1 second). If the count is different from that which was calculated on the previous execution, the client shall generate the event that causes the execution of the serviceToRespondTo. The latest count shall then be stored as a reference for the next calculation.
This eventType requires the specification of the DTCStatusMask in the request message (eventTypeParameter#1).


U


ONDTCS




02


onTimerInterrupt
This value identifies the event as a timer interrupt, but the timer and its values are not part of the ResponseOnEvent service.
This eventType requires the specification of more details in the request message (eventTypeRecord).
Length of eventTypeRecord: 1 byte.


U


OTI




03


onChangeOfDataIdentifier
This value identifies the event as a new internal data record identified by the dataIdentifier. The data values are vehicle-manufacturer-specific.
This eventType requires the specification of more details in the request message (eventTypeRecord).
Length of eventTypeRecord: 2 bytes.


U


OCODID




Table 94 (continued)



 Hex(bit 5-0)  
        Description       
       Cvt              
     Mnemonic    


04

reportActivatedEvents
This value is used to indicate that in the positive response all events are reportedThis value is used to indicate that in the positive response all events are reportedthat have been activated in the server with the ResponseOnEvent service (and arecurrently active).Length of eventTypeRecord: 0 byte.

U
RAE


05

startResponseOnEvent
This value is used to indicate to the server to activate the event logic (includingThis value is used to indicate to the server to activate the event logic (includingevent window timer) that has been set up and start sending responses on event.Length of eventTypeRecord: 0 byte.

M
STRTROE


06

clearResponseOnEvent
This value is used to clear the event logic that has been set up in the server. (ThisThis value is used to clear the event logic that has been set up in the server. (Thisalso stops the server sending responses on event.)Length of eventTypeRecord: 0 byte.

M
CLRROE


07

onComparisonOfValues
This is a defined alteration of a data value out of a specific record identified by aThis is a defined alteration of a data value out of a specific record identified by adataIdentifier which identifies a data value event. With this sub-function, the usershall have the possibility of defining an event at the occurrence of a specific resultgathered from a defined measurement value comparison. A specific measurementvalue included in a data record assigned to a defined dataIdentifier is comparedwith a given comparison value. The specified operator defines the kind ofcomparison. The event occurs if the comparison result is positive.Length of eventTypeRecord: 10 bytes.

U
OCOV


08-1F

ISOSAEReserved
This range of values is reserved by this document for future definition.

M
ISOSAERESRVD


20-2F

VehicleManufacturerSpecific
This range of values is reserved for vehicle-manufacturer-specific use.

U
VMS


30-3E

SystemSupplierSpecific
This range of values is reserved for system-supplier-specific use.

U
SSS


3F

ISOSAEReserved
This value is reserved by this document for future definition.

M
ISOSAERESRVD



 
Hex
 




(bit 5-0)

 



04


reportActivatedEvents


U


RAE



 

This value is used to indicate that in the positive response all events are reported that have been activated in the server with the ResponseOnEvent service (and are currently active).

 
 


 

Length of eventTypeRecord: 0 byte.

 
 



05


startResponseOnEvent


M


STRTROE



 

This value is used to indicate to the server to activate the event logic (including event window timer) that has been set up and start sending responses on event.

 
 


 

Length of eventTypeRecord: 0 byte.

 
 



06


clearResponseOnEvent


M


CLRROE



 

This value is used to clear the event logic that has been set up in the server. (This also stops the server sending responses on event.)

 
 


 

Length of eventTypeRecord: 0 byte.

 
 



07


onComparisonOfValues


U


OCOV



 

This is a defined alteration of a data value out of a specific record identified by a dataIdentifier which identifies a data value event. With this sub-function, the user shall have the possibility of defining an event at the occurrence of a specific result gathered from a defined measurement value comparison. A specific measurement value included in a data record assigned to a defined dataIdentifier is compared with a given comparison value. The specified operator defines the kind of comparison. The event occurs if the comparison result is positive.

 
 


 

Length of eventTypeRecord: 10 bytes.

 
 



08 - 1F


ISOSAEReserved


M


ISOSAERESRVD



 

This range of values is reserved by this document for future definition.

 
 



20 - 2F


VehicleManufacturerSpecific


U


VMS



 

This range of values is reserved for vehicle-manufacturer-specific use.

 
 



30 - 3E


SystemSupplierSpecific


U


SSS



 

This range of values is reserved for system-supplier-specific use.

 
 



3F


ISOSAEReserved


M


ISOSAERESRVD



 

This value is reserved by this document for future definition.

 
 



Description Cvt Mnemonic
 
NOTE For easier description, the request message sub-function parameters can be divided into two different groups:




sub-function parameters to request a set-up of response on event (“ROE set-up sub-functions”), and


sub-function parameters to control the response on event set-up, like startResponseOnEvent, stopResponseOnEvent clearResponseOnEvent, reportActivatedEvents (“ROE control sub-functions”).


Request message data parameter definition


 
The following data parameters are defined for this service:
 
Table 95 — Request message data parameter definition
 




Definition




eventWindowTime
The parameter eventWindowTime is used to specify a window for the event logic to be active in the server. If the parameter value of eventWindowTime is set to 02 hex then the response time is infinite. In case of an infinite event window, it is recommended to close the event window by a certain signal (e.g. power off). See annex B.2 for specified eventWindowTimes.
NOTE This parameter is not applicable to be evaluated by the server if the eventType is equal to a ROE control sub-function.




eventTypeRecord
This parameter record contains additional parameters for the specified eventType.




serviceToRespondToRecord
This parameter record contains the service parameters (service Id and service parameters) of the service to be executed in the server each time the specified event defined in the eventTypeRecord occurs.




 


Positive response message
 


Positive response message definition
 
Table 96 — Positive response message definition for all sub-functions but reportActivatedEvents
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ResponseOnEvent Response Service Id


S


C6


ROEPR




#2


eventType


M


00-7F


ETP




#3


numberOfIdentifiedEvents


M


00-FF


NOIE




#4


eventWindowTime


M


00-FF


EWT




 
#5


eventTypeRecord[] = [
eventTypeParameter 1
:
eventTypeParameter m ]


 
Ca 1


 
00-FF


ETR_




ETP1




:


:


:


:




#(m-1)+5


C1


00-FF


ETPm




 
#n-(r-1)-1


serviceToRespondToRecord[] = [
serviceId serviceParameter 1
:
serviceParameter r ]


 
M


 
00-FF


STRTR_




SI




#n-(r-1)


Cb 2


00-FF


SP1




:


:


:


:




#n


C2


00-FF


SPr




a
 
b


C1 is present if the eventType requires additional parameters to be specified for the event to respond to.
C2 is present if the service request of the service to respond to requires additional service parameters.




Table 97 — Positive response message definition — sub-function = reportActivatedEvents
 




A_Data byte


Parameter name


Cvt


Hex value


Mnemonic




#1


ResponseOnEvent Response Service Id


S


C6


ROEPR




#2


eventType = reportActivatedEvents


M


04


ETP_RAE




#3


numberOfActivatedEvents


M


00-FF


NOIE




#4


eventTypeOfActiveEvent #1


Ca 1


00-FF


EVOAE




#5


eventWindowTime #1


C1


00-FF


EWT




 
#6
:
#(m-1)+6


eventTypeRecord #1[] = [
eventTypeParameter 1
:
eventTypeParameter m ]


 
Cb 2
: C2


 
00-FF
: 00-FF


ETR_ ETP1
: ETPm




 
#p-(o-1)-1
#p-(o-1)
:
#p


serviceToRespondToRecord #1[] = [
serviceId serviceParameter 1
:
serviceParameter o ]


 
Cc 3
Cd 4
: C4


 
00-FF
00-FF
: 00-FF


STRTR_ SI SP1
:
SPo




:


:


:


:


:




:


eventTypeOfActiveEvent #k


C1


00-FF


EVOAE




:


eventWindowTime #k


C1


00-FF


EWT




 
:
:
:


eventTypeRecord #k[] = [
eventTypeParameter 1
:
eventTypeParameter q ]


 
C2
: C2


 
00-FF
: 00-FF


ETR_ ETP1
: ETPm




 
#n-(r-1)-1
#n-(r-1)
:
#n


serviceToRespondToRecord #k[] = [
serviceId serviceParameter 1
:
serviceParameter r ]


 
C3C4
: C4


 
00-FF
00-FF
: 00-FF


STRTR_ SI SP1
:
SPr



 





C1 is present if an active event is reported.


C2 is present if the reported eventType of the active event (eventTypeOfActiveEvent) requires additional parameters to be specified for the event to respond to.


C3 shall be present when reporting an active event.


C4is present if the reported service request of the service to respond to requires additional service parameters.



Positive response message data parameter definition



 
Table 98 — Response message data parameter definition
 




Definition




eventType
This parameter is an echo of bits 6 - 0 of the sub-function parameter of the request message.




eventTypeOfActiveEvent
This parameter is an echo of the sub-function parameter of the request message that was issued to set-up the active event. The applicable values are the ones specified for the eventType sub-function parameter.




numberOfActivatedEvents
This parameter contains the number of active events when the client requests to report the number of active events. This number reflects the number of events reported in the response message.




numberOfIdentifiedEvents
This parameter contains the number of identified events during an active event window and is only applicable for the response message sent at the end of the event window (in case of a finite event window). The initial response to the request message shall contain a zero (0) in this parameter.




eventWindowTime
This parameter is an echo of the eventWindowTime parameter from the request message. When reporting an active event, this parameter contains the time remaining for the event to be active.




eventTypeRecord
This parameter is an echo of the eventTypeRecord parameter from the request message. When reporting an active event, this parameter is an echo of the eventTypeRecord of the request that was issued to set-up the active event.




serviceToRespondToRecord
This parameter is an echo of the serviceToRespondToRecord parameter from the request message. When reporting an active event, this parameter is an echo of the serviceToRespondToRecord of the request that was issued to set up the active event.




 


Supported negative response codes (NRC_)
 
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 99.
 
Table 99 — Supported negative response codes
 




Hex


Description


Cvt


Mnemonic




12


subFunctionNotSupported
Send if the sub-function parameter in the request message is not supported.


M


SFNS




13


incorrectMessageLengthOrInvalidFormat
The length of the message is wrong.


M


IMLOIF




22


conditionsNotCorrect
Used when the server is in a critical normal mode activity and therefore cannot perform the requested functionality.


U


CNC




31


requestOutOfRange
The server shall use this response code:


M


ROOR






if it detects an error in the eventTypeRecord parameter;


if the specified eventWindowTime is invalid.



Message flow example(s) ResponseOnEvent
 


Assumptions
 
For the message flow examples, it is assumed that the eventWindowTime equal to 08 hex defines an event window of 80 seconds (eventWindowTime * 10 seconds). The client requests a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).
 
NOTE The definition of the eventWindowTime is vehicle-manufacturer-specific, except for certain values as specified in B.2.
 
The following conditions apply to the shown message flow examples and flowcharts:
 




Trigger signal: It is up to the vehicle manufacturer to define a specific trigger signal which causes the client (external test equipment, OBD-Unit, diagnostic master, etc.) to start the ResponseOnEvent request message. This trigger signal could be enabled by an event as well as by a fixed timing schedule like a heartbeat-time (which should be greater than the eventWindowTime). Furthermore, there could be a synchronous message (e.g. SYNCH-signal) on the data link used as trigger signal.
 


Open event window: On receiving the ResponseOnEvent request message, the server shall evaluate the request. If the evaluation is positive, the server shall set up the event logic and shall send the initial positive response message of the ResponseOnEvent service. To activate the event logic, the client shall request ResponseOnEvent sub-function startResponseOnEvent. After the positive response, the event logic is activated and the event window timer is running. It is up to the vehicle manufacturer to define the event window in detail, using the parameter eventWindowTime (e.g. timing window, ignition on/off window). In case of detecting the specified eventType (EART_), the server shall respond immediately with the response message corresponding to the serviceToRespondToRecord in the ResponseOnEvent request message.
 


Close event window: It is recommended to close the event window of the server according to the parameter eventWindowTime. After this action, the server shall stop sending event-driven diagnostic response messages. The same could either be reached by sending the ResponseOnEvent (ROE_) request message including the parameter stopResponseOnEvent, or by power off.
 


Example #1 — ResponseOnEvent (finite event window)


 
Table 100 — Set up ResponseOnEvent request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent request SID


86


ROE




#2


eventTypeRecord [ eventType ] = onDTCStatusChange, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE


01


ET_ODTCSC




#3


eventWindowTime = 80 seconds


08


EWT




#4


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#5


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#6


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#7


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




Table 101 — ResponseOnEvent initial positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = onDTCStatusChange


01


ET_ODTCSC




#3


numberOfIdentifiedEvents = 0


00


NOIE




#4


eventWindowTime = 80 seconds


08


EWT




#5


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#6


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#7


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#8


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




 
 
Once the event logic is set up, it shall then be activated.
 
Table 102 — Start ResponseOnEvent request message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent request SID


86


ROE




#2


eventTypeRecord [ eventType ] = startResponseOnEvent, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE


05


ET_STRTROE




#3


eventWindowTime (will not be evaluated)


08


EWT




 
Table 103 — ResponseOnEvent positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = onDTCStatusChange


01


ET_ODTCSC




#3


numberOfIdentifiedEvents = 0


00


NOIE




#4


eventWindowTime


08


EWT




 
 
If the specified event occurs, the server sends the response message according to the specified serviceToRespondToRecord.
Table 104 — ReadDTCInformation positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ReadDTCInformation response SID


59


RDTCI




#2


DTCStatusAvailibilityMask


FF


DTCSAM




#3
#4


DTCCount [ DTCCountHighByte ] = 0
DTCCount [ DTCCountLowByte ] = 4


00
04


DTCCNT_HB
DTCCNT_LB




 
 
The message flow for cases where the client requests a report on the currently active events in the server during the active event window will look as follows.
 
Table 105 — ResponseOnEvent request number of active events message flow example #1
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent request SID


86


ROE




#2


eventTypeRecord [ eventType ] = reportActivatedEvents, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE


04


ET_RAE




 
Table 106 — ResponseOnEvent reportActivatedEvents positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = reportActivatedEvents


04


ET_RAE




#3


numberOfActivatedEvents = 1


01


NOAE




#4


eventTypeOfActiveEvent = onDTCStatusChange


01


ET_ODTCSC




#5


eventWindowTime = 80 seconds


08


EWT




#6


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#7


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#8


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#9


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




If the specified event window time has expired, the server shall send a final positive response.
 
Table 107 — ResponseOnEvent final positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = onDTCStatusChange


01


ET_ODTCSC




#3


numberOfIdentifiedEvents = 1


01


NOIE




#4


eventWindowTime = 80 seconds


08


EWT




#5


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#6


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#7


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#8


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




 
9.10.5.2.1 Example #1 — Flowcharts
 
The following flowcharts show two different kinds of server behaviour.
 


No event occurs within the finite event window: in this case, the server shall send the response of the ResponseOnEvent at the end of the event window.
 


Multiple events (#1 to #n) within a finite event window: each positive response of the serviceToRespondTo is related to an identified event (#1 to #n) and shall have the same service identifier (SId) but might have different content. At the end of the event_Window, the server shall transmit a positive response message of the responseOnEvent service, which indicates the numberOfIdentifiedEvents.
 

 

 
Figure 13 — Finite event window — No event during active event window
 

 

 
Figure 14 — Finite event window — Multiple events during active event window
 
9.10.5.3 Example #2 — ResponseOnEvent (infinite event window)
 
Table 108 — ResponseOnEvent request message flow example #2
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent request SID


86


ROE




#2


eventTypeRecord [ eventType ] = onDTCStatusChange, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE


01


ET_ODTCSC




#3


eventWindowTime = infinite


02


EWT




#4


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#5


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#6


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#7


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




Table 109 — ResponseOnEvent initial positive response message flow example #2
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = onDTCStatusChange


01


ET_ODTCSC




#3


numberOfIdentifiedEvents = 0


00


NOIE




#4


eventWindowTime = infinite


02


EWT




#5


eventTypeRecord [ eventTypeParameter ] = testFailed status


01


ETP1




#6


serviceToRespondToRecord [ serviceId ] = ReadDTCInformation


19


RDTCI




#7


serviceToRespondToRecord [ sub-function ] =


01


RNDTC



 

reportNumberOfDTCByStatusMask

 
 



#8


serviceToRespondToRecord [ DTCStatusMask ] = testFailed status


01


DTCSM




 
 
Once the event logic is set up, it shall then be activated.
 
Table 110 — Start ResponseOnEvent request message flow example #2
 




Message direction:


client  server




Message type:


Request




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent request SID


86


ROE




#2


eventTypeRecord [ eventType ] = startResponseOnEvent, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE


05


ET_STRTROE




#3


eventWindowTime (will not be evaluated)


02


EWT




 
Table 111 — ResponseOnEvent positive response message flow example #2
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ResponseOnEvent response SID


C6


ROEPR




#2


eventType = onDTCStatusChange


05


ET_ODTCSC




#3


numberOfIdentifiedEvents = 0


00


NOIE




#4


eventWindowTime


02


EWT




In case the specified event occurs, the server sends the response message according to the specified serviceToRespondToRecord.
 
Table 112 — ReadDTCInformation positive response message flow example #1
 




Message direction:


server  client




Message type:


Response




A_Data byte


Description (all values are in hexadecimal)


Byte value (hex)


Mnemonic




#1


ReadDTCInformation response SID


59


RDTCI




#2


DTCStatusAvailibilityMask


xx


DTCSAM




#3
#4


DTCCount [ DTCCountHighByte ] = 0
DTCCount [ DTCCountLowByte ] = 4


00
04


DTCCNT_HB
DTCCNT_LB




 
9.10.5.3.1 Example #2 — Flowcharts
 
The following flowcharts show two different kinds of server behaviour.
 


No event occurs within the infinite event window.
 


Multiple events (#1 to #n) within a infinite event window: each positive response of the serviceToRespondTo is related to an identified event (#1 to #n) and shall have the same service identifier (SId) but might have different content.
 

 

 
Figure 15 — Infinite event window — No event during active event window
 

 

 
Figure 16 — Infinite event window — Multiple events during active event window
 
9.10.5.4 Example #3 — ResponseOnEvent (infinite event window) — Sub-function parameter “onComparisonOfValues”
 
This example only explains the utilization of sub-function parameter “onComparisonOfValues”, assuming that the communication behaviour of the ROE service described in Example #1 and Example #2 has not changed. Therefore, this example does not describe the complete message flow. Instead, only the event window set-up request message and the positive response message to the occurring event is shown and explained. Start and stop request messages as well as the different response messages are already described in the examples above.
 
The following conditions apply:
 


service 22 hex – ReadDataByIdentifier is chosen as the serviceToRespondTo;
 


the dataIdentifier 0104 hex includes the measurement value which is to be compared at data byte #11 and #12 (this measurement value may also be read by utilising service 22 hex);
 


an event occurs if the measurement value (MV) is higher than the so-called comparison parameter (CP), therefore the operator value (see description below) is chosen as 01 hex – “MV > CP”;
 


as hysteresis value 0A hex – 10 % is chosen;
 


as eventWindowTime the value 02 hex – “infinite” is chosen;
 


as storageState (eventType sub-function bit 6 ) the value 1 binary – “storeEvent” is chosen;
 


in any case, a response is requested.
The following is a description of the eventTypeRecord. The usage of the eventTypeRecord is vehicle- manufacturer-specific, similar to the eventTypes described so far. Therefore, the following description is only an example explaining the usage of the eventType “onComparisonOfValues”. The specific number of necessary eventTypeRecord parameters is also manufacturer-specific. In this example, 10 data bytes are used.
 
Byte #4&5: dataIdentifier 0104 hex.
 
Byte #6&7: Localization of reading and definition of reading type. The bit numbering within these 2 bytes of information is counted from the least significant bit through to the most significant bit. Bit #0 (LSB) - Bit #9 (MSB) contain the start bit number of the reading. With 10 bits, the maximal size of a data record is 128 bytes.
 
EXAMPLE 1 If the reading is in the 11th byte of the data record, the following applies: 11x8 = 88 dec = 0001011000b Bit
#10 - Bit #14: length in bits - 1. With 5 bits, there is a maximum size of 32 bits = “long”.
 
EXAMPLE 2 For a “word”, the length is therefore 15 dec = 01111b Bit #15: Sign entry: 1 = signed, 0 = unsigned.
 
EXAMPLE 3 Total assignment would be: 1011 1100 0101 1000b = BC58 hex, thus byte #6 contains BC hex, byte #7 contains 58 hex.
 
Byte #8: Comparison operation (operator) defines the type of comparison which shall be executed:


MV>CP content: 01 hex;


MVCP 02 hex;


MV=CP 03 hex;


MV>CP 04 hex;


“” provided for analogue values, “=” and “>” for digital variables;


MV: measurement value; and


CP: comparison parameter.
 
EXAMPLE 4 Operator MV > CP = 01 hex.
 
Byte #9-12: Comparison parameters: due to the 4-byte length, all data formats from Bit through to Long type can be transmitted.
 
EXAMPLE 5 If the comparison value is 5242 dec = 00 00 14 7A hex, byte #9 = 00 hex, byte #10 = 00 hex, byte #11 = 14 hex and byte #12 = 7A hex....