高效的汽車電子測試――種貫穿HIL仿真到診斷的測試

這種測試的一個重要基礎是殘余總線仿真。理想情況下這種仿真并非由手工建立，而是從系統的描述數據庫中自動生成和參數化的。實際工作由所謂的建模DLL(比如交互層、網絡管理等)完成，它們是隨工具一起提供的或者是由Vector作為OEM專用建模包提供的。殘余總線仿真為模擬節點提供的信號可以直接從測試腳本中獲取，也可以手工方式激勵或添加。

與測試階段中系統化的計劃、執行和歸檔活動相比，伴隨開發的測試通常省略了正式的執行和歸檔。然而，這些測試對提高整體質量做出了實質性貢獻，因為他們賦予了開發者為后續的測試階段提供更穩定的產品的能力。

4.成熟度評估和誤差分析

在開發過程中，為了評估ECU的成熟度，需要對所有執行過的測試進行全面的評價。除了要考慮單個測試結果在可靠性和相關性方面的質量，更重要的是采用適當的測試來全面覆蓋所要求的特性。因此，非正式的測試結果對成熟度分析也是有幫助的。前提條件是(除記錄測試過程外)使用兼容的配置管理。從完成面向質量的、結構化的開發過程的角度來說，這也是十分必要的。

無論在何時何地(測試實驗室或工作臺上)，無需用戶或測試用例開發人員進行干涉，使用CANoe執行測試時都會生成一個測試記錄。這樣在進行伴有測試的開發時就不需要做額外的工作。用于測試記錄的 XML是一種開放格式，以使其它工具使用以對結果進行更深入的處理。例如在進行成熟度分析時可以使用一個測試管理系統來評價測試記錄。

這項工作的本質是測試結果到測試用例、測試用例到需求的映射。使用唯一的標識符(比如一個需求ID)可以很容易地實現這一點，測試用例開發者在單個測試用例中會引用它。CANoe會自動將該標識符復制到測試記錄中，這樣所有測試用例、測試結果和需求就可以明確地關聯起來(圖4)。

圖4: 測試用例和測試結果由ID明確地引用。

分析實際發生錯誤的原因至少與記錄和評估測試結果同樣重要。大多數測試工具都不會提供這樣的功能或者僅提供一些并不完善的功能。一個重要原因就是錯誤分析經常被當作開發者的一項完全獨立的任務。首先，他們面臨理解測試中檢測到的錯誤并跟蹤其原因的問題。尤其是當測試實驗室報告錯誤時，開發者甚至時常無法使用測試中用到的系統。

基于上述原因，測試臺上的測試步驟以及每一個與DUT間的交互動作都將被強制記錄，特別是總線通信。在分析階段，CANoe允許重放和分析任何需要的記錄（日志）。從而有可能在開發場所使用與測試臺上相同的測試系統以從中受益，這樣開發者就可以獨立地再現生成錯誤的測試用例。在很多情況下，甚至是有必要進行簡化時（比如為了避免選擇不存在的測量硬件）都可以執行相關測試用例。

5.信號抽象和診斷

抽象是處理軟件開發和系統設計中復雜度問題時普遍采用的重要方法。它也可用來處理測試。ECU中不斷增多的功能不僅增加了系統的復雜度，還需要更廣泛和復雜的測試。選擇正確的抽象層組成測試不僅會影響創建測試用例所需要的工作量、進而影響成本，而且會影響測試用例的質量。就像所有其它軟件組件一樣，測試用例本身也可能會存在錯誤，應該在使用之前進行檢查。此外，還需要必要的維護，比如適應需求的改變和修訂測試用例。

信號層抽象是測試ECU功能的常用方法，這也是為什么在ECU中實際的應用程序通常會基于信號抽象的原因(圖5)。例如，在一個CAN系統中，ECU交互層提供了信號抽象。這正是CANoe使用交互層的方式；利用網絡描述中的信息，它將自身參數化。網絡描述同樣也可用于創建ECU軟件。這保證了ECU和測試環境使用相同的抽象層從而在兩者間形成最佳的協調。

信號抽象也表示了――至少在協議層――殘余總線仿真。比如，它保證周期性信號的確是按周期發送的。在測試中，ECU是假定置于總線通信的真實環境下的。此外，當修改了系統通信矩陣時，通常可以繼續使用保持不變的測試用例。對相同的應用程序，抽象使得相似項目中的測試用例得到復用。

圖5: 信號一方面提供了消息和I/O線路間的抽象，另一方面提供了測試定義和仿真模型間的抽象。