UDS診斷概述

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

診斷服務(wù)概覽

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

常見NRC碼

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

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

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

尋址方式

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

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

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

$10會(huì)話控制

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$3E會(huì)話保持

3E服務(wù)用于會(huì)話模式一直保持在非默認(rèn)會(huì)話，不會(huì)因?yàn)?E時(shí)間超時(shí)而自動(dòng)掉到默認(rèn)會(huì)話。

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$11ECU復(fù)位

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

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

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

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

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$14清除DTC

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

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$19 讀取DTC

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

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

19 01 讀取DTC數(shù)量

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

請(qǐng)求格式

響應(yīng)格式：

19 02 讀取DTC列表

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

請(qǐng)求格式：

響應(yīng)格式：

19 03 讀取DTC快照信息

請(qǐng)求格式：

響應(yīng)格式：

19 04 讀取指定DTC快照信息

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

請(qǐng)求格式：

響應(yīng)格式：

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

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

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

請(qǐng)求格式：

響應(yīng)格式：

19 0A 讀取所有DTC信息

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$85控制DTC設(shè)置

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

常用子功能

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

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

請(qǐng)求格式

響應(yīng)格式：

支持的NRC:

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

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

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

bit 0 testFailed：

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

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

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

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

bit 1 testFailedThisOperationCycle ：

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

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

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

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

bit 2 pendingDTC ：

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

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

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

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

bit 3 confirmedDTC ：

當(dāng)bit3置1時(shí)，說明故障已經(jīng)發(fā)生了一段時(shí)間，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的時(shí)候，DTC被存儲(chǔ)在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：

因?yàn)椴⒉皇撬械腄TC測(cè)試都是從上電就開始的，所以該位用來(lái)表示上次調(diào)用14服務(wù)清除診斷消息后，是否進(jìn)行過完整的test。如果進(jìn)行了完整的test，無(wú)論結(jié)果如何，都置0，否則置1。

“0”= 自上次清除診斷信息以來(lái)，DTC測(cè)試至少返回一次測(cè)試結(jié)果（無(wú)論通過或失?。?/p>

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

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

bit 5 testFailedSinceLastClear ：

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

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

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

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

bit 6 testNotCompletedThisOperationCycle：

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

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

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

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

bit 7 : warningIndicatorRequested

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

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

$19擁有28個(gè)子服務(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ù)去獲取軟件的版本號(hào)，車輛VIN碼等信息。在接收到22服務(wù)請(qǐng)求后，服務(wù)器應(yīng)訪問由DID參數(shù)指定的記錄的數(shù)據(jù)元素，并在包含相關(guān)數(shù)據(jù)記錄參數(shù)的單個(gè)DID肯定響應(yīng)中傳輸其值。請(qǐng)求消息可以多次包含相同的DID。服務(wù)器應(yīng)將每個(gè)DID視為一個(gè)單獨(dú)的參數(shù)，并根據(jù)要求經(jīng)常使用每個(gè)DID的數(shù)據(jù)進(jìn)行響應(yīng)。22服務(wù)為獲取對(duì)應(yīng)DID的數(shù)據(jù)。

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC:

$27安全訪問

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

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

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

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

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

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$28通信控制

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

28服務(wù)子功能：

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

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

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

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

控制類型 （communicationType）：

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

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC

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

請(qǐng)求格式：SID+DID+DATA

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

請(qǐng)求格式：

響應(yīng)格式：

支持的NRC：

$31例程控制

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

31服務(wù)子功能：

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

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

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

這里注意請(qǐng)求順序，否則就NRC=24了

請(qǐng)求格式：

響應(yīng)格式：

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

總結(jié):

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

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

版權(quán)聲明：本文為CSDN博主「贊哥哥.」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明，已獲作者轉(zhuǎn)載許可。