引言

       在整車電子電氣體系中，診斷系統的設計扮演著至關重要的角色，負責支持整車的刷寫、故障排查和EOL(End of Line)等關鍵操作。這一重要性在于這些操作的實現都依賴于診斷系統的全面支持。因此，在設計診斷系統時，必須確保系統具備全面性、安全性和高效性。

       診斷系統設計主要涵蓋了診斷方案設計、診斷需求定義和診斷數據庫開發。本文會逐一介紹這些環節，以便更好地理解和把握診斷系統設計的全貌。

診斷方案設計

       在進行具體的需求定義前，首先需要確定診斷方案，主要內容包括明確本地診斷、遠程診斷、OTA (Over The Air)、車內診斷的診斷路徑。這里以本地診斷為例進行介紹，常見診斷方案包括隔離方案和透傳方案。

    · 隔離方案

         隔離方案是指將車內和車外劃分為不同的網段，診斷儀發送的診斷信息必須通過邊緣節點進行路由映射后，再轉發至車內的目標節點。

        采用這種方案的優點很明顯： 

         ? 因為車內外的網段隔離，可以更好的進行安全防護。

         ? 網關統一進行轉發，可以由網關進行不同診斷路徑的管理。

         當然此方案也有一定的缺陷，最明顯的就是如果網關的轉發性能不足，則診斷路由的延時會較長，會影響一些場景（如刷寫）的效率。

    · 透傳方案

         透傳方案是將車內和車外劃分在同一個網段，診斷儀可以直接與車內節點建立以太網診斷鏈接，無需經過邊緣節點進行路由。

        透傳方案的優點有以下兩點：

         ? 診斷儀可與車內以太網節點直接建立鏈接，無需中間節點路由，傳輸大數據時效率高。

         ? 對網關的路由性能要求較低，做好不同傳輸協議（如DoIP-CAN）的路由即可。

         其缺點一是不方便網關做統一的管理，其次就是安全性方面有更高的要求。

診斷需求定義

       當確定了診斷方案后，就可以著手進行具體的診斷系統設計工作。以下是一些常見且關鍵的環節。

    · 診斷拓撲圖定義

         ? 根據整車拓撲和診斷方案，確定每個控制器診斷、刷寫的路徑。

         ? 繪制診斷網絡拓撲圖，以清晰展示各個節點之間的關系。

     · 診斷ID分配

         ? 為診斷節點分配合適的診斷ID地址。

         ? 為車內/車外診斷設備、物理尋址和功能尋址分配合適的地址。

         ? 分配CAN請求響應ID（參考ISO 15765-4）。

         ? 分配以太網DoIP邏輯地址 (參考ISO 13400-2)。

    · 整車配置字

         ? 如果診斷平臺包含多個車型或者不同配置，開發整車配置字是必要的。

         ? 確保配置字能夠正確標識車型和配置，方便在診斷平臺中進行正確的配置切換。

    · 診斷需求規范

         ? 包含了平臺可能會用到的診斷服務和基礎需求。

         ? 針對不同的總線需要考慮其對UDS診斷的影響，例如：會話層時間參數的值的差異。

         ? 由于車內包含各種傳輸協議，所以需要注意診斷對底層協議的需求約束。這里以以太網為例子，包括doip需求定義、tcpip相關參數定義、物理層定義等。

    · 刷寫需求規范

         在進行刷寫需求規范的開發時，需注意不同種類的控制器會使用不同的刷寫流程。一般可以將控制器分為：嵌入式系統控制器、帶有文件管理系統的控制器。

         ? 嵌入式控制器：這類控制器基于BootLoader進行刷寫，一般需要先執行擦除例程，再使用0x34、0x36、0x37服務請求進行文件寫入。

         ? 帶有文件管理系統的控制器：一般為使用OS操作系統的控制器，先使用0x38、0x36、0x37服務進行程序的下載，再由文件管理系統通過安裝例程進行安裝操作。

         ? 如果有并行刷寫、靜默刷寫等特殊的需求，也需要在刷寫需求規范中進行明確定義。

    · 網關路由規范與網關路由表

         ? 根據診斷方案和拓撲圖，明確路由方案，制定網關路由規范。

         ? 當路由方案確認后，需要進行網關路由表的開發，以確保每個路由節點能夠選擇正確的路由路徑。

         以上是診斷需求定義中的一些重要環節，這些內容都對診斷具體參數的開發和診斷功能的實現起著指導性的作用。

診斷數據庫開發

        診斷調查問卷和診斷數據庫的開發是一個長期持續的工作。在這個過程中，我們需要整合企業標準的定義，各方向專業工程師的建議以及供應商反饋的信息，并持續完善和優化。診斷調查問卷中的內容將應用于研發、生產、售后等各個階段。

         ? ECU DATA: 控制器信息

             對每個ECU進行詳細的描述，包括CAN ID、邏輯地址等信息。

         ? Service: 診斷服務定義

             列出每個ECU支持的服務、子功能、否定響應、支持的安全等級等信息。

         ? DID (Data Identifier): 數據ID

             包括系統DID和供應商自定義DID；靜態DID和動態DID。

             對每個DID的功能進行描述，包括其示例、范圍和用途。

         ? Routine: 例程

             包括刷寫相關的例程、EOL相關例程以及功能相關例程等。

             提供每個例程的詳細說明和執行步驟。

         ? DTC (Diagnostic Trouble Codes): 診斷故障碼

             包括基本通信相關、信息安全相關和功能相關的DTC。

             對每個DTC提供詳細的描述，包括使能條件、記錄條件和恢復條件等。

         ? Snapshot: 快照數據

             通常會管理最近一次和第一次的快照信息，包括車輛的基礎數據和狀態。

         ? 梳理交互邏輯及信息

             通常會記錄發生計數器和老化計數器。

         ? 其他內容

             如時間參數、28服務的通信配置、2F服務的定義等，這里不再詳細贅述。

         在完成診斷調查問卷的開發之后，我們需要將問卷轉換成診斷數據庫，以便進行診斷數據交換。在此過程中，需要注意診斷數據庫的格式以及適用的工具鏈的選擇，以確保在進行優劣取舍時能夠做出明智的決策。在數據庫格式的選取方面，鑒于ODX格式的開源屬性，該格式能夠較好地適應整車開發、生產及售后各階段的需求，因而是一種較為推薦的數據庫格式。

總結

       在當今汽車電子電氣架構逐漸完善的背景下，診斷系統設計已不僅僅是純粹的診斷問題，而需要對整車的通信、功能和安全性進行綜合考量。例如，在設計診斷方案時，需要考慮到診斷路徑的安全性和可靠性。在進行診斷需求定義和數據庫開發時，需要思考到不同診斷場景下的差異化要求。綜合各方面需求的診斷系統會為整車從研發生產到售后都提供強有力的支持。

       了解更多：請致電 010-64840808轉6116 或發郵件至market_dept@hirain.com（聯系時請說明來自EEPW）