《道路車輛 統(tǒng)一的診斷服務》征求意見稿

ICS

點擊此處添加中國標準文獻分類號

中華人民共和國國家標準

GB/TXXXXX—XXXX/ISO14229

道路車輛統(tǒng)一診斷服務(UDS)

Roadvehicles-Unifieddiagnosticservices

（ISO14229，MOD）

（征求意見稿）

（本稿完成日期：2020.01.15）

前言

本部分按照GB/T1.1—2009給出的規(guī)則起草。

本部分使用翻譯法修改采用ISO14229《道路車輛統(tǒng)一診斷服務(UDS)》系列標準，包含ISO14229的下

列部分：

——第1部分：規(guī)范和要求；

——第2部分：會話層服務；

——第3部分：CAN的統(tǒng)一診斷設備(UDSonCAN)；

——第4部分：FlexRay實施的統(tǒng)一診斷服務(UDSonFR)；

——第5部分：IP實施的統(tǒng)一診斷服務(UDSonIP)；

——第6部分：K-Line實施的統(tǒng)一診斷服務(UDSonK-Line)；

——第7部分：局域互連網(wǎng)絡(UDSonLIN)上的UDS。

本部分與ISO14229的技術性差異如下：

——修改了本部分的適用范圍；

——關于標準中的引用文件，本部分做了具有技術性差異的調整：

用等同采用國際標準的GB/TXXXX代替ISO14229系列標準；

本部分由中華人民共和國工業(yè)和信息化部提出。

本部分由全國汽車標準化技術委員會（SAC/TC114）歸口。

本部分起草單位：。

本部分主要起草人：。

道路車輛統(tǒng)一診斷服務(UDS)

1范圍

本部分規(guī)定了道路車輛統(tǒng)一診斷服務(UDS)的基本要求、會話層服務、啟用控制區(qū)區(qū)域網(wǎng)絡(CAN)的統(tǒng)一

診斷設備、FlexRay實施的統(tǒng)一診斷服務(UDSonFR)、因特網(wǎng)協(xié)議實施的統(tǒng)一診斷服務(UDSonIP)、K-Line實

施的統(tǒng)一診斷服務(UDSonK-Line)、局域互連網(wǎng)絡(UDSonLIN)上的UDS。

本標準適用于道路車輛統(tǒng)一診斷服務。

2規(guī)范性引用文件

下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。

ISO10681-2道路車輛FlexRay通信第2部分：通信層服務(Roadvehicles—Communicationon

FlexRay—Part2:Communicationlayerservices)

ISO13400（所有部分）道路車輛互聯(lián)網(wǎng)協(xié)議的診斷通信（DoIP）（Roadvehicles—Diagnostic

communicationoverInternetProtocol(DoIP)）

ISO14230-1道路車輛K-Line(DoK-Line)診斷系統(tǒng)第1部分:物理層（Roadvehicles—Diagnostic

communicationoverK-Line(DoK-Line)—Part1:Physicallayer）

ISO14230-2道路車輛K-Line(DoK-Line)診斷系統(tǒng)第2部分:數(shù)據(jù)鏈路層（Roadvehicles—Diagnostic

communicationoverK-Line(DoK-Line)—Part2:Datalinklayer）

ISO14230-4道路車輛K-Line(DoK-Line)診斷系統(tǒng)第4部分:排放相關系統(tǒng)的需求（Road

vehicles—Diagnosticsystems—KeywordProtocol2000—Part4:Requirementsforemission-relatedsystems）

ISO15765-1道路車輛基于控制器局域網(wǎng)的診斷通信第1部分：綜述（Roadvehicles—Diagnostic

communicationoverControllerAreaNetwork(DoCAN)—Part1:Generalinformationandusecasedefinition）

ISO15765-2道路車輛基于控制器局域網(wǎng)的診斷通信第2部分：傳輸層協(xié)議和網(wǎng)絡層服務（Road

vehicles—DiagnosticcommunicationoverControllerAreaNetwork(DoCAN)—Part2:Transportprotocoland

networklayerservices）

ISO15765-4道路車輛基于控制器局域網(wǎng)的診斷通信第3部分：排放相關系統(tǒng)的需求（Road

vehicles—DiagnosticcommunicationoverControllerAreaNetwork(DoCAN)—Part4:Requirementsfor

emissions-relatedsystems）

ISO17458-2道路車輛FlexRay通信系統(tǒng)第2部分：數(shù)據(jù)鏈路層規(guī)范(Roadvehicles—FlexRay

communicationssystem—Part2:Datalinklayerspecification)

ISO17458-4道路車輛FlexRay通信系統(tǒng)第4部分：電氣物理層規(guī)范(Roadvehicles—FlexRay

communicationssystem—Part4:Electricalphysicallayerspecification)

ISO17987-3道路車輛本地互連網(wǎng)絡(LIN)第3部分：協(xié)議規(guī)范(Roadvehicles—Local

InterconnectNetwork(LIN)—Part3:Protocolspecification)

