ISO14229诊断服务文档

DIAG

需积分: 5 31 浏览量更新于2023-12-16 收藏 5.5MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

ISO 14229是一份关于汽车统一诊断服务的规范和要求的文件。该文件的第一版于2006年12月1日发布，目前已经更新到第二版。这份标准的目的是为了确保不同品牌和类型的道路车辆能够通过统一的接口进行诊断和通信。它定义了统一的诊断服务（Unified Diagnostic Services，简称UDS），包括诊断会话管理、ECU（Electronic Control Unit，电子控制单元）诊断和编程、故障代码诊断和清除、数据流和信号诊断以及安全性和网络管理等。 ISO 14229规范了UDS的实现要求，包括通信协议、数据传输、错误处理和诊断服务的逻辑结构等方面。它要求车辆生产商必须实现和遵守UDS的各项要求，并在车辆诊断工具中使用UDS进行汽车诊断。该标准采用了统一的诊断服务会话协议（Diagnostic Session Control）。通过该协议，诊断工具可以与车辆的ECU建立会话连接，并进行诊断和通信。标准还规定了不同诊断会话的类型，例如默认会话、扩展会话和制造商定义的会话等。此外，ISO 14229还定义了各种诊断服务的功能和要求。例如，在ECU诊断和编程方面，标准规定了诊断通讯传输的方式、DTC（Diagnostic Trouble Code，故障码）的格式和解释、编程数据的格式和传输等。在故障诊断方面，标准规定了故障码的存储和清除、故障诊断数据的格式和传输等。同时，该标准还强调了UDS的安全性和网络管理。它要求诊断服务的传输必须采用安全协议，防止未经授权的访问和攻击。此外，标准还规定了网络管理的要求，包括ECU在网络中的唯一标识符和网络配置的管理等。综上所述，ISO 14229是一份关于汽车统一诊断服务的重要标准。它确保了不同品牌和类型的车辆能够通过统一的接口进行诊断和通信。该标准规定了UDS的实现要求，包括通信协议、数据传输、错误处理和诊断服务的逻辑结构等。它对于汽车制造商和诊断工具供应商来说，是一个重要的参考和指导。随着汽车技术的不断发展，ISO 14229的更新版将会继续推出，以适应新的需求和挑战。

资源详情

资源推荐

ISO 14229:2006(E)

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.

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

6.4 Format description of remote service primitives

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

BA178AF3E36A6D10FCA78F9BA277B963B9C98CF3ACDDBB832BFD67AACDE4149F28C44B1A89F80BBEB7E14BBA665183CDB375DAAF5CDE7E7BA16775E66F98348E6364E9EB087C48E04D32000F10BD217AF1B17335B096

A&I-Abo-Beuth-Bayerische Motoren Werke AG-KdNr.13570-LfNr.3457867001-2007-01-03 18:24

ISO 14229:2006(E)

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.

6.4.2 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, ...]

)

BA178AF3E36A6D10FCA78F9BA277B963B9C98CF3ACDDBB832BFD67AACDE4149F28C44B1A89F80BBEB7E14BBA665183CDB375DAAF5CDE7E7BA16775E66F98348E6364E9EB087C48E04D32000F10BD217AF1B17335B096

A&I-Abo-Beuth-Bayerische Motoren Werke AG-KdNr.13570-LfNr.3457867001-2007-01-03 18:24

ISO 14229:2006(E)

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.

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

BA178AF3E36A6D10FCA78F9BA277B963B9C98CF3ACDDBB832BFD67AACDE4149F28C44B1A89F80BBEB7E14BBA665183CDB375DAAF5CDE7E7BA16775E66F98348E6364E9EB087C48E04D32000F10BD217AF1B17335B096

A&I-Abo-Beuth-Bayerische Motoren Werke AG-KdNr.13570-LfNr.3457867001-2007-01-03 18:24

ISO 14229:2006(E)

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

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

6.5 Service data unit specification

6.5.1 Mandatory parameters

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

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

BA178AF3E36A6D10FCA78F9BA277B963B9C98CF3ACDDBB832BFD67AACDE4149F28C44B1A89F80BBEB7E14BBA665183CDB375DAAF5CDE7E7BA16775E66F98348E6364E9EB087C48E04D32000F10BD217AF1B17335B096

A&I-Abo-Beuth-Bayerische Motoren Werke AG-KdNr.13570-LfNr.3457867001-2007-01-03 18:24

ISO 14229:2006(E)

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.

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

6.5.1.4 TA_Type, Target Address type

Type: enumeration

Range: physical, functional

BA178AF3E36A6D10FCA78F9BA277B963B9C98CF3ACDDBB832BFD67AACDE4149F28C44B1A89F80BBEB7E14BBA665183CDB375DAAF5CDE7E7BA16775E66F98348E6364E9EB087C48E04D32000F10BD217AF1B17335B096

A&I-Abo-Beuth-Bayerische Motoren Werke AG-KdNr.13570-LfNr.3457867001-2007-01-03 18:24

剩余299页未读，继续阅读