引言

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

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

診斷方案設計

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

• 隔離方案

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

采用這種方案的優(yōu)點很明顯：

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

-網關統(tǒng)一進行轉發(fā)，可以由網關進行不同診斷路徑的管理。

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

• 透傳方案

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

透傳方案的優(yōu)點有以下兩點：

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

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

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

診斷需求定義

當確定了診斷方案后，就可以著手進行具體的診斷系統(tǒng)設計工作。以下是一些常見且關鍵的環(huán)節(jié)。

• 診斷拓撲圖定義

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

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

• 診斷ID分配

-為診斷節(jié)點分配合適的診斷ID地址。

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

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

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

• 整車配置字

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

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

• 診斷需求規(guī)范

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

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

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

• 刷寫需求規(guī)范

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

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

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

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

• 網關路由規(guī)范與網關路由表

-根據診斷方案和拓撲圖，明確路由方案，制定網關路由規(guī)范。

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

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

診斷數據庫開發(fā)

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

- ECU DATA: 控制器信息

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

- Service: 診斷服務定義

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

- DID (Data Identifier): 數據ID

包括系統(tǒng)DID和供應商自定義DID；靜態(tài)DID和動態(tài)DID。

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

-Routine: 例程

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

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

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

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

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

-Snapshot: 快照數據

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

-梳理交互邏輯及信息

通常會記錄發(fā)生計數器和老化計數器。

-其他內容

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

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

總結

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