解讀UDS協(xié)議—附錄表應(yīng)用

今天是2022年7月9日，魔都天氣晴朗無風(fēng)，又一個周末，無加班，暗喜。坐在電腦前可以敲擊些文字，記錄下這周時間的痕跡，也希望以文字為載體，可以在后續(xù)的日子里，作為打開記憶閘門的鑰匙。

昨天看到新聞?wù)f日本前首相遇刺，無意中看到朋友圈以及網(wǎng)上吃瓜者的狂歡?？偢杏X這種心態(tài)要不得，就好像強(qiáng)者出現(xiàn)意外，弱者的暗自慶幸，關(guān)鍵在于把自己擺在弱者的位置上。

2022年注定是一個不平凡的年度，俄烏戰(zhàn)爭、漂亮國為保證其位置所做的舉措、英國首相辭職、日首相事件、疫情的反反復(fù)復(fù)等等，讓有房貸在身的人有莫名的焦慮（自己）。可能是到了這樣的年齡，焦慮和希望并存，需要自己去花時間探索。因為焦慮，代表了對自己現(xiàn)在的不滿，想折騰下自己。文似看山不喜平，人生亦如此，想要的是芝麻開花步步高。

老規(guī)矩，分享一句自己喜歡的話，避免成為高知識低文化的工科男：

“

年輕時候的我，以為堅持是永不退縮。慢慢的一個年紀(jì)才明白，堅持就是猶豫著，退縮著，心猿意馬著，一步三停著還在往前走。

”

警惕自己成為“烏合之眾”中的一員，寧愿是寂寞是個人的狂歡。獨(dú)立、邊緣、自信、不妥協(xié)！

Return to today's topic！

本文主要匯總下UDS（ISO 14229）協(xié)議關(guān)于附錄表的應(yīng)用，在車載診斷有兩個范疇：

1、針對OEM

主要應(yīng)用場景：

-> 界定產(chǎn)生故障的部件；

-> ECU Software update；

-> ECU配置。

2、針對社會及法規(guī)

主要關(guān)于以往傳統(tǒng)燃油車動力域排放相關(guān)標(biāo)準(zhǔn)：

-> 車輛尾氣排放監(jiān)測

-> 滿足閾值的外部可檢查性

前者應(yīng)用協(xié)議主要為ISO 14229，后者協(xié)議主要用ISO 15031?？紤]到現(xiàn)階段電動車所占比重在逐年增加，關(guān)于電動車相關(guān)國標(biāo)也在發(fā)布使用。最近幾年也有另外一個趨勢，行業(yè)用考慮使用兩套協(xié)議來開發(fā)協(xié)議棧，有諸多不便，就打算使用一套協(xié)議棧同時兼顧兩方面的內(nèi)容：

使用ISO 27145交融ISO 14229和ISO 15031,相當(dāng)于使用UDS Service 22/19/14等服務(wù)代替0x01 - 0x0A十個服務(wù)功能。

回歸正題，關(guān)于UDS協(xié)議附錄表，有Annex A-J 10個附錄表。

Annex A

主要是關(guān)于NRC的規(guī)定以及解釋。NRC是Negtive Response Code，在如下診斷模型中：

NRC作用是告知測試工程師為何ECU給與否定響應(yīng)。在附錄表中具體定義如下，可參看：

對于每一個NRC對應(yīng)含義在UDS協(xié)議中都有明確定義，OEM在定義需求規(guī)范時，UDS協(xié)議也有預(yù)留為給用戶自定義。其中NRC22（ConditionNotCorrect），具體是什么條件，可以按照用戶自定義。

對于NRC優(yōu)先級，UDS協(xié)議給出了基本推薦：

而對于具體服務(wù)，UDS協(xié)議在每個服務(wù)格式定義后面，有時候也會有具體NRC優(yōu)先級推薦：

需要注意的是，不是每一個服務(wù)都會有，看情況。對于企業(yè)需求規(guī)范，可以基于自身需求做詳細(xì)定義即可。

Annex B

該附錄表是關(guān)于Service 參數(shù)詳細(xì)定義：

涉及到常規(guī)ECU通信和網(wǎng)絡(luò)管理報文的使能與否。

Annex C

