概述

  定义诊断系统的通用需求-与数据链路无关的诊断服务  

ISO 14229-1 UDS在各种数据链路的未来实现

应用层接口服务

 .应用层服务概述

• 服务原语（6个）

1.  请求 request
2.  请求_确认 req_confirm
3.  指示 indication
4.  响应 response
5.  响应一确认 rsp_confirm
6.  确认 conf irm

•   有确认服务
•   无确认服务

 有确认服务

客户端应用层 (Client)       服务器端应用层(Server)

service_name.request, service_name.req_confirm,service  name.confirm,service  name.indication,service_name.response,service_name.rsp_confirm

 无确认服务

服务原语的格式

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 (addressinginformation);

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

⎯ “[,parameter 1, ...]” are parameters that depend on the specific service (e.g. parameter 1 can be thediagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of theparameter list may be empty.

• request

service_name.request (

SA,

TA,

TA_type,(枚举：用于描 述功能还是物 理寻址方式)

[RA,]  （远程地址，可选〉

[,parameter 1, ...]

)

• indication

service_name.indication (

SA,

TA,

TA_type,

[RA,]  （远程地址，可选〉

[,parameter 1, ...]

)

service_name.request和service_name.indication中的[,parameter 1, ...]：原语中的数据 单元内容一致。

• Response

service_name.response (

SA,

TA,

TA_type,

[RA,]  （远程地址，可选〉

Result

[,parameter 1, ...]

) 

• confirm

service_name.confirm (

SA,

TA,

TA_type,

[RA,]  （远程地址，可选〉

Result

[,parameter 1, ...]

)

• request-confirm

service_name.req_confirm (

SA,

TA,

TA_type,

[RA,]  （远程地址，可选〉

Result

)

•  response-confirm

service_name.rsp_confirm (

SA,

TA,

TA_type,

[RA,]  （远程地址，可选〉

Result

)

 车辆系统需求

• 客户 （Tester） 和服务器 C ECU） 统一编址
• 每一个Tester和ECU的地址是唯一的
• RA  C 远程地址〉 独立分配 

远程诊断示例1：Remote server example with remote network

The external test equipment sends a remote diagnostic request message with

⎯ SA = 241 (F1 hex),

⎯ TA = 200 (C8 hex), 

⎯ 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),

⎯ 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), 

⎯ 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),

⎯ RA = 62 (3E hex).

The external test equipment receives the message.

远程诊断示例2（上图）：Remote server example without remote network

The external test equipment sends a remote diagnostic request message with

⎯ SA = 241 (F1 hex),

⎯ TA = 200 (C8 hex),

⎯ RA = 62 (3E hex).

The gateway receives the message and passes it over to the remote server function. The remote serverreceives 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),

⎯ RA = 62 (3E hex).

The external test equipment receives the message.

 远程诊断示例2：Remote client example with remote network

The external test equipment sends a remote diagnostic request message with

⎯ SA = 242 (F1 hex),

⎯ TA = 10 (0A hex),

⎯ RA = 18 (12 hex).

The gateway receives the message and sends it out on the main network with

⎯ SA = 200 dec,

⎯ TA = 18 dec,

⎯ 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),

⎯ 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),

⎯ RA = 18 (12 hex).

The external test equipment receives the message.

应用层协议

• A_SDU: 应用层服务数据单元

Application Layer Service Data Unit

SA, TA, TA_type  [,RA]  [,parameter1,...]

• A_PDU : 应用层协议数据单元

Application Layer Protocol Data Unit SA, TA, TA_type  [,RA],A_Data

A_Data=A_PCl+[parameter1,...]

• A_PCI: 应用层协议控制信息

Application Layer Protocol Control Information 

• A_PUD = A_PCI+ A _SDU

 应用层协议控制信息

• 2种不同的格式 〈 由服务原语和Result参数决定〉
• A_PCI (SI)

         SI: Service ID(Request服务和Result=positive的Response)      

           类型：1字节无符号整数

           范围：00~FF

• A_PCl(NR_Sl,SI)

         NR_SI-Negative Service ID

          类型：1字节无符号整数

          范围：7F

服务标识符SI

•  请求服务标识符SI

类型：1字节无符号整数

范围：00~FF

请求服务的ID:  X0XXXXXX（第6位为0)

示例：ReadDTClnformation服务Request  0x19   B00011001

• 肯定响应服务标识符SI

类型：1字节无符号整数

范围：00~FF

肯定响应服务的ID:  X1XXXXXX  （第6位为1)

肯定响应服务的ID =请求服务的ID+0x40

示例：ReadDTClnformation服务Response 0x59 B01011001

• 否定响应服务标识符NR_SI

类型：1字节无符号整数

范围：7F

 Negative response A_PDU

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

Service description conventions

