UDS診斷概述

UDS（Unified Diagnostic Services，統(tǒng)一的診斷服務(wù)）診斷協(xié)議是在汽車電子ECU環(huán)境下的一種診斷通訊協(xié)議。簡單來說，可以理解為UDS診斷協(xié)議就是ISO 14229協(xié)議，在ISO 14229協(xié)議中定義了UDS服務(wù)用法、服務(wù)格式等信息。UDS診斷最主要目的是為了能夠快速準(zhǔn)確判斷車輛或者某個控制器的故障以及故障原因，從而為維修提供可靠的依據(jù)。

診斷服務(wù)概覽

UDS診斷包括6大類，26種服務(wù)，每種服務(wù)都有自己獨(dú)立的ID，即SID（Service Identifier）

常見NRC碼

什么是NRC？一句話總結(jié)，NRC碼用來快速判斷故障原因的重要依據(jù)。

不同會話支持的服務(wù)

并不是所有服務(wù)都只在一個會話下活動，由此就有了會話優(yōu)先級的概念，下圖列出了不同會話下支持的服務(wù)列表。

尋址方式

UDS診斷服務(wù)是實現(xiàn)人或設(shè)備與ECU控制器交流的一種語言，在總線上往往有著眾多ECU設(shè)備，作為診斷設(shè)備既可以與所有的ECU一起溝通，也可以指定某一個ECU單獨(dú)溝通。所以尋址方式就有功能尋址（Functionally Addressed）和物理尋址（Physically Addressed）兩種。

1、功能尋址：即廣播診斷請求Request，同時等待總線上的ECU給與響應(yīng)。

2、物理尋址：指定發(fā)送特定診斷請求Request，等待指定ECU給與響應(yīng)。

$10會話控制

DiagnosticSessionControl（診斷會話控制）服務(wù)用于啟用服務(wù)器中的不同診斷會話。該服務(wù)是在服務(wù)器端使能不同的會話模式，可以通過會話模式賦予不同診斷服務(wù)的執(zhí)行權(quán)限。

請求格式：

響應(yīng)格式：

支持的NRC：

$3E會話保持

3E服務(wù)用于會話模式一直保持在非默認(rèn)會話，不會因為3E時間超時而自動掉到默認(rèn)會話。

請求格式：

響應(yīng)格式：

支持的NRC：

$11ECU復(fù)位

此服務(wù)主要基于請求消息中復(fù)位類型執(zhí)行ECU復(fù)位。在ECU執(zhí)行復(fù)位之前，ECU需回復(fù)肯定響應(yīng)消息，才可復(fù)位成功，在ECU成功復(fù)位后，ECU應(yīng)激活默認(rèn)會話。

常用的復(fù)位類型，即子功能：

11 01 硬復(fù)位，即模擬的狀態(tài)為電源斷開再重新接上的復(fù)位。

11 02 Keyoffon復(fù)位，模擬的是駕駛員先關(guān)閉點(diǎn)火開關(guān)再打開類型的復(fù)位。

11 03 軟復(fù)位，模擬的是軟件請求的復(fù)位，如軟件內(nèi)部出現(xiàn)非預(yù)期執(zhí)行時觸發(fā)的Reset。

請求格式：

響應(yīng)格式：

支持的NRC：

$14清除DTC

