UDS診斷概述
UDS(Unified Diagnostic Services,統(tǒng)一的診斷服務(wù))診斷協(xié)議是在汽車(chē)電子ECU環(huán)境下的一種診斷通訊協(xié)議。簡(jiǎn)單來(lái)說(shuō),可以理解為UDS診斷協(xié)議就是ISO 14229協(xié)議,在ISO 14229協(xié)議中定義了UDS服務(wù)用法、服務(wù)格式等信息。UDS診斷最主要目的是為了能夠快速準(zhǔn)確判斷車(chē)輛或者某個(gè)控制器的故障以及故障原因,從而為維修提供可靠的依據(jù)。
診斷服務(wù)概覽
UDS診斷包括6大類(lèi),26種服務(wù),每種服務(wù)都有自己獨(dú)立的ID,即SID(Service Identifier)
常見(jiàn)NRC碼
什么是NRC?一句話(huà)總結(jié),NRC碼用來(lái)快速判斷故障原因的重要依據(jù)。
不同會(huì)話(huà)支持的服務(wù)
并不是所有服務(wù)都只在一個(gè)會(huì)話(huà)下活動(dòng),由此就有了會(huì)話(huà)優(yōu)先級(jí)的概念,下圖列出了不同會(huì)話(huà)下支持的服務(wù)列表。
尋址方式
UDS診斷服務(wù)是實(shí)現(xiàn)人或設(shè)備與ECU控制器交流的一種語(yǔ)言,在總線(xiàn)上往往有著眾多ECU設(shè)備,作為診斷設(shè)備既可以與所有的ECU一起溝通,也可以指定某一個(gè)ECU單獨(dú)溝通。所以尋址方式就有功能尋址(Functionally Addressed)和物理尋址(Physically Addressed)兩種。
1、功能尋址:即廣播診斷請(qǐng)求Request,同時(shí)等待總線(xiàn)上的ECU給與響應(yīng)。
2、物理尋址:指定發(fā)送特定診斷請(qǐng)求Request,等待指定ECU給與響應(yīng)。
$10會(huì)話(huà)控制
DiagnosticSessionControl(診斷會(huì)話(huà)控制)服務(wù)用于啟用服務(wù)器中的不同診斷會(huì)話(huà)。該服務(wù)是在服務(wù)器端使能不同的會(huì)話(huà)模式,可以通過(guò)會(huì)話(huà)模式賦予不同診斷服務(wù)的執(zhí)行權(quán)限。
請(qǐng)求格式:
響應(yīng)格式:
支持的NRC:
$3E會(huì)話(huà)保持
3E服務(wù)用于會(huì)話(huà)模式一直保持在非默認(rèn)會(huì)話(huà),不會(huì)因?yàn)?E時(shí)間超時(shí)而自動(dòng)掉到默認(rèn)會(huì)話(huà)。
請(qǐng)求格式:
響應(yīng)格式:
支持的NRC:
$11ECU復(fù)位
此服務(wù)主要基于請(qǐng)求消息中復(fù)位類(lèi)型執(zhí)行ECU復(fù)位。在ECU執(zhí)行復(fù)位之前,ECU需回復(fù)肯定響應(yīng)消息,才可復(fù)位成功,在ECU成功復(fù)位后,ECU應(yīng)激活默認(rèn)會(huì)話(huà)。
常用的復(fù)位類(lèi)型,即子功能:
11 01 硬復(fù)位,即模擬的狀態(tài)為電源斷開(kāi)再重新接上的復(fù)位。
11 02 Keyoffon復(fù)位,模擬的是駕駛員先關(guān)閉點(diǎn)火開(kāi)關(guān)再打開(kāi)類(lèi)型的復(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開(kāi)頭的會(huì)被強(qiáng)制置1。
示例:14 FF FF FF(清除所有DTC) ,此參數(shù)包含3個(gè)字節(jié)的值,表示要清除的DTC組(例如動(dòng)力總成,車(chē)身,底盤(pán))或特定的DTC。
請(qǐng)求格式:
響應(yīng)格式:
支持的NRC:
$19 讀取DTC
19服務(wù)是UDS里的重中之重了,可謂是沒(méi)有19服務(wù)就失去了診斷服務(wù)的意義,下面就詳細(xì)介紹下此服務(wù)的作用以及用法。
故障碼包括四個(gè)大類(lèi),分別是PCBU,P是powertrain動(dòng)力系統(tǒng),C是Chassis底盤(pán),B是Body車(chē)身,U是network通信系統(tǒng)。一個(gè)DTC信息占用4個(gè)字節(jié)。最后一個(gè)字節(jié)是DTC的狀態(tài)。
19 01 讀取DTC數(shù)量
通過(guò)狀態(tài)掩碼去查找與其相匹配的故障個(gè)數(shù),通過(guò)該服務(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快照信息
為了方便找到故障的原因,車(chē)廠一般會(huì)在診斷調(diào)查表中定義一些信息作為快照信息,例如故障的發(fā)生時(shí)間、電壓、行駛里程數(shù)、車(chē)速等。在對(duì)應(yīng)故障發(fā)生時(shí),ECU端要記錄發(fā)生故障時(shí)的快照信息;而04服務(wù)就是用于請(qǐng)求指定故障碼(DTC)的快照信息,通過(guò)查找故障發(fā)生時(shí)刻的這些數(shù)據(jù),來(lái)分析故障原因。
請(qǐng)求格式:
響應(yīng)格式:
上圖:響應(yīng)報(bào)文中DTCSnapshotRecordNumber表示返回的是該DTC的哪一個(gè)快照記錄;DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定義的成員量;如定義的快照數(shù)據(jù)有車(chē)速、電壓、轉(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ù)用于在診斷刷寫(xiě)的過(guò)程中關(guān)閉DTC記錄,因?yàn)樵谒?xiě)的過(guò)程中往往是針對(duì)某個(gè)ECU節(jié)點(diǎn)單獨(dú)進(jìn)行刷寫(xiě),其他的對(duì)手件ECU節(jié)點(diǎn)始終處于正常工作狀態(tài),那么此時(shí)應(yīng)當(dāng)發(fā)送功能尋址給到各ECU節(jié)點(diǎn)使得其停止記錄DTC,刷寫(xiě)完成之后再重新開(kāi)啟對(duì)手件DTC記錄功能即可。
常用子功能
85 01:繼續(xù)更新?tīng)顟B(tài)碼狀態(tài)位。
85 02:停止更新?tīng)顟B(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通過(guò)則置0,如果調(diào)用了14服務(wù)清除DTC的話(huà),也需要重新置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)開(kāi)始時(shí),這個(gè)位需要置0,在調(diào)用了14服務(wù)后也需要置0。如果該位置1,那么一直保持置1狀態(tài)直到新的檢測(cè)循環(huán)開(kāi)始,因此bit1可以理解為當(dāng)前DTC。如果bit2和bit3通常一起使用。對(duì)于沒(méi)有網(wǎng)絡(luò)管理的 ECU,這個(gè)起始點(diǎn)就是 KL15 通斷。也就是說(shuō)上電時(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滿(mǎn)足故障觸發(fā)條件,則bit2置1。bit2位其實(shí)是表示DTC處于testFailed和confirmedDTC之間的一個(gè)狀態(tài),稱(chēng)為待定DTC。因?yàn)镈TC并不是一達(dá)到觸發(fā)位就會(huì)被報(bào)出來(lái)的,而是故障出現(xiàn)一段時(shí)間后才會(huì)被確認(rèn),而中間的這個(gè)狀態(tài)就用bit2位來(lái)表示,因此bit2位又可被稱(chēng)為待定DTC。當(dāng)某個(gè)DTC剛達(dá)到判定條件的時(shí)候,bit2被置1,若一段時(shí)間后故障條件不滿(mǎn)足了,則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í),說(shuō)明故障已經(jīng)發(fā)生了一段時(shí)間,也就是bit2至少有一次被置1了。需要注意的是,bit3置1的時(shí)候,DTC被存儲(chǔ)在EEprom中,但并不代表現(xiàn)在故障還存在,所以可以理解為歷史故障。在調(diào)用14服務(wù)清除DTC后需要置0。
“0”= 自上次調(diào)用ClearDiagnosticInformation后,或在滿(mǎn)足故障診斷碼的老化條件(或由于故障記憶溢出而清除了故障診斷碼)后,從未確認(rèn)過(guò)故障診斷碼。
“1”= 自上次調(diào)用ClearDiagnosticInformation后至少確認(rèn)一次的DTC,且尚未滿(mǎn)足老化標(biāo)準(zhǔn)
—————————————————————————————
bit 4 testNotCompletedSinceLastClear:
因?yàn)椴⒉皇撬械腄TC測(cè)試都是從上電就開(kāi)始的,所以該位用來(lái)表示上次調(diào)用14服務(wù)清除診斷消息后,是否進(jìn)行過(guò)完整的test。如果進(jìn)行了完整的test,無(wú)論結(jié)果如何,都置0,否則置1。
“0”= 自上次清除診斷信息以來(lái),DTC測(cè)試至少返回一次測(cè)試結(jié)果(無(wú)論通過(guò)或失?。?。
“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é)果。如果滿(mǎn)足老化閾值或發(fā)生故障記憶溢出,則車(chē)輛制造商應(yīng)負(fù)責(zé)將該位重置為零(“0”)。
“1”=自上次清除診斷信息以來(lái),DTC測(cè)試至少返回一次失敗結(jié)果。
—————————————————————————————
bit 6 testNotCompletedThisOperationCycle:
該位表示在當(dāng)前檢測(cè)循環(huán)周期過(guò)程中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)告警告指示,比如說(shuō)儀表盤(pán)上的警示燈等。但不是所有的DTC都會(huì)有警告指示,如果沒(méi)有和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ù)有:掩碼類(lèi)型:01 (讀取符合掩碼條件的DTC數(shù)量),后面的參數(shù)是DTC狀態(tài)掩碼,若為01表示我想讀當(dāng)前故障,若為08表示我想讀歷史故障,若為09表示當(dāng)前故障和歷史故障都想讀。
$22讀數(shù)據(jù)
22服務(wù)其英文全稱(chēng):ReadDataByIdentifier Service,為通過(guò)DID讀取數(shù)據(jù)的服務(wù),例如,在使用中可以通過(guò)22服務(wù)去獲取軟件的版本號(hào),車(chē)輛VIN碼等信息。在接收到22服務(wù)請(qǐng)求后,服務(wù)器應(yīng)訪(fǎng)問(wèn)由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安全訪(fǎng)問(wèn)
安全訪(fǎng)問(wèn)服務(wù),主要功能是為了通過(guò)診斷安全地訪(fǎng)問(wèn)服務(wù)端,也就是ECU,而設(shè)置的一層保護(hù)機(jī)制。安全訪(fǎng)問(wèn)服務(wù)用于修改存儲(chǔ)在內(nèi)存中的 ECU 數(shù)據(jù),在此之前,用戶(hù)首先必須通過(guò)該服務(wù)授予訪(fǎng)問(wèn)權(quán)限。此服務(wù)的目的是提供一種訪(fǎng)問(wèn)信息和/或診斷服務(wù)的方法,這些服務(wù)因安全、排放或安全原因而受到限制。比如一些用于將例程或信息下載/上傳到服務(wù)器中,并從服務(wù)器中讀取特定的內(nèi)存位置的診斷服務(wù)可能需要安全訪(fǎng)問(wèn)。因?yàn)橄螺d到服務(wù)器中的不當(dāng)程序或信息無(wú)疑可能會(huì)損害ECU,或危及車(chē)輛遵守排放、違反安全或安保標(biāo)準(zhǔn)。安全訪(fǎng)問(wèn)的機(jī)制通過(guò)使用種子和密鑰來(lái)實(shí)現(xiàn)
使用此服務(wù)的典型示例如下∶
1. 客戶(hù)端首先發(fā)送請(qǐng)求種子的診斷請(qǐng)求
2. 服務(wù)端收到請(qǐng)求后,計(jì)算一個(gè)隨機(jī)種子通過(guò)診斷響應(yīng)發(fā)送給客戶(hù)端
3. 客戶(hù)端收到種子后,使用定義好的算法計(jì)算出密鑰,然后通過(guò)診斷請(qǐng)求發(fā)送給服務(wù)端
4. 服務(wù)端收到密鑰后,與自己計(jì)算的密鑰作對(duì)比,如果一致,驗(yàn)證通過(guò),如果不一致,驗(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ā))
控制類(lèi)型 (communicationType):
第3個(gè)字節(jié)為控制類(lèi)型,01所有應(yīng)用報(bào)文, 02 所有網(wǎng)絡(luò)管理報(bào)文, 03 都包括。
舉例:禁止收發(fā)所有報(bào)文 28 03 03 總線(xiàn)上所有報(bào)文停止通訊
請(qǐng)求格式:
響應(yīng)格式:
支持的NRC
$2E寫(xiě)數(shù)據(jù)
請(qǐng)求格式:SID+DID+DATA
響應(yīng)格式:6E+發(fā)送請(qǐng)求的DID+寫(xiě)入的DATA
請(qǐng)求格式:
響應(yīng)格式:
支持的NRC:
$31例程控制
客戶(hù)端端使用31服務(wù)來(lái)執(zhí)行定義的步驟序列并獲取特定序列的相關(guān)結(jié)果。該服務(wù)有極大的靈活性。31服務(wù)的典型用途可以包括擦除內(nèi)存、重置定義的數(shù)據(jù)、覆蓋正常服務(wù)控制策略以及控制ECU值隨時(shí)間變化的功能。通過(guò)31服務(wù)可以啟動(dòng)特定序列、停止運(yùn)行該特定序列、請(qǐng)求運(yùn)行結(jié)果。該服務(wù)以往常用于ECU在做軟件修改更新時(shí),應(yīng)用于檢查刷寫(xiě)條件是否滿(mǎn)足、傳輸數(shù)據(jù)完整性以及獨(dú)立性檢測(cè)。
31服務(wù)子功能:
Service 31 01:開(kāi)始執(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é)。
責(zé)任編輯:彭菁
-
控制器
+關(guān)注
關(guān)注
114文章
17116瀏覽量
184432 -
通訊協(xié)議
+關(guān)注
關(guān)注
10文章
289瀏覽量
20857
原文標(biāo)題:UDS 診斷服務(wù)詳細(xì)解讀
文章出處:【微信號(hào):談思實(shí)驗(yàn)室,微信公眾號(hào):談思實(shí)驗(yàn)室】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
TSMaster 的 CAN UDS 診斷操作指南(上)

TSMaster 的 CAN UDS 診斷操作指南(下)

Aurix TC364D是否可以通過(guò)某些UDS服務(wù)停用HSM?
誰(shuí)能幫我解答下CAN總線(xiàn)中的UDS診斷?
UDS診斷命令備忘錄
OBDII與UDS的區(qū)別是什么
UDS診斷協(xié)議在純電動(dòng)汽車(chē)電機(jī)控制器中的應(yīng)用說(shuō)明
UDS基礎(chǔ)知識(shí)介紹

UDS之19服務(wù)中04子服務(wù):讀取快照數(shù)據(jù)

UDS診斷服務(wù)介紹之31服務(wù)

UDS診斷服務(wù)響應(yīng)規(guī)則介紹

基于CAN總線(xiàn)的UDS診斷Bootloader升級(jí)MCU工具

汽車(chē)UDS協(xié)議棧與XCP協(xié)議棧

UDS之29服務(wù):認(rèn)證服務(wù)

盟通方案|如何集成UDS協(xié)議

評(píng)論