遵循V模式的大多數(shù)的開發(fā)任務可歸結于測試和驗證。全面的測試可以幫助開發(fā)人員盡可能早的發(fā)現(xiàn)并排除錯誤。

　　CANopen系統(tǒng)開發(fā)中涉及的任務范圍包括從單個ECU的開發(fā)到整個系統(tǒng)的配置和啟動。一個比較可取的做法是使用經(jīng)過驗證的工具，這樣能充分利用CANopen的靈活性。同時，開發(fā)人員不必關心單個ECU的協(xié)議功能實現(xiàn)。

　　在整個系統(tǒng)開發(fā)過程的每個階段都必須有相應的測試工作。實際上，初始測試不是在第一級客戶的真實系統(tǒng)上完成的，而是使用一個包含有所有組成最終系統(tǒng)的組件的測試臺進行測試。該測試臺同時也包括特殊的測量、測試診斷設備、執(zhí)行器，盡可能使測試系統(tǒng)環(huán)境與真實系統(tǒng)一致。當系統(tǒng)的規(guī)模較大時，構建這樣一個測試臺也許是非常困難的，而且成本很高，通常情況下只能實現(xiàn)一個單獨的測試臺。在大多數(shù)情況下，這將成為測試過程中的一個瓶頸。

　　解決這一問題的出路在于使用一種成熟的，能容易實現(xiàn)整個系統(tǒng)原型的工具。該工具將提供測試功能的理想的解決方案。

原型環(huán)境

　　首先并且首要的，整個系統(tǒng)的原型CAN網(wǎng)絡應該支持測試和驗證。此外，該原型還應該提供早期項目開發(fā)功能。因此，用真實的ECU或仿真ECU表示整個系統(tǒng)中的各個獨立組件這一過程是非常重要的。這樣可以相對簡單的在系統(tǒng)開發(fā)過程中測試真實ECU的功能完整性。因此原型環(huán)境的功能性要求比純仿真要多得多。

                  
　　仿真一個復雜系統(tǒng)是成本很高的，而且工作量很大。合適的工具可以大大簡化這一任務。Vector Informatik 公司的CANoe. CANopen產(chǎn)品能真正支持用戶建立系統(tǒng)原型的通信部分。只需要幾個簡單的配置步驟就可以創(chuàng)建一個原型系統(tǒng)，其通信功能與真實系統(tǒng)完全相同。

　　首先，為CANopen ECU選擇一個EDS(Electronic Data Sheet)描述文件。如果該設備的描述文件不存在，是因為設備開發(fā)過程尚未結束，將使用一個空模板占位。

　　下一步，在總線上交互的應用程序數(shù)據(jù)被關聯(lián)起來。例如，位于5#地址設備的輸入“PressureValve” 與10#地址設備的變量 “GasPressure“相關聯(lián)。用這樣的方法定義原型系統(tǒng)的所有的過程數(shù)據(jù)對象( Process Data Object)連接。CANopen可以自動計算映射關系，并可以在隨后修改。

　　下一步，所有原型系統(tǒng)的配置信息都存放于設備配置文件(DCF – Device Configuration File).中。用戶可以利用這些配置文件來創(chuàng)建一個原型環(huán)境。對于每個真實系統(tǒng)中的ECU都生成一個具有相同通信屬性的CANoe中的副本。

　　原型環(huán)境的通信部分在CANoe工具啟動時生效。通過服務數(shù)據(jù)對象(SDO=Service Data Objects)可以訪問（仿真）ECU的目標目錄；可以對這些目錄作額外的修改。

應用表現(xiàn)

　　系統(tǒng)中獨立ECU的應用表現(xiàn)是另一個原型階段感興趣的內(nèi)容。不能從EDS文件中導出ECU的應用表現(xiàn)，因為EDS文件只是表示了目標目錄的框架。通常應用表現(xiàn)的構建是另外編程實現(xiàn)的。

