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

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

　　6 高效的測試生成

　　對測試用例的精密研究顯示：很多測試用例可以僅從幾個循環(huán)模式中生成。在網(wǎng)關ECU中這一點更為明顯：大多數(shù)測試用例用于檢查信號和報文的路由。最終，使用大量測試用例的唯一原因是存在大量可能的輸入和輸出數(shù)據(jù)。但是同樣類型的模式也存在于其他類型的ECU中。抽象地說，這意味著許多功能是如此進行測試的：首先使用合適的激勵使ECU進入一個特殊狀態(tài)，然后檢查進入的

狀態(tài)。這種測試用例的循環(huán)模式是：設置信號（激勵），等待最大容許響應時間，然后檢查新ECU狀態(tài)下的信號。根據(jù)使用測試模式的經(jīng)驗，用戶可能識別幾個附加的運行時模式，并從中生成許多測試用例。

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

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

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

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

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

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

　　7 總結

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