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

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

1.引言

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

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

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

2.分析、仿真和測(cè)試工具

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

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

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

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

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

圖2：雙機(jī)運(yùn)行的CANoe Real-Time提供了更高的實(shí)時(shí)性。

3.測(cè)試與開(kāi)發(fā)的集成

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

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

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

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

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

CANoe的測(cè)試組件可以手動(dòng)、半自動(dòng)和完全自動(dòng)化的完成測(cè)試。開(kāi)發(fā)者可以從簡(jiǎn)單測(cè)試入手，然后對(duì)它們進(jìn)行擴(kuò)展和完善。通常，復(fù)雜測(cè)試的創(chuàng)建過(guò)程是確認(rèn)部門(mén)的任務(wù)，他們要在開(kāi)發(fā)者的測(cè)試上建立他們的測(cè)試。

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

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

4.成熟度評(píng)估和誤差分析

在開(kāi)發(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)化的開(kāi)發(fā)過(guò)程的角度來(lái)說(shuō)，這也是十分必要的。

無(wú)論在何時(shí)何地(測(cè)試實(shí)驗(yàn)室或工作臺(tái)上)，無(wú)需用戶(hù)或測(cè)試用例開(kāi)發(fā)人員進(jìn)行干涉，使用CANoe執(zhí)行測(cè)試時(shí)都會(huì)生成一個(gè)測(cè)試記錄。這樣在進(jìn)行伴有測(cè)試的開(kāi)發(fā)時(shí)就不需要做額外的工作。用于測(cè)試記錄的 XML是一種開(kāi)放格式，以使其它工具使用以對(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è)試用例開(kāi)發(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明確地引用。

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

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

5.信號(hào)抽象和診斷

抽象是處理軟件開(kāi)發(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)。

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

圖5: 信號(hào)一方面提供了消息和I/O線(xiàn)路間的抽象，另一方面提供了測(cè)試定義和仿真模型間的抽象。

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

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

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

6.高效的測(cè)試生成

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

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

圖6：使用模式抽象了測(cè)試用例的實(shí)際執(zhí)行從而簡(jiǎn)化了測(cè)試開(kāi)發(fā)。

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

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

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

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

7.總結(jié)

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