診斷協議那些事兒

本文為診斷協議那些事兒專欄首篇文章，旨在介紹診斷的起源、發展歷史，讓讀者對診斷有一個基本的認識。

---

文章目錄

• 診斷協議那些事兒
• 一、診斷的起源
• 二、UDS是什么？
• • 1.診斷D（診斷通信協議）
  • • 1.1 為什么汽車需要診斷？
    • 1.2 診斷的基本原理
    • 1.3 診斷的應用領域
    • 1.4 診斷實現模型
  • 2.服務S（診斷服務）
  • • ①ISO15031
    • ②ISO14230
    • ③ISO14229
  • 3.統一U（可以基于任意總線）
• 總結

---

一、診斷的起源

診斷的概念來源于醫學，當病人出現頭暈、發燒、嘔吐、骨折等不適癥狀時，去醫院就診，醫生通過詢問、觀察，或者儀器（CT、血檢等）檢測，利用數據對病癥做出判斷，并給出合理建議的過程。
車輛診斷的過程也有類似的地方，外部診斷設備，通過通信媒介（CAN、LIN、以太網等）連接車輛，獲取車輛狀態信息，為了能夠快速準確的判斷車輛或者某個控制器的故障以及故障原因，從而在不拆解整車的情況下為維修提供可靠的依據。

二、UDS是什么？

Unified Diagnostic Services：統一 診斷 服務，形象理解-就是通過一套標準的服務，對當前汽車進行數據操作。

1.診斷D（診斷通信協議）

1.1 為什么汽車需要診斷？

隨著電子技術與汽車技術相結合，電子技術的不斷發展，駕駛員對于車輛不再僅僅滿足于代步功能的需求，迫切要求提高車輛的動力性、舒適性、經濟性和安全性。因此ECU數量不斷增加，由最初的幾個到現在上百個。數量的不斷增加雖滿足了駕駛員的新需求，但給車輛售后維修帶來了極大的挑戰，難以判定故障類型的問題。從20世紀80年代起，美歐等地汽車制造商開始在電噴系統上裝備車載自診斷模塊（On-Board Diagnostics Module），便于快速界定車身發生故障部位，方便售后維修（現代車載診斷功能不僅僅局限于此）。

①汽車網絡復雜性的增加
②汽車ECU的增加
③控制策略復雜性的增加
④診斷策略的增加
⑤法規和標準
⑥排放標準
⑦質量控制
⑧召回風險管控

1.2 診斷的基本原理

自診斷模塊能在汽車運行過程中實時監測電控系統及其電路元件的工作狀況，如有異常，根據特定的算法判斷出具體的故障，并以診斷故障代碼(DTC，Diagnostic Trouble Codes)的形式存儲在汽車電腦芯片內。可以為車輛的維修和保養提供幫助，維修人員可以利用汽車原廠專用儀器讀取故障碼，從而可以對故障進行快速定位，故障排除后，采用專用儀器清除故障碼。
OBD的工作原理（參考）：汽車在正常運行時，汽車的電子控制系統輸入和輸出的信號（電壓或電流）會在一定的范圍內有一定規律地變化；當電子控制系統電路的信號出現異常且超出了正常的變化范圍，并且這一異常現象在一定時間（幾 個連續行程）內不會消失，ECU 則判斷為這一部分出現故障，故障顯示燈點亮，同時監測器把這一故障以代碼的形式存入存儲設備中，被存儲的故障代碼在檢修時可以通過故障顯示燈或 OBDⅡ診斷儀來讀取。如果故障不再存在，監控器在連續 3 次未接收到相關信號后，將指令故障顯示燈熄滅。故障顯示燈熄滅后，發動機暖機循環約 40 次，則故障代碼會自動從存儲器中被清除掉。

1.3 診斷的應用領域

廣泛應用于開發、生產、售后等各個領域。

結合ISO14229診斷服務看，車輛診斷的作用涉及故障檢測（DTC）、程序升級、EOL下線檢測（車型配置、IO控制）、讀取軟硬件版本號/VIN等。

1.4 診斷實現模型