3術語、定義和縮略語

3.1術語和定義

ISO/IEC7498-1、ISO14230-1、ISO14230-2、ISO10681-2、ISO15765-1、ISO15765-2以及ISO15765-4、

ISO17987（所有部分）中界定的及下列術語和定義適用于本文件。

3.1.1

網(wǎng)關gateway

用于在OSI各層級傳輸PDU的網(wǎng)絡設備。

示例：允許使用不同通信協(xié)議和不同通信速率的控制模塊網(wǎng)絡相互進行通信的網(wǎng)絡設備，包括但不限于網(wǎng)橋、交換機、路

由器或應用層路由等網(wǎng)關裝置。

3.1.2

路由器router

在OSI第3層和第4層傳輸PDU的網(wǎng)絡設備。

3.1.3

交換機switch

在OSI第2層傳輸PDU的網(wǎng)絡設備。

引導管理器bootmanager

引導軟件的一部分，在ECU電源接通或復位后立即執(zhí)行，其主要目的是檢查執(zhí)行重編程軟件的有效的應

用程序是否可控。

注：引導管理器還可以考慮將控制轉換到重新編程軟件的其他條件。

3.1.4

引導內存分區(qū)bootmemorypartition

引導軟件所在的服務端內存的區(qū)域。

3.1.5

引導軟件bootsoftware

在服務端內存的特殊部分中執(zhí)行的軟件，主要用于啟動ECU并執(zhí)行服務端刷新。

注1：刷新過程中，這個內存區(qū)域不會被擦除，并且當服務端應用程序丟失或被認為無效時必須執(zhí)行，以確保其重編程服

務端。

注2：參照術語3.1和3.17。

3.1.6

客戶端client

診斷儀的一個使用診斷服務的功能。（Tester）

注：診斷儀通常使用其他功能，如數(shù)據(jù)庫管理，數(shù)據(jù)解析，人機接口。

3.1.7

診斷數(shù)據(jù)diagnosticdata

電子控制單元的存儲器中的數(shù)據(jù)，且該數(shù)據(jù)可能被診斷儀檢查和/或可能被修改。

注1：診斷數(shù)據(jù)包括模擬輸入輸出，數(shù)字輸入輸出，中間值和各種狀態(tài)信息。

注2：診斷數(shù)據(jù)的示例如車速，節(jié)氣門開度，外后視鏡位置，系統(tǒng)狀態(tài)等。診斷數(shù)據(jù)定義了三種類型的值：

——當前值：電子控制單元正常運行當前使用的值（或由此產(chǎn)生）;

——存儲值：在特定時刻（例如當發(fā)生故障或周期性地）產(chǎn)生的當前值的內部備份;該備份在電子控制單元的控制下進行;

——靜態(tài)值：如VIN。

服務端沒有義務基于診斷的目的保留其數(shù)據(jù)的內部備份，在這種情況下，診斷儀只能請求當前值。

注3：基于售后或開發(fā)的應用場景會選擇不同的服務端功能（例如，只在開發(fā)的應用場景下，允許訪問所有存儲器位置）。

3.1.8

診斷例程diagnosticroutine

嵌入在電子控制單元中并且可以根據(jù)客戶端的請求由服務端啟動的例程。

注：它可以運行非正常的操作程序，或者可以在此模式下啟用并使用正常的操作程序執(zhí)行。在第一種情況下，不適用于

服務端的正常操作。在第二種情況下，當電子控制單元的所有其它部分正常工作時，可以運行多個診斷程序。

3.1.9

診斷服務diagnosticservice

客戶端發(fā)起的信息交換，以便請求服務端的診斷信息或/和基于診斷目的修改ECU行為。

3.1.10

診斷會話diagnosticsession

服務端啟用特定的診斷服務和功能集的內部狀態(tài)。

3.1.11

診斷故障碼diagnostictroublecode

DTC

由車載診斷系統(tǒng)定義的用于標識故障狀態(tài)的數(shù)字通用標識符。

3.1.12

電子控制單元ECU

至少包括一個服務端的電子控制單元。

注：被認為是電子控制單元的系統(tǒng)包括防抱死制動系統(tǒng)（ABS）和發(fā)動機管理系統(tǒng)。

3.1.13

功能單元functionalunit

功能密切相關或互補的診斷服務集。

3.1.14

整型integertype

具有不同值的簡單類型，包括正整數(shù)、負整數(shù)和零。

3.1.15

本地客戶端localclient

與服務端連接到同一本地網(wǎng)絡的客戶端，并且是與服務端同一地址空間。

3.1.16

本地服務端localserver

與客戶端連接到同一本地網(wǎng)絡的服務端，并且是與客戶端同一地址空間。

3.1.17

開放系統(tǒng)互聯(lián)opensystemsinterconnection

OSI

3.1.18

永久DTCpermanentDTC

