如何從0到1設(shè)計(jì)診斷系統(tǒng)

引言

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

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

診斷方案設(shè)計(jì)

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

• 隔離方案

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

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

- 因?yàn)檐噧?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é)點(diǎn)建立以太網(wǎng)診斷鏈接，無需經(jīng)過邊緣節(jié)點(diǎn)進(jìn)行路由。

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

-診斷儀可與車內(nèi)以太網(wǎng)節(jié)點(diǎn)直接建立鏈接，無需中間節(jié)點(diǎn)路由，傳輸大數(shù)據(jù)時效率高。

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

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

診斷需求定義

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

• 診斷拓?fù)鋱D定義

-根據(jù)整車拓?fù)浜驮\斷方案，確定每個控制器診斷、刷寫的路徑。

-繪制診斷網(wǎng)絡(luò)拓?fù)鋱D，以清晰展示各個節(jié)點(diǎn)之間的關(guān)系。

• 診斷ID分配

-為診斷節(jié)點(diǎn)分配合適的診斷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é)點(diǎn)能夠選擇正確的路由路徑。

以上是診斷需求定義中的一些重要環(huán)節(jié)，這些內(nèi)容都對診斷具體參數(shù)的開發(fā)和診斷功能的實(shí)現(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ā)生計(jì)數(shù)器和老化計(jì)數(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ì)已不僅僅是純粹的診斷問題，而需要對整車的通信、功能和安全性進(jìn)行綜合考量。例如，在設(shè)計(jì)診斷方案時，需要考慮到診斷路徑的安全性和可靠性。在進(jìn)行診斷需求定義和數(shù)據(jù)庫開發(fā)時，需要思考到不同診斷場景下的差異化要求。綜合各方面需求的診斷系統(tǒng)會為整車從研發(fā)生產(chǎn)到售后都提供強(qiáng)有力的支持。