當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

计算机网络学习 - UDS协议

發布時間：2023/12/10 编程问答 31 豆豆

生活随笔收集整理的這篇文章主要介紹了计算机网络学习 - UDS协议小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄

- 一、背景
- 二、概述
- 三、診斷原理
- 四、UDS診斷服務
- 五、DTC

一、背景

????????汽車故障診斷是利用ECU監測控制系統各組成部分的工作情況，發現故障后自動啟動故障記錄和處理邏輯。汽車故障診斷模塊不僅能夠存儲記憶汽車故障，還能夠實時提供汽車各種運行參數。外部診斷設備通過一定的診斷通信規則與ECU建立診斷通信，并讀取這些故障和參數，同時解析出來供外部測試人員分析。

二、概述

????????統一診斷服務（Unified Diagnostic Services），簡稱UDS。是ISO 15765和ISO 14229定義的一種汽車通用診斷協議，位于OSI模型中的應用層，它可在不同的汽車總線（例如CAN、LIN、Flexray、Internet、K-line）上實現，是當前汽車領域廣泛使用的一種車載診斷協議標準。
????????UDS協議的應用層定義是ISO 14229-1，目前大部分汽車廠商均采用UDS on CAN的診斷協議。

三、診斷原理

????????根據UDS的診斷協議，汽車上的控制系統需要根據規則化的診斷協議進行故障記錄和處理，最終體現為診斷故障代碼（Diagnostic Trouble Code，DTC）的方式。例如，網絡通信丟失的故障診斷機制：
????????自動變速箱控制單元（Transmission Control Unit，TCU）和制動防抱死系統（Antilock Brake System，ABS）是CAN車載網絡上的兩大電子控制單元，這2個ECU要通過CAN網絡進行大量的信息交互。但是由于電磁干擾、串擾、靜電等外界干擾或電子控制單元本身控制策略引起的通信停止等原因，2個電子控制單元之間可能會出現通信丟失的現象。
????????控制系統需要將故障信息（例如：通信丟失故障信息）診斷出來，以處理通信被破壞時出現丟失幀的故障現象，并記錄為DTC。一旦某一控制系統，如TCU監測到一段規定的時間內并沒有接收到ABS發來的通信數據，便將此DTC記錄下來。外部診斷設備通過規則的診斷通信與控制系統建立診斷通信連接，并選擇相應的診斷方式。例如：讀取故障信息服務時，就會將此故障信息讀出，并在診斷儀中顯示出來。

四、UDS診斷服務

SID ，診斷服務標識符（Service Identifier）。
DID，數據標識符（Data Identifier）。
SF，子功能（Sub-Function）。
NRC，否定響應碼（Negative Response Code），如果ECU拒絕了一個請求，它會回應一個NRC，不同的NRC有不同的含義。
SA，源地址（Source Address ）。
TA，目標地址（Target Address）。
Tester，測試儀。

????????UDS一般有兩種尋址模式：

物理尋址（Physical Addressing），是一種點對點的尋址模式，一條報文對應于單獨一個Server（ECU）。
功能尋址（Functional Addressing），一條報文對應本網絡中所有Server（ECU），也就是說本網絡中所有ECU都要對這條指令做出響應。

????????UDS本質上是一種定向的通信，是一種交互協議（Request/Response），采用的是Client/Server的模式，基本是Client發送一個請求報文，Server根據請求報文做出回應，Client一般情況下是指測試儀（Tester），Server一般是指電控單元（ECU）。UDS每種服務都有自己獨立的ID，即SID，UDS請求報文中需要包含SID，有UDS報文和響應如下：

????????根據功能和處理目的被分類為不同的功能單元：