即使在清除DTC請求之后，仍然保持在非易失性存儲器中的診斷故障碼（DTC），直到滿足其他要求才能

進行清除（例如，每個DTC的適合的監(jiān)視器已成功通過）。

3.1.19

記錄record

一個或多個通過唯一標識方式引用的診斷數(shù)據(jù)元素。

注：記錄的示例是包括各種輸入/輸出數(shù)據(jù)和故障代碼的快照。

3.1.20

遠程服務端remoteserver

不直接連接到診斷主網(wǎng)絡的服務端。

注1：通過遠程地址識別遠程服務端。遠程地址表示其地址獨立于主網(wǎng)絡的地址空間。

注2：通過主網(wǎng)絡上的本地服務端訪問遠程服務端。主網(wǎng)絡上的每個本地服務端都可以作為一組獨立的遠程服務端的網(wǎng)關。

因此，必須有一對地址始終用于識別遠程服務端：一個本地地址，用于標識遠程網(wǎng)絡的網(wǎng)關，以及一個標識遠程服務端本身的

遠程地址。

3.1.21

遠程客戶端remoteclient

不直接連接到診斷主網(wǎng)絡的客戶端。

注1：通過遠程地址識別遠程客戶端。

注2：遠程地址表示其地址獨立于主網(wǎng)絡的地址空間。

3.1.22

刷新軟件reprogrammingsoftware

引導軟件的一部分，用于電子控制單元的刷新。

3.1.23

安全security

保護車輛模塊不受來自車輛診斷數(shù)據(jù)鏈路“未授權”入侵的機制。

3.1.24

服務端server

電子控制單元提供診斷服務的部分功能。

3.1.25

支持的診斷故障碼（DTC）supportedDTC

當前被配置/標定并且能夠在預定義的車輛條件下執(zhí)行的診斷故障代碼，。

3.1.26

診斷設備tester

控制諸如車載電子控制單元的測試，檢查，監(jiān)控或診斷等功能的系統(tǒng)，可專用于特定類型的操作員（例

如專用于車庫機械的非車載掃描工具，專用于裝配廠的非車載測試工具或車載診斷儀）

注：診斷設備也被稱為客戶端。

3.2縮略語

下列縮略語適用于本文件。

.con：服務原語.確認（serviceprimitive.confirmation）

.ind：服務原語.指示（serviceprimitive.indication）

.req：服務原語.請求（serviceprimitive.request）

A_PCI：應用層協(xié)議控制信息（applicationlayerprotocolcontrolinformation）

AE：擴展地址（addressextension）

CF：連續(xù)幀（consecutiveframe）

CDD：通信數(shù)據(jù)詞典（commondatadictionary）

CMD：通信消息詞典（commonmessagedictionary）

DSC：診斷會話控制（diagnosticsessioncontrol）

DA：目標地址（destinationaddress）

DLC：數(shù)據(jù)長度碼（datalengthcode）

DoFR：基于FlexRay的診斷通信（diagnosticcommunicationoverFlexRay）

DID：數(shù)據(jù)標識符（dataidentifier）

DoIP：互聯(lián)網(wǎng)協(xié)議的診斷通信（diagnosticcommunicationoverInternetProtocol）

DoIP_AI：DoIP地址信息（DoIPaddressinformation）

ECU：電子控制單元（electroniccontrolunit）

EDR：事件數(shù)據(jù)記錄儀（eventdatarecorder）

FF：首幀（firstframe）

FB：首字節(jié)（firstbyte）

FC：流控幀（flowcontrol）

FF：第一幀（firstframe）

FR：總線（FlexRay）

ID：標識符（identifier）

IP：互聯(lián)網(wǎng)協(xié)議（InternetProtocol）

ISO：國際標準化組織（InternationalStandardizationOrganization）

LF：結束幀（lastframe）

Mtype：報文類型（messagetype）

NA：網(wǎng)絡地址（networkaddress）

NAD：節(jié)點地址（nodeaddress）

NCF：節(jié)點配置文件（nodeconfigurationfile）

N/A：不適用(notapplicable)

NR_SI：否定響應服務標識符（negativeresponseserviceidentifier）

NRC：否定響應代碼（negativeresponsecode）

OSI：開放系統(tǒng)互聯(lián)（opensystemsinterconnection）

P2：服務器響應時間（serverresponsetime）

pDID：周期數(shù)據(jù)標識符（periodicdataidentifier）

Rx：接收（reception）

SA：源地址（sourceaddress）

SF：單幀（singleframe）

SFID：子功能標識符（subfunctionidentifier）

SID：服務標識符（serviceidentifier）

SM：子網(wǎng)掩碼（subnetmask）

SOM：消息起始（startofmessage）

STF：起始幀（startframe）

STmin：間隔時間（separationtime）

STRT：待服務端響應（serviceToRespondTo）

S_AE：會話層地址擴展（sessionlayeraddressextension）

S_SA：會話層源地址（sessionlayersourceaddress）

