一種貫穿HIL仿真到診斷的汽車電子測(cè)試環(huán)境
加入技術(shù)交流群
圖3：測(cè)試在所有開發(fā)階段都是不可或缺的
除了連接不同的測(cè)試階段，開發(fā)和測(cè)試活動(dòng)也必須相互聯(lián)系且互相適應(yīng)。應(yīng)當(dāng)將測(cè)試?yán)斫鉃殚_發(fā)的一個(gè)組成部分，它需要使用恰當(dāng)?shù)姆椒ê凸ぞ邅?lái)支持。在程序和結(jié)構(gòu)上得到保證之外，必須保證這一點(diǎn)。在此，重要的是測(cè)試與開發(fā)一起進(jìn)行，而不是只在要求的正式確認(rèn)階段進(jìn)行。理想的情況是，可以直接在ECU開發(fā)者的工作地點(diǎn)利用現(xiàn)有的資源直接進(jìn)行測(cè)試。
為此，CANoe提供了一個(gè)用來(lái)執(zhí)行測(cè)試的運(yùn)行時(shí)環(huán)境，并可以與殘余總線仿真和分析功能并行使用。該流程非常容易建立，尤其是在開發(fā)者已經(jīng)使用CANoe進(jìn)行殘余總線仿真和總線通信分析的情況下。
CANoe的測(cè)試組件可以手動(dòng)、半自動(dòng)和完全自動(dòng)化的完成測(cè)試。開發(fā)者可以從簡(jiǎn)單測(cè)試入手，然后對(duì)它們進(jìn)行擴(kuò)展和完善。通常，復(fù)雜測(cè)試的創(chuàng)建過(guò)程是確認(rèn)部門的任務(wù)，他們要在開發(fā)者的測(cè)試上建立他們的測(cè)試。
這種測(cè)試的一個(gè)重要基礎(chǔ)是殘余總線仿真。理想情況下這種仿真并非由手工建立，而是從系統(tǒng)的描述數(shù)據(jù)庫(kù)中自動(dòng)生成和參數(shù)化的。實(shí)際工作由所謂的建模DLL(比如交互層、網(wǎng)絡(luò)管理等)完成，它們是隨工具一起提供的或者是由Vector作為OEM專用建模包提供的。殘余總線仿真為模擬節(jié)點(diǎn)提供的信號(hào)可以直接從測(cè)試腳本中獲取，也可以手工方式激勵(lì)或添加。
與測(cè)試階段中系統(tǒng)化的計(jì)劃、執(zhí)行和歸檔活動(dòng)相比，伴隨開發(fā)的測(cè)試通常省略了正式的執(zhí)行和歸檔。然而，這些測(cè)試對(duì)提高整體質(zhì)量做出了實(shí)質(zhì)性貢獻(xiàn)，因?yàn)樗麄冑x予了開發(fā)者為后續(xù)的測(cè)試階段提供更穩(wěn)定的產(chǎn)品的能力。
成熟度評(píng)估和誤差分析
在開發(fā)過(guò)程中，為了評(píng)估ECU的成熟度，需要對(duì)所有執(zhí)行過(guò)的測(cè)試進(jìn)行全面的評(píng)價(jià)。除了要考慮單個(gè)測(cè)試結(jié)果在可靠性和相關(guān)性方面的質(zhì)量，更重要的是采用適當(dāng)?shù)臏y(cè)試來(lái)全面覆蓋所要求的特性。因此非正式的測(cè)試結(jié)果對(duì)成熟度分析也是有幫助的。前提條件是(除記錄測(cè)試過(guò)程外)使用兼容的配置管理。從完成面向質(zhì)量的、結(jié)構(gòu)化的開發(fā)過(guò)程的角度來(lái)說(shuō)，這也是十分必要的。
無(wú)論在何時(shí)何地(測(cè)試實(shí)驗(yàn)室或工作臺(tái)上)，無(wú)需用戶或測(cè)試用例開發(fā)人員進(jìn)行干涉，使用CANoe執(zhí)行測(cè)試時(shí)都會(huì)生成一個(gè)測(cè)試記錄。這樣在進(jìn)行伴有測(cè)試的開發(fā)時(shí)就不需要做額外的工作。用于測(cè)試記錄的XML是一種開放格式，以使其它工具使用以對(duì)結(jié)果進(jìn)行更深入的處理。例如在進(jìn)行成熟度分析時(shí)可以使用一個(gè)測(cè)試管理系統(tǒng)來(lái)評(píng)價(jià)測(cè)試記錄。
這項(xiàng)工作的本質(zhì)是測(cè)試結(jié)果到測(cè)試用例、測(cè)試用例到需求的映射。使用唯一的標(biāo)識(shí)符(比如一個(gè)需求ID)可以很容易地實(shí)現(xiàn)這一點(diǎn)，測(cè)試用例開發(fā)者在單個(gè)測(cè)試用例中會(huì)引用它。CANoe會(huì)自動(dòng)將該標(biāo)識(shí)符復(fù)制到測(cè)試記錄中，這樣所有測(cè)試用例、測(cè)試結(jié)果和需求就可以明確地關(guān)聯(lián)起來(lái)(圖4)。
圖4：測(cè)試用例和測(cè)試結(jié)果由ID明確地引用
基于上述原因，測(cè)試臺(tái)上的測(cè)試步驟以及每一個(gè)與DUT間的交互動(dòng)作都將被強(qiáng)制記錄，特別是總線通信。在分析階段，CANoe允許重放和分析任何需要的記錄(日志)。從而有可能在開發(fā)場(chǎng)所使用與測(cè)試臺(tái)上相同的測(cè)試系統(tǒng)以從中受益，這樣開發(fā)者就可以獨(dú)立地再現(xiàn)生成錯(cuò)誤的測(cè)試用例。在很多情況下，甚至是有必要進(jìn)行簡(jiǎn)化時(shí)(比如為了避免選擇不存在的測(cè)量硬件)都可以執(zhí)行相關(guān)測(cè)試用例。
信號(hào)抽象和診斷
抽象是處理軟件開發(fā)和系統(tǒng)設(shè)計(jì)中復(fù)雜度問(wèn)題時(shí)普遍采用的重要方法。它也可用來(lái)處理測(cè)試。ECU中不斷增多的功能不僅增加了系統(tǒng)的復(fù)雜度，還需要更廣泛和復(fù)雜的測(cè)試。選擇正確的抽象層組成測(cè)試不僅會(huì)影響創(chuàng)建測(cè)試用例所需要的工作量、進(jìn)而影響成本，而且會(huì)影響測(cè)試用例的質(zhì)量。就像所有其它軟件組件一樣，測(cè)試用例本身也可能會(huì)存在錯(cuò)誤，應(yīng)該在使用之前進(jìn)行檢查。此外，還需要必要的維護(hù)，比如適應(yīng)需求的改變和修訂測(cè)試用例。
信號(hào)層抽象是測(cè)試ECU功能的常用方法，這也是為什么在ECU中實(shí)際的應(yīng)用程序通常會(huì)基于信號(hào)抽象的原因(圖5)。例如，在一個(gè)CAN系統(tǒng)中，ECU交互層提供了信號(hào)抽象。這正是CANoe使用交互層的方式；利用網(wǎng)絡(luò)描述中的信息，它將自身參數(shù)化。網(wǎng)絡(luò)描述同樣也可用于創(chuàng)建ECU軟件。這保證了ECU和測(cè)試環(huán)境使用相同的抽象層從而在兩者間形成最佳的協(xié)調(diào)。
評(píng)論