基于Vxworks的CANopen從站在風機控制器中的實現(xiàn)

顧開祥，姜智銳，杜國斌，邵鵬程

（上海中廣核工程科技有限公司，上海， 200241）

0 引言

風力發(fā)電作為能源主力軍之一，在2020年持續(xù)維持高景氣度，根據(jù)國家能源局公布的數(shù)據(jù)，繼2010年以來，我國風電新增裝機連續(xù)保持世界第一。全行業(yè)的產(chǎn)品升級迭代和科技進步不斷得到推進，總線技術(shù)在風電項目中得到大量的應用。從OSI網(wǎng)絡模型的角度來看同，現(xiàn)場總線網(wǎng)絡一般只實現(xiàn)了第 1 層（物理層）、第2 層（數(shù)據(jù)鏈路層）、第7層（應用層）。因為現(xiàn)場總線通常只包括一個網(wǎng)段，因此不需要第 3 層（傳輸層）和第4層（網(wǎng)層），也不需要第5層（會話層）第6層（描述層）的作用。

其中CAN（Controller Area Network） 現(xiàn)場總線僅僅定義了第1層、第2 層（見ISO11898標準）；實際設計中，這兩層完全由硬件實現(xiàn)，設計人員無需再為此開發(fā)相關(guān)軟件（Software）或固件（Firmware）?；?CAN 的高層協(xié)議：CAL 協(xié)議和基于 CAL 協(xié)議擴展的 CANopen 協(xié)議。CANopen協(xié)議是 CAN-in-Automation(CiA)定義的標準之一， 并且在發(fā)布后不久就獲得了廣泛的承認。相較于其他總線，由于CAN總線技術(shù)在通訊速率、通訊距離、錯誤處理能力等方面的綜合優(yōu)點，提高了系統(tǒng)的實時性、可靠性與靈活性，因此在現(xiàn)場設備中得到廣泛運用。

1 總體設計

這部分內(nèi)容主要闡述系統(tǒng)的總體設計，根據(jù)實際采用的PPC硬件、軟件操作系統(tǒng)及Codesys軟件給出總體設計方案，明確設計過程中的技術(shù)要點。并結(jié)合CANopen開源協(xié)議棧，通過分析該協(xié)議框架后，給出使用方法。CANopen從站系統(tǒng)主要是為上層應用程序提供PDO數(shù)據(jù)交互功能。該功能實現(xiàn)主要包括以下部分：

(1)用戶程序的PDO數(shù)據(jù)交互實現(xiàn)是基于Vxworks和Codesys組件接口程序，實際的CANopen協(xié)議報文在PPC硬件上以驅(qū)動的形式實現(xiàn)。

(2)CANopen協(xié)議部分的PDO、SDO、NMT等協(xié)議應用實現(xiàn)是基于開源CANopen協(xié)議。通過將該協(xié)議棧移植到PPC控制器上，來完成CAN應用層功能。

(3)CANopen協(xié)議報文由CAN鏈路層的發(fā)送或接收完成，通過PPC硬件控制CAN鏈路層控制芯片和CAN的PHY芯片，最終實現(xiàn)與外部CAN主站的數(shù)據(jù)交互。

CANopen總線網(wǎng)絡由一個主設備和多個從設備構(gòu)成分布系統(tǒng)，每個節(jié)點設備通過不同的COB-ID為標識。在Codesys應用程序開發(fā)過程中，可根據(jù)實際項目的開發(fā)將系統(tǒng)中任意滿足協(xié)議要求的數(shù)據(jù)通過調(diào)用組件接口將其傳到CANopen協(xié)議棧中對應的TPDO映射變量，同樣也可通過調(diào)用組件接口獲取協(xié)議棧中相應的RPDO映射變量的數(shù)據(jù)。以該形式即可完成CAN主站設備和CAN從站設備間的PDO交互?？傮w設計如圖1所示。

圖1 總體設計框圖

關(guān)于如何保證主從站數(shù)據(jù)交互的可靠性與實時性要求。其中可靠性主要依賴RPDO、TPDO預定義規(guī)則，即每個PDO對應地址中的數(shù)據(jù)定義是確定，其次CANopen開源協(xié)議的可靠性是經(jīng)過很多平臺測試驗證的。實時性要求，開源棧協(xié)議實現(xiàn)是基于Vxworks任務調(diào)度的強實時性及相關(guān)定時或信號傳遞等資源的低延時的基礎(chǔ)上完成的，故實時性是能達到要求的。

