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

 在當今的汽車電子開發(fā)過程中，測試扮演著十分重要的角色。然而，在使用正確的策略、思想和工具以使將來實現(xiàn)更為高效和自動化執(zhí)行測試方面，業(yè)界仍然有許多潛力可挖。本文分析了測試技術(shù)的現(xiàn)狀，闡明了在實踐中所發(fā)生的交互作用疑難問題，并且證明了今天已經(jīng)可以使用現(xiàn)成的工具以一種優(yōu)雅而高效的方式解決與測試相關(guān)的具體項目任務(wù)。   

    1.引言

    過去十年，汽車電子行業(yè)的狀況發(fā)生了翻天覆地的變化。起初，在汽車上僅使用了幾個ECU，但是現(xiàn)在某些豪華車安裝的ECU數(shù)量已經(jīng)超過[JW1]了60個。增加的電子系統(tǒng)提高了安全性、舒適性并節(jié)約了能源。今天，更多的創(chuàng)新依賴于電子技術(shù)，而很多功能的實現(xiàn)也日益依賴于軟件。

    復(fù)雜度的提高使得全面而高效的測試變得比以往任何時候都更加重要。大量電子元件的廣泛使用導(dǎo)致潛在錯誤源的數(shù)量急劇增多。由于測試可以盡早發(fā)現(xiàn)并改正錯誤和降低成本，因此無論在ECU開發(fā)的哪個所有階段它都是不可或缺的。此外，只有將部件集成起來并運行于真實環(huán)境和實時條件下時，一些系統(tǒng)缺陷才會暴露出來。這讓測試成為了一門跨部門和跨廠商的學(xué)科。

    早期發(fā)生的大量電子故障說明，在不考慮上述事實且忽視系統(tǒng)測試的情況下會發(fā)生什么問題。問題發(fā)現(xiàn)的越晚，對抬高成本產(chǎn)生的影響就越嚴重。而極端情況下由于修正錯誤而引起的產(chǎn)品召回更加清楚地說明了這一點。雖然汽車工業(yè)的成員吸取了這些教訓(xùn)，對測試極為重視，然而我們?nèi)匀豢梢酝ㄟ^現(xiàn)有的資源來進一步提高測試效率。此外，盡管測試成本占用了項目預(yù)算大部分資源，但它保證了ECU的正確功能。因此，使用明晰的概念(比如使用現(xiàn)代方法和工具代替不全面的自動測試步驟)來最大化的提高測試質(zhì)量和測試深度是非常重要的。

    2.分析、仿真和測試工具

    ECU網(wǎng)絡(luò)是汽車電子的中樞。而殘余總線仿真方法為進行ECU測試建立了重要基礎(chǔ)。如果沒有對ECU環(huán)境的初步模擬，那么大多數(shù)ECU都不能有效地地運行。比如，很多ECU只有在提供網(wǎng)絡(luò)管理功能的條件下才能正常運轉(zhuǎn)。

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

圖1：CANoe包含針對網(wǎng)絡(luò)系統(tǒng)的分析、仿真和測試功能。

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

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

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

    3.測試與開發(fā)的集成

    如今的開發(fā)模型在各個開發(fā)階段都要求進行測試(圖3)。通常，個體測試是獨立的、分離的活動，是由專門的人使用專門的工具、語言和方法在有適當配置的專用工作站上完成的。這里，創(chuàng)建測試通常是一項獨立的工作，與其他開發(fā)活動是分開的。