主要是關(guān)于DID內(nèi)容的定義，一個DID表示ECU的一個數(shù)據(jù)內(nèi)容，在診斷功能中經(jīng)常跟Service 22/2E等服務(wù)配合使用，在AUTOSAR框架中，Tester發(fā)送診斷請求，先到DCM模塊，需要獲取DID內(nèi)容時，需要基于RTE關(guān)聯(lián)SWC，形成數(shù)據(jù)Link關(guān)系來獲取所需要的數(shù)據(jù)內(nèi)容。

對于DID內(nèi)容，UDS中有如下定義：

主要分為兩個內(nèi)容：

-> 預(yù)留了相應(yīng)區(qū)間，給用戶自定義；

-> 關(guān)于通用的DID，做了聲明定義。

需要注意的是在整車級別中，DID數(shù)量趨向于不夠使用，這個時候可以采取單個DID，定義多重內(nèi)容，減少DID數(shù)據(jù)資源。對于單個DID，在RTE端也是一個Runnable，至于這最終反饋什么內(nèi)容，主要由用戶自定義實現(xiàn)。

Annex D

該附錄主要是關(guān)于DTC相關(guān)內(nèi)容，關(guān)于DTC，涉及到不同的協(xié)議，對于DTC格式也不盡相同。如下所示：

在OBD關(guān)于DTC定義是2個Bytes，UDS協(xié)議關(guān)于DTC定義3個Bytes長度，特別是在ISO 15031中關(guān)于2個Bytes還有具體定義：

在附錄表D中，ISO 14229協(xié)議定義了諸多內(nèi)容：

-> groupOfDTC parameter definition；

-> DTCStatusMask and statusOfDTC bit definitions；

-> DTC status bit definitions；

-> DTC severity and class definition；

-> FunctionalGroupIdentifier definition

如果初次接觸車載診斷，DTC這點(diǎn)是一個難點(diǎn)，特別是在AUTOSAR框架中，DEM模塊關(guān)于此處有很多名詞，若不理順，會有很多點(diǎn)不容易理解：

1、DTC Status bit相互轉(zhuǎn)換關(guān)系；

2、運(yùn)行周期、檢測周期、檢測結(jié)果.....相關(guān)概念；

3、PreFailed、PrePassed、DTCFaultDetectionCounter等概念；

4、快照信息、擴(kuò)展類統(tǒng)計數(shù)據(jù)等記錄概念。

這些信息都在該附錄表中有詳細(xì)描述：

Annex E

該附錄表主要關(guān)于IO Control（Input output control functional unit data-parameter definitions）相關(guān)內(nèi)容定義。

Service 2F詳細(xì)功能可參看如下鏈接：

漫話UDS之Service 2F

Annex F

該附錄表主要講述Service 31（Routine functional unit data-parameter definitions）相關(guān)內(nèi)容。

定義了Service DID可以應(yīng)用的范圍。關(guān)于Service 31具體功能可參看如下鏈接：

漫話UDS之Service 31

Annex G

主要是關(guān)于Upload and download functional unit data-parameter相關(guān)定義：

定義了相關(guān)參數(shù)，具體這邊也可參看如下文章：

UDS之ECU刷寫（Software Update）那回事

Annex H

Examples for addressAndLengthFormatIdentifier parameter values，詳細(xì)如下：

Annex I

該附錄表主要講解Service 27相關(guān)內(nèi)容，定義了ECU從Locked -> Unlocked流程示意圖，以及等待時間。

關(guān)于Service 27詳細(xì)內(nèi)容也可參看如下文章：

漫話UDS之Service 27

Annex J

主要講述了多Tester（Recommended implementation for multiple client environments）場景：

伴隨著車載以太網(wǎng)引入到車載網(wǎng)絡(luò)中，該類場景會更多機(jī)會出現(xiàn)，近端Tester、遠(yuǎn)程Tester、車內(nèi)Tester，如何區(qū)分優(yōu)先級，將會對網(wǎng)關(guān)有更大的要求。

匯總

整個ISO14229協(xié)議定義了26個UDS診斷服務(wù)，也通過附錄表補(bǔ)充了相關(guān)內(nèi)容。在用戶定義自屬需求規(guī)范時，參看相關(guān)內(nèi)容即可。