如何從0到1設(shè)計診斷系統(tǒng)
加入技術(shù)交流群
引言
在整車電子電氣體系中，診斷系統(tǒng)的設(shè)計扮演著至關(guān)重要的角色，負(fù)責(zé)支持整車的刷寫、故障排查和EOL(End of Line)等關(guān)鍵操作。這一重要性在于這些操作的實現(xiàn)都依賴于診斷系統(tǒng)的全面支持。因此，在設(shè)計診斷系統(tǒng)時，必須確保系統(tǒng)具備全面性、安全性和高效性。
診斷系統(tǒng)設(shè)計主要涵蓋了診斷方案設(shè)計、診斷需求定義和診斷數(shù)據(jù)庫開發(fā)。本文會逐一介紹這些環(huán)節(jié)，以便更好地理解和把握診斷系統(tǒng)設(shè)計的全貌。
診斷方案設(shè)計
在進(jìn)行具體的需求定義前，首先需要確定診斷方案，主要內(nèi)容包括明確本地診斷、遠(yuǎn)程診斷、OTA (Over The Air)、車內(nèi)診斷的診斷路徑。這里以本地診斷為例進(jìn)行介紹，常見診斷方案包括隔離方案和透傳方案。
· 隔離方案
隔離方案是指將車內(nèi)和車外劃分為不同的網(wǎng)段，診斷儀發(fā)送的診斷信息必須通過邊緣節(jié)點進(jìn)行路由映射后，再轉(zhuǎn)發(fā)至車內(nèi)的目標(biāo)節(jié)點。
采用這種方案的優(yōu)點很明顯：
? 因為車內(nèi)外的網(wǎng)段隔離，可以更好的進(jìn)行安全防護(hù)。
? 網(wǎng)關(guān)統(tǒng)一進(jìn)行轉(zhuǎn)發(fā)，可以由網(wǎng)關(guān)進(jìn)行不同診斷路徑的管理。
當(dāng)然此方案也有一定的缺陷，最明顯的就是如果網(wǎng)關(guān)的轉(zhuǎn)發(fā)性能不足，則診斷路由的延時會較長，會影響一些場景（如刷寫）的效率。
· 透傳方案
透傳方案是將車內(nèi)和車外劃分在同一個網(wǎng)段，診斷儀可以直接與車內(nèi)節(jié)點建立以太網(wǎng)診斷鏈接，無需經(jīng)過邊緣節(jié)點進(jìn)行路由。
透傳方案的優(yōu)點有以下兩點：
? 診斷儀可與車內(nèi)以太網(wǎng)節(jié)點直接建立鏈接，無需中間節(jié)點路由，傳輸大數(shù)據(jù)時效率高。
? 對網(wǎng)關(guān)的路由性能要求較低，做好不同傳輸協(xié)議（如DoIP-CAN）的路由即可。
其缺點一是不方便網(wǎng)關(guān)做統(tǒng)一的管理，其次就是安全性方面有更高的要求。
診斷需求定義
當(dāng)確定了診斷方案后，就可以著手進(jìn)行具體的診斷系統(tǒng)設(shè)計工作。以下是一些常見且關(guān)鍵的環(huán)節(jié)。
· 診斷拓?fù)鋱D定義
? 根據(jù)整車拓?fù)浜驮\斷方案，確定每個控制器診斷、刷寫的路徑。
? 繪制診斷網(wǎng)絡(luò)拓?fù)鋱D，以清晰展示各個節(jié)點之間的關(guān)系。
· 診斷ID分配
? 為診斷節(jié)點分配合適的診斷ID地址。
? 為車內(nèi)/車外診斷設(shè)備、物理尋址和功能尋址分配合適的地址。
? 分配CAN請求響應(yīng)ID（參考ISO 15765-4）。
? 分配以太網(wǎng)DoIP邏輯地址 (參考ISO 13400-2)。
· 整車配置字
? 如果診斷平臺包含多個車型或者不同配置，開發(fā)整車配置字是必要的。
? 確保配置字能夠正確標(biāo)識車型和配置，方便在診斷平臺中進(jìn)行正確的配置切換。
· 診斷需求規(guī)范
? 包含了平臺可能會用到的診斷服務(wù)和基礎(chǔ)需求。
? 針對不同的總線需要考慮其對UDS診斷的影響，例如：會話層時間參數(shù)的值的差異。
? 由于車內(nèi)包含各種傳輸協(xié)議，所以需要注意診斷對底層協(xié)議的需求約束。這里以以太網(wǎng)為例子，包括doip需求定義、tcpip相關(guān)參數(shù)定義、物理層定義等。
· 刷寫需求規(guī)范
在進(jìn)行刷寫需求規(guī)范的開發(fā)時，需注意不同種類的控制器會使用不同的刷寫流程。一般可以將控制器分為：嵌入式系統(tǒng)控制器、帶有文件管理系統(tǒng)的控制器。
? 嵌入式控制器：這類控制器基于BootLoader進(jìn)行刷寫，一般需要先執(zhí)行擦除例程，再使用0x34、0x36、0x37服務(wù)請求進(jìn)行文件寫入。
? 帶有文件管理系統(tǒng)的控制器：一般為使用OS操作系統(tǒng)的控制器，先使用0x38、0x36、0x37服務(wù)進(jìn)行程序的下載，再由文件管理系統(tǒng)通過安裝例程進(jìn)行安裝操作。
? 如果有并行刷寫、靜默刷寫等特殊的需求，也需要在刷寫需求規(guī)范中進(jìn)行明確定義。
· 網(wǎng)關(guān)路由規(guī)范與網(wǎng)關(guān)路由表
? 根據(jù)診斷方案和拓?fù)鋱D，明確路由方案，制定網(wǎng)關(guān)路由規(guī)范。
? 當(dāng)路由方案確認(rèn)后，需要進(jìn)行網(wǎng)關(guān)路由表的開發(fā)，以確保每個路由節(jié)點能夠選擇正確的路由路徑。
以上是診斷需求定義中的一些重要環(huán)節(jié)，這些內(nèi)容都對診斷具體參數(shù)的開發(fā)和診斷功能的實現(xiàn)起著指導(dǎo)性的作用。
診斷數(shù)據(jù)庫開發(fā)
診斷調(diào)查問卷和診斷數(shù)據(jù)庫的開發(fā)是一個長期持續(xù)的工作。在這個過程中，我們需要整合企業(yè)標(biāo)準(zhǔn)的定義，各方向?qū)I(yè)工程師的建議以及供應(yīng)商反饋的信息，并持續(xù)完善和優(yōu)化。診斷調(diào)查問卷中的內(nèi)容將應(yīng)用于研發(fā)、生產(chǎn)、售后等各個階段。
? ECU DATA: 控制器信息
對每個ECU進(jìn)行詳細(xì)的描述，包括CAN ID、邏輯地址等信息。
? Service: 診斷服務(wù)定義
列出每個ECU支持的服務(wù)、子功能、否定響應(yīng)、支持的安全等級等信息。
? DID (Data Identifier): 數(shù)據(jù)ID
包括系統(tǒng)DID和供應(yīng)商自定義DID；靜態(tài)DID和動態(tài)DID。
對每個DID的功能進(jìn)行描述，包括其示例、范圍和用途。
? Routine: 例程
包括刷寫相關(guān)的例程、EOL相關(guān)例程以及功能相關(guān)例程等。
提供每個例程的詳細(xì)說明和執(zhí)行步驟。
? DTC (Diagnostic Trouble Codes): 診斷故障碼
包括基本通信相關(guān)、信息安全相關(guān)和功能相關(guān)的DTC。
對每個DTC提供詳細(xì)的描述，包括使能條件、記錄條件和恢復(fù)條件等。
? Snapshot: 快照數(shù)據(jù)
通常會管理最近一次和第一次的快照信息，包括車輛的基礎(chǔ)數(shù)據(jù)和狀態(tài)。
? 梳理交互邏輯及信息
通常會記錄發(fā)生計數(shù)器和老化計數(shù)器。
? 其他內(nèi)容
如時間參數(shù)、28服務(wù)的通信配置、2F服務(wù)的定義等，這里不再詳細(xì)贅述。
在完成診斷調(diào)查問卷的開發(fā)之后，我們需要將問卷轉(zhuǎn)換成診斷數(shù)據(jù)庫，以便進(jìn)行診斷數(shù)據(jù)交換。在此過程中，需要注意診斷數(shù)據(jù)庫的格式以及適用的工具鏈的選擇，以確保在進(jìn)行優(yōu)劣取舍時能夠做出明智的決策。在數(shù)據(jù)庫格式的選取方面，鑒于ODX格式的開源屬性，該格式能夠較好地適應(yīng)整車開發(fā)、生產(chǎn)及售后各階段的需求，因而是一種較為推薦的數(shù)據(jù)庫格式。
總結(jié)
在當(dāng)今汽車電子電氣架構(gòu)逐漸完善的背景下，診斷系統(tǒng)設(shè)計已不僅僅是純粹的診斷問題，而需要對整車的通信、功能和安全性進(jìn)行綜合考量。例如，在設(shè)計診斷方案時，需要考慮到診斷路徑的安全性和可靠性。在進(jìn)行診斷需求定義和數(shù)據(jù)庫開發(fā)時，需要思考到不同診斷場景下的差異化要求。綜合各方面需求的診斷系統(tǒng)會為整車從研發(fā)生產(chǎn)到售后都提供強(qiáng)有力的支持。
了解更多：請致電 010-64840808轉(zhuǎn)6116 或發(fā)郵件至market_dept@hirain.com（聯(lián)系時請說明來自EEPW）
*博客內(nèi)容為網(wǎng)友個人發(fā)布，僅代表博主個人觀點，如有侵權(quán)請聯(lián)系工作人員刪除。
