ISO14229 理解（一）
前言
ISO-14229用于汽車行業(yè)診斷通信的需求規(guī)范，它只規(guī)定了與診斷相關(guān)的服務(wù)需求，并沒有涉及通信機(jī)制，因此要實(shí)現(xiàn)一個(gè)完整的診斷通信還需要定義網(wǎng)絡(luò)層協(xié)議（比如ISO-15765），還有底層硬件實(shí)現(xiàn)方式（比如CAN控制器）。由于不涉及網(wǎng)絡(luò)通信機(jī)制，可以架設(shè)在各種網(wǎng)絡(luò)之上，因此ISO-14229也稱為UDS（Unified Diagnostic Services）統(tǒng)一診斷服務(wù)。
在ISO14229里，共有26個(gè)UDS服務(wù)：
用法
其實(shí)診斷通信的機(jī)制很簡單，可以類比client-server通信方式，即客戶端發(fā)送request，服務(wù)器收到request之后進(jìn)行處理，然后向客戶端發(fā)送response。但是，診斷協(xié)議有自己的特色，它規(guī)定了在request和response的格式，在收到request的時(shí)候要做格式的檢查。同時(shí)由于尋址方式的不同，有無sub-function的支持等，也會(huì)影響request和response的處理方式和結(jié)果。
舉例：
首先來看服務(wù)請求和響應(yīng)格式，“請求”由client端發(fā)送給server，UDS規(guī)定使用1個(gè)byte來表示診斷服務(wù)，即所謂的Service ID,簡稱SID。請求報(bào)文里帶有SID，根據(jù)具體的服務(wù)內(nèi)容后面加具體的數(shù)據(jù)。肯定響應(yīng)格式由“SID+40+具體的數(shù)據(jù)”。否定響應(yīng)格式是一個(gè)固定的格式“7F+請求報(bào)文里的SID+一個(gè)字節(jié)的NRC”
診斷的request格式分2種，一種有sub-function的，一種沒有sub-function的，上述例子是沒有sub-function的。
當(dāng) UDS 服務(wù)支持 Subfunction 的請求和響應(yīng)格式時(shí)：
“請求”為 “SID + 一個(gè)字節(jié)Subfunction + 具體的數(shù)據(jù)”，
肯定響應(yīng)為“SID+40+Subfunction+具體的數(shù)據(jù)”，
而有的UDS服務(wù)里面是不支持 Subfunction，是支持DID的，DID是“數(shù)據(jù)ID”的意思，
它的請求格式為：“SID+具體的DID+數(shù)據(jù)內(nèi)容”，
肯定響應(yīng)為：“SID+40+DID+具體的數(shù)據(jù)”。
1. Request
基本格式：歸納起來，診斷的request格式無非以下2種：
即有無sub-function的區(qū)別。其中，我把DID也歸為Parameter
有sub-function：
在介紹有sub-function情況的request之前，首先要了解一下sub-function的定義方法。下圖是從ISO14229中截來的，它是對sub-function的定義。
值得注意的是Bit 7，從字面上來看它用來指示是否要抑制Positive Response。的確，它的目的就是這個(gè)意思，當(dāng)Bit 7為1（1 = ‘true’）時(shí)，對該request的Positive Response要被抑制，即不發(fā)送Positive Response；當(dāng)Bit7為0（0 = ‘false’）時(shí)，對該request的Positive Response不被抑制，正常發(fā)送。除了Bit 7，Sub-function有不同的值，具體的值和含義在協(xié)議中對每個(gè)服務(wù)的解釋時(shí)都會(huì)有介紹。
不帶sub-function：
不帶sub-function的服務(wù)，就帶parameter。Parameter可以是DID，可以是輸入?yún)?shù)，可以是自定義的值，字節(jié)數(shù)目也是視具體要求而定。一般在協(xié)議內(nèi)都會(huì)有表格，當(dāng)遇到具體問題時(shí)，可查表確定。
2. Response：
一般來講，response會(huì)在一個(gè)服務(wù)被request且執(zhí)行之后發(fā)送，成功的話就發(fā)positive response，失敗的話要發(fā)negative response，但是也有例外的時(shí)候，比如ECUreset，他要求先發(fā)送response，然后再去執(zhí)行具體的reset，因?yàn)槿绻萺eset，那么ECU的通信模塊shut down，是無法發(fā)送出去response的。一般像這種特殊情況，協(xié)議會(huì)在描述具體服務(wù)時(shí)標(biāo)注出來。
Positive Response：
基本格式：
其中要注意第一個(gè)字節(jié)是由SID和0x40的和構(gòu)成，至于為什么要這樣做，只能說協(xié)議就是這么規(guī)定的，只要是Positive的response，其第一個(gè)字節(jié)就是要由相應(yīng)SID的值再加上0x40構(gòu)成。這里的Parameter項(xiàng)是optional的，具體要看協(xié)議規(guī)定。
舉例：
比如session control的service：
舉個(gè)不帶sub-function的例子，比如ReadDataById這個(gè)service：
Send：22 F1 86（byte1是SID，byte2和byte3是DID，可視為parameter的一種） Receive：62 F1 86 01（byte1的62是SID+0x40，byte2和byte3是DID，byte4是讀到的數(shù)據(jù)）注釋： 不論是物理尋址還是功能尋址，對于Positive Response來說都沒有影響，只需要關(guān)注sub-function中的Bit 7 suppressPosRspMsgIndicationBit是0還是1，如果為0即false，那么正常發(fā)送即可，如果是1即true，那么就不發(fā)送response。如果根本沒有subfunction呢，那么什么都不要考慮，肯定是要發(fā)送positive response的。
Negative Response：
基本格式:
看起來比較簡單，格式比較固定，只要是Negative Response，第一字節(jié)就一定是0x7F，第二字節(jié)照抄原來的SID，第三個(gè)字節(jié)是錯(cuò)誤響應(yīng)碼，指示具體錯(cuò)誤響應(yīng)的原因，這個(gè)NRC可以在協(xié)議中查到，并且不同的服務(wù)所支持的NRC也有規(guī)定。
下面這張圖列舉了部分原因代碼，比如，如果ECU給出7F 22 13這個(gè)negative response，則說明22這個(gè)服務(wù)因?yàn)樵\斷請求數(shù)據(jù)長度不對的原因無法執(zhí)行。
還是拿session control 這個(gè)service來舉例：
Send：10 05（現(xiàn)在sun-function變?yōu)?5了，假定系統(tǒng)不支持這個(gè)sub-function） Receive：7F 10 12（7F即指代錯(cuò)誤響應(yīng)，10為SID，12是NRC，查協(xié)議可知其指代sub-function not supported 這個(gè)錯(cuò)誤）格式講完了，來看看在物理尋址和功能尋址情況下，Negative Response分別有什么區(qū)別：
首先在物理尋址情況下，只要是Negative Response就應(yīng)該按照規(guī)定格式發(fā)送。而在功能尋址情況下，有一點(diǎn)特殊，對于NRC為0x11（service not supported）、0x12（subfunction not supported）、0x31（request out of range）這三種情況，功能尋址是不會(huì)發(fā)送response的。
Request的檢查策略
總結(jié)
以上是生活随笔為你收集整理的ISO14229 理解（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux文件管理 | Liunx 常用
- 下一篇： 现货K线图知识之五：北坡炮兵并排跑