UDS診斷服務介紹之31服務

正文

服務功能

功能描述

根據(jù)ISO14119-1標準中所述，診斷服務31服務主要用于實現(xiàn)針對某類測試場景，非正常工況下的程序活動以及其他擦除內(nèi)存等連續(xù)性操作步驟的集合。

在某些情況下2F服務的基本功能也是能夠通過31服務來實現(xiàn)，可以理解2F實現(xiàn)的功能31服務均可以實現(xiàn)，不過如果能夠用2F實現(xiàn)的功能來用31服務，未免有些大材小用，因此31服務則是用于更為復雜的輸入輸出控制場景，而2F服務則可用于較為簡單常見的輸入輸出控制場景。

下列文中使用到的Client可直接理解為上位機Tester，Server可直接理解為接受Tester診斷請求的ECU。

應用場景

一般而言，對于31診斷服務，主要應用場景為以下場合：

比如用于某sensor特定工況下的操作集合，如進行攝像頭或者雷達內(nèi)參標定流程；

在整車制造過程中較為常見的便是某Sensor的外參標定工位，在該工位中需要用到31服務開啟標定例程，標定流程結束后也能夠31服務獲取標定例程的最終結果；

如雷達使用過程中的非正常工況下的發(fā)波波形配置調整可以通過31服務來實現(xiàn)；

在進行UDS刷寫過程中可以通過31服務來觸發(fā)內(nèi)存的擦除操作等；

上述這些應用場景較為常見，這里就不一一列舉。

除了在哪些應用場景下使用，在此還需要針對31服務提出如下幾點注意事項：

31服務針對同一控制場景一般可分為開始，停止，獲取結果三個過程，這三個過程并不是同時存在，是否需要同時存在完全可以客戶自定義；

31服務針對每一個控制場景均可以一個Routine ID來進行唯一的區(qū)別，因此不同的控制場景應采用唯一的Routine ID來進行區(qū)別；

通過AUTOSAR工具鏈配置的31 Routine回調函數(shù)命名時，函數(shù)名除了說明其基本功能以外，也需要將對應的Routine ID體現(xiàn)在函數(shù)名稱中，這樣便于搜索排查問題，是一種不錯的代碼實踐；

對于31服務涉及的回調函數(shù)，一般不建議走RTE，主要是從代碼可維護角度而言，更加簡潔明了，實現(xiàn)效率高，走RTE接口還需增加額外的工作量，沒有必要且容易出錯。

31服務控制基本原理：

如下圖1所示，針對31服務的通信控制過程會經(jīng)過如下幾個AUTOSAR BSW模塊進行處理，然后完成最終的Routine控制，具體步驟如下：

Client 發(fā)送診斷指令給到Server，Server接收到指令后通過確認Routine Type來決定調用不同的回調函數(shù)；

在每個回調函數(shù)中便可以實現(xiàn)客戶自定義的控制場景，具體場景就是要根據(jù)客戶需求來自定義來實現(xiàn)的。

圖1 31服務控制流程圖

服務請求

服務請求是Client發(fā)送給到Server的診斷服務指令。

請求格式

按照ISO14229-1標準所述，如下圖2所示為31服務診斷請求格式，即上述31服務控制原理中診斷服務請求格式：

圖2 31診斷服務請求格式

上述參數(shù)routineControlOptionRecord是可選項，在項目中可自定義，如傳遞相關的一些控制參數(shù)等。除此之外，就是SID，SubFunction，routineIdentifier這三個參數(shù)則必選，下圖3中各參數(shù)解釋如下：

圖3 31診斷服務請求格式說明

請求實例

開啟Routine(01)

以開啟Routine為例，假設Routine ID為0201，該Routine則用于進行短時間的輸入輸出控制， 31服務診斷請求開啟Routine實例如下圖4所示：

圖4 31服務開啟Routine請求實例

停止Routine(02)

