1 引言

過去十年，汽車電子行業的狀況發生了翻天覆地的變化。起初，在汽車上僅使用了幾個ECU，但是現在某些豪華車安裝的ECU數量超過了60個。增加的電子系統提高了安全性、舒適性并節約了能源。今天，更多的創新依賴于電子技術，并且很多功能的實現日益依賴于軟件。

復雜度的增長使得全面而高效的測試變得比以往任何時候都更加重要。大量電子元件的廣泛使用導致潛在錯誤源的數量急劇增多。測試可以極早發現并改正錯誤、盡可能降低成本，在ECU開發的所有階段它都是不可或缺的。只有將部件集成起來并運行于真實環境和實時條件下時，一些系統缺陷才會暴露出來。這讓測試成為了一門跨部門和跨廠商的學科。

早期發生的大量電子故障說明在不考慮上述事實、忽視系統測試的情況下會發生什么問題。在開發過程中問題發現的越晚，那么對成本增長產生的影響就越嚴重。極端情況下由于修正錯誤而引起的產品召回更加清楚地說明了這一點。雖然汽車工業的成員吸取了這些教訓，現在對測試極為重視，然而可以通過利用現有的資源進一步提高效率。雖然測試成本占用了相當的項目預算，但是保證了ECU的正確功能。因此，使用明晰的概念（比如使用現代方法和工具代替不恰當的自動測試步驟）達到最高的測試質量和測試深度是非常重要的。

2 分析、仿真和測試工具

ECU網絡是汽車電子的中樞。在這里，殘余總線仿真方法為進行ECU測試建立了重要基礎。如果沒有對ECU環境的初步模擬，那么大多數ECU都不能有意義地運行。比如，很多ECU只有在提供網絡管理功能的條件下才能正常運轉。

來自Vector Informatik公司的CANoe是一個被廣泛使用的用于分析、仿真和測試分布式、嵌入式系統的工具（圖1）。它被廣泛應用于殘余總線仿真并且支持所有重要的總線系統——特別是CAN、LIN、MOST和FlexRay——Vector Informatik公司也提供適用于這些總線系統的PC接口。現有的商業接口卡可用于從CANoe訪問ECU的I/O線路。此外，Vector宣布將發布一種帶有特定測試功能（比如切換附加負載到ECU終端和將其直接短路）的I/O硬件產品。

不同的分析功能、仿真組件和測試序列依賴于以數據庫形式集成在工具中的模型。它們可能是用于CAN的DBC格式的通信矩陣、用于FlexRay的FIBEX文件、用于MOST的XML功能目錄或用于LIN的LDF文件。同樣地，可使用CDD和ODX描述文件來描述ECU的診斷功能。測試描述文件除了包含系統的基本信息外，還包含了信號、報文和診斷服務等的符號化名稱。這簡化了測試人員和測試開發者的工作，并且在測試和通信描述之間創建了一個抽象層。

任何運行Windows操作系統的簡單PC工作站都可運行CANoe。使用實時配置系統可以建立具備高實時性能的、更為強大的測試站。實時配置系統由兩部分組成（圖2）：一臺運行實時操作系統（Windows CE）的專用電腦，用于執行殘余總線仿真和實際的測試；另一臺獨立的PC機，用作圖形用戶界面和進行評估。在該設置中，系統也可用作進行部件HIL測試的測試執行環境。

［圖2：雙機運行的CANoe Real-Time提供了更高的實時性］

3 測試與開發的集成

如今的開發模型在多個開發階段都要求進行測試（圖3）。通常，個體測試是獨立的、分離的活動，是由專門的人使用專門的工具、語言和方法在正確裝備的專用工作站上完成的。這里，創建測試通常是一項獨立的工作，與其它開發活動是分開的。

［圖3：測試在所有開發階段都是不可或缺的］

這種分段式的工作方法產生于將開發過程中眾多不同的任務分配給專門的工作組。但是，如果對任務分割的要求太嚴格，那么存在于不同開發和測試任務間的眾多關聯點將很有可能不能被優化利用。比如，只有很好地協調部件測試和系統測試才能避免開發大量內容相同的冗余測試用例。當使用兼容工具時，已經開發出來的測試用例可以作為其它不同領域的開發基礎。避免冗余開發釋放了占用的資源，比如可以將其投入到現有測試用例及其高級開發的確認工作中。全面的測試管理為協作提供了堅實的基礎，共用相同的測試用例優化了測試的廣度和深度。協調也有助于發現和填補測試缺口。

除了連接不同的測試階段，開發和測試活動也必須相互聯系并互相適應。應當將測試理解為開發的組成部分，需要使用恰當的方法和工具對其進行廣泛的支持。這必須從程序上和組織上得到保證。這里，重要的是測試與開發一起進行，而不是只在要求的正式確認階段進行。理想的情況是，可以直接在ECU開發者的工作地點利用現有的資源直接進行測試。

為此，CANoe提供了一個用來執行測試的運行時環境，并可以與殘余總線仿真和分析功能并行使用 。該流程非常容易建立，尤其是在開發者已經使用CANoe進行殘余總線仿真和總線通信分析的情況下。