　　集成了CAPL編程語言的軟件工具CANoe可以非常容易地描述ECU的表現(xiàn)。也可以用DLL描述ECU的表現(xiàn)。DLL用C/C++編寫，并鏈接到原型環(huán)境。CANoe也可以與Matlab/Simulink很好的集成。

　　根據(jù)需求等級不斷細化，原型將越來越優(yōu)化。完成了原型系統(tǒng)后，需要對整個系統(tǒng)進行測試。在這一環(huán)節(jié)，軟件工具CANoe將提供測試創(chuàng)建、評估和記錄。CANopen系統(tǒng)的測試功能需求包含以下幾個等級：

協(xié)議層：

　　一個例子是依據(jù)CiA e.V的規(guī)范對SDO協(xié)議的測試。這個例子中，包括了對被測設備(DUT- device under test)發(fā)送請求，對接受到的響應作出評估。不管在系統(tǒng)的獨立設備中是否實現(xiàn)了基于CANopen的通信協(xié)議都可以對其進行測試。
通信層：

　　不在此處測試協(xié)議的正確性，而是對(獨立的)協(xié)議順序的邏輯流進行了驗證，如對PDO的配置。在 PDO測試的例子中，在對象目錄中的PDO相關的實體必須按指定的順序書寫。在好的測試案例下，能檢測到遵循這一順序；在壞的測試案例下，錯誤的順序?qū)⒈憩F(xiàn)在被測設備的響應中。創(chuàng)建這一測試需要徹底理解CANopen的細節(jié)，最主要的是理解所使用的不同通信機制之間的相互關系。
應用層：

　　應用層的測試會檢查過程變量之間的關系。要證實變量之間的關系，必須滿足如下先決條件：過程變量必須能與PDO發(fā)生交換，系統(tǒng)必須完全可配置。例如，在測試時，閥的狀態(tài)可被看作溫度或壓力的函數(shù)。這一例子說明用戶必須能清楚地描述測試。

測試過程

　　使用CANoe工具，借助于集成的CAPL編程語言可以準確描述測試過程。開發(fā)者使用CAPL語言可準確描述對復雜的通信系統(tǒng)的相當靈活的測試過程。每個CAPL測試模塊是一個包含許多獨立測試用例的獨立測試。每個測試用例又包含了許多測試步。在測試執(zhí)行時，CANoe工具可依次運行各個測試用例。合適的測試流程控制可以跳過或重復某些測試。這樣可實現(xiàn)動態(tài)測試功能。

　　借助預先定義的CAPL函數(shù)能大大簡化產(chǎn)生測試用例的過程。一個典型的測試順序可能具有這樣的結構：先仿真被測設備，測試人員等待其響應，然后做出評估。CAPL提供了很多測試流程與事件同步的函數(shù)，比如接受一個特定的消息或者一個改變了的（可能通過COM修改）環(huán)境變量的值。與此同時，能在類似的后臺監(jiān)控到其它條件或約束的實現(xiàn)。如果在等待某個特定報文的過程中，用戶希望檢查此總線上是否還在周期性發(fā)送另一不同報文，這一功能就很有用。

　　尤其是建立自動執(zhí)行的測試時，對每個獨立的測試步結果的詳細數(shù)據(jù)記錄是非常重要的。另外的CAPL函數(shù)可用于將結果寫入XML文件作后處理，也可以寫入HTML文件做直接評估。CANoe工具的測試過程也可以由XML文件指定。如果能通過同一工具生成許多類似的測試過程，是更受歡迎的。CANoe工具提供了大量的XML格式的測試模板并能非常合適地使用。

總結

　　CANopen網(wǎng)絡系統(tǒng)的原型開發(fā)總是有許多重要的工作要做。不管怎樣，為了不需要等到項目階段的后期才能得到關于功能和系統(tǒng)性能的結論，原型設計經(jīng)常是至關重要的。用戶通過專用工具創(chuàng)建原型并得到支持，尤其能很容易實現(xiàn)對技術通信需求的覆蓋。 CANoe工具的測試功能讓系統(tǒng)開發(fā)人員在項目的每個階段都能進行驗證工作，直至最終得到完美的系統(tǒng)。