診斷和通信管理功能單元（Diagnostic and Communication Management）
$10 - 診斷會話控制（DiagnosticSessionControl）
????????該服務請求ECU從活動會話過渡到其他會話。包含三個子功能：01 - Default、02 - Programming、03 - Extended。
$11 - 電控單元復位（ECUReset）
????????該服務請求ECU執行復位。ECUReset請求參數的示例包括：hardReset、keyOffOnReset、softReset。
$27 - 安全訪問（SecurityAccess）
????????此服務用于在活動診斷會話中達到更高的安全級別。可能需要SecurityAccess請求來解鎖并訪問受保護的功能及數據（例如通過DID讀取ECU ID信息）。也可以用于從一個會話通過解鎖以成功切換到其他會話。
????????例子：
????????Rx：02 27 05 00 00 00 00 00，安全訪問，05子功能。
????????Tx：07 67 05 08 27 11 F0 77，肯定響應，回復了對應安全級別的種子。
????????Rx：06 27 06 FF FF FF FF 00，發送密鑰，4個FF。注意06是與05成對使用的。
????????Tx：03 7F 27 78 00 00 00 00，否定響應，7F+27+NRC。
????????Tx：02 67 06 00 00 00 00 00，肯定響應，通過安全校驗。
$28 - 通訊控制（CommunicationControl）
????????該服務請求ECU控制其通信行為。一個典型的示例包括要求CAN總線中的ECU關閉車載通信，以提高診斷通信的效率。
$3E - 待機握手（TesterPresent）
????????TesterPresent請求通常定期發送，并包含一個功能地址。它指示測試儀仍處于連接狀態（存在），并請求ECU保持當前診斷狀態（例如，除默認會話之外的其他會話處于活動狀態，RoE機制仍處于活動狀態）。對這個服務的正響應抑制可以減少總線負載。
????????例子：02 3E 80 00 00 00 00 00，發送一個3E服務的報文，保持非默認會話狀態，80表示無需回復。
$83 - 訪問時間參數（AccessTimingParameter）
????????該請求用于讀取和/或修改通信定時參數。
$84 - 安全數據傳輸（SecuredDataTransmission）
????????此請求用于傳輸受加密方法保護的診斷數據。為此，必須實現位于應用程序層與測試儀和ECU的應用程序之間的“安全子層”。數據根據ISO 15764（擴展數據鏈接安全性）進行處理。
$85 - 診斷故障碼設置控制（ControlDTCSetting）
????????該服務要求ECU停止/恢復DTC的設置。將此服務與車載通信切換（服務$28通訊控制）相結合，可增加用于Flash編程的速度。
$86 - 事件響應（ResponseOnEvent）
????????事件響應（RoE）服務請求ECU自動傳輸指定事件的響應。
$87 - 鏈路控制（LinkControl）
????????該服務請求控制通信數據速率。對于CAN，它會影響ISO 11898中規定的數據鏈路層，從而影響用于板載通信以及診斷通信的數據速率。轉換數據速率的請求分為：驗證網絡上的ECU是否允許特定的數據速率，在驗證結果為肯定的情況下請求轉換，執行轉換。
數據傳輸功能單元（Data Transmission）
$22 - 通過ID讀數據（ReadDataByldentifier）
????????該服務請求讀取由DID參數標識的數據記錄值。DID用于標識特定的本地數據記錄。數據標識符0xF224可以包含諸如電池電壓，歧管絕對壓力，空氣質量流量，車輛大氣壓以及計算出的負載值之類的數據。
$23 - 通過地址讀內存（ReadMemoryByAddress）
????????該服務請求讀取指定內存范圍的當前值。請求參數是內存地址和內存大小。用于請求參數的字節數在addressAndLengthFormatldentifier中指定。
$24 - 通過ID讀比例數據（ReadScalingDataByidentifier）
????????該服務請求ECU將縮放信息值傳輸到測試儀。測試人員使用定標信息值來轉換數據。這項服務的實施增加了ECU軟件的實用性。作為替代，測試器可以將縮放比例信息存儲在數據庫中。
$2A - 通過周期ID讀取數據（ReadDataUyPeriodicidentifier）
????????該服務請求定期發送數據記錄值。所請求的數據的傳輸速率由傳輸模式參數設置，例如“中等速率發送”，例如300 ms。
$2C - 動態定義標識符（DynamicallyDefineDataldentifier）
????????該服務允許測試人員在ECU中動態定義新的數據標識符，其中包含對靜態定義的標識符和/或內存地址的引用。測試人員隨后可以通過服務請求2A（readDataByPeriodicIdentifier）讀取此動態定義的數據記錄。動態定義的標識符的一個優點是，一次服務可以請求傳輸很多的的數據記錄。
$2E - 通過ID寫數據（WriteDataByldentifier）
????????通過此服務，可以將由標識符（DID）指定的數據記錄寫入ECU存儲器。
$3D - 通過地址寫內存（WriteMemoryByAddress）
????????該服務允許將數據記錄直接寫入ECU的內存。請求參數是內存地址和內存大小以及數據記錄。用于參數內存地址和內存大小的字節數在addressAndLengthFormatidentifier中指定。
存儲數據傳輸功能單元（Stored Data Transmission）
$14 - 清除診斷信息（ClearDiagnosticInformation）
????????清除（復位）DTC格式，它可以改變DTC的狀態。此服務允許在一個或多個ECU中清除錯誤存儲器的內容。因此，可以使用物理地址或功能地址來請求服務。3個FF代表清除所有DTC。例如：
????????請求：14 + FF + FF + FF；
????????響應：54 。
$19 - 讀取故障碼信息（ReadDTCInformation）
????????診斷故障代碼（DTC）用于編碼和識別檢測到的與排放有關和與排放無關的故障。DTC通常為三個字節，OBD II占用兩個字節。該服務從一個或多個ECU請求DTC信息的狀態。因此，該服務可以用物理地址或功能地址查詢。測試人員可以請求與DTC關聯的已存儲數據記錄，也稱為“DTC快照”。DTC快照包含故障發生時的特定數據值。
輸入輸出控制功能單元（Input & Output Control）
$2F - 通過標識符控制輸入輸出（InputOutputControlByIdentifier）
????????該服務主要用于代替輸入信號的值和/或控制ECU的輸出。通常，此服務會繞過ECU的應用程序軟件并直接觸發輸出電路，然后直接讀取連接到輸入電路的傳感器。
例行程序功能單元（Remote Activation of Routine）
$31 - 例行程序控制（RoutineControl）
????????該服務用于維護和停止ECU內部例行程序。可以讀取例程的結果以進行分析。該例行程序由兩個字節的例行程序identifier標識。
上傳下載功能單元（Upload & Download）
$34 - 請求下載（RequestDownload）
????????此服務啟動從測試儀到ECU的數據傳輸。當ECU準備從測試儀接收數據時，它會發送肯定響應，其中包含用于后續數據傳輸的可用塊大小（每個傳輸數據請求的數據字節數）
$35 - 請求上傳（RequestUpload）
????????此服務啟動從ECU到測試儀的數據傳輸。當ECU準備好將數據發送到測試儀時，它會發送一個肯定的響應，其中包含用于后續數據傳輸的塊大小（每個傳輸數據請求的數據字節數）
$36 - 數據傳輸（TransferData）
????????此服務用于在測試儀和ECU之間（下載）或在ECU和測試儀之間（向上）傳輸數據。如果需要一個以上的transferData請求來傳輸數據，則使用blockSequenceCounter對傳輸次數進行計數。計數器允許在傳輸損壞后重復傳輸塊。因此，在出現通信問題時，不必再次傳輸完整的數據
$37 - 請求退出傳輸（RequestTransferExit）
????????該服務用于終止transferData服務。完整的數據傳輸從requestDownloadrequestUpload服務開始，再由幾個transferData服務繼續，并由requestTransferExit服務完成。
$38 - 請求文件傳輸（RequestFileTransfer）
????????該服務用于終止transferData服務。完整的數據傳輸從requestDownloadrequestUpload服務開始，再由幾個transferData服務繼續，并由requestTransferExit服務完成。