CANoe的測試組件可以手動、半自動和完全自動化的完成測試。開發者可以從簡單測試入手，然后對它們進行擴展和完善。通常，復雜測試的創建過程是確認部門的任務，他們要在開發者的測試上建立他們的測試。

這種測試的重要基礎是殘余總線仿真。在理想情況下，這種仿真不是手工建立的，而是從系統的描述數據庫中自動生成和參數化的。實際工作由所謂的建模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是運行在有關總線通信的現實環境下的。此外，當修改了系統通信矩陣時，通常可以繼續使用保持不變的測試用例。對相同的應用程序，抽象使得相似項目中的測試用例得到重用。

在ECU測試中，重要的并不僅僅是信號接口。只有在對ECU進行較深層訪問時，對許多ECU功能的測試才會有意義。這樣的訪問是由診斷和標定接口提供的，它們通過ECU的現有總線接口接入。使用簡單的消息序列對這些接口進行訪問是沒有意義的，因為在通信進程下面存在著規定的協議。使用合適的診斷和標定抽象 會更加便捷和可靠。

在CANoe中，由來自CANdela工具的描述文件或者ODX描述文件負責診斷訪問層的參數化。如果沒有對ECU實際診斷能力的描述文件，那么可以使用CANoe提供的針對KWP2000和UDS的一般描述。ECU專用的一般描述文件或診斷描述文件都為方便地訪問那里定義的診斷服務提供了便利。有可能獲得與前文所述的信號抽象一樣的抽象和優點。

通過CANoe中的測試腳本就可以使用測量和標定協議CCP和XCP訪問ECU的內部變量。測量和標定工具CANape處理這些協議和需要的ECU描述文件（A2L）。 CANoe通過COM接口控制CANape。這樣就達到了與前面所描述的信號和診斷抽象相同的目標。

6 高效的測試生成

對測試用例的精密研究顯示：很多測試用例可以僅從幾個循環模式中生成。在網關ECU中這一點更為明顯：大多數測試用例用于檢查信號和報文的路由。最終，使用大量測試用例的唯一原因是存在大量可能的輸入和輸出數據。但是同樣類型的模式也存在于其他類型的ECU中。抽象地說，這意味著許多功能是如此進行測試的：首先使用合適的激勵使ECU進入一個特殊狀態，然后檢查進入的狀態。這種測試用例的循環模式是：設置信號（激勵），等待最大容許響應時間，然后檢查新ECU狀態下的信號。根據使用測試模式的經驗，用戶可能識別幾個附加的運行時模式，并從中生成許多測試用例。

這些模式表示有進一步優化測試用例生成的機會。CANoe除了提供典型的測試用例編程外，還為用戶提供了基于測試模式定義測試用例的方式。因為測試步驟是已知的而且永久集成在了提供的模式中，所以就沒有必要再對模式內容進行編程了（圖6）。測試用例的生成被簡化為定義目標行為，包括任何需要的補充數據，比如允許的建立時間。

很明顯，提供的測試模式位于前文所述的信號抽象之上，借助關聯的數據庫允許對信號、報文等的符號化訪問。也可能使用診斷服務或I/O信號。簡而言之：整個CANoe的測試基層結構可與測試模式共用。如果有的需求超出了這些能力，仍然可以選擇測試用例編程。

［圖6：使用模式抽象了測試用例的實際執行從而簡化了測試開發］

測試用例的自動生成是在有合適信息源的情況下有效創建測試的另一種方法。生成的測試內容必然受限于描述水平和來源的深度。然而，生成提供了有價值的支持，主要是當通過測試覆蓋正式定義的ECU基本特性時。生成測試需要相當低的工作量，這導致能更快地進行測試從而可能更早地發現不良的動向。

［圖7： 使用生成器可以從完全不同的來源創建測試］

Vector的工具鏈利用了這種測試生成器方法。諸如DBC數據庫或CANdela定義等描述文件被用作生成器的來源（圖7）。生成器使用這些文件生成測試用例，然后由CANoe執行。因為測試腳本可能使用整個工具的基層結構，所以測試生成器通常都設計的非常簡單。比如，只需少量的工作，生成器就可以從用戶定義的網關描述（例如數據庫形式或Excel電子表格）中創建恰當的測試用例。借助前面講到的測試模式，從客戶的特定數據到測試模式格式只需要簡單的轉換。用戶可直接創建這樣的生成器。Vector以項目服務的方式提供進一步的支持。

7 總結

汽車OEM和供應商應對增長的ECU測試需求的唯一途徑是高效地創建測試和自動化執行測試。本文介紹的測試工具提供了一種被證明的使用信號抽象、集成的診斷、標定和I/O接口、測試模式概念和測試用例生成器來實現測試任務的解決方案。CANoe是一個高性能的測試ECU和網絡的運行時環境。使用該工具在開發者的工作地點、不需要做多少工作就能在早期創建和執行測試。CANoe的開放接口促進了全面的測試策略和受工具支持的測試管理的無縫集成。盡管一些用戶還把它當作一種遠景設想，然而恰當地集成CANoe可能在今天就可以確定成熟度了。Vector正在持續地開發CANoe適應這些領域的使用，并為用戶提供現代而高效的測試平臺支持。

責任編輯：gt