正文

服務功能

功能描述

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

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

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

應用場景

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

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

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

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

在進行UDS刷寫過程中可以通過31服務來觸發內存的擦除操作等；

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

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

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

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

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

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

31服務控制基本原理：

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

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

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

圖1 31服務控制流程圖

服務請求

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

請求格式

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

圖2 31診斷服務請求格式

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

圖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：該參數固定為SID+0x40 = 0x71；

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

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

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

routineStatusRecord: 同上；

正響應實例

開啟Routine(01)

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

圖8 31 01正響應示例

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

停止Routine(02)

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

圖9 31 02正響應示例

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

獲取Routine結果(03)

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

圖10 31 03正響應示例

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

負響應NRC支持

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

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

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

圖11 31服務NRC支持

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

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

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

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

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

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

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

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

圖12 31服務NRC優先級

審核編輯：湯梓紅