更多文章
華為蔡建永：智能網聯汽車的數字安全和功能安全挑戰與思考
汽車數據合規要點
車載以太網技術發展與測試方法
車載以太網防火墻設計
SOA：整車架構下一代的升級方向
軟件如何「吞噬」汽車？
汽車信息安全 TARA 分析方法實例簡介
汽車FOTA信息安全規范及方法研究
聯合國WP.29車輛網絡安全法規正式發布
滴滴下架，我卻看到數據安全的曙光
從特斯拉被約談到車輛遠程升級（OTA）技術的合規
如何通過CAN破解汽
會員權益:?(點擊可進入)談思實驗室VIP會員
點擊上方藍字談思實驗室
獲取更多汽車網絡安全資訊
功能描述
根據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來決定調用不同的回調函數；
在每個回調函數中便可以實現客戶自定義的控制場景，具體場景就是要根據客戶需求來自定義來實現的。
服務請求是Client發送給到Server的診斷服務指令。
按照ISO14229-1標準所述，如下圖2所示為31服務診斷請求格式，即上述31服務控制原理中診斷服務請求格式：
上述參數routineControlOptionRecord是可選項，在項目中可自定義，如傳遞相關的一些控制參數等。除此之外，就是SID，SubFunction，routineIdentifier這三個參數則必選，下圖3中各參數解釋如下：
開啟Routine(01)
以開啟Routine為例，假設Routine ID為0201，該Routine則用于進行短時間的輸入輸出控制， 31服務診斷請求開啟Routine實例如下圖4所示：
停止Routine(02)
以停止Routine為例，31服務診斷停止Routine請求實例如下圖5所示：
獲取Routine結果(03)
以獲取Routine結果為例，31服務診斷獲取Routine結果請求實例如下圖5所示：
服務響應是針對Client對Server診斷請求的響應。
如下圖7所示，為31診斷服務的正響應格式：
從上圖中可以看出，31診斷服務的正響應由以下二個部分組成：
Response ID：該參數固定為SID+0x40 = 0x71；
SubFunction：該參數為上述診斷請求格式中Routine Type保持一致;
routineIdentifier: 該參數與診斷服務請求中的routineIdentifier中保持一致；
routineInfo：一般可以理解為客戶自定義，作為可選項；
routineStatusRecord: 同上；
開啟Routine(01)
如下圖8所示，為上述31 01 02 01請求示例所對應的正響應：
其中，0x01就是跟診斷請求中31 01中的RoutineType保持一致即可，同時routineStatusRecord則是根據客戶需求進行自定義回復。
停止Routine(02)
如下圖9所示，為上述31 02 02 01請求示例所對應的正響應：
其中，0x02就是跟診斷請求中31 02中的RoutineType保持一致即可，同時routineStatusRecord則是根據客戶需求進行自定義回復。
獲取Routine結果(03)
如下圖10所示，為上述31 03 02 01請求示例所對應的正響應：
其中，0x03就是跟診斷請求中31 03中的RoutineType保持一致即可，同時routineStatusRecord則是根據客戶需求進行自定義回復。
絕大多數情況下，Server針對Client的請求都會給到正響應，比如發生重啟前需確保整車處于安全狀態，如引擎熄火，車速不能超過3km/h等，或者為了防止不按照診斷請求格式進行請求，那么Server需要通過某種方式來告訴Client執行不成功的原因在哪里以便于調查問題直至得到正響應。
因此ISO14229-1針對所有的診斷服務提供了一種統一的診斷負響應的診斷格式：7F +SID + NRC。
其中NRC全稱為Negetive Responce Code，每個NRC具有唯一的含義來代表當前診斷請求錯誤的原因所在。當然每個診斷服務支持的NRC不盡相同，具體支持的NRC需要參考ISO14229-1標準文檔，對于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所示：
碼上報名
AutoSec?2023 第七屆中國汽車網絡安全周暨第四屆智能汽車數據安全展，9月13-15日，上海
更多文章
軟件如何「吞噬」汽車？
汽車信息安全 TARA 分析方法實例簡介
汽車FOTA信息安全規范及方法研究
聯合國WP.29車輛網絡安全法規正式發布
滴滴下架，我卻看到數據安全的曙光
從特斯拉被約談到車輛遠程升級（OTA）技術的合規
如何通過CAN破解汽
會員權益:?(點擊可進入)談思實驗室VIP會員
