新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設計應用 > 一種貫穿HIL仿真到診斷的汽車電子測試環(huán)境

一種貫穿HIL仿真到診斷的汽車電子測試環(huán)境

作者: 時間:2013-10-11 來源:網(wǎng)絡 收藏

newmaker.com
圖3:測試在所有開發(fā)階段都是不可或缺的

這種分段式的工作方法源于將開發(fā)過程中眾多不同的任務分配給專門的工作組。但是,如果對任務分割的要求太嚴格,那么不同開發(fā)和測試任務間的眾多關(guān)聯(lián)點將很有可能不能被優(yōu)化利用。例如只有很好地協(xié)調(diào)部件測試和系統(tǒng)測試才能避免開發(fā)過多內(nèi)容相同的冗余測試用例。當使用兼容工具時,已經(jīng)開發(fā)出來的測試用例可以作為其他不同領(lǐng)域的開發(fā)基礎(chǔ)。避免冗余開發(fā)的做法釋放了占用的資源,舉例來說,可以將其投入到現(xiàn)有測試用例及其高級開發(fā)的確認工作中。全面的測試管理為協(xié)作提供了堅實的基礎(chǔ),共用相同的測試用例優(yōu)化了測試的廣度和深度。協(xié)調(diào)也有助于發(fā)現(xiàn)和填補測試缺口。

除了連接不同的測試階段,開發(fā)和測試活動也必須相互聯(lián)系且互相適應。應當將測試理解為開發(fā)的一個組成部分,它需要使用恰當?shù)姆椒ê凸ぞ邅碇С?。在程序和結(jié)構(gòu)上得到保證之外,必須保證這一點。在此,重要的是測試與開發(fā)一起進行,而不是只在要求的正式確認階段進行。理想的情況是,可以直接在ECU開發(fā)者的工作地點利用現(xiàn)有的資源直接進行測試。

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

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

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

與測試階段中系統(tǒng)化的計劃、執(zhí)行和歸檔活動相比,伴隨開發(fā)的測試通常省略了正式的執(zhí)行和歸檔。然而,這些測試對提高整體質(zhì)量做出了實質(zhì)性貢獻,因為他們賦予了開發(fā)者為后續(xù)的測試階段提供更穩(wěn)定的產(chǎn)品的能力。

成熟度評估和誤差分析

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

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

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

newmaker.com
圖4:測試用例和測試結(jié)果由ID明確地引用

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

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

信號抽象和

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

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


關(guān)鍵詞: HIL仿真 診斷 汽車電子

評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