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

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

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

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

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

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

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

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

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

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

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

主要包括以下幾個(gè)功能模塊：

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

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

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

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

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

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

測試報(bào)告生成與處理：在測試執(zhí)行完成后，自動(dòng)生成詳細(xì)的測試報(bào)告，并對(duì)報(bào)告進(jìn)行標(biāo)準(zhǔn)化處理，便于項(xiàng)目后續(xù)分析和管理。

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

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

圖3: Parameters.cin示例圖

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

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

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

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

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

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

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

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