其實診斷通訊的機制很簡單，可以模擬client-server通訊方式，即客戶端傳送request，伺服器收到request之後進行處理，然後向客戶端傳送response。但是，診斷協議有自己的特色，它規定了在request和response的格式，在收到request的時候要做格式的檢查。同時由於定址方式的不同，有無sub-function的支援等，也會影響request和response的處理方式和結果。下面將我就具體情況分析，盡量做到簡介明了。
歸納起來，診斷的request格式無非以下2種：
+ +
+ 即有無sub-function的區別。其中，我把did也歸為parameter
在介紹有sub-function情況的request之前，首先要了解一下sub-function的定義方法。下圖是從iso14229中截來的，它是對sub-function的定義。
值得注意的是bit 7，從字面上來看它用來指示是否要抑制positive response。的確，它的目的就是這個意思，當bit 7為1（1 = 『true』）時，對該request的positive response要被抑制，即不傳送positive response；當bit7為0（0 = 『false』）時，對該request的positive response不被抑制，正常傳送。除了bit 7，sub-function有不同的值，具體的值和含義在協議中對每個服務的解釋時都會有介紹。
根據2.2的說明，不帶sub-function的服務，就帶parameter。parameter可以是did，可以是輸入引數，可以是自定義的值，位元組數目也是視具體要求而定。一般在協議內都會有**，當遇到具體問題時，可查表確定。
一般來講，response會在乙個服務被request且執行之後傳送，成功的話就發positive response，失敗的話要發negative response，但是也有例外的時候，比如ecureset，他要求先傳送response，然後再去執行具體的reset，因為如果先reset，那麼ecu的通訊模組shut down，是無法傳送出去response的。一般像這種特殊情況，協議會在描述具體服務時標註出來。
基本格式：
+ +
+ 其中要注意第乙個位元組是由sid和0x40的和構成，至於為什麼要這樣做，只能說協議就是這麼規定的，只要是positive的response，其第乙個位元組就是要由相應sid的值再加上0x40構成。這裡的parameter項是optional的，具體要看協議規定。
比如session control的service：
send：10 01（byte1的10是sid，byte2的01是sub-function，且可知bit 7是false）
receive：50 01 （byte1是sid+0x40，byte2是sub-funtion）
再舉個不帶sub-function的例子，比如readdatabyid這個service：
send：22 f1 86（byte1是sid，byte2和byte3是did，可視為parameter的一種）
receive：62 f1 86 01（byte1的62是sid+0x40，byte2和byte3是did，byte4是讀到的資料）
不論是物理定址還是功能定址，對於positive response來說都沒有影響，只需要關注sub-function中的bit 7 suppressposrspmsgindicationbit是0還是1，如果為0即false，那麼正常傳送即可，如果是1即true，那麼就不傳送response。如果根本沒有subfunction呢，那麼什麼都不要考慮，肯定是要傳送positive response的。
基本格式:
<0x7f> + +
看起來比較簡單，格式比較固定，只要是negative response，第一位元組就一定是0x7f，第二位元組照抄原來的sid，第三個位元組是錯誤響應碼，指示具體錯誤響應的原因，這個nrc可以在協議中查到，並且不同的服務所支援的nrc也有規定。
還是拿session control 這個service來舉例：
send：10 05（現在sun-function變為05了，假定系統不支援這個sub-function）
receive：7f 10 12（7f即指代錯誤響應，10為sid，12是nrc，查協議可知其指代sub-function not supported 這個錯誤）
格式講完了，來看看在物理定址和功能定址情況下，negative response分別有什麼區別。
首先在物理定址情況下，只要是negative response就應該按照規定格式傳送。而在功能定址情況下，有一點特殊，對於nrc為0x11（service not supported）、0x12（subfunction not supported）、0x31（request out of range）這三種情況，功能定址是不會傳送response的。
下面用一張流程圖來展示收到request之後ecu如何檢查他的合法性，並確定是正響應還是負響應，傳送還是不傳送。這裡只是展示最基本的步驟，還有具體的和每個服務相關的條件判斷，需要結合具體需求來討論。
uds幀格式 UDS診斷服務響應規則
如果我們說uds診斷服務是實現人或裝置與ecu控制器交流的一種語言，那麼診斷服務的響應規則就如同是語法，而sid service id 定義就如同詞彙。因此了解響應規則和sid的意義就基本能了解與ecu溝通的方法和含義。本文先來介紹一下響應規則。1.定址方式 在匯流排上往往有著眾多ecu裝置，作為診...
UDS中31服務的請求和響應的問題
31服務 ecu對特定的did賦予了某些操作，這些操作是ecu去執行的。怎麼去讓ecu去執行這些操作呢，這個時候就需要用31服務去開啟did這個按鈕。31服務可以對did進行三種控制操作，01開啟，02停止，03請求結果。只要31服務使用01 02 03三個子服務中任意乙個去控制某個特定的did，e...
http請求和響應頭格式分析
一.響應格式 下面是通過firebug獲取的響應頭資料資訊 響應頭資訊 原始頭資訊 響應格式主要有響應行，響應頭，響應體組成 響應行響應頭 2.content length 表示內容長度。只有當瀏覽器使用持久http連線時才需要這個資料。如果你想要利用持久連線的優勢，可以把輸出文件寫入bytearr...