車輛的診斷需要有Tester端和ECU端，Tester端和ECU端通過一問一答的形式進行通信，因而Tester端和ECU端都需要遵循同樣的通信協議。常用的診斷協議有ISO 14230，ISO 15031，ISO 15765，還有我們熟悉的ISO 14229就是UDS協議，在協議里面定義了各個服務的請求、響應的報文格式，以及ECU怎樣處理診斷請求報文。

2.服務S（診斷服務）

診斷通信機制：基于C/S架構的請求/響應機制
Client客戶端：診斷請求的提出者——Tester（診斷儀）
Sever服務器：診斷響應的提供者——ECU（電子控制單元）

各個協議規定了不同的服務，不同的診斷服務代表著不同的功能，具體如下：

①ISO15031

服務描述

01	Request current powertrain diagnostic data 請求當前動力總成診斷數據
02	Request current powertrain diagnostic data 請求當前動力總成診斷數據
03	Request emission-related diagnostic trouble codes 請求與排放相關的診斷故障代碼
04	Clear/Reset emission-related diagnostic information 清除/重置排放相關診斷信息
05	Request oxygen sensor monitoring test results 請求氧氣傳感器監測測試結果
06	Request on-board monitoring test results for specific monitored systems 請求特定監控系統的車載監控測試結果
07	Request emission-related diagnostic trouble codes detected during current or last completed driving cycle 請求在當前或上次完成的駕駛循環中檢測到的與排放相關的診斷故障代碼
08	Request control of on-board system, test, or component 請求控制車載系統、測試或組件
09	Request vehicle information 請求車輛信息
0A	Request emission-related diagnostic trouble codes with permanent status 請求具有永久狀態的與排放相關的診斷故障代碼

②ISO14230

③ISO14229

詳情請查閱：UDS診斷服務列表

3.統一U（可以基于任意總線）

①OBD：On-Board Diagnostics
第一代OBD（OBD-I）
i.加州環保局（CARB）1985年立法，1988年開始實施
ii.要求對硬件失效（包括氧傳感器、廢氣在循環閥、供油系統和發動機系統）實施監控
iii.沒有統一的故障碼和通訊協議標準
第二代OBD（OBD-II）
建立了標準化故障碼和通訊協議標準

②ISO 14230：Keyword Protocol 2000（KWP2000）
該協議實現了一套完整的車載診斷服務，并且滿足 E-OBD（European On Board Diagnose）標準。最初使用K-Line串行傳輸，最大通信速率10.4Kbps。由于 K 線物理層和數據鏈路層在網絡管理和通訊速率上的局限性，使得 K 線無法滿足日趨復雜的車載診斷網絡的需求。而 CAN網絡（Controller Area Network）由于其非破壞性的網絡仲裁機制、較高的通訊速率（可達 1M bps）和靈活可靠的通訊方式被廣泛使用，發展為基于CAN總線的KWP2000（ISO 15765）。

③ISO 15765 Diagnostic On CAN
基于CAN總線傳輸，最大速率達1Mbps

④ISO 15031 On-Board Diagnostic（OBD）
與排放相關的診斷通信，是由法規要求，具有強制標準需要參照的，最初目的是環保（同時方便售后維修）。

⑤ISO 14229-1：Unified Diagnostic Services
定義了診斷服務，只是一個應用層協議，不涉及網絡，可以基于任意總線。
與OBD最大的區別就在Unified（統一）上，它是面向整車所有ECU的，而OBD是面向排放系統ECU的。

因為全球有許多OEM，假如每家OEM都定義自己的診斷通信標準，則會造成社會資源不必要浪費（Supplier要根據不同OEM搭建功能實現平臺）。因此定義統一的診斷協議，讓大家都遵守，避免浪費社會資源，這也是ISO組織定義車載診斷行業標準的目的（ISO 14229、ISO 15765、ISO 14230、ISO 15031等）。在協議中定義診斷通信的準則：診斷請求、診斷響應的規則； 診斷服務類型；ECU處理診斷請求的規則、診斷請求和診斷響應的內容；診斷通信的參數，數據傳輸的準則等等。

---

總結

以上就是今天要講的內容，本文僅僅簡單介紹了UDS的起源和發展，還有許多值得去挖掘和研究的內容，后續小編會不斷介紹ISO協議，以此來加深對診斷的理解。

總結

以上是生活随笔為你收集整理的UDS协议发展历史的全部內容，希望文章能夠幫你解決所遇到的問題。

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