S_Data：會話層數(shù)據(jù)傳輸服務名稱（sessionlayerdatatransferservicename）

SI：服務標識符（serviceidentifier）

SOM：消息起始（startofmessage）

S_Mtype：會話層消息類型（sessionlayermessagetype）

S_PDU：會話層協(xié)議數(shù)據(jù)單元（sessionlayerprotocoldataunit）

S_TA：會話層目標地址（sessionlayertargetaddress）

S_TAtype：會話層目標地址類型（sessionlayertargetaddresstype）

TA：目標地址（targetaddress）

Tx：發(fā)送（transmission）

UDS：統(tǒng)一診斷服務（unifieddiagnosticservices）

UDSonFR：基于FlexRay的統(tǒng)一診斷服務（UnifiedDiagnosticServices(UDS)onFlexRay）

UART：通用異步收發(fā)兩用機（universalasynchronousreceivertransmitter）

USDT：未確認分段數(shù)據(jù)傳輸（unacknowledgedsegmenteddatatransfer）

UUDT：未確認不分段數(shù)據(jù)傳輸（unacknowledgedunsegmenteddatatransfer）

VM：車輛制造商（vehiclemanufacturer）

4約定

本標準遵循適用于診斷服務的OSI服務公約（ISO/IEC10731）中的約定。

5規(guī)范和要求

5.1一般規(guī)定

本標準是基于OSI服務約定（ISO/IEC10731：1994）中的慣例，因為它們適用于診斷服務。

這些約定規(guī)定了服務用戶與服務提供者之間的交互。信息通過服務原語在服務用戶和服務提供者之間傳

遞參數(shù)。

服務和協(xié)議之間的區(qū)別如圖1所示。

本標準定義了確認和未確認的服務。

確認的服務使用六個服務原語請求，請求確認，指示，響應，響應確認和確認。

未確認的服務僅使用請求，請求確認和指示服務原語。

圖1依據(jù)OSI模型的UDS參考文件實施

本標準定義的所有服務，請求和指示服務原語都具有相同的格式和參數(shù)。因此，對于所有服務，響應和確

認服務原語（除了請求確認和響應確認）總是具有相同的格式和參數(shù)。

本標準在定義服務原語時，僅列出請求和響應服務原語。

5.2應用層服務

5.2.1概述

應用層服務通常被稱為診斷服務。應用層服務用于基于客戶端-服務端的系統(tǒng)，以執(zhí)行諸如車載車輛服

務端的測試，檢查，監(jiān)控或診斷等功能?？蛻舳耍ㄍǔ７Q為診斷設備）使用應用層服務來請求在一個或多個服

務端中執(zhí)行診斷功能。服務端（通常作為ECU的部分功能）使用應用層服務將由請求的診斷服務提供的響應數(shù)

據(jù)發(fā)送回客戶端。客戶端通常是非車載診斷儀，但在某些系統(tǒng)中也可以是車載診斷儀。應用層服務的使用獨立

于客戶端，無論該客戶端是車載還是非車載診斷儀。同一車輛系統(tǒng)中允許有多個客戶端。

診斷應用層的服務接口提供了大量具有相同通用結構的服務。對于每個服務，規(guī)定了六項服務原語：由診

斷儀應用中的客戶端功能使用的服務請求原語，將所請求的診斷服務的數(shù)據(jù)傳遞到診斷應用層：

——服務請求原語：在診斷儀應用中由客戶端使用，將所請求的診斷服務的數(shù)據(jù)傳遞到診斷應用層;

——服務請求-確認原語：在診斷儀應用中由客戶端使用，指示在服務請求原語中傳遞的數(shù)據(jù)在診斷儀所

連接得總線上成功發(fā)送;

——服務指示原語：由診斷應用層使用，將數(shù)據(jù)發(fā)送到ECU診斷應用的服務端；

——服務響應原語：由ECU診斷應用的服務端使用，將由所請求的診斷服務提供的響應數(shù)據(jù)發(fā)送到診斷應

用層；

——服務響應-確認原語：由ECU診斷應用中的服務端使用，指示在ECU接收到診斷請求的總線上成功發(fā)

送服務響應原語中傳遞的數(shù)據(jù)；

——服務確認原語：由診斷應用層使用，將數(shù)據(jù)發(fā)送給診斷儀應用中的客戶端。

圖3中是應用層服務原語-確認服務。

時間時間

客戶端應用層服務器應用層

P2_ClientP2_Server

ServiceName.request

請求

開始消息開始

ServiceName.request-confirmServiceName.indication

結束

ServiceName.response

響應

消息

結束

ServiceName.confirmServiceName.response-confirm

時間時間

圖3應用層服務原語-確認服務

圖4描述了應用層服務原語-非確認服務

時間時間

客戶端應用層服務器應用層

P2_ClientP2_Server

ServiceName.request

請求

消息

ServiceName.request-confirmServiceName.indication