2 CANopen從站的設計實現(xiàn)

■2.1 從站功能概述

CANopen 是 在 CAL基礎(chǔ)上開發(fā)的，使用了CAL 通訊和服務協(xié)議子集，提供了分布式控制系統(tǒng)的一種實現(xiàn)方案。CANopen在保證網(wǎng)絡節(jié)點互用性的同時允許節(jié)點的功能隨意擴展：或簡單或復雜。

CANopen的核心概念是設備對象字典（OD：Object Dictionary），在其他現(xiàn)場總線（ Profibus， Interbus-S）系統(tǒng)中也使用這種設備描述形式。注意：對象字典不是 CAL的一部分，而是在 CANopen 中實現(xiàn)的。在 OSI 模型中，CAN標準、CANopen 協(xié)議之間的關(guān)系如圖2所示。

圖2 CAN標準、CANopen 協(xié)議關(guān)系圖

CANopen從站功能實現(xiàn)如下3種協(xié)議報文（通訊對象）：

(1)網(wǎng)絡管理報文：負責CAN網(wǎng)絡的管理和 設備ID 分配服務：如初始化，配置和網(wǎng)絡管理（包括：節(jié)點保護）。

(2)服務數(shù)據(jù)對象 SDO(Service Data Object)：通過使用索引和子索引， SDO 使客戶機能夠訪問設備（服務器）對象字典中的項（對象）。協(xié)議是確認服務類型：為每個消息生成一個應答。

(3)過程數(shù)據(jù)對象 PDO（ Process Data Object）：用來傳輸實時數(shù)據(jù)， 數(shù)據(jù)從一個生產(chǎn)者傳到一個或多個消費者。數(shù)據(jù)傳送限制在 1 到 8 個字節(jié)。

■2.2 CAN從站硬件實現(xiàn)

從站硬件的搭建主要分為三個部分，首先是控制器使用的是PPC架構(gòu)的單核控制器主頻450M；其次是CAN的控制采用的是飛利浦的PCA82C200芯片，將欲收發(fā)的消息（報文），轉(zhuǎn)換為符合CAN規(guī)范的CAN幀，通過CAN收發(fā)器，在CAN-bus上交換信息；最后是CAN收發(fā)器部分采用的是MAX305 1芯片，主要實現(xiàn)CAN控制器的邏輯電平轉(zhuǎn)換為CAN總線的差分電平，在兩條有差分電壓的總線電纜上傳輸數(shù)據(jù)。CAN從站硬件實現(xiàn)如圖3所示。

圖3 CAN從站硬件實現(xiàn)框圖

■2.3 CAN從站軟件實現(xiàn)

控制器系統(tǒng)的軟件開發(fā)采用WindRiver公司的Tornado2.2集成開發(fā)環(huán)境， 操作系統(tǒng)版本為Vxworks 5.5.1。軟件實現(xiàn)均基于模塊化的設計，包括移植CANopen開源協(xié)議棧的應用程序。CANopen從站的軟件框圖如圖4所示。

圖4 CAN從站軟件實現(xiàn)框圖

2.3.1 CAN底層驅(qū)動程序?qū)崿F(xiàn)

這部分工作主要是完成PCA82C200CAN控制器的控制實現(xiàn)，通過對該CAN控制器內(nèi)部REG的讀寫操作完成芯片的參數(shù)配置初始化、總線狀態(tài)監(jiān)測、報文收發(fā)等。該芯片初始化實現(xiàn)函數(shù)PCA_Init()、REG讀操作函數(shù)PCA_REG_Read()、REG寫操作函數(shù)PCA_REG_Write（）等。CAN芯片初始化部分實現(xiàn)，流程圖如5所示。

關(guān)于控制器的CAN報文發(fā)送，底層報文的傳輸是由PCA82C200獨立完成的，主控制器(PPC)將需發(fā)送的數(shù)據(jù)寫入CAN控制器寄存器中，CAN控制器首先會把數(shù)據(jù)放到緩沖區(qū)里，通過查詢或中斷的方式來判斷數(shù)據(jù)的發(fā)送是否完成。完成時對應的寄存器狀態(tài)字會被置為1或中斷會被觸發(fā)。本設計是基于查詢的方式實現(xiàn)的。首先通過輪詢確定當前發(fā)送緩沖區(qū)是否空閑，接著寫發(fā)送緩沖區(qū)。具體如流程圖6所示。

