ISO14229 理解（一）
前言
ISO-14229用于汽車行業診斷通信的需求規范，它只規定了與診斷相關的服務需求，并沒有涉及通信機制，因此要實現一個完整的診斷通信還需要定義網絡層協議（比如ISO-15765），還有底層硬件實現方式（比如CAN控制器）。由于不涉及網絡通信機制，可以架設在各種網絡之上，因此ISO-14229也稱為UDS（Unified Diagnostic Services）統一診斷服務。
在ISO14229里，共有26個UDS服務：
用法
其實診斷通信的機制很簡單，可以類比client-server通信方式，即客戶端發送request，服務器收到request之后進行處理，然后向客戶端發送response。但是，診斷協議有自己的特色，它規定了在request和response的格式，在收到request的時候要做格式的檢查。同時由于尋址方式的不同，有無sub-function的支持等，也會影響request和response的處理方式和結果。
舉例：
首先來看服務請求和響應格式，“請求”由client端發送給server，UDS規定使用1個byte來表示診斷服務，即所謂的Service ID,簡稱SID。請求報文里帶有SID，根據具體的服務內容后面加具體的數據。肯定響應格式由“SID+40+具體的數據”。否定響應格式是一個固定的格式“7F+請求報文里的SID+一個字節的NRC”
診斷的request格式分2種，一種有sub-function的，一種沒有sub-function的，上述例子是沒有sub-function的。
當 UDS 服務支持 Subfunction 的請求和響應格式時：
“請求”為 “SID + 一個字節Subfunction + 具體的數據”，
肯定響應為“SID+40+Subfunction+具體的數據”，
而有的UDS服務里面是不支持 Subfunction，是支持DID的，DID是“數據ID”的意思，
它的請求格式為：“SID+具體的DID+數據內容”，
肯定響應為：“SID+40+DID+具體的數據”。
1. Request
基本格式：歸納起來，診斷的request格式無非以下2種：
即有無sub-function的區別。其中，我把DID也歸為Parameter
有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有不同的值，具體的值和含義在協議中對每個服務的解釋時都會有介紹。
不帶sub-function：
不帶sub-function的服務，就帶parameter。Parameter可以是DID，可以是輸入參數，可以是自定義的值，字節數目也是視具體要求而定。一般在協議內都會有表格，當遇到具體問題時，可查表確定。
2. Response：
一般來講，response會在一個服務被request且執行之后發送，成功的話就發positive response，失敗的話要發negative response，但是也有例外的時候，比如ECUreset，他要求先發送response，然后再去執行具體的reset，因為如果先reset，那么ECU的通信模塊shut down，是無法發送出去response的。一般像這種特殊情況，協議會在描述具體服務時標注出來。
Positive Response：
基本格式：
其中要注意第一個字節是由SID和0x40的和構成，至于為什么要這樣做，只能說協議就是這么規定的，只要是Positive的response，其第一個字節就是要由相應SID的值再加上0x40構成。這里的Parameter項是optional的，具體要看協議規定。
舉例：
比如session control的service：
舉個不帶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的。
Negative Response：
基本格式:
看起來比較簡單，格式比較固定，只要是Negative Response，第一字節就一定是0x7F，第二字節照抄原來的SID，第三個字節是錯誤響應碼，指示具體錯誤響應的原因，這個NRC可以在協議中查到，并且不同的服務所支持的NRC也有規定。
下面這張圖列舉了部分原因代碼，比如，如果ECU給出7F 22 13這個negative response，則說明22這個服務因為診斷請求數據長度不對的原因無法執行。
還是拿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的檢查策略
總結
以上是生活随笔為你收集整理的ISO14229 理解（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux文件管理 | Liunx 常用
- 下一篇： 现货K线图知识之五：北坡炮兵并排跑