時間時間

圖4應用層服務原語-非確認服務

對于給定的服務，請求-確認原語和響應-確認原語通常具有相同的服務數(shù)據(jù)單元。這些服務原語的目的是

指示先前的請求或響應服務原語調用已經(jīng)完成。本標準中描述的服務將不會使用這些服務原語，但是數(shù)據(jù)鏈路

特定的實施文檔可能會使用這些描述來定義諸如服務執(zhí)行參考點。（當響應完全傳送到客戶端時，ECU復位服

務將調用復位，客戶端通過服務端響應確認原語在服務端中指示）

5.2.2應用層服務格式描述

應用層服務可以具有兩種不同的格式，具體取決于車輛診斷系統(tǒng)的配置方式。應用層服務的格式由參數(shù)

A_Mtype控制。

如果把車輛系統(tǒng)配置到客戶端可以使用A_SA和A_TA地址參數(shù)對所有服務端進行尋址，則應使用應用層服

務的默認格式。即A_Mtype=diagnostics。

如果把車輛系統(tǒng)配置到客戶端需要使用除了A_SA和A_TA地址參數(shù)之外的地址信息對特定服務端進行尋

址，則應使用應用層服務的遠程格式。即A_Mtype=remotediagnostics。

應用層服務的不同格式在6.3中規(guī)定。

5.2.3服務原語的格式描述

通用定義

所有應用層服務都具有相同的通用格式。服務原語是按如下格式進行編寫：

service_name.type(

parameterA,parameterB,parameterC

[,parameter1,...]

)

注：

——“service_name”是診斷服務的名稱（例如：診斷會話控制），

——“type”指示服務原語的類型（例如：請求），

——“parameterA,...”是A_SDU（應用層服務數(shù)據(jù)單元）作為服務原語傳遞的值的列表（尋址信息），

——“parameterA,parameterB,parameterC”是必須包含在所有服務調用中的強制參數(shù)。

——“[,parameter1,...]”是取決于特定服務的參數(shù)（例如：parameter1可以是診斷會話控制服務的診斷會話）。[]

表示參數(shù)列表的這一部分可能為空。

服務請求和服務指示原語

對于每個應用層服務，根據(jù)以下通用格式指定服務請求和服務指示原語：

service_name.request(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Length,

A_Data[,parameter1,...],

)

診斷設備應用程序中的客戶端功能使用請求原語啟動服務并將所請求的診斷服務的數(shù)據(jù)傳遞給應用層。

service_name.indication(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Length,

A_Data[,parameter1,...],

)

應用層使用指示原語來指示對ECU診斷應用程序有重要意義的內部事件，并將關于所請求診斷服務的數(shù)據(jù)

傳遞給ECU診斷應用程序的服務端功能。這意味著當數(shù)據(jù)從客戶端發(fā)送到服務端時，各個參數(shù)的值不應由應用

層的對等通信協(xié)議實體改變。由客戶端應用程序中的客戶端功能傳遞到服務請求呼叫的應用層的相同值將由對

等應用層的服務指示由診斷應用程序的服務端功能接收。

服務響應和服務確認原語

對于每個應用層服務，根據(jù)以下通用格式指定服務響應和服務確認原語：

service_name.response(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Length,

A_Data[,parameter1,...],

)

ECU診斷應用程序中的服務端功能使用響應原語來啟動服務并將所請求的診斷服務提供的響應數(shù)據(jù)發(fā)送

到應用層。

service_name.confirm(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Length,

A_Data[,parameter1,...],

)

應用層使用確認原語來指示對客戶端應用有重要意義的內部事件，并將關聯(lián)的之前的服務所請求的結果傳

遞給診斷設備應用程序中的客戶端功能。它不一定指示遠程對等接口的任意活動，例如，如果服務端不支持所

請求的服務或者通信被破壞。

特定應用層的響應和確認原語通常具有相同的參數(shù)和參數(shù)值。這意味著當數(shù)據(jù)從服務端發(fā)送到客戶端時，

各個參數(shù)的值不應被應用層的對等通信協(xié)議實體改變。由ECU診斷應用程序的服務端功能傳遞到服務響應呼叫

中的應用層的相同值將由客戶端功能在診斷測試應用程序中從對等應用層的服務確認接收。

對于每個響應和確認原語將規(guī)定兩種不同的服務數(shù)據(jù)單元（兩組參數(shù)）。

——如果請求的診斷服務可以通過ECU中的服務端功能成功執(zhí)行，則應與第一個服務數(shù)據(jù)單元一起使用肯

定響應和肯定確認原語。

——如果請求的診斷服務失敗或不能通過ECU中的服務端功能及時完成，則應將第二服務數(shù)據(jù)單元用于否

定響應和否定確認原語。

服務請求-確認和服務響應-確認原語

對于每個應用層服務，根據(jù)以下通用格式規(guī)定服務請求-響應和服務響應-確認原語：

