回顧接觸UDS的過程
自畢業後，我一直幹了2年的Autosar CAN通訊開發。
開發的主要內容簡單概括就是：套用報文開發、網管報文開發、休眠喚醒開發，及CAN網絡相關故障開發，並沒有涉及UDS開發，但雖然沒有涉及開發，但多多少少都聽過一點（特別是後來跑路的時候，惡補了學習了一手，嘿嘿）。
我剛開始接觸診斷相關內容的時候，對診斷沒有任何概念。所以聽到同事們討論什麽SID啦、DID啦，DTC啦，什麽27啦。
不能說聽得不太懂，只能說一臉懵逼。
小小的腦瓜大大的問號，SID？SID是什麽？怎麽還有DID，DTC？它們是什麽關系，他們是一個類別的東西吧？長得這麽像！
所以就百度，好了，假設你是一個對UDS診斷沒有任何概念的小白。你看看百度出來的東西。
你看看上面這圖，我就問你，你說這是小白能看懂的東西嗎？？什麽每種服務都有自己獨立的ID，我連服務是什麽鬼都不知道，我看得懂才怪了。
所以，我連SID的概念都花了好久才搞明白。
於是，我問同事，有沒有什麽資料能夠學習UDS，然後，他們都告訴我，讓我看14229-1和15765-2這兩個標準文件。
然而，一個文件三四百頁，內容這麽多，怎麽看啊，主要是，對小白來說，如此多內容的文件，是很難捉住重點的，這樣就很費勁了。
有一次，領導把我派去了測試部支援3天，讓我跟著一個測試部的同事測UDS的內容，想起來也挺不好意思，這3天我也沒幫到什麽忙，主要是不懂這些數據，舉個小栗子，看下面這張圖。
這一串串數據，讓一個對診斷沒有任何概念的小白來看哪裏能看懂啊。
後來，我明白了什麽是SID、DID，什麽又是DTC，診斷報文的這些數據要怎麽看。
但是，由於沒有具體開發過UDS，因此並不知道這些東西具體是怎麽去開發的。比如19服務有個DTC狀態碼，這個狀態碼是要怎麽開發？是Autosar配置工具配置的嗎？還是不需配置靜態程式碼已經全部實作？
兩年過去，在換了一個企業後，有機會開始正式開發UDS和對UDS進行完整的測試，讓我對UDS從概念上的認識進入到了UDS各個具體內容開發的認識。
下面就開始講一下我理解的UDS基本概念。
UDS的作用
當一輛汽車出現故障的時候，維修人員會拿著診斷儀接上汽車，然後讀取出車上的故障資訊，這樣就知道車上什麽地方出故障了。（這只是其中一個功能，另外還有軟件升級、標定等等。）
能實作山上面這個過程，就是因為有UDS的存在。
我們所說的診斷UDS開發，就是程式碼實作上面圖中「ECU-A」的診斷功能。最終使得ECU-A能夠根據診斷儀的請求，返回對應的數據資訊。
UDS的宏觀認識
就像地球總共由7塊大陸組成一樣。且先不管UDS的具體細節內容，UDS世界總共由以下這些「大陸板塊」組成：
大家把這些大陸板塊稱之為： SID，即：診斷服務ID，簡稱「服務」 。每一個服務都有它的獨特的職能。(車企常用到的每個服務後續我會每個都寫一篇去展開描述。)
整個UDS都是圍繞上面這些服務展開的， 服務下面又會有子服務 。這就好比「國家」的概念。「國家」是不會做事情的，做事情的是「國家」下面的各個「部門」，你可以把各個診斷服務理解為各個「國家」，子服務理解國家下面的「部門」。
舉個栗子：28服務（CommunicationControl）有下面的這些子服務。
28服務它的作用是通訊控制，但是真正具體幹活的是它的各個子服務，比如0x00：使能報文的發送和接收。
UDS的CAN通訊鏈路
UDS的最終目的，是如一開始那張圖。告訴診斷儀自己的故障資訊、透過診斷儀升級軟件、標定等等。
而通訊總線，就是實作這些功能的媒介。
所謂的UDSOnCan，其實就是字面意思： 基於CAN總線的UDS 。
大家都知道，汽車上不止有CAN總線，可能還有LIN總線、乙太網路等等。所以，UDS還可以「On」在其它總線上。我們這裏講的是UDSOnCan，如下圖。
從上面這張官方標準的圖就可以看出UDS在整個CAN通訊中的鏈路了，但會比較抽象。
所以我按照Autosar的架構畫了下面的圖，UDS的整個鏈路如下圖紅色線所示：
UDSOnCan相關協定如下圖示。
11898 ：這個是關於CAN總線的相關標準。比如它會描述CANH、CAHL的電平要求是多少、一幀CAN報文的結構定義、關於CAN Tranceive的一些要求等等。從上面的圖中也可以看到，不只是診斷報文的這部份要滿足11898，網管報文、套用報文也是同樣要滿足這個。實際上，所有的CAN報文，都得滿足11898。
15765-2 ：這個就是診斷報文的傳輸協定標準，比如發送多幀時要如何發送，每幀的時間間隔等等。
14229-1 ：到這一層，才是真正開啟UDS的世界，具體的UDS功能都在這個標準文件中定義。
診斷開發。一般來說實際上是指CANTP模組（15765-2）、DCM模組和DEM模組（14229-1）。
UDS的報文種類
UDS總共有3種報文。 物理請求報文、功能請求報文、響應報文
我們先來講一下為什麽會有這3種診斷報文。
由於一輛汽車上有十幾個ECU。因此，診斷儀對車上ECU的操作共有兩種情況。
① 對某一個ECU單獨進行操作 。比如讀取某一個ECU的故障資訊、升級某一個ECU的軟件
② 同時對所有ECU進行操作 。比如整車處於喚醒過程中，大家都在往外發送報文，總線負載率相對較高。但診斷人員現在需要對某一個ECU升級軟件，總線負載率高可能會影響，因此，需要先讓所有的ECU都停止發送套用報文。這時候就需要通知所有ECU停發套用報文。
根據上面第①種情況。就出現了第一種診斷報文類別： 物理請求報文。 每個ECU都有自己唯一的診斷實體位址。當ECU接收到實體位址是指向自己的診斷報文時就要根據這幀報文的請求內容做出對應的操作。簡單來說，就是一對一。
根據上面第②種情況。就出現了第二種診斷報文類別： 功能請求報文 。在同一個CAN網絡上所有ECU的功能地址是一樣的。在同一個CAN網絡，當ECU接收到功能地址的診斷報文時都要根據這幀報文的請求內容做出對應的操作。簡單來說，就是一對多。
好了，物理請求報文和功能請求報文都是ECU要接收的診斷報文，ECU接收到診斷報文後需要回應。因此就出現了第三種診斷報文類別： 響應報文 。
上面的描述可以用下面兩張圖表示：
另外需要註意的是： 物理請求報文是支持回應多幀的。而功能請求報文只支持回應單幀。這在15765-2中8.3.2.4就有說明。
結束
到這裏為止。關於UDS的一些基本概念應該就差不多了。接下來我會先講一下15765-2，即UDSOnCan的「OnCan」，也即CANTP層。
朋友們，關註下我呀，我以我過來人，再用小白的角度認真寫的知識總結一定讓你的腦子餓肚子進來，扶墻出去...
返回目錄
Autosar BSW 開發筆記（目錄）
