作者 |愛(ài)吃小炒肉
小編 | 不吃豬頭肉

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

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

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

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

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

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

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

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

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

圖2: 診斷測(cè)試集成方案組成

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

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

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

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

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

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

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

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

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

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

圖3: Parameters.cin示例圖

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

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

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

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

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

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

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

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