service_name.req_confirm(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Result

)

應用層使用請求-確認原語來指示對客戶端應用程序有重要意義的內部事件，并將關聯(lián)的之前的服務所請

求的結果傳遞給診斷設備應用程序中的客戶端功能。

service_name.rsp_confirm(

A_MType,

A_SA,

A_TA,

A_TA_type,

[A_AE],

A_Result

)

應用層使用響應-確認原語來指示對服務端應用程序有重要意義的內部事件，并將關聯(lián)的之前的服務所響

應的結果傳遞給診斷設備應用程序中的服務端功能。

5.2.4服務數(shù)據(jù)單元定義

強制參數(shù)

.1通用定義

應用層服務包含三個強制參數(shù)。以下參數(shù)定義適用于本標準中規(guī)定的所有應用層服務（標準和遠程格式）。

.2A_Mtype,應用層消息類型

類型：枚舉

范圍：診斷，遠程診斷

描述：

參數(shù)Mtype應用于識別6.2中規(guī)定的車輛診斷系統(tǒng)的格式。本標準為此參數(shù)指定了兩個值的范圍：

如果A_Mtype=診斷，service_name原語應由參數(shù)A_SA，A_TA和A_TAtype組成。

如果A_Mtype=遠程診斷，service_name原語應由參數(shù)A_SA，A_TA、A_TAtype和A_AE組成。

.3A_SA，應用層源地址

類型：2字節(jié)無符號整型數(shù)值

范圍：0x0000–0xFFFF

描述：

參數(shù)SA應用于對標識客戶端和服務端地址的標識符進行編碼。

對于服務請求（和服務指示），A_SA表示已請求診斷服務的客戶端地址。請求診斷服務的每個客戶端功都

應用一個A_SA值表示。如果在同一個診斷設備實現(xiàn)多個客戶端，那么每個客戶端應具有自己的客戶端標識符

和相應的A_SA值。

對于服務響應（和服務確認），A_SA表示已執(zhí)行請求的診斷服務的服務端的地址。服務端可以在一個ECU

中實現(xiàn)，也可以在多個ECU中分布式實現(xiàn)。如果服務端僅在一個ECU中實現(xiàn)，則只能使用一個A_SA值進行編

碼。如果服務端在多個ECU中分布式實現(xiàn)，則相應的服務端功能地址應為每個服務端編碼一個A_SA值。

如果消息來源于遠程客戶端或服務端，則A_SA代表本地服務端，該服務端為遠程網(wǎng)絡到主網(wǎng)絡的網(wǎng)關。

注：如果使用物理尋址請求消息，響應消息中的A_SA值將與相應請求消息中的A_TA值相同。

.4A_TA，應用層目標地址

類型：2字節(jié)無符號整型數(shù)值

范圍：0x0000–0xFFFF

描述：

參數(shù)A_TA應用于對標識客戶端和服務端地址的標識符進行編碼。

有兩種尋址方式：

——物理尋址；

——功能尋址。

因此，可以為車輛系統(tǒng)定義兩個獨立的目標地址集（每個尋址方式一個）。

物理尋址始終是在一個ECU中實現(xiàn)的服務端的專用消息。當使用物理尋址時，通信是客戶端和服務端之間

的點對點通信。

如果客戶端不知道要響應診斷服務請求的服務端的物理地址，或者服務端是否在多個ECU中分布實現(xiàn)，則

客戶端將使用功能尋址。當使用功能尋址時，通信是從客戶端到在一個或多個ECU中實現(xiàn)的服務端的廣播通信。

對于服務請求（和服務指示），A_TA表示將執(zhí)行請求的診斷服務的服務端的標識符。如果正在尋址遠程服

務端，則A_TA代表本地服務端，該服務端為遠程網(wǎng)絡到主網(wǎng)絡的網(wǎng)關。

對于服務響應（和服務確認），A_TA表示最初請求診斷服務并應接收請求的數(shù)據(jù)（即請求的A_SA）的客戶

端地址。服務響應（和服務確認）應始終使用物理尋址。如果遠程客戶端被尋址，則A_TA代表本地服務端，

該服務端為遠程網(wǎng)絡到主網(wǎng)絡的網(wǎng)關。

注：響應消息的A_TA值始終與相應請求消息的A_SA值相同。

.5A_TA_Type，應用層目標地址類型

類型：枚舉

范圍：物理，功能

描述：

參數(shù)A_TA_type是A_TA參數(shù)的擴展。它用于表示傳輸消息的尋址方式。

.6A_Result

類型：枚舉

范圍：ok,error

描述：

req_confirm和rsp_confirm原語使用參數(shù)“A_Result”來指示消息是否已正確發(fā)送（ok）或消息傳輸是否不

成功（錯誤）。

.7A_Length

類型：4字節(jié)無符號整型數(shù)值

范圍：0d–(232-1)d

描述:

該參數(shù)包括發(fā)送/接收的數(shù)據(jù)的長度。

