隨着車輛中ECU複雜度的增加,診斷的測試範圍以及完成診斷功能驗證需要花費的時間和精力也在增加。幸運的是,應用診斷自動化測試工具完成驗證工作所需要花費的時間和精力不再是線性增長。儘管診斷測試的範圍不斷擴大,但創建和執行測試用例的時間和人力投入相對穩定。UDS和診斷描述格式CDD/ODX標準的制定,爲完成高覆蓋度和高質量的自動化測試提供了可能性。此外,診斷應用和刷寫測試也可以實現自動化。

2006年,UDS(ISO 14229)標準的發佈,使得診斷自動化測試跨出了重要的一步:診斷服務的統一,爲更深入地實現跨整車廠的診斷協議測試提供了可能性。與UDS協議對比,KWP2000協議在實現診斷功能過程中允許很大的自由度,需要整車廠基於自己的需求定製化實現其功能,這使得自動化測試的實現變得困難。UDS修訂版於2013年發佈,新版本UDS可以實現更高覆蓋度的自動化協議測試。

除協議規範之外,診斷數據的描述是測試用例自動生成的另一個重要的先決條件。爲了能夠自動生成測試用例,必須“知道”ECU中定義的診斷服務。Vector提供的CANdelaStudio軟件可以基於診斷需求規範定義診斷服務,並導出診斷數據庫(CDD或ODX格式)。與此同時,Vector提供的CANoe.DiVa軟件可以通過導入CDD或ODX文件,自動生成全面的測試用例。

這些測試用例覆蓋了有效和無效的請求,而這些請求則將ECU中的正確處理和錯誤處理用於測試。CANoe可以加載測試用例並自動執行,生成的測試結果會在測試報告中詳細記錄(如圖1)。對於功能複雜的ECU,自動生成的測試用例可能超過10,000個且無需冗餘測試。

圖 1:CANoe.DiVa測試流程示意圖

如果每個ECU都有CDD或ODX格式的診斷數據庫,那麼從診斷需求規範到全面的自動化協議測試只需一小步,僅需很少的準備工作就可以檢測到協議錯誤。

1、AUTOSAR提高診斷協議質量

當AUTOSAR軟件模塊用於診斷時,AUTOSAR基礎軟件可以處理診斷儀的一系列協議非法測試(例如格式不正確)。由於AUTOSAR基礎軟件通常使用診斷數據庫(DEXT)作爲診斷模塊的需求輸入,提高了診斷需求的一致性,因此ECU的診斷響應通常也會符合協議要求。在使用AUTOSAR模塊時,簡單的協議錯誤的比例明顯下降。因此,用於測試評估和故障排除的時間和精力相應的也會減少。儘管如此,協議測試仍然很重要,原因如下:

在DoIP和OTA應用的某些情況下,不需要與診斷儀直接進行物理連接。對於整個車隊中的車輛,協議錯誤可能會對某些服務產生負面影響。在最壞的情況下,協議錯誤可能允許對車輛進行安全攻擊。基於診斷功能,客戶體驗的新用例將持續發展。這些新用例將導致更頻繁和更廣泛的使用診斷功能。由此可以預見,對診斷功能實現的質量要求將會繼續提高。

2、軟件更新驗證

儘管ECU刷寫採用了診斷標準化服務,但刷寫的流程仍然是整車廠特殊定義的,諸如數據傳輸的加密機制(數據識別、Checksum、簽名等),結果是每個整車廠都擁有獨一無二的刷寫流程,這意味着每個整車廠都有一個特定的軟件更新序列。因此,對於不同的整車廠項目,供應商需要使用不同的刷寫序列,還必須爲每個整車廠開發和維護特定的測試環境。在生產和售後服務中,ECU軟件刷寫是不可或缺的。考慮到未來OTA需求,車輛中可靠的軟件刷寫功能比以往任何時候都更加重要,軟件更新的頻率會更加頻繁,類似於我們已經熟悉的手機移動設備(例如修復安全漏洞)。在刷寫過程中應該儘量避免對ECU刷寫失敗而導致ECU不能正常工作的情況。但即使是成熟的智能手機制造商,採取了複雜的保護措施,在對軟件版本進行更新時也會不可避免的出現問題,從而對刷寫測試提出了更高的要求。

Vector提供的vFlash軟件可以應用於不同整車廠的軟件刷寫,目前爲止已經爲超過100個整車廠定製了刷寫模板(基於刷寫規範的刷寫序列)。CANoe.DiVa通過調用vFlash刷寫工程,自動生成刷寫過程的測試用例。除了測試刷寫過程中的時序、相關服務的格式等,還會測試刷寫序列、刷寫異常序列、欠壓、中斷等,實現對Bootloader穩健性的全面性測試。

除此之外,對刷寫過程中相關數據(識別數據或者簽名)的測試需要整車廠提供特定的詳細信息。對於此類測試,Vector已經爲衆多整車廠提供了特定的測試擴展,即CANoe.DiVa Plugin。

3、診斷應用的驗證

診斷應用功能驗證是確保車輛診斷功能實現的唯一辦法。診斷數據庫(CDD或ODX)定義診斷需求,測試工具則從診斷數據庫中提取與應用相關的信息用於測試用例的自動生成。例如,基於對指定數值範圍的描述,自動生成驗證傳輸值合理性的測試用例。爲了實現診斷應用的自動化測試,需要搭建ECU的應用仿真。ECU的應用配置信息可以從如下渠道獲取:

圖 2:硬件在環測試示意圖

CANoe.DiVa還支持通過Excel文件導入/導出診斷參數配置和DTC配置。

交互式的配置選項提高了診斷應用測試的半自動化程度,甚至部分診斷應用測試達到全自動化。但是必須承認的是,診斷應用測試的自動化程度距離診斷協議測試的自動化程度還有一段距離。

4、測試範圍、測試評估和進一步處理

CANoe.DiVa實現的診斷協議驗證的高度自動化保證了測試的高效性。同時,CANoe.DiVa支持用戶測試需求擴展,以CANoe.DiVa Plugin的方式定製化滿足客戶的特殊需求,保證了測試的高覆蓋度。越來越多的整車廠在系統安全導向的診斷應用場景下受益於 CANoe.DiVa 及CANoe.DiVa Plugin的自動化測試驗證,供應商也從驗證安全導向的診斷功能測試中受益匪淺。

當前,全球衆多整車廠都採用CANoe.DiVa實現診斷測試,並在測試過程中節省了大量時間(如圖3所示)。CANoe.DiVa的測試後處理能力包括:

圖3:手動測試與自動測試的對比

結論/展望

ECU的診斷範圍和診斷質量需求在持續增加。慶幸的是,基於CANoe.DiVa的診斷自動化測試方案顯著減少了診斷驗證所用的時間和人力投入,同時極大地增加了測試的廣度和深度。

隨着車聯網應用的不斷增加,車輛網絡安全需求迅速增加,“安全性測試”已經成爲焦點話題。OTA 擴展了訪問車輛的途徑,爲車輛診斷開闢了新的應用領域,但同時也可能帶來新的安全問題。基於CANoe.DiVa的有效測試可以幫助用戶消除一些潛在的隱患。

查看原文 >>
相關文章