作者:autogeek
原文鏈接:http://www.cnblogs.com/autogeek/p/4458658.html
1. 簡單的通信機制
其實診斷通信的機制很簡單，可以類比client-server通信方式，即客戶端發送request，服務器收到request之后進行處理，然后向客戶端發送response。但是，診斷協議有自己的特色，它規定了在request和response的格式，在收到request的時候要做格式的檢查。同時由於尋址方式的不同，有無sub-function的支持等，也會影響request和response的處理方式和結果。下面將我就具體情況分析，盡量做到簡介明了。
2. Request
2.1 基本格式
歸納起來，診斷的request格式無非以下2種：
<SID> + <Sub-function> + <Parameter>
<SID> + <Parameter>
即有無sub-function的區別。其中，我把DID也歸為Parameter
2.2 有sub-function
在介紹有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.3 不帶sub-function
根據2.2的說明，不帶sub-function的服務，就帶parameter。Parameter可以是DID，可以是輸入參數，可以是自定義的值，字節數目也是視具體要求而定。一般在協議內都會有表格，當遇到具體問題時，可查表確定。
3. Response
一般來講，response會在一個服務被request且執行之后發送，成功的話就發positive response，失敗的話要發negative response，但是也有例外的時候，比如ECUreset，他要求先發送response，然后再去執行具體的reset，因為如果先reset，那么ECU的通信模塊shut down，是無法發送出去response的。一般像這種特殊情況，協議會在描述具體服務時標注出來。
3.1 Positive Response
基本格式：
<SID+0x40> + <Sub-function> + <Parameter>
<SID+0x40> + <Parameter>
其中要注意第一個字節是由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的。
3.2 Negative Response
基本格式:
<0x7F> + <SID> + <NRC>
看起來比較簡單，格式比較固定，只要是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的。
4. Request的檢查策略
下面用一張流程圖來展示收到request之后ECU如何檢查他的合法性，並確定是正響應還是負響應，發送還是不發送。這里只是展示最基本的步驟，還有具體的和每個服務相關的條件判斷，需要結合具體需求來討論。