圖5 CAN芯片初始化流程圖

圖6 CAN報文發(fā)送流程圖

關(guān)于CAN控制器報文接收，當控制器接收到報文時會將數(shù)據(jù)放到接收緩沖區(qū)中，實現(xiàn)方式與發(fā)送一樣均有兩種方式，本設計數(shù)據(jù)接收采用的是中斷的方式，當控制器觸發(fā)接收中斷條件后，會觸發(fā)相關(guān)中斷，同時數(shù)據(jù)會存放到接收緩存中。當接收完數(shù)據(jù)后需要清除相關(guān)的中斷狀態(tài)，等待下次接收中斷的觸發(fā)。具體實現(xiàn)流程如流程圖7所示。

圖7 CAN報文接收流程圖

2.3.2 驅(qū)動接口實現(xiàn)

關(guān)于驅(qū)動接口實

現(xiàn)，本設計與采用的嵌入式操作系統(tǒng)有關(guān)，同時需要兼顧CANopen協(xié)議棧接口。根據(jù)協(xié)議棧的設計，調(diào)用CAN底層驅(qū)動接口函數(shù)即可控制底層硬件。功能實現(xiàn)框圖如圖8所示。該過程需加載CAN驅(qū)動，主要包含以下接口：CAN口的打開、關(guān)閉、數(shù)據(jù)收發(fā)及波特率的設置。

圖8 驅(qū)動功能實現(xiàn)框圖

2.3.2.1 系統(tǒng)定時器機制

在開源協(xié)議棧實現(xiàn)中，很多的接口交互都與定時器有關(guān)，交互的實時性取決于定時器的精度，這直接決定了從站功能實現(xiàn)的可靠性。故在PPC架構(gòu)中實現(xiàn)CANopen從站功能首先需要解決定時問題。基于Vxworks提供的精準軟定時器和信號量，完成協(xié)議棧中時間調(diào)度程序。在創(chuàng)建的任務中調(diào)用延時接口完成對協(xié)議棧的時間調(diào)度任務。

2.3.2.2 驅(qū)動接口函數(shù)

該部分是實現(xiàn)的是協(xié)議棧與底層驅(qū)動的接口函數(shù)，基于底層操作的基本接口實現(xiàn)，可用于上層應用對底層的控制。驅(qū)動與協(xié)議棧主要實現(xiàn)內(nèi)容包含CAN設備的打開、關(guān)閉、讀、寫操作。該驅(qū)動為字符設備驅(qū)動，利用Vxworks I/O系統(tǒng)為用戶程序提供統(tǒng)一接口，使得上層應用程序與底層硬件相互獨立。

■2.4 CANopen從站協(xié)議棧移植實現(xiàn)

2.4.1 CANopen開源協(xié)議棧介紹

現(xiàn)市場上主流的CANopen開源協(xié)議棧主要有MicroCANOPEN、CANOPENNode和CANFestival三種。使用開源協(xié)議?？梢詼p少開發(fā)難度和降低開發(fā)周期，且開源協(xié)議?？偩€功能齊全。本實現(xiàn)選擇CANFestival協(xié)議棧，該協(xié)議棧編寫于2001年，已經(jīng)過若干項目驗證至今，代碼成熟度很高。該協(xié)議相比較于其他的開源協(xié)議有如下優(yōu)點：

(1)該開源協(xié)議棧完全符合國際協(xié)議標準并支持CIADS-301，功能上相對完整。

(2)該開源協(xié)議棧已在多種平臺上完成了移植，應用廣泛可靠性高。協(xié)議棧的實現(xiàn)是基于標準C，可移植性強且官方相關(guān)支持資料完善。

(3)該協(xié)議棧的操作使用簡單易上手，比如開發(fā)人員可根據(jù)實際項目對對象字典進行隨意配置。

