UDS診斷概述

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

診斷服務概覽

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

常見NRC碼

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

不同會話支持的服務

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

尋址方式

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

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

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

$10會話控制

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

請求格式：

響應格式：

支持的NRC：

$3E會話保持

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

請求格式：

響應格式：

支持的NRC：

$11ECU復位

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

常用的復位類型，即子功能：

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

11 02 Keyoffon復位，模擬的是駕駛員先關閉點火開關再打開類型的復位。

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

請求格式：

響應格式：

支持的NRC：

$14清除DTC

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

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

請求格式：

響應格式：

支持的NRC：

$19 讀取DTC

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

故障碼包括四個大類，分別是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ù)，通過該服務診斷儀能夠請求ECU中DTC狀態(tài)與DTC狀態(tài)掩碼相匹配的故障碼個數(shù)。如果某一個故障碼的實際狀態(tài)位為1，并且DTC狀態(tài)掩碼中的相應位也為1，那么就認為該故障碼的狀態(tài)與DTC狀態(tài)掩碼相匹（即：如果DTC狀態(tài)掩碼字節(jié)與DTC實際狀態(tài)字節(jié)進行邏輯“位與”運算后的結(jié)果為非零值，那么兩者就相匹配）；此時則將故障數(shù)+1。如果診斷儀定義了一個狀態(tài)掩碼，其中包含ECU不支持的位，那么ECU僅使用本身支持的位進行處理故障信息。

請求格式

響應格式：

19 02 讀取DTC列表

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

請求格式：

響應格式：

19 03 讀取DTC快照信息

請求格式：

響應格式：

19 04 讀取指定DTC快照信息

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

請求格式：

響應格式：

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

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

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

請求格式：

響應格式：

19 0A 讀取所有DTC信息

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

請求格式：

響應格式：

支持的NRC：

$85控制DTC設置

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

常用子功能

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

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

請求格式

響應格式：

支持的NRC:

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

該mask由主機廠提供：

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

bit 0 testFailed：

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

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

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

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

bit 1 testFailedThisOperationCycle ：

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

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

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

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

bit 2 pendingDTC ：

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

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

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

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

bit 3 confirmedDTC ：

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

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

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

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

bit 4 testNotCompletedSinceLastClear：

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

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

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

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

bit 5 testFailedSinceLastClear ：

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

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

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

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

bit 6 testNotCompletedThisOperationCycle：

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

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

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

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

bit 7 : warningIndicatorRequested

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

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

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

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

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

請求格式：

響應格式：

支持的NRC:

$27安全訪問

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

使用此服務的典型示例如下∶

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

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

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

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

請求格式：

響應格式：

支持的NRC：

$28通信控制

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

28服務子功能：

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

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

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

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

控制類型 （communicationType）：

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

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

請求格式：

響應格式：

支持的NRC

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

請求格式：SID+DID+DATA

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

請求格式：

響應格式：

支持的NRC：

$31例程控制

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

31服務子功能：

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

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

Service 31 02：停止運行例程。

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

請求格式：

響應格式：

總結(jié):

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