五、DTC

????????診斷故障碼（Diagnostic Trouble Code，DTC），是故障類型的"身份ID"，用于汽車故障時對故障部位及原因的排查。一個DTC信息占用4個字節：

????????每個DTC均由DTC內容和DTC狀態表示：

DTC內容。代表了該故障的具體故障方式、故障標志等信息。其中，DTCHighByte、DTCMiddleByte這兩個字節表示故障內碼，對應5位標準故障碼（第一位是字母，后面四位是數字），如"B100016"這個故障碼中的"B1000"，最后面的"16"則是DTCLowByte的內容（DTCLowByte是描述故障種類和子類型，該部分內容遵循ISO 15031-6，對于不需要該字節信息的DTC，可填充為0x00）。
故障內碼與5位標準故障碼的位置對應關系如下：

1、第一位
2、第二位
3、第三位是數字，表示故障所屬的子系統，以對動力系統為例（P開頭的故障碼），有以下的情況：
????????0 - 表示燃油和空氣計量輔助排放控制整個系統。
????????1 - 表示燃油和空氣計量系統。
????????2 - 表示燃油和空氣計量系統（噴油器）。
????????3 - 表示點火系統。
????????4 - 表示廢氣控制系統。
????????5 - 表示巡航、怠速控制系統。
????????6 - 車載電腦和輸出信號。
????????7 - 傳動系統控制。
????????8 - 傳動系統控制。
4、第四、五位也是數字，表示具體故障對象和類型。
故障碼的16進制表示：
????????根據前面介紹的故障內碼與5位標準故障碼的對應關系，我們可以將標準故障碼換算成其16進制的表示，便于我們在代碼中的記錄操作。
????????關于標準故障碼換算為16進制表示，其實只需根據第一小節中介紹的故障內碼與5位標準故障碼的對應關系，將標準故障碼的第一、第二位（如下例中的“U0”、“B1”）換算為對應的內碼格式，再以16進制表示出來，至于后面的其他內容，其格式本來就是16進制進行表示的，直接照著寫下來即可（其實只是將標準故障碼的第一、二位進行轉換即可了）。例如：
U007304，其故障內碼為：1100 0000 0111 0011，換算成16進制則為C073，補充上DTCLowByte（04），則其完整的16進制表示為0xC07304。
B100016，其故障內碼為：1001 0000 0000 0000，換算成16進制則為9000，補充上DTCLowByte（16），則其完整的16進制表示為0x900016。
DTC狀態。則表示當前的故障處于什么狀態，它由8位組成，每個位代表了不同的故障狀態信息。