在CANFestiva協(xié)議中，全部源碼可分為4部分：目標接口程序、CAN驅(qū)動接口程序、協(xié)議庫文件及CAN主從站的用戶程序。在協(xié)議庫文件中主要包含三點：調(diào)度管理、節(jié)點管理及核心協(xié)議代碼。高層協(xié)議包含SDO、PDO、NMT、SYNC等，關(guān)于這部分程序的移植是不用做任何修改，關(guān)于主從節(jié)點主要包含節(jié)點的狀態(tài)反饋及對象字典的定義。對于開發(fā)人員需要修改的代碼工作量主要在硬件驅(qū)動適配及與操作系統(tǒng)的接口適配上。

SDO報文、同步報文、心跳報文等是需要通過定時器功能的支持，可通過操作系統(tǒng)的軟件定時功能來實現(xiàn)，主要得益于Vxworks具有很好的實時性，無需硬件定時器也能可靠的出觸發(fā)關(guān)報文的發(fā)送。CANFestival開源協(xié)議中各代碼結(jié)構(gòu)功能關(guān)系如圖9所示。

圖9 CANOPEN各代碼結(jié)構(gòu)功能關(guān)系圖

2.4.2 CANopen應用層功能實現(xiàn)

CANopen應用協(xié)議是基于CiA標準設計的，以為主從站的硬件連接、硬件接口定義，軟件接口定義給出明確的說明。主從站的通訊報文及對象字典，采用結(jié)構(gòu)化的方法。數(shù)據(jù)的交互雙方設備按照對象字典的設定即可，而對象字典內(nèi)容可根據(jù)主索引與子索引來查詢。

2.4.2.1 從協(xié)議棧應用主流程

程序上電后，首先是創(chuàng)建相關(guān)任務并初始化通訊參數(shù)，對相應的數(shù)據(jù)進行更新。完成相關(guān)初始化后，從站設備會自動發(fā)起啟動設備報文（boot_up）給主站設備，接著從站設備按照協(xié)議規(guī)范進入預操作模式。下一步從設備將進入?yún)f(xié)議棧的主任務，最后通過周期性查詢接收報文并逐條解析，主任務根據(jù)解析內(nèi)容判斷該報文控制從設備運行狀態(tài)。根據(jù)解析報文進入不同的階段處理函數(shù)，完成相應的交互處理。如果主任務一直沒有收到主站設備請求報文，從站依然按照設備描述文件上傳相關(guān)PDO報文。主站接收到從站報文后，同樣會按照規(guī)則進行解析后，進入相關(guān)處理函數(shù)。

如果主站配置了節(jié)點守護功能，主站設備會按照設定的周期時間，向從站設備發(fā)送節(jié)點守護報文。節(jié)點守護報文實際就是CAN的遠程幀，當從設備被收到該報文后，進行解析，判斷報文類型，再進入相關(guān)的處理子函數(shù)進行處理。該處理方式就是回復一個標準幀，數(shù)據(jù)長度為一個字節(jié)。其中該字節(jié)的最高位每次會翻轉(zhuǎn)一次。如表1所示。

表1 節(jié)點守護

因協(xié)議棧程序是基于結(jié)構(gòu)化、模塊化的方式開發(fā)的，因此對于開發(fā)者而言移植及運用比較簡易方便。主流程圖如圖10所示。

圖10 主流程圖

2.4.2.2 對象字典的編寫

對象字典是CANopen協(xié)議最核心的部分，對于從站設備需要編寫TestSlav e.c源文件。其實現(xiàn)主要分為兩部分：CIA-301規(guī)定的設備通訊參數(shù)、設備參數(shù)、PDO及SDO的參數(shù)配置。關(guān)于CAN從站設備節(jié)點對象字典的設置是確定的，需要在設備運行前將相關(guān)內(nèi)容配置完。

從站設備啟動后，主站設備會向從設備發(fā)送SDO配置報文，從站設備收到請求報文后按照協(xié)議規(guī)定方式解析主索引和子索引數(shù)據(jù)后，在對象字典中找到相應的內(nèi)容。

2.4.2.3 SDO服務數(shù)據(jù)對象處理

從站設備處理SDO請求報文，此類型的報文是配置通訊相關(guān)參數(shù)。當從設備接收到SDO請求時，首先會判斷該請求是對OD進行讀操作還是寫操作。然后根據(jù)主索引和子索引找到相應的位置對其進行相應的讀或?qū)懖僮?。對象字典的?nèi)容也是按照既定協(xié)議規(guī)則進行查找賦值的。處理完成后，會按照協(xié)議規(guī)范相應操作成功或失敗。

