作者 |愛吃小炒肉
小編 | 不吃豬頭肉

方案銜接
本方案是對北匯信息提供的CAN/CAN FD/CAN XL/LIN/FlexRay總線網(wǎng)絡(luò)及診斷測試解決方案的進一步補充和優(yōu)化，雖然此測試系統(tǒng)方案的結(jié)構(gòu)和接口采用模塊化的設(shè)計思路，可根據(jù)測試需求進行功能模塊的裁剪和定制，使測試系統(tǒng)具備一定的延展性并可適配不同平臺變型測試需求，但在具體的測試實施過程中，尤其是在車型平臺和控制器變化時，測試腳本的復(fù)用性問題仍然存在一些挑戰(zhàn)。注：點擊最下方“閱讀原文”查看CAN/CAN FD/CAN XL/LIN/FlexRay總線網(wǎng)絡(luò)及診斷測試解決方案在此基礎(chǔ)上，本方案針對單控制器或整車網(wǎng)絡(luò)及診斷測試過程中的測試腳本復(fù)用難題進行了深入分析，提出了通過通信數(shù)據(jù)庫抽象、網(wǎng)關(guān)路由表適配與動態(tài)測試參數(shù)管理的方式，進一步提升測試腳本在不同車型上的復(fù)用性和自動化程度，確保新車型上線的測試效率。

方案背景
在汽車電子控制器（ECU）的網(wǎng)絡(luò)與診斷測試過程中，車型平臺和控制器的差異導(dǎo)致了測試腳本的開發(fā)難以復(fù)用，主要體現(xiàn)在以下幾個方面：

數(shù)據(jù)庫文件差異：各控制器的數(shù)據(jù)庫文件各不相同，導(dǎo)致某一車型平臺的測試腳本在測試執(zhí)行時需要手工變更具體的測試參數(shù)。

網(wǎng)關(guān)路由表差異：不同的車型平臺和控制器可能采用不同的網(wǎng)關(guān)路由表，導(dǎo)致測試參數(shù)需要根據(jù)不同路由表進行調(diào)整。

測試參數(shù)的差異性：每個車型或控制器在進行網(wǎng)絡(luò)和診斷測試時，其輸入輸出參數(shù)（如信號速率、消息ID等）也有所不同，這些參數(shù)在開發(fā)過程中必須被細化和定制化，進一步增加了開發(fā)復(fù)雜度。

通信協(xié)議的差異：各車型平臺使用的通信協(xié)議可能存在差異，常見的有CAN、CANFD、LIN、FlexRay、Ethernet等。這些協(xié)議在數(shù)據(jù)傳輸方式、速率、數(shù)據(jù)幀結(jié)構(gòu)等方面有所不同，導(dǎo)致為某種協(xié)議設(shè)計的測試腳本在面對另一種協(xié)議時，無法直接使用。例如，CAN和FlexRay在數(shù)據(jù)傳輸方式、數(shù)據(jù)幀格式、通信速率上的不同會導(dǎo)致信號監(jiān)控和數(shù)據(jù)捕獲邏輯的腳本完全不同。

診斷服務(wù)差異：不同的車型和控制器，涉及的診斷請求、數(shù)據(jù)格式、DTC解析方式也不同，使得針對某種診斷服務(wù)編寫的測試腳本難以復(fù)用于另一個車型或控制器。

鑒于以上這些差異導(dǎo)致的測試腳本開發(fā)的重復(fù)性工作量大，復(fù)用性差的問題，使得業(yè)內(nèi)整車廠面臨了頗為棘手的問題就是測試部門開發(fā)的部件級測試腳本釋放給供應(yīng)商后，由于各控制器涉及的參數(shù)不一樣，腳本難以適配，要么供應(yīng)商自己重新開發(fā)、要么整車廠測試部門的相關(guān)人員分類調(diào)試適配，不管是哪種解決辦法都會嚴重影響控制器交付時間乃至車型上市時間。