.8A_Data

類型：字節(jié)流

范圍：N/A

描述：

該參數(shù)包括要由較高層實體交換的所有數(shù)據(jù)。

車輛系統(tǒng)要求

車輛制造商應確保系統(tǒng)中的每個服務端都具有唯一的標識服務端地址的標識符。車輛制造商應確保系統(tǒng)中

的每個客戶端都具有唯一的標識客戶端地址的標識符。

車輛系統(tǒng)診斷網(wǎng)絡的所有客戶端和服務端地址都應編碼在相同的源地址范圍內。這表示客戶端和服務端不

能在同一給定的車輛系統(tǒng)中用相同的A_SA值表示。

服務端的物理目標地址應始終與服務端的源地址相同。

遠程服務端標識符的分配可以獨立于主網(wǎng)絡上的標識客戶端和服務端地址的標識符。

一般來說，只有所尋址的服務端應響應客戶端請求的消息。

可選參數(shù)-A_AE，應用層遠程地址

類型：2字節(jié)無符號整型數(shù)值

范圍：0x0000–0xFFFF

描述：

A_AE用于擴展可用的地址范圍以對客戶端和服務端標識符進行編碼。A_AE只能用于區(qū)分本地服務端和遠

程服務端概念的車輛。遠程地址表示其自身的地址范圍，與主網(wǎng)絡上的地址無關。

參數(shù)A_AE應用于編碼遠程客戶端和服務端標識符。A_AE可以根據(jù)具有A_AE的消息的方向表示遠程目標

地址或遠程源地址。

對于由主網(wǎng)絡上的客戶端發(fā)送的服務請求（和服務指示），A_AE表示將執(zhí)行請求的診斷服務的遠程服務端

標識符（遠程目標地址）。

A_AE可以用作物理地址和功能地址。對于A_AE的每個值，系統(tǒng)構建器應指定該值表示的是物理地址還是

功能地址。

注：沒有特殊參數(shù)用以表示物理或功能的遠程地址，以A_TA_type指定A_TA的尋址方法的方式。物理和

功能遠程地址共享相同的1字節(jié)范圍的值，每個值的含義應由系統(tǒng)架構師定義。

對于由遠程服務端發(fā)送的服務響應（和服務確認），A_AE表示已執(zhí)行請求的診斷服務的遠程服務端的物理

位置（遠程源地址）。

遠程服務端可以僅在一個ECU中實現(xiàn)，或者在多個ECU中分布實現(xiàn)。如果遠程服務端僅在一個ECU中實

現(xiàn)，則只能使用一個A_AE值進行編碼。如果遠程服務端在多個ECU中分布實現(xiàn)，則應使用一個A_AE值對遠

程客戶端標識符進行編碼，且遠程服務端的每個物理地址都有一個A_AE值。

5.3應用層協(xié)議

5.3.1一般定義

應用層協(xié)議應始終是確認的消息傳輸，這意味著對于從客戶端發(fā)送的每個服務請求，服務端應發(fā)送一個或

多個相應的響應。

該規(guī)則的唯一例外是在使用功能尋址時的一些情況，或者請求/指示規(guī)定不應產(chǎn)生響應/確認。為了不給系

統(tǒng)帶來許多不必要的消息，在幾個情況下，即使服務端無法完成請求的診斷服務，也不會發(fā)送否定的響應消息。

這些例外情況在本標準的相關小節(jié)中進行了描述（例如，見7.5）。

應用層協(xié)議應與會話層協(xié)議并行處理。這意味著即使客戶端正在等待之前發(fā)出的請求的響應，也應符合適

當?shù)臅拰佣〞r要求（例如，根據(jù)需要發(fā)送“診斷設備在線服務”請求以保持其他服務端的診斷會話，其實現(xiàn)

取決于所使用的數(shù)據(jù)鏈路層）。

5.3.2協(xié)議數(shù)據(jù)單元規(guī)定

A_PDU（應用層協(xié)議數(shù)據(jù)單元）由A_SDU（應用層服務數(shù)據(jù)單元）和層特定控制信息A_PCI（應用層協(xié)議

控制信息）直接構成。A_PDU應具有以下通用格式：

A_PDU(

Mtype,

SA,

TA,

TA_type,

[RA,]

A_Data=A_PCI+[parameter1,...],

Length

)

其中：

——“Mtype，SA，TA，TA_type，RA，Length”與A_SDU中使用的參數(shù)相同;

——“A_Data”是為每個單獨的應用層服務定義的一串字節(jié)數(shù)據(jù)。A_Data字符串應以A_PCI開頭，后面

是每個服務指定的A_SDU的所有服務特定參數(shù)。括號表示參數(shù)列表的這部分可能為空;

——“Length”決定A_Data的字節(jié)數(shù)。

5.3.3應用層協(xié)議控制信息

PCI，協(xié)議控制信息

A_PCI有兩種格式。A_PCI參數(shù)的第一個字節(jié)的值代表格式。