Bit 0：testFailed
????????通常來說，ECU內部以循環的方式不斷地針對預先定義好的錯誤路徑進行測試，如果在最近的一次測試中，在某個錯誤路徑中發現了故障，則相應DTC的這一個狀態位就要被置1，表示出錯。此時DTC的testFailed位被置1，但是它不一定被ECU存儲到non-volatile memory中，只有當pendingDTC或confirmedDTC被置1時DTC才會被存儲。而pendingDTC或confirmedDTC被置1的條件應該是檢測到錯誤出現的次數或時間滿足某個預定義的門限。當錯誤消失或者診斷儀執行了清除DTC指令時，testFailed會再次被置為0。
Bit 1：testFailedThisOperationCycle
????????這個bit用于標識某個DTC在當前的operation cycle中是否出現過testFailed置1的情況，即是否出現過錯誤。operation cycle的起始點是：ECU通過網絡管理喚醒，到ECU通過網絡管理進入睡眠。對于沒有網絡管理的ECU，這個起始點就是KL15通斷。通過bit 0我們無法判斷某個DTC是否出現過，比如，當前testFailed=0，說明當前這個DTC沒有出錯，如果testFailedThisOperationCycle=1的話，就說明這個DTC在當前這個operation cycle中出過錯，但是當前錯誤又消失了。
Bit 2：pendingDTC
????????根據規范的解釋，pendingDTC=1表示某個DTC在當前或者上一個operation cycle中是否出現過。pendingDTC位其實是位于testFailed和confirmedDTC之間的一個狀態，有的DTC被確認的判定條件比較嚴苛，需要在多個operation cycle中出現才可以被判定為confirmed的狀態，此時就需要借助于pendingDTC位了。pendingDTC=1的時候，DTC就要被存儲下來了，如果接下來的兩個operation cycle中這個DTC都還存在，那么confirmedDTC就要置1了。如果當前operation cycle中，故障發生，pendingDTC=1，但是在下一個operation cycle中，故障沒有了，pendingDTC仍然為 1，再下一個operation cycle中，故障仍然不存在，那么pendingDTC就可以置0了。
Bit 3：confirmedDTC
????????當confirmedDTC=1時，則說明某個DTC已經被存儲到ECU的non-volatile memory中，說明這個DTC曾經滿足了被confirmed的條件。但是請注意，confirmedDTC=1時，并不意味著當前這個DTC仍然出錯，如果confirmedDTC=1，但testFailed=0，則說明這個DTC表示的故障目前已經消失了。將confirmedDTC重新置0的方法只有刪除DTC，UDS用0x14服務，OBD用0x04服務。
Bit 4：testNotCompletedSinceLastClear
????????這個bit用于標識，自從上次調用了清理DTC的服務（UDS用0x14服務，OBD用0x04服務）之后，是否成功地執行了對某個DTC的測試（不管測試結果是什么，只關心是否測了）。因為很多DTC的測試也是需要滿足某些邊界條件的，并不是ECU上電就一定會對DTC進行檢測。
testNotCompletedSinceLastClear=1，自從清理DTC之后還沒有完成過針對該DTC的測試。
testNotCompletedSinceLastClear=0，自從清理DTC之后已經完成過針對該DTC的測試。
Bit 5：testFailedSinceLastClear
????????這個位與bit1有些類似，bit1標識某個DTC在當前的operation cycle中是否出現過testFailed置1的情況，而testFailedSinceLastClear標識的是在上次執行過清理DTC之后某個DTC是否出過錯。
testFailedSinceLastClear=0，自從清理DTC之后該DTC沒有出過錯。
testFailedSinceLastClear=1，自從清理DTC之后該DTC出過至少一次錯。
Bit 6：testNotCompletedThisOperationCycle
????????這個位與bit4類似，b4標識自從上次調用了清理DTC的服務之后，是否成功地執行了對某個DTC的測試。而testNotCompletedThisOperationCycle則標識在當前operation cycle中是否成功地執行了對某個DTC的測試。
testNotCompletedThisOperationCycle=1，在當前operation cycle中還沒在完成過針對該DTC的測試。
testNotCompletedThisOperationCycle=0，在當前operation cycle中已經完成過針對該DTC的測試。
Bit 7：warningIndicatorRequested
????????某些比較嚴重的DTC會與用戶可見的警告指示相關聯，比如儀表上的報警燈，或者是文字，或者是聲音。這個warningIndicatorRequested就用于此類DTC。
warningIndicatorRequested=1， ECU請求激活警告指示。
warningIndicatorRequested=0，ECU不請求激活警告指示。
????????注意，如果這個DTC不支持警告指示，則這個位永遠置0。

總結

以上是生活随笔為你收集整理的计算机网络学习 - UDS协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： LightOJ 1393 Crazy C
下一篇：【深度学习】——日常知识点总结（持续更新