軟件集成方案
為解決上述問題，北匯信息提出一套涵蓋數(shù)據(jù)庫文件轉(zhuǎn)換、測試參數(shù)生成、測試工程重組、測試執(zhí)行驅(qū)動、測試報告處理等從輸入物處理、測試執(zhí)行到報告處理的全流程自動化處理方案。方案的核心如圖1和圖2所示。圖1: 網(wǎng)絡(luò)通信測試集成方案組成

圖2: 診斷測試集成方案組成

主要包括以下幾個功能模塊：

信號矩陣生成數(shù)據(jù)庫文件：將通信信號矩陣，自動轉(zhuǎn)換為數(shù)據(jù)庫文件DBC、LDF、FIBEX等，并用于后續(xù)的測試參數(shù)生成。

數(shù)據(jù)庫解析及預(yù)處理：自動解析數(shù)據(jù)庫文件，解決不同格式（如DBC和ARXML）帶來的差異，減少人工干預(yù)的復(fù)雜性。

測試參數(shù)生成：根據(jù)數(shù)據(jù)庫文件、路由表及通用參數(shù)表，生成所需的測試參數(shù)文件，統(tǒng)一輸入格式，確保不同車型間的參數(shù)復(fù)用性。

測試工程重組及編譯：系統(tǒng)根據(jù)生成的測試參數(shù)，自動重組CANoe的測試工程并完成工程編譯，減少手動配置的時間。

自動驅(qū)動CANoe：通過自動化腳本調(diào)用CANoe進行測試執(zhí)行，省去繁瑣的手動操作，提升測試效率。

測試信息GUI輸入：提供一個簡單的GUI界面，供測試人員輸入控制器信息、測試工程目錄等，簡化了測試流程。

測試報告生成與處理：在測試執(zhí)行完成后，自動生成詳細的測試報告，并對報告進行標準化處理，便于項目后續(xù)分析和管理。

方案執(zhí)行步驟示例說明（說明中以診斷調(diào)查表作為輸入物）：

腳本開發(fā)時采用參數(shù)化，將診斷相關(guān)的參數(shù)統(tǒng)一存放在Parameters.cin中，便于后續(xù)跨平臺或輸入物變更復(fù)用工程

圖3: Parameters.cin示例圖

測試用例開發(fā)時使用Parameters.cin中的變量

使用PAVELINK.SOA-Converter工具導(dǎo)入診斷調(diào)查表，工具自動轉(zhuǎn)換為ODX，配置相關(guān)信息后自動解析并生成測試使用的Parameters.cin

圖4: 自動生成參數(shù)的配置界面

圖5: 解析ODX/PDX自動生成參數(shù)的操作界面

使用生成的Parameters.cin替換工程中的文件

啟動測試，自動驅(qū)動CANoe執(zhí)行后續(xù)測試過程

監(jiān)控測試過程，測試完成后自動讀取CANoe生成的XML報告，并根據(jù)配置的Excel模板進行解析和處理，生成最終測試報告

方案優(yōu)勢
提高復(fù)用度：該方案通過統(tǒng)一信號和數(shù)據(jù)庫處理流程，降低不同車型和控制器間的腳本差異，提高腳本復(fù)用度。
減少人工步驟：統(tǒng)一的配置界面，只需要在界面中配置相關(guān)的輸入物路徑和必要的參數(shù)，一鍵執(zhí)行測試，中間過程無需手工干預(yù)。
增強兼容性：無論是DBC或ARXML、CDD或ODX亦或是矩陣表，該方案都能夠通過統(tǒng)一的預(yù)處理和解析模塊，確保腳本的兼容性。
此方案將有效提升汽車電子網(wǎng)絡(luò)及診斷測試的自動化水平，解決多車型、多控制器的測試腳本復(fù)用難題。北匯信息專注于汽車電子測試領(lǐng)域，提供全域全鏈的汽車電子測試解決方案，不斷升級自動化測試系統(tǒng)，持續(xù)提升測試效率。如有測試系統(tǒng)或測試服務(wù)的需求，歡迎垂詢！