CANopen已經在很多對成本敏感且要求靈活組網的應用領域（從工業自動化到商用汽車）成為了總線通信標準。CANopen標準的設備子協議，簡化了總線節點之間的通信，同時使來自不同廠商的ECU、傳感器和執行器能夠輕松實現互連。一個專業的原型建模及測試工具不僅能服務于復雜CANopen項目的工程開發 ，還能為工程師提供此領域的相關基礎知識。

開發一個CANopen網絡系統，其任務范圍從開發各個單ECU到整個網絡能夠運行起來。對于系統開發商而言，如果從一開始就采用CANopen系統，則為整個系統開發工作開了個無法估量的好頭。在系統開發的V模式流程中，“驗證和確認”占了很大一部分工作。因此，盡可能早地進行全面的測試工作，可大大減少因為太晚發現錯誤而帶來的風險。V模式開發流程如圖1所示：

圖1 V-模式開發流程
通過測試裝置進行系統驗證

系統開發過程中的系統化測試在所有開發步驟中是不可或缺的。但一般都要等到很晚，即獲得真實的系統組件后，才能進行測試。如果出現問題，則系統完成的時間會面臨風險。

實際上，測試一般都不在真實的系統上進行，取而代之的是使用測試裝置，在模擬的測試環境下進行。除了有專門的測量和診斷裝置外，還包括各種執行器，以盡可能的模仿切合實際的系統環境。根據不同的項目規模，這樣的測試裝置可能會花費很大的成本及勞力。這種測試裝置的瓶頸在于如何將以上各種因素集成到各個測試環節之中。因為往往只能有一個測試設置可以起作用。

有一種方法可以擺脫這種窘境，那就是借助軟件工具，在軟件環境下搭建整個系統的原型。借助軟件工具還具備一個優點是，軟件工具同時還提供測試的測試功能。

借助軟件工具創建系統原型環境

一個CAN網絡系統的原型起碼應支持測試及驗證。此外，另一個重點是系統原型里的各個單獨組件可以被真實的或模擬的ECU取代。利用這種方式，在系統開發的過程中，就可以比較容易地測試各個真實ECU的功能及性能。創建一個復雜系統的原型，需要借助合適的工具且要通過復雜的嘗試。Vector公司提供的CANoe.CANopen在創建系統原型通信方面提供了有效的幫助。僅需通過短短幾個配置步驟，就可讓用戶創建一個系統原型，其通信性能完全符合真實的系統。

CANopen網絡中各ECU的行為通過描述文件（EDS-電子數據表格）定義，這些描述文件需要事先選擇或創建好。接下來，需要定義將來會通過總線進行數據交換的的各數據間的相互關系，例如：某個CANopen網絡上節點地址是5的設備（壓力傳感器），其輸入值“壓力”被鏈接到節點地址是10的設備（控制模塊）的“氣壓”變量上。這些工作即是定義系統原型里所有PDO（進程數據對象）的相互關系。

配置工具會自動計算這些PDO的映射關系，這些映射關系如果有必要的話在以后還可以修改。所有配置都做好之后，配置工具的輸出是設備配置信息DCF（DCF-設備配置文件），根據這個配置信息，用戶就可以生成原型環境了，如，CANoe可以生成與各個真實ECU對應相同的通信屬性。只要運行CANoe，整個原型環境的通信部分功能就已經具備了。如圖2所示：

圖2 一個簡單的模擬的由中央控制和I/O節點組成的CANopen網絡
定義應用程序行為

每一個單獨ECU的應用程序行為都不可能直接從EDS文件中派生出來，因為EDS文件只是映射每一個對象字典的結構。因此，制定應用層程序行為總是涉及額外的編程工作。借助于CANoe環境里的CAPL編程語言，可以快速地實現ECU行為編程。此外，還可以將ECU行為編寫成DLL文件，并在CANoe中引用，同樣可以輕松集成Matlab/Simulink模型。如圖3所示：

圖3 CANoe.CANopen環境示意圖
測試功能

當系統原型建立之后，需要對整個工程進行必要的測試。CANoe支持用戶在它的環境下創建測試序列、測試過程記錄及測試結果評估。一個CANopen系統的測試功能由以下幾個等級構成：見圖4所示。

協議級

通過協議級的測試，保證各個基于CANopen通信子協議的設備，可按照CANopen規范集成到整個系統里。

通信級

通信級測試重要的不是保證協議的正確，而是保證協議序列正確的邏輯順序，如PDO的配置。對象字典里PDO相關入口描述必須要符合特定的順序。

應用程序級

應用程序級測試用于檢查過程變量之間的相互關系。下面的幾個前提條件必須滿足，甚至決定了相互關系：首先，過程變量交換必須使用PDO，因此，系統必須充分配置。這就意味著，例如，某個閥門的狀態可以根據溫度或壓力的值來檢測。顯然，用戶必須要有相關的know-how去制定測試。

圖4 CANopen里的測試級別
用CANoe創建和執行測試流程

測試序列可借助集成于CANoe環境的CAPL編程語言來制定，每個CAPL測試模塊代表一個單獨的測試，每一個單獨的測試有多個測試案例，這些測試案例又可能包含多個測試步驟。當測試運行時，CANoe按順序調用各個測試案例。適當的測試流程控制可選擇性的跳過或重復某個測試。同時，在后臺監測此步驟與其他約束條件的一致性狀態。例如，當CANoe正在等待某一個特定信息的同時時，又可以檢測看是否有某個特定的其它報文被定期地發送到總線上。

特別是在自動化測試時，重要的是需要詳細記錄每一個測試步驟的結果。CAPL程序里的其它函數用于處理將測試結果寫到XML文件，用于事后處理。CANoe的測試序列也可以通過XML語言實現。這在需要通過單個工具生成大量的測試流程時是非常有利的。因此，CANoe在XML中實現了一系列的測試模式，并能夠進行相應的處理。

總結

創建CANopen網絡的原型，總是需要花費相當大的勞力。然而，這一過程往往又是至關重要的，可以防止在項目的后期才發現功能性錯誤。用戶借助CANoe.CANopen可以高效地創建系統原型，同時，可以很容易地滿足在通信方面的技術要求。在項目的各個階段，網絡原型為系統開發商提供了及時檢查和驗證組件完整性所需的測試功能。(end)