This clause defines how each diagnostic service is described in ISO 14229. It defines the general serviceThis clause defines how each diagnostic service is described in ISO 14229. It defines the general servicedescription format of each diagnostic service.This clause gives a brief outline of the functionality of the service. Each diagnostic service specification startswith 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 parameteris described by one of the following convention (Cvt) values given in Table 8

 Table 8  A_PDU parameter conventions

Cvt:约定

M:强制

U:用户选择

C:是否使用依赖于其它参数

S:强制从参数列表中选择 〈枚举类型〉

请求A_PDU

• 请求示例 〈带子功能〉Request A_PDU definition with sub-function

• 请求示例 〈不带子功能〉Request A_PDU definition without sub-function

服务描述约定

   子功能参数$Level(LEV＿）的定义

• 1字节数据
•  Bit7:  禁止肯定响应指示位suppressPosRspMsglndicationBit    

           0: FALSE：需要肯定响应

           1: TRUE： 禁止肯定响应

•  Bit6:  子功能参数值 （0x00~0x7F)            

           使用子功能参数字节，但仅支持

           suppressPosRspMsglndicationBit 的服务必须支持0x0子 功能

Request message sub-function parameter $Level (LEV_) definition

Request message sub-function parameter $Level (LEV_) definitionThis subclause defines the sub-function $levels (LEV_) parameter(s) defined for the request/indication of theservice .

This subclause does not contain any definition for cases where the described service does not use a subfunctionparameter value and does not utilize the suppressPosRspMsgIndicationBit (this implicitly indicatesthat 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

The sub-function parameter value is a 7-bit value (bits 6-0 of the sub-function parameter byte) that can haveThe sub-function parameter value is a 7-bit value (bits 6-0 of the sub-function parameter byte) that can havemultiple values to further specify the service behaviour.

Each service only supporting the suppressPosRspMsgIndicationBit has to support the zeroSubFunctionEach service only supporting the suppressPosRspMsgIndicationBit has to support the zeroSubFunction(00 hex).

Services supporting sub-function parameter values in addition to the suppressPosRspMsgIndicationBit shallServices supporting sub-function parameter values in addition to the suppressPosRspMsgIndicationBit shallsupport 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 accountEach service contains a table that defines values for the sub-function parameter values, taking into accountonly the bits 0-6.

Table 12 — Request message sub-function parameter definition

The convention (Cvt) column in the table above shall be interpreted as follows.The convention (Cvt) column in the table above shall be interpreted as follows.

Table 13 — Sub-function parameter conventions

The complete sub-function parameter byte value is calculated based on the value of theThe complete sub-function parameter byte value is calculated based on the value of thesuppressPosRspMsgIndicationBit and the sub-function parameter value chosen.

Table 14 — Calculation of the sub-function byte value

Request message data parameter definition

This subclause defines the data-parameter(s) $DataParam (DP_) for the request/indication of the serviceThis 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 anydata parameter. The data parameter portion can contain multiple bytes. This subclause provides a genericdescription of each data parameter; detailed definitions can be found in the annexes of this document. Theannexes also specify whether a data parameter shall be supported or is user-optional to be supported if theserver supports the service.

Table 15 — Request message data parameter definition

• 肯定响应A_PDU   Positive response A_PDU

• 否定响应A PDU

Request message flow example

Positive response message flow example

Negative response message flow example

Supported negative response codes (常见：11，12，13，31，78)

服务响应的执行规则Server response implementation rules

对带子功能参数的请求消息的响应

The following subclauses specify the behaviour of the server when executing a service. The server and theThe following subclauses specify the behaviour of the server when executing a service. The server and theclient shall follow these implementation rules.

The server shall support its list of diagnostic services regardless of addressing mode (physical, functionalThe server shall support its list of diagnostic services regardless of addressing mode (physical, functionaladdressing type).

IMPORTANT — As required by the tables in the following subclauses, negative response messageswith negative response codes of SNS (serviceNotSupported), SFNS (subFunctionNotSupported) andROOR (requestOutOfRange) shall never be transmitted when functional addressing was used for therequest message.

Request message with sub-function parameter and server response behaviour

对物理寻址的客户端请求消息Physically addressed client request message

Functionally addressed client request message

对不带子功能参数的请求消息的晌应Request message without sub-function parameter and server response behaviour

Physically addressed client request message

Functionally addressed client request message

各功能单元具体服务描述

标准下载(英文版-2013):

ISO 14229-1-2013规格和要求.pdf

ISO 14229-2-2013会话层服务.PDF

ISO 14229-3-2012在CAN实施上的统一诊断服务.pdf

ISO 14229-4-2012在FlexRay实施上的统一诊断服务.pdf

ISO 14229-5_2013互联网协议实施上的统一诊断服务.pdf

ISO 14229-6-2013在K线上的诊断服务.pdf