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

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

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

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

原型環境

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

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

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

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

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

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

應用表現

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

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

根據需求等級不斷細化，原型將越來越優化。完成了原型系統后，需要對整個系統進行測試。在這一環節，軟件工具CANoe將提供測試創建、評估和記錄。CANopen系統的測試功能需求包含以下幾個等級：

協議層：

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

通信層：

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

應用層：

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

測試過程

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

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

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

總結

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