對于所有第一個字節(jié)不等于0x7F的服務請求和服務響應，應使用以下定義：

A_PCI(

SI)

其中：

——“SI”是參數(shù)服務標識符。

對于第一個字節(jié)值等于0x7F的服務響應，應使用以下定義：

A_PCI(

NR_SI,

SI

)

其中：

——“NR_SI”是識別否定服務響應/確認的特殊參數(shù);

——“SI”是服務標識符的參數(shù)。

注：對于服務通過周期性標識符讀取數(shù)據(jù)（0x2A，見10.5）中定義的周期性數(shù)據(jù)響應消息的傳輸，應用層協(xié)議數(shù)據(jù)單元（A_PDU）

中不存在A_PCI。

SI，服務標識符

類型：1字節(jié)無符號整型數(shù)值

范圍：0x00–0xFF根據(jù)表2的定義。

表2服務標識符定義

服務標識符服務類型（第6位）定義出處

0x10–0x3E本標準定義的服務請求本標準

0x3F不適用預留

0x50–0x7E本標準定義的肯定響應本標準

0x7F否定響應服務標識符本標準

0x80–0x82不適用本標準預留

0x83–0x88本標準定義的服務請求本標準

0x89–0xB9不適用本標準預留

0xBA–0xBE服務請求系統(tǒng)供應商定義

0xBF–0xC2不適用本標準預留

0xC3–0xC8本標準定義的肯定響應本標準

0xC9–0xF9不適用本標準預留

0xFA–0xFE肯定響應系統(tǒng)供應商定義

0xFF不適用預留

注：請求消息的服務標識符和肯定響應消息的服務標識符之間存在一一對應的關系，SI字節(jié)值的第7位（bit6）表示服務

類型。所有請求消息的SI第7位（bit6）=0。除了通過“周期性標識符讀取數(shù)據(jù)”（0x2A，參見10.5）服務的定期數(shù)據(jù)響

應消息之外，所有肯定響應消息的SI第7位（bit6）=1。

描述：

SI將用于對服務原語中已被調用的特定服務進行編碼。每個請求服務應分配一個唯一的SI值。每個肯定

響應服務也應分配相應的唯一SI值。

服務標識符用于表示從應用層傳遞到較低層（并從較低層返回）的A_Data數(shù)據(jù)字符串中的服務。

NR_SI,否定響應服務標識符

類型：1字節(jié)無符號整型值

固定值：0x7F

描述：

參數(shù)NR_SI是識別否定服務響應/確認的特殊參數(shù)。應是A_PCI的一部分，用于否定響應/確認消息。

注：NR_SI值與SI值協(xié)調。為了使A_Data編碼和解碼更容易，NR_SI值不用于SI值。

5.3.4否定響應/確認服務原語

每個診斷服務都具有否定響應/否定確認消息，根據(jù)表3中的A_Data字節(jié)值定義。A_Data第一個字節(jié)

（A_PCI.NR_SI）通常是特定的否定響應服務標識符。A_Data第二個字節(jié)（A_PCI.SI）應為否定響應消息對應的

服務請求/指示消息的服務標識符值的副本。

表3A_PDU否定響應

A_PDU參數(shù)參數(shù)名稱約定值字節(jié)值助記符

SA源地址M0xXXXXSA

TA目標地址M0xXXXXTA

TAtype目標地址類型M0xXXTAT

RA遠程地址C0xXXXXRA

A_Data.A_PCI.NR_SI否定響應SIDM0x7FSIDNR

A_Data.A_PCI.SI<服務名稱>請求SIDM0xXXSIDRQ

A_Data.Parameter1響應碼M0xXXNRC_

M(強制)：在發(fā)出否定響應A_PDU的情況下，這些A_PDU參數(shù)應該存在。

C（有條件的）：RA（遠程地址）PDU參數(shù)僅在遠程尋址的情況下才存在。

注：A_Data代表否定響應消息的消息數(shù)據(jù)字節(jié)。

在否定響應消息中使用參數(shù)responseCode來指示診斷服務失敗或無法及時完成的原因。這些值在附錄A.1

中定義。

5.3.5服務端響應實施規(guī)則

一般定義

以下小節(jié)規(guī)定了執(zhí)行服務時的服務端的行為。服務端和客戶端應遵循這些實施規(guī)則。

一般的服務端響應行為

本節(jié)中規(guī)定的一般的服務端響應行為對所有請求消息都是必需的。驗證步驟從接收請求消息開始。下圖

展示了三種實現(xiàn)要求：

——強制：每個請求消息都要進行檢查

——可選：可以由每個請求消息來選擇性地進行檢查

——制造商/供應商自定義：該步驟可以通過附加的制造商/供應商的具體檢查來擴展。

整車廠/供

可選應商自定

強制義

服務器是

否忙碌？

YES

否定響應碼0x21

NO

是否探測到

制造商指定