此服務(wù)它可以改變DTC的狀態(tài)。DTC狀態(tài)中的八個位，除bit4和bit6外均會被清零，包含當(dāng)前故障（TestFailed）和歷史故障(ConfirmedDTC）。bit4和bit6這兩個testNotCompleted開頭的會被強(qiáng)制置1。

示例：14 FF FF FF(清除所有DTC) ,此參數(shù)包含3個字節(jié)的值，表示要清除的DTC組(例如動力總成，車身，底盤)或特定的DTC。

請求格式：

響應(yīng)格式：

支持的NRC：

$19 讀取DTC

19服務(wù)是UDS里的重中之重了，可謂是沒有19服務(wù)就失去了診斷服務(wù)的意義，下面就詳細(xì)介紹下此服務(wù)的作用以及用法。

故障碼包括四個大類，分別是PCBU，P是powertrain動力系統(tǒng)，C是Chassis底盤，B是Body車身，U是network通信系統(tǒng)。一個DTC信息占用4個字節(jié)。最后一個字節(jié)是DTC的狀態(tài)。

19 01 讀取DTC數(shù)量

通過狀態(tài)掩碼去查找與其相匹配的故障個數(shù)，通過該服務(wù)診斷儀能夠請求ECU中DTC狀態(tài)與DTC狀態(tài)掩碼相匹配的故障碼個數(shù)。如果某一個故障碼的實際狀態(tài)位為1，并且DTC狀態(tài)掩碼中的相應(yīng)位也為1，那么就認(rèn)為該故障碼的狀態(tài)與DTC狀態(tài)掩碼相匹（即：如果DTC狀態(tài)掩碼字節(jié)與DTC實際狀態(tài)字節(jié)進(jìn)行邏輯“位與”運(yùn)算后的結(jié)果為非零值，那么兩者就相匹配）；此時則將故障數(shù)+1。如果診斷儀定義了一個狀態(tài)掩碼，其中包含ECU不支持的位，那么ECU僅使用本身支持的位進(jìn)行處理故障信息。

請求格式

響應(yīng)格式：

19 02 讀取DTC列表

按照定義的狀態(tài)掩碼的形式去查找匹配的故障：將匹配的DTC標(biāo)識符（3個字節(jié)）、DTC狀態(tài)（1個字節(jié)）信息返回。上一小節(jié)的01子服務(wù)只統(tǒng)計與狀態(tài)掩碼相匹配的DTC個數(shù)，02子服務(wù)則會將這些匹配的DTC信息返回。

請求格式：

響應(yīng)格式：

19 03 讀取DTC快照信息

請求格式：

響應(yīng)格式：

19 04 讀取指定DTC快照信息

為了方便找到故障的原因，車廠一般會在診斷調(diào)查表中定義一些信息作為快照信息，例如故障的發(fā)生時間、電壓、行駛里程數(shù)、車速等。在對應(yīng)故障發(fā)生時，ECU端要記錄發(fā)生故障時的快照信息；而04服務(wù)就是用于請求指定故障碼（DTC）的快照信息，通過查找故障發(fā)生時刻的這些數(shù)據(jù)，來分析故障原因。

請求格式：

響應(yīng)格式：

上圖：響應(yīng)報文中DTCSnapshotRecordNumber表示返回的是該DTC的哪一個快照記錄；DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定義的成員量；如定義的快照數(shù)據(jù)有車速、電壓、轉(zhuǎn)速、里程這四項信息；

19 06讀取擴(kuò)展數(shù)據(jù)信息

除了前面04服務(wù)的快照信息；一般還會再定義一個擴(kuò)展信息，用于記錄故障的一些其他信息，比如故障發(fā)生的次數(shù)、老化次數(shù)、已老化次數(shù)等。而將下來介紹的06服務(wù)就是用于請求指定故障碼（DTC）的擴(kuò)展信息。

請求格式：

響應(yīng)格式：

19 0A 讀取所有DTC信息

請求所有支持的DTC信息（3字節(jié)的DTC標(biāo)識符+1字節(jié)的DTC狀態(tài)位），其響應(yīng)報文與02服務(wù)一致；但要區(qū)分，該服務(wù)返回的是所有DTC的信息；而02服務(wù)是返回與請求時狀態(tài)掩碼相與不為0 的DTC信息。

請求格式：

響應(yīng)格式：

支持的NRC：

$85控制DTC設(shè)置

此服務(wù)用于在診斷刷寫的過程中關(guān)閉DTC記錄，因為在刷寫的過程中往往是針對某個ECU節(jié)點(diǎn)單獨(dú)進(jìn)行刷寫，其他的對手件ECU節(jié)點(diǎn)始終處于正常工作狀態(tài)，那么此時應(yīng)當(dāng)發(fā)送功能尋址給到各ECU節(jié)點(diǎn)使得其停止記錄DTC，刷寫完成之后再重新開啟對手件DTC記錄功能即可。

常用子功能

85 01：繼續(xù)更新狀態(tài)碼狀態(tài)位。

85 02：停止更新狀態(tài)碼狀態(tài)位。

請求格式

響應(yīng)格式：

支持的NRC:

$19服務(wù)故障狀態(tài)掩碼位定義

該mask由主機(jī)廠提供：

#主要第0位和第三位用的比較多，所以一般故障掩碼的值為0x09

bit 0 testFailed：

指示最近執(zhí)行test的結(jié)果，test失敗置1，但是它不一定被ECU存儲到EEprom中，只有當(dāng)bit2或bit3被置1時DTC才會被存儲。test通過則置0，如果調(diào)用了14服務(wù)清除DTC的話，也需要重新置0

“0”= DTC測試的最新結(jié)果表明未檢測到故障。

“1”= DTC測試的最新結(jié)果表明了一個成熟的失敗結(jié)果。

—————————————————————————————

bit 1 testFailedThisOperationCycle ：

該位表示在當(dāng)前test中，診斷test是否已經(jīng)報告了一個testFailed結(jié)果。當(dāng)新的檢測循環(huán)開始時，這個位需要置0，在調(diào)用了14服務(wù)后也需要置0。如果該位置1，那么一直保持置1狀態(tài)直到新的檢測循環(huán)開始，因此bit1可以理解為當(dāng)前DTC。如果bit2和bit3通常一起使用。對于沒有網(wǎng)絡(luò)管理的 ECU，這個起始點(diǎn)就是 KL15 通斷。也就是說上電時間內(nèi)出現(xiàn)的故障，該位都會置1，不管是否存儲。

“0”= testFailed:在當(dāng)前操作周期內(nèi)或在當(dāng)前操作周期內(nèi)調(diào)用ClearDiagnosticInformation后，尚未報告testFailed結(jié)果。

“1”= testFailed:在當(dāng)前操作周期中至少報告了一次testFailed結(jié)果。

—————————————————————————————

bit 2 pendingDTC ：

根據(jù)ISO 14229的定義，當(dāng)一個test結(jié)束時，若某個DTC滿足故障觸發(fā)條件，則bit2置1。bit2位其實是表示DTC處于testFailed和confirmedDTC之間的一個狀態(tài)，稱為待定DTC。因為DTC并不是一達(dá)到觸發(fā)位就會被報出來的，而是故障出現(xiàn)一段時間后才會被確認(rèn)，而中間的這個狀態(tài)就用bit2位來表示，因此bit2位又可被稱為待定DTC。當(dāng)某個DTC剛達(dá)到判定條件的時候，bit2被置1，若一段時間后故障條件不滿足了，則bit2置0，若一段時間后故障仍然存在，那么bit3就要置1了。

“0”= 在完成測試完成且未檢測到故障的操作循環(huán)后或調(diào)用ClearDiagnosticInformation服務(wù)時，該位應(yīng)設(shè)置為0。

“1”= 如果在當(dāng)前操作循環(huán)中檢測到故障，則該位應(yīng)設(shè)置為1并鎖定。

—————————————————————————————

bit 3 confirmedDTC ：

當(dāng)bit3置1時，說明故障已經(jīng)發(fā)生了一段時間，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的時候，DTC被存儲在EEprom中，但并不代表現(xiàn)在故障還存在，所以可以理解為歷史故障。在調(diào)用14服務(wù)清除DTC后需要置0。

“0”= 自上次調(diào)用ClearDiagnosticInformation后，或在滿足故障診斷碼的老化條件（或由于故障記憶溢出而清除了故障診斷碼）后，從未確認(rèn)過故障診斷碼。

“1”= 自上次調(diào)用ClearDiagnosticInformation后至少確認(rèn)一次的DTC，且尚未滿足老化標(biāo)準(zhǔn)

—————————————————————————————

bit 4 testNotCompletedSinceLastClear：

因為并不是所有的DTC測試都是從上電就開始的，所以該位用來表示上次調(diào)用14服務(wù)清除診斷消息后，是否進(jìn)行過完整的test。如果進(jìn)行了完整的test，無論結(jié)果如何，都置0，否則置1。

“0”= 自上次清除診斷信息以來，DTC測試至少返回一次測試結(jié)果（無論通過或失?。?。

“1”= 自上次清除診斷信息后，DTC測試尚未運(yùn)行到完成。

—————————————————————————————

bit 5 testFailedSinceLastClear ：

該位表示在上次調(diào)用14服務(wù)清除后DTC后，若test DTC未進(jìn)行測試或者測試了但結(jié)果是pass時置0，如果test運(yùn)行完成并且返回結(jié)果為fails，那么該位置1。在調(diào)用14服務(wù)清除DTC后需要置0。bit4和bit5通常一起使用。

“0”=自上次清除診斷信息后，DTC測試未顯示失敗結(jié)果。如果滿足老化閾值或發(fā)生故障記憶溢出，則車輛制造商應(yīng)負(fù)責(zé)將該位重置為零（“0”）。

“1”=自上次清除診斷信息以來，DTC測試至少返回一次失敗結(jié)果。

—————————————————————————————

bit 6 testNotCompletedThisOperationCycle：

該位表示在當(dāng)前檢測循環(huán)周期過程中DTC test是否完成，若完成了置0，未完成置1。在調(diào)用ClearDiagnosticDTC后需要置1。

“0”= DTC測試在當(dāng)前駕駛循環(huán)期間（或自上次在當(dāng)前操作循環(huán)期間清除診斷信息以來）完成。

“1”= 此操作循環(huán)（或自上次清除此操作循環(huán)的診斷信息后），DTC測試尚未運(yùn)行到完成。

—————————————————————————————

bit 7 : warningIndicatorRequested

該位報告警告指示，比如說儀表盤上的警示燈等。但不是所有的DTC都會有警告指示，如果沒有和DTC相關(guān)的警告存在，該位應(yīng)置0；如果該DTC有相關(guān)警告指示，bit3置1的時候，bit7也要置1。在調(diào)用14服務(wù)清除DTC后需要置0

—————————————————————————————

$19擁有28個子服務(wù)（Sub-Function）。常用的子服務(wù)有：掩碼類型：01 (讀取符合掩碼條件的DTC數(shù)量),后面的參數(shù)是DTC狀態(tài)掩碼，若為01表示我想讀當(dāng)前故障，若為08表示我想讀歷史故障，若為09表示當(dāng)前故障和歷史故障都想讀。

$22讀數(shù)據(jù)

22服務(wù)其英文全稱：ReadDataByIdentifier Service，為通過DID讀取數(shù)據(jù)的服務(wù)，例如，在使用中可以通過22服務(wù)去獲取軟件的版本號，車輛VIN碼等信息。在接收到22服務(wù)請求后，服務(wù)器應(yīng)訪問由DID參數(shù)指定的記錄的數(shù)據(jù)元素，并在包含相關(guān)數(shù)據(jù)記錄參數(shù)的單個DID肯定響應(yīng)中傳輸其值。請求消息可以多次包含相同的DID。服務(wù)器應(yīng)將每個DID視為一個單獨(dú)的參數(shù)，并根據(jù)要求經(jīng)常使用每個DID的數(shù)據(jù)進(jìn)行響應(yīng)。22服務(wù)為獲取對應(yīng)DID的數(shù)據(jù)。

請求格式：

響應(yīng)格式：

支持的NRC:

$27安全訪問

安全訪問服務(wù)，主要功能是為了通過診斷安全地訪問服務(wù)端，也就是ECU，而設(shè)置的一層保護(hù)機(jī)制。安全訪問服務(wù)用于修改存儲在內(nèi)存中的 ECU 數(shù)據(jù)，在此之前，用戶首先必須通過該服務(wù)授予訪問權(quán)限。此服務(wù)的目的是提供一種訪問信息和/或診斷服務(wù)的方法，這些服務(wù)因安全、排放或安全原因而受到限制。比如一些用于將例程或信息下載/上傳到服務(wù)器中，并從服務(wù)器中讀取特定的內(nèi)存位置的診斷服務(wù)可能需要安全訪問。因為下載到服務(wù)器中的不當(dāng)程序或信息無疑可能會損害ECU，或危及車輛遵守排放、違反安全或安保標(biāo)準(zhǔn)。安全訪問的機(jī)制通過使用種子和密鑰來實現(xiàn)

使用此服務(wù)的典型示例如下∶

1. 客戶端首先發(fā)送請求種子的診斷請求

2. 服務(wù)端收到請求后，計算一個隨機(jī)種子通過診斷響應(yīng)發(fā)送給客戶端

3. 客戶端收到種子后，使用定義好的算法計算出密鑰，然后通過診斷請求發(fā)送給服務(wù)端

4. 服務(wù)端收到密鑰后，與自己計算的密鑰作對比，如果一致，驗證通過，如果不一致，驗證失敗

請求格式：

響應(yīng)格式：

支持的NRC：

$28通信控制

根據(jù)ISO14119-1標(biāo)準(zhǔn)中所述，診斷服務(wù)28服務(wù)主要用于網(wǎng)絡(luò)中的報文發(fā)送與接受，比如控制應(yīng)用報文的發(fā)送與接收，又或是控制網(wǎng)絡(luò)管理報文的發(fā)送與接收。

28服務(wù)子功能：

00：enableRxAndTx（使能收發(fā)）

01：enableRxAndDisableTx （使能接收并禁止發(fā)送）

02：disableRxAndEnableTx （禁止接收并使能發(fā)送）

03：disableRxAndTx（禁止收發(fā)）

控制類型 （communicationType）：

第3個字節(jié)為控制類型，01所有應(yīng)用報文， 02 所有網(wǎng)絡(luò)管理報文， 03 都包括。

舉例：禁止收發(fā)所有報文 28 03 03 總線上所有報文停止通訊

請求格式：

響應(yīng)格式：

支持的NRC

$2E寫數(shù)據(jù)

請求格式：SID+DID+DATA

響應(yīng)格式：6E+發(fā)送請求的DID+寫入的DATA

請求格式：

響應(yīng)格式：

支持的NRC：

$31例程控制

客戶端端使用31服務(wù)來執(zhí)行定義的步驟序列并獲取特定序列的相關(guān)結(jié)果。該服務(wù)有極大的靈活性。31服務(wù)的典型用途可以包括擦除內(nèi)存、重置定義的數(shù)據(jù)、覆蓋正常服務(wù)控制策略以及控制ECU值隨時間變化的功能。通過31服務(wù)可以啟動特定序列、停止運(yùn)行該特定序列、請求運(yùn)行結(jié)果。該服務(wù)以往常用于ECU在做軟件修改更新時，應(yīng)用于檢查刷寫條件是否滿足、傳輸數(shù)據(jù)完整性以及獨(dú)立性檢測。

31服務(wù)子功能：

Service 31 01：開始執(zhí)行例程。

Service 31 03：請求例程結(jié)果。

Service 31 02：停止運(yùn)行例程。

這里注意請求順序，否則就NRC=24了

請求格式：

響應(yīng)格式：

總結(jié):

本文主要基于14229協(xié)議介紹UDS常用診斷服務(wù)，服務(wù)子功能及對應(yīng)服務(wù)支持的NRC碼。診斷服務(wù)的內(nèi)容實在太多，挑選了重要部分進(jìn)行總結(jié)。
責(zé)任編輯：彭菁