圖3：測試在所有開發(fā)階段都是不可或缺的。

    這種分段式的工作方法源于將開發(fā)過程中眾多不同的任務(wù)分配給專門的工作組。但是，如果對任務(wù)分割的要求太嚴格，那么不同開發(fā)和測試任務(wù)間的眾多關(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)系且互相適應(yīng)。應(yīng)當將測試理解為開發(fā)的一個組成部分，它需要使用恰當?shù)姆椒ê凸ぞ邅碇С?。在程序和結(jié)構(gòu)上得到保證之外，必須保證這一點。在此，重要的是測試與開發(fā)一起進行，而不是只在要求的正式確認階段進行。理想的情況是，可以直接在ECU開發(fā)者的工作地點利用現(xiàn)有的資源直接進行測試。

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

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

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

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

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

    在開發(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會自動將該標識符復(fù)制到測試記錄中，這樣所有測試用例、測試結(jié)果和需求就可以明確地關(guān)聯(lián)起來(圖4)。

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

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

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

    5.信號抽象和診斷

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

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

    信號抽象也表示了——至少在協(xié)議層——殘余總線仿真。比如，它保證周期性信號的確是按周期發(fā)送的。在測試中，ECU是假定置于總線通信的真實環(huán)境下的。此外，當修改了系統(tǒng)通信矩陣時，通?？梢岳^續(xù)使用保持不變的測試用例。對相同的應(yīng)用程序，抽象使得相似項目中的測試用例得到復(fù)用。

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

    在ECU測試中，重要的并不僅僅是信號接口。只有在對ECU進行較深層訪問時，對許多ECU功能的測試才會有意義。這樣的訪問是由診斷和標定接口提供的，它們通過ECU的現(xiàn)有總線接口接入。由于在通信進程下已有既定的協(xié)議，使用簡單的消息序列對這些接口進行訪問是沒有意義的。而使用適當?shù)脑\斷和標定抽象才會更加方便與可靠。

    在CANoe中，由來自CANdela工具的描述文件或者ODX描述文件負責(zé)診斷訪問層的參數(shù)化。如果沒有對ECU實際診斷能力的描述，則可使用CANoe提供的針對KWP2000和UDS的一般描述。ECU專用的一般描述文件或診斷描述文件都為方便地訪問那里定義的診斷服務(wù)提供了便利，開發(fā)人員也許會獲得與上文信號抽象中同樣的抽象數(shù)據(jù)和優(yōu)點。

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

    6.高效的測試生成

    對測試用例的深入研究表明：很多測試用例可以僅從幾個循環(huán)模式中生成。這種情況在網(wǎng)關(guān)ECU中尤為明顯：大多數(shù)測試用例用于檢查信號和報文的路由。也就是說，使用大量測試用例的唯一原因是存在著大量可能的輸入和輸出數(shù)據(jù)。但是同樣類型的模式也存在于其他類型的ECU中。這意味著許多功能的測試都是如此進行的：首先使用合適的激勵使ECU進入一個特殊狀態(tài)，然后檢查進入的狀態(tài)。這種測試用例的循環(huán)模式是：設(shè)置信號（激勵），等待最大容許響應(yīng)時間，然后檢查新ECU狀態(tài)下的信號。根據(jù)使用測試模式的經(jīng)驗，用戶可能識別幾個附加的運行時模式，并從中生成許多測試用例。

    上述模式表明，測試用例的生成還有被進一步優(yōu)化的機會。除了提供典型的測試用例編程外，CANoe還為用戶提供了基于測試模式來定義測試用例的方式。因為測試步驟是已知的而且已被集成在了提供的模式中，所以就沒有必要再對模式內(nèi)容進行編程了(圖6)。這樣一來測試用例的生成就被簡化為定義目標行為，包括任何需要的補充數(shù)據(jù)，比如允許的建立時間。

圖6：使用模式抽象了測試用例的實際執(zhí)行從而簡化了測試開發(fā)。

    很明顯，提供的測試模式位于前文所述的信號抽象之上，借助關(guān)聯(lián)的數(shù)據(jù)庫賦予了對信號、報文等符號化訪問的能力，并且將使用診斷服務(wù)或I/O信號也變成了可能。簡言之：整個CANoe的測試基層結(jié)構(gòu)可與測試模式共用。如果真的有需求超出了這些能力，還可以選擇對測試用例進行編程。

    測試用例的自動生成是在有合適信息源的情況下有效創(chuàng)建測試的另一種方法。雖然生成的測試內(nèi)容必然受限于描述水平和來源的深度。然而當通過測試覆蓋正式定義的ECU基本特性時，這種測試卻提供了相當有價值的支持。生成測試需要很少量的工作，這就使得測試能更快的進行，從而更早地發(fā)現(xiàn)問題。

圖7: 使用生成器可以從完全不同的來源創(chuàng)建測試。

    Vector的工具鏈利用了這種測試生成器的方法。諸如DBC數(shù)據(jù)庫或CANdela定義等描述文件是生成器的資源(圖7)。在使用這些文件生成測試用例之后，CANoe就可以立即執(zhí)行了。因為測試腳本可能使用整個工具的基層結(jié)構(gòu)，所以測試生成器通常都設(shè)計的非常簡單。比如只需少量的工作生成器就可以從用戶定義的網(wǎng)關(guān)描述(例如數(shù)據(jù)庫形式或 Excel電子表格)中創(chuàng)建恰當?shù)臏y試用例。借助前文講到的測試模式，從客戶的特定數(shù)據(jù)到測試模式格式中間只有一步簡單的轉(zhuǎn)換。用戶可直接創(chuàng)建這樣的生成器。Vector以項目服務(wù)的方式提供進一步的支持。

    7.總結(jié)

    汽車OEM和供應(yīng)商應(yīng)對增長的ECU測試需求的唯一途徑是高效地創(chuàng)建測試和自動化執(zhí)行測試。本文介紹的測試工具提供了一種被證明的、使用信號抽象/診斷/標定/I/O接口的集成、測試模式概念和測試用例生成器來實現(xiàn)測試任務(wù)的解決方案。CANoe是一個測試ECU和網(wǎng)絡(luò)的高性能實時運行環(huán)境。測試開發(fā)人員只需在自己的工作臺就能在早期創(chuàng)建和執(zhí)行測試，且僅需做少量工作。CANoe的開放接口促進了全面的測試策略以及工具支持的測試管理的無縫集成。盡管一些用戶還把它當作一種遠景設(shè)想，但只要適當?shù)丶蒀ANoe，也許這種技術(shù)在今天就可以達到成熟水平了。Vector正在持續(xù)地開發(fā)CANoe以適應(yīng)上述領(lǐng)域的應(yīng)用，并為用戶提供現(xiàn)代而高效的測試平臺支持。