以停止Routine為例，31服務診斷停止Routine請求實例如下圖5所示：

圖5 31服務停止Routine請求實例

獲取Routine結果(03)

以獲取Routine結果為例，31服務診斷獲取Routine結果請求實例如下圖5所示：

圖6 31服務獲取Routine結果請求實例

服務響應

服務響應是針對Client對Server診斷請求的響應。

正響應格式

如下圖7所示，為31診斷服務的正響應格式：

圖7 31診斷服務正響應格式

從上圖中可以看出，31診斷服務的正響應由以下二個部分組成：

Response ID：該參數(shù)固定為SID+0x40 = 0x71；

SubFunction：該參數(shù)為上述診斷請求格式中Routine Type保持一致;

routineIdentifier: 該參數(shù)與診斷服務請求中的routineIdentifier中保持一致；

routineInfo：一般可以理解為客戶自定義，作為可選項；

routineStatusRecord: 同上；

正響應實例

開啟Routine(01)

如下圖8所示，為上述31 01 02 01請求示例所對應的正響應：

圖8 31 01正響應示例

其中，0x01就是跟診斷請求中31 01中的RoutineType保持一致即可，同時routineStatusRecord則是根據(jù)客戶需求進行自定義回復。

停止Routine(02)

如下圖9所示，為上述31 02 02 01請求示例所對應的正響應：

圖9 31 02正響應示例

其中，0x02就是跟診斷請求中31 02中的RoutineType保持一致即可，同時routineStatusRecord則是根據(jù)客戶需求進行自定義回復。

獲取Routine結果(03)

如下圖10所示，為上述31 03 02 01請求示例所對應的正響應：

圖10 31 03正響應示例

其中，0x03就是跟診斷請求中31 03中的RoutineType保持一致即可，同時routineStatusRecord則是根據(jù)客戶需求進行自定義回復。

負響應NRC支持

絕大多數(shù)情況下，Server針對Client的請求都會給到正響應，比如發(fā)生重啟前需確保整車處于安全狀態(tài)，如引擎熄火，車速不能超過3km/h等，或者為了防止不按照診斷請求格式進行請求，那么Server需要通過某種方式來告訴Client執(zhí)行不成功的原因在哪里以便于調查問題直至得到正響應。

因此ISO14229-1針對所有的診斷服務提供了一種統(tǒng)一的診斷負響應的診斷格式：7F +SID + NRC。

其中NRC全稱為Negetive Responce Code，每個NRC具有唯一的含義來代表當前診斷請求錯誤的原因所在。當然每個診斷服務支持的NRC不盡相同，具體支持的NRC需要參考ISO14229-1標準文檔，對于31服務而言支持的NRC如下圖：

圖11 31服務NRC支持

當診斷請求的subfuntion不在Server支持的范圍內(nèi)時，則Server會回復”7F 31 12“；

當發(fā)送報文長度或者格式不對時，則Server會回復"7F 31 13"；

例如當嘗試請求復位時且當前車速條件不滿足，此時Client發(fā)送診斷請求時，Server將會回復“7F 31 22”來告訴請求者當前進入編程會話的條件不滿足，請再次檢查進入編程會話的條件；

當某個routine還沒有Start時便請求結果或者中止Routine時，那么Server會回復"7F 31 24";

當routineIdentifier或者可選的routineControlOptionRecord中均超出規(guī)定的范圍時，則Server會回復“7F 31 31”；

當該routineIdenfier設置了安全訪問等級時，如果未解鎖便執(zhí)行該31服務，則Server會回復"7F 31 33";

當31服務用于擦除NVM時，在此過程中如果出現(xiàn)失敗那么Server便會回復"7F 31 72"

上述NRC也存在對應的優(yōu)先級，因此小T將對應的31服務NRC優(yōu)先級展示如下圖12所示：

圖12 31服務NRC優(yōu)先級

審核編輯：湯梓紅