為了監控排放相關系統，比如發動機和變速箱，美國和歐洲制定了OBD（On-Board-Diagnose）標准。OBD定義了排放相關系統必須支持的診斷服務和數據傳輸格式，支撐OBD數據傳輸的底層數據鏈路可以是K線，也可以是CAN線，目前大多數車的OBD接口都是CAN總線。OBD是與UDS並列的一套應用層協議，對於與排放相關的ECU來說，通常這種ECU上既要實現OBD，也實現UDS。下圖展示了UDS與OBD在整個診斷通信協議棧中的位置。
ISO為OBD分配了ISO-15031系列標准號，總共7本。而美國的SAE也為OBD分配了相應的標准號。它們在內容上是相同的。具體對應關系如下。
本文只重點關注ISO-15031-5，即OBD所用的診斷服務。在理解了這些診斷服務之后，其他的內容也就很容易理解了。
OBD總共定義了9個診斷服務，每個服務用一個byte來代表，即所謂的Service
ID（SID），從0x01到0x09。
Service 01 - Request Current Powertrain Diagnostic Data：
該服務用於讀取動力系統當前的診斷數據，比如某個傳感器的狀態、發動機轉速、DTC數量、故障指示燈是否亮起等，命令格式是SID + 若干PID（Parameter ID）。每個PID也是一個byte，所以理論上PID取值范圍是0x00至0xFF，但是ISO-15031-5只明確定義了部分PID，其余的值都保留。問題來了，OBD定義了如此多的PID，那么某個ECU到底支持哪些PID，診斷儀是如何獲知的呢？實際上，PID分為兩類，一類用於表征具體的數據，而另一類則用於指出該ECU支持哪些PID。用於第二種目的的PID分別是0x00 , 0x20 , 0x40…. 讀取其中一個ID后ECU會返回4個字節的結果，這4個字節中的每個bit表示其所對應的PID是否被支持。以下面這個例子來說明就很容易理解了：
OBD request for SID 01
OBD response for SID 01
通常來說，診斷儀要首先讀取00、20、40這些ID，然后就知道ECU支持哪些其他的PID了，而其他的PID就是很直接地表示某種數據，在ISO-15031-5的附錄中有全部數據格式的定義。
Service 02 - Request Powertrain Freeze Frame Data
一旦ECU確定了某個故障，就要把這個故障被確定時的相關狀態信息“凍結”下來，即所謂的凍結幀，這些狀態信息對車輛故障的確定非常重要，因為它們記錄了車輛發生故障時的很多相關信息，這些狀態信息數據必須在ISO-15031-5的PID列表中選擇（與Service 01使用的PID列表相同）。02命令和01命令的使用方式非常相似，只不過02讀取的是故障發生時的數據，而01讀取的當前數據，數據格式和含義都是相同的。與01命令不同的是，02命令中多了一個frame字節，如下圖所示：
OBD規定，用frame = 0x00來代表讀取凍結幀。如果主機廠想自己再定義些什么其他的幀，或者多定義幾個凍結幀，則可以給frame分配上其他的編號。
需要指出的是，OBD只規定了ECU需要為一個DTC存儲凍結幀，當ECU中同時存在多個DTC時，就要根據優先級來判定存儲誰的凍結幀了。
Service 03 - Request Emission-Related Diagnostic Trouble Codes
服務03用於讀取存儲在ECU中的與排放相關的“confirmed” DTC（可以參見本專欄中“汽車控制器（ECU）中DTC的狀態位”一文），用法非常簡單，它沒有任何參數，診斷儀只需要發送03即可。下面兩張圖分別展示了03命令的請求和響應格式。
OBD request for SID 03
OBD response for SID 03
在03命令的響應中，第2個字節表示DTC數量，后面每兩個字節表示一個DTC。
Service 04 - Clear/Reset Emission-Related Diagnostic Information
04服務用於清空ECU中存儲的與排放相關的DTC。除了DTC以外，以下的信息也要被清除。
執行04命令時被清理的信息
它的使用非常簡單，請求是一個字節的04，響應是一個字節的44。只有在發動機沒有運轉的時候才可以執行這個服務，否則ECU應該給出NRC 0x22（條件不滿足）來拒絕該服務。
Service 05 - Request Oxygen Sensor Monitoring Test Results
05服務用於讀取氧傳感器的狀態，對於OBDonCAN來說不支持該服務，相應的功能由06服務實現。
Service 06 - Request On-Board Monitoring Test Results for Specific Monitored Systems
該服務用於請求對特定被監測系統的監測結果。OBD中定義了一個MID（Monitor ID）的表格，來標識被監測系統。一個ECU不一定需要支持所有的MID，獲知具體支持哪些MID的方法與01和02服務所使用的方法相同，也是先讀取00，20，40等ID。06服務的命令格式是SID + 若干MID，命令格式如下
06服務的request
06服務的response
06服務的response中，針對某一個MID，可能有多個TID（Test ID），因為針對一個系統可能有多個測試項目。TID表格也在OBD中定義。06服務的response格式固定，每個MID的每個TID有6部分組成，可以在上面的例子中看出：
1. MID
2. TID
3. Unit And Scaling ID，用於標識這個TID的測試內容是什么，比如電壓、時間、計數器之類的。
4. Test Value，實際測量值
5. Min. Test Value，這個測量值的最小值
6. Max. Test Value，這個測量值的最大值
Service 07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle
07服務也是獲取DTC，但是它與03服務區別在於，它用於獲取在當前以及上一個駕駛循環中出現的處於“pending”狀態的DTC（可以參見本專欄中“汽車控制器（ECU）中DTC的狀態位”一文），而03服務獲取的是confirmed DTC。
它的請求格式和響應格式如下兩幅圖：
07服務的request
07服務的response
Service 08 - Request Control of On-Board System, Test or Component
08服務用於對系統進行控制，進行元件測試操作。它相當於UDS中定義的2F和31服務。它的使用方法是SID + TID，注意這個TID與05和06服務的TID不同，在OBD中有一個專門給08服務使用的TID表格。
Service 09 - Request Vehicle Information
09服務用於讀取車輛信息，它的命令請求格式是SID + 若干InfoType ，InfoType在OBD標准中有定義。並不是所有的InfoType都需要被支持，具體哪些InfoType被支持，可以采用和01服務相同的方法來獲知，讀取00，20，40等ID。比如InfoType = 02代表17個ASCII的Vehicle Identification Number。
目前，UDS和OBD是兩套應用層協議，而OBD所提供診斷服務其實屬於UDS所提供服務的一個子集，理論上來說UDS中的診斷服務都可以實現OBD中的要求。為了降低同時需要實現兩套協議的成本，所以標准化組織分配了ISO 27145（World-Wide Harmonized OBD）這個標准號來將OBD與UDS統一，使用UDS中的診斷服務來替代OBD相關的診斷服務。具體替換方案如下表：
WWH-OBD中UDS與OBD服務的對應關系
比如，在OBD中，使用02，03，07分別讀取confirmed DTC，DTC環境數據，pending DTC，而這些功能都可以通過UDS中的19服務來實現（配合上不同的狀態掩碼和讀取參數）。