2.4.2.4 PDO過程數(shù)據(jù)對象處理

在SDO配置完成后，過程數(shù)據(jù)對象處理就會按照該配置的通訊參數(shù)和映射參數(shù)進行運行處理。PDO通訊參數(shù)：主要涉及PDO的傳輸類型、禁止時間、事件時間等，對于RPDO通訊參數(shù)范圍在1400H～15FFH，TPDO在1800H～19FFH之間；PDO映射參數(shù)：映射應用對象到PDO中是在設備對象字典中描述的，對于RPDO范圍在1600H～2000H，TPDO在1A00～1BFF之間。PDO的報文內(nèi)容是寫入預先定義好的映射字典中。

PDO的交互方式取決于SDO對其的配置，如同步類型可以配置PDO根據(jù)同步報文數(shù)量來控制PDO報文；如遠程幀類型可以配置PDO按照是否收到遠程幀來控制PDO報文；如事件類型則可以通過數(shù)據(jù)的值是否發(fā)生變化來控制

PDO報文。以同步類型為例，其控制PDO流程圖如圖11所示。

圖11 同步類型 PDO流程圖

■2.5 應用程序PDO數(shù)據(jù)控制

主要涉及兩個接口：PDO數(shù)據(jù)發(fā)送和PDO數(shù)據(jù)接收App_PdoDataGet()、App_PdoDataSend()；該接口是通過Codesys與Vxworks接口組件實現(xiàn)的。兩個接口函數(shù)設計的參數(shù)為：PDO通道值、PDO數(shù)據(jù)指針、PDO數(shù)據(jù)指針長度。

數(shù)據(jù)接收接口對應的是從站設備的RPDO，需要獲取相關(guān)的PDO數(shù)據(jù)時，即可根據(jù)PDO通道值獲取對應的PDO映射地址中的數(shù)據(jù)。當需要發(fā)送數(shù)據(jù)時可根據(jù)相應的PDO通道將數(shù)據(jù)傳到映射地址中完成數(shù)據(jù)發(fā)送。

3 系統(tǒng)測試

在完成CANopen從站模塊的軟硬件設計與調(diào)試后，需要對CANopen從站的CANopen通訊協(xié)議進行測試驗證。系統(tǒng)硬件測試環(huán)境搭建完成后如圖12所示。系統(tǒng)中的主站功能由某廠家風機控制器的主控模塊完成；同時利用第三方CAN工具及其上位機軟件在總線上進行抓包，供過程分析與性能驗證。

圖12 系統(tǒng)實物圖

系統(tǒng)搭建完成后，將各個單元上電運行。待CAN設備完成初始化等任務后，系統(tǒng)即進入運行模式。整個通訊過程無需其他操作。通訊過程首先是從站設備發(fā)送Boot_up啟動幀，表示從站設備已完成啟動待配置；接著主站會按照EDS文件配置從站參數(shù)，讀配置成功則響應的包數(shù)據(jù)頭為0x4x開頭，對于寫配置成功后響應的數(shù)據(jù)頭以0x60開頭。還有其他通訊如表2所示。

表2 測試數(shù)據(jù)

整個過程基本驗證了通訊功能。并通過大量驗證測試數(shù)據(jù)傳輸一直保持穩(wěn)定高效。因此，可證明該設計的CANopen從站系統(tǒng)滿足CANopen通訊協(xié)議。

4 總結(jié)

本文設計部分首先介紹了CANopen系統(tǒng)搭建的總體設計，并闡述了CANopen總線的基本概念，介紹了如何將CANopen開源協(xié)議棧應用到風機控制器上 。過程中并對軟軟硬件設計方案中的注意項進行了說明。如硬件設計給出了具體型號的芯片、功能介紹等；軟件設計則給出相關(guān)設計方法及思路，并通過各個軟件開發(fā)平臺進行開發(fā)設計。設計完成后則通過實際硬件進行驗證，并對測試數(shù)據(jù)進行分析注釋。實際結(jié)果表明CANopen總線控制可使系統(tǒng)控制線路簡單、過程調(diào)試方便，提高了控制系統(tǒng)的可靠性和實時性 。