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

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

圖1 V-模式開發(fā)流程
通過測試裝置進(jìn)行系統(tǒng)驗證

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

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

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

借助軟件工具創(chuàng)建系統(tǒng)原型環(huán)境

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

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

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

圖2 一個簡單的模擬的由中央控制和I/O節(jié)點組成的CANopen網(wǎng)絡(luò)
定義應(yīng)用程序行為

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

圖3 CANoe.CANopen環(huán)境示意圖
測試功能

當(dāng)系統(tǒng)原型建立之后，需要對整個工程進(jìn)行必要的測試。CANoe支持用戶在它的環(huán)境下創(chuàng)建測試序列、測試過程記錄及測試結(jié)果評估。一個CANopen系統(tǒng)的測試功能由以下幾個等級構(gòu)成：見圖4所示。

協(xié)議級

通過協(xié)議級的測試，保證各個基于CANopen通信子協(xié)議的設(shè)備，可按照CANopen規(guī)范集成到整個系統(tǒng)里。

通信級

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

應(yīng)用程序級

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

圖4 CANopen里的測試級別
用CANoe創(chuàng)建和執(zhí)行測試流程

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

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

總結(jié)

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