無人機仿真系統(tǒng)CAN總線調度及注冊機制設計

賈振宇，李春濤，李　妍

(南京航空航天大學 自動化學院，南京　210016)

?

無人機仿真系統(tǒng)CAN總線調度及注冊機制設計

賈振宇，李春濤，李妍

(南京航空航天大學 自動化學院，南京210016)

針對無人機仿真系統(tǒng)傳輸數(shù)據(jù)量大，實時性要求高等特點，以基于CAN總線的飛行仿真系統(tǒng)為平臺，設計了總線時間調度以及狀態(tài)檢測機制，對數(shù)據(jù)進行分組分時傳輸，保證總線通信的實時性，為仿真測試提供了一套正確有效的驗證平臺;針對傳統(tǒng)仿真系統(tǒng)接口資源固定，不利于更改升級的問題，設計了接口資源注冊機制，根據(jù)各接口節(jié)點的注冊信息建立系統(tǒng)接口資源表，進行統(tǒng)一管理，提高了系統(tǒng)的靈活性，便于仿真系統(tǒng)的開發(fā)。

CAN總線；飛行仿真系統(tǒng)；時間調度；狀態(tài)檢測；接口注冊

0　引言

制系統(tǒng)控制律與控制邏輯正確性和可靠性的測試平臺，飛行仿真平臺對實時性有較高的要求，以保證仿真結果的正確性。國內對無人機仿真系統(tǒng)的研究較為廣泛，西北工業(yè)大學搭建了基于PC104和VxWorks的飛行仿真系統(tǒng)[1]，并對分布式飛行仿真技術進行了研究[2]；國防科技大學利用快速原型技術設計了實時分布式飛行仿真系統(tǒng)[3]；南京航空航天大學采用快速原型與VxWorks相結合的方式，設計了實時仿真系統(tǒng)，以保證系統(tǒng)實時性[4]。

對于復雜的仿真系統(tǒng)，仿真對象包括傳感器、舵機和無人機相關子系統(tǒng)等設備，仿真過程中會產(chǎn)生大量仿真數(shù)據(jù)交互，如果不對數(shù)據(jù)交互進行統(tǒng)一調度，大量數(shù)據(jù)交互存在數(shù)據(jù)傳輸沖突，影響仿真系統(tǒng)的實時性。與此同時，傳統(tǒng)仿真系統(tǒng)接口資源相對固定，主要針對某一固定類型無人機仿真對象。雖然傳統(tǒng)仿真系統(tǒng)留有相應的備份接口資源，但當接口資源變化較大時，備份接口資源不能滿足需求，需要變更硬件和底層驅動，工作量大且不夠靈活，不利于仿真系統(tǒng)的開發(fā)。

針對上述兩個問題，本文以基于CAN總線的某樣例無人機仿真系統(tǒng)(以下簡稱仿真系統(tǒng))為硬件平臺，根據(jù)CAN總線的傳輸特性，設計了主從靜態(tài)分時調度機制以及狀態(tài)檢測機制，對總線通信進行合理調度，避免數(shù)據(jù)傳輸沖突，保證傳輸?shù)膶崟r性和可靠性；同時設計了接口資源注冊機制，對接口資源進行統(tǒng)一管理，實現(xiàn)接口資源可擴展，提高了仿真系統(tǒng)的靈活性，為仿真系統(tǒng)的開發(fā)提供了方便。

1　仿真系統(tǒng)平臺

仿真系統(tǒng)不僅要求仿真系統(tǒng)運行解算具有較高的實時性，同樣要求內部通信具有較高的實時性和可靠性，對內部通信總線提出了較高要求。

目前工業(yè)上應用的總線有很多，包括RS485、I2C、1553B、CAN等總線，其中CAN總線憑借其實時性和可靠性等特點，已經(jīng)在航空工業(yè)、工業(yè)控制、安全防護、農業(yè)生產(chǎn)等領域得到了廣泛應用[5]。和其他總線相比，CAN總線具有實時性高、可靠性高、受環(huán)境干擾小以及配置靈活等優(yōu)點。

基于CAN總線通信的仿真系統(tǒng)平臺如圖1所示。為了保證模型解算的實時性，減輕CPU單元的負擔，采用多塊板卡分工協(xié)作的方式，將仿真系統(tǒng)分為CPU單元和接口單元，CPU單元負責模型解算和任務調度等功能，接口單元負責與外界進行數(shù)據(jù)交換。CPU單元與各接口單元之間通過內部CAN總線進行數(shù)據(jù)傳輸，系統(tǒng)內部的數(shù)據(jù)通信為CPU單元與接口單元的數(shù)據(jù)交互，各接口單元之間不存在數(shù)據(jù)交互，故將CPU單元作為主節(jié)點，各接口單元作為從節(jié)點，各個節(jié)點掛接到CAN總線上。CAN總線可分為上行總線和下行總線，分別傳輸CPU單元向接口單元流向的數(shù)據(jù)和接口單元向CPU單元流向的數(shù)據(jù)，以減輕CAN總線負載。

圖1　仿真系統(tǒng)結構示意圖

2　CAN總線通信機制設計

2.1CAN總線時間調度設計

仿真系統(tǒng)內部CAN總線分為上行總線和下行總線，上行總線數(shù)據(jù)傳輸方式為CPU單元向多個接口單元發(fā)送數(shù)據(jù)，由CPU單元確定數(shù)據(jù)發(fā)送時機，而下行總線是多個接口單元向CPU單元發(fā)送數(shù)據(jù)，總線數(shù)據(jù)傳輸時機不確定，具有隨機性，存在同一時間幾個接口單元同時發(fā)送數(shù)據(jù)的情況，雖然CAN自身帶有非破壞仲裁機制，可以保證所有消息能夠根據(jù)其各自的優(yōu)先級進行連續(xù)發(fā)送[5]，但延時時間不確定且總線負載不均衡，存在負載時高時低的情況。為了保證上行總線傳輸數(shù)據(jù)的實時性以及數(shù)據(jù)傳輸時機的可確定性，采用基于主節(jié)點時間的分時調度方式對整個內部總線通信網(wǎng)絡進行管理[6]，以避免總線數(shù)據(jù)傳輸?shù)臎_突。

總線分時調度時，主節(jié)點為每個節(jié)點提供一個時間基準，用來作為各節(jié)點發(fā)送消息的參考時間，不同類型的消息在各自特定的時間段進行發(fā)送，而無需和總線上的其他任何消息進行競爭，這樣就可以避免丟失仲裁，同時延遲時間是確定的[5-6]。

將CPU單元的硬件定時器作為全局時間的時鐘定時器，定義2 ms為數(shù)據(jù)通信的原子周期，10 ms為數(shù)據(jù)通信的基本周期,一個基本周期包括5個原子周期。每經(jīng)過一個原子周期，主節(jié)點將通過總線廣播一幀包含當前原子周期序號的時間同步幀，從節(jié)點根據(jù)原子周期序號判斷當前所在的時間窗口。在一個基本周期中針對不同類型的接口數(shù)據(jù)分配不同的時間片，接口單元接收CPU單元廣播的時間同步幀，根據(jù)時間同步幀中的原子周期序號判斷當前是否是數(shù)據(jù)上傳時間窗口，如果不是自身接口節(jié)點上傳數(shù)據(jù)時間窗口，等待其他節(jié)點上傳數(shù)據(jù)；如果是自身上傳數(shù)據(jù)時間窗口，則上傳數(shù)據(jù)。

如圖2所示，t1時刻CPU單元發(fā)送時間同步幀，1553B接口單元接收到時間同步幀進行對比，確認當前為1553B接口數(shù)據(jù)發(fā)送時間窗口，開始發(fā)送數(shù)據(jù)；而其他接口單元接收到時間同步幀對比后，確認不是對應接口的時間窗口，不發(fā)送數(shù)據(jù)。同樣的，在t2、t3時刻，只有與時間窗口對應的接口單元發(fā)送數(shù)據(jù)，其他接口單元不發(fā)送數(shù)據(jù)。

圖2　接口單元分時發(fā)送數(shù)據(jù)

分配至各通信接口單元專屬時間窗口的多少由該單元所需上傳數(shù)據(jù)量的大小所決定，表1是各接口的單位時間傳輸?shù)臄?shù)據(jù)量，可以看出串行通信接口單元的數(shù)據(jù)量最大而1553B接口單元、開關量接口單元和模擬量單元數(shù)據(jù)量較小。通信原子周期為2 ms,每個節(jié)點上傳數(shù)據(jù)時間至少為2 ms,按照CAN總線最大負載的50%計算，2 ms內CAN總線可傳輸約70字節(jié)數(shù)據(jù)，可滿足接口傳輸數(shù)據(jù)量的要求，因此接口類型時間窗口均為一個原子周期。

表1　接口數(shù)據(jù)量

圖3為CAN總線數(shù)據(jù)通信周期內各通信接口單元數(shù)據(jù)調度時間片分配示意圖，將第2時間片分配給1553B接口單元，第3時間片分配給串行通信接口單元，模擬量接口單元與開關量接口單元共用第4時間片，第5個時間片為備用以便后期擴展，而第1時間片用于總線節(jié)點的狀態(tài)檢測，每兩個基本周期進行一次狀態(tài)檢測。

圖3　總線時間調度時間片分布

2.2狀態(tài)檢測機制設計

CPU單元和接口單元采用了狀態(tài)檢測機制，即心跳機制。心跳是各通信模塊定時發(fā)出的狀態(tài)報告信號，也可以根據(jù)系統(tǒng)需求定義為一次設備握手操作[7]。在仿真過程中，CPU單元定時向各接口單元發(fā)送檢測信號并接收接口單元反饋的狀態(tài)信號，CPU單元判斷狀態(tài)信號有無和狀態(tài)信號內容，便可以識別出接口單元的工作狀態(tài)，上報給仿真管理計算機。

圖4　系統(tǒng)接口單元表

這里采用了基于“請求-應答”方式的故障檢測機制[8],包括的狀態(tài)檢測請求幀以及狀態(tài)檢測應答幀。狀態(tài)檢測的周期為兩個基本周期，在第一個基本周期的第1時間片進行狀態(tài)檢測，如圖3所示。主節(jié)點周期發(fā)送狀態(tài)檢測請求幀，各從節(jié)點在每個狀態(tài)檢測周期成功接收到該請求幀后需在同一個時間窗內返回一個狀態(tài)檢測應答幀。主節(jié)點在3個狀態(tài)檢測周期未能接收到某個節(jié)點狀態(tài)檢測應答幀，說明接口單元至少6個周期內未傳輸數(shù)據(jù)或傳輸?shù)臄?shù)據(jù)有誤，認為該節(jié)點故障。

主節(jié)點周期向上下行總線發(fā)送狀態(tài)檢測幀，檢測上下行數(shù)據(jù)鏈路的狀態(tài)。故障類型如表2所示。當節(jié)點數(shù)據(jù)鏈路故障時，可通過軟件對控制器進行復位重啟，而節(jié)點單元異常和數(shù)據(jù)鏈路斷路故障時，需要更換相應的接口單元并進一步檢查硬件是否正常。

表2　故障分類

3　接口單元注冊機制設計

為了提高仿真系統(tǒng)開發(fā)的靈活性，實現(xiàn)對接口單元的靈活添加和刪除，根據(jù)仿真系統(tǒng)的結構特點，采用接口單元上報資源信息的注冊機制，實現(xiàn)CPU單元動態(tài)獲取各接口單元資源信息。

系統(tǒng)啟動后，各接口單元會向CPU單元發(fā)送資源注冊幀，資源注冊幀包括接口單元類型(串口、開關量、1553B等)、設備號(板卡唯一標識)、接口資源以及傳輸數(shù)據(jù)分配的CAN總線ID標識符。CPU單元根據(jù)接收到的注冊信息建立系統(tǒng)接口單元表和系統(tǒng)接口資源表，CPU單元通過維護這兩張表，實現(xiàn)對接口單元的管理和調用。

系統(tǒng)接口單元表包含了當前注冊的所有接口單元的基本信息，CPU單元可以查詢此表獲取當前可用接口資源。表中每個接口單元用一個結構體進行表示，該結構體定義如下：

typedef struct

{

鏈接指針；

接口單元類型;

設備號；

輸入接口個數(shù)；

輸出接口個數(shù)；

}DEV_Struct;

該結構體給出了鏈接指針、接口單元類型、設備號和接口資源的個數(shù)，結構相對簡單，只存儲了一些關鍵信息。整個系統(tǒng)接口單元表中的接口單元結構通過指針鏈接在一起，有新的接口單元注冊時，直接將相應的單元結構體添加到隊列中。如圖4所示是系統(tǒng)接口單元表的示意圖。

當仿真系統(tǒng)接口需求變更，對接口單元進行刪減時，系統(tǒng)接口資源表也隨之變化。系統(tǒng)中可能存在多個同類型的接口單元，雖然接口類型和資源一樣，但每個接口單元的設備號唯一，CPU單元可以根據(jù)設備號確定唯一的接口通道。

CPU單元建立系統(tǒng)接口單元表的同時，會根據(jù)設備號建立系統(tǒng)接口資源表，用于存儲分配給各接口的CAN總線ID標識符，每個接口通道都有自己唯一的ID標識符。接口資源表分為兩種類型：接收接口資源表和發(fā)送接口資源表，分別用來存放用于接收、發(fā)送的接口通道分配的ID標識符。接口資源表結構如表3所示。

表3　系統(tǒng)接口資源表

當CPU單元要通過某個接口通道發(fā)送數(shù)據(jù)時，首先會查詢系統(tǒng)接口單元表，找到對應接口所在單元的設備號，根據(jù)設備號與通道號在系統(tǒng)發(fā)送接口資源表中找到對應的CAN總線ID標識符，將數(shù)據(jù)組幀，通過CAN總線發(fā)送給對應接口單元。具體流程如圖5所示。

圖5　CPU單元發(fā)送數(shù)據(jù)過程

相應的，當CPU單元接收到數(shù)據(jù)時，需要判斷數(shù)據(jù)來自哪個接口通道，CPU單元會對比系統(tǒng)接收接口資源表中的ID標識符，找到對應的設備號和通道號，再根據(jù)設備號查詢系統(tǒng)接口單元表，匹配接口類型。接口類型和通道號可以唯一確定數(shù)據(jù)來源，從而將接收到的數(shù)據(jù)存放到對應的數(shù)據(jù)緩沖區(qū)中，由相關處理程序進行解碼處理。具體流程如圖6所示。

圖6　CPU單元接收數(shù)據(jù)過程

4　系統(tǒng)測試

為了驗證仿真系統(tǒng)CAN總線通信機制設計的性能和正確性，本文從CAN總線通信性能、總線時間調度兩個方面進行測試[9-11]。

4.1CAN總線可靠性測試

為了驗證CAN總線的傳輸數(shù)據(jù)的可靠性，搭建了如圖7所示的測試平臺。CPU單元作為主節(jié)點通過下行總線發(fā)送測試數(shù)據(jù)，接口單元作為從節(jié)點接收測試數(shù)據(jù)并通過上行總線轉發(fā)測試數(shù)據(jù)，由CAN監(jiān)測設備監(jiān)測總線上的數(shù)據(jù)，與測試數(shù)據(jù)進行對比分析。主節(jié)點以2 ms的時間周期發(fā)送10幀測試數(shù)據(jù)，使總線在約50%的負載情況下進行4小時通信測試。

圖7　CAN測試結構

總線測試情況統(tǒng)計如表4所示，可以看出通信過程中丟幀、錯幀計數(shù)均為0，表明CAN總線通信可以保證通信的可靠性，滿足飛行仿真系統(tǒng)通信的可靠性要求。

表4　CAN總線通信測試

4.2總線時間調度測試

為了驗證總線收發(fā)數(shù)據(jù)的調度情況，搭建起半物理仿真測試環(huán)境，將飛行控制系統(tǒng)與仿真平臺連接，進行閉環(huán)仿真測試。在測試過程中對CAN總線收發(fā)數(shù)據(jù)任務進行了監(jiān)測。

如表5所示，統(tǒng)計部分仿真發(fā)送任務和接收任務執(zhí)行時間和運行周期。由測試結果可知，仿真系統(tǒng)中總線收發(fā)任務都能按照周期要求運行，且都能在其周期時間內執(zhí)行完畢，可以說明總線任務調度正確。

表5　部分收發(fā)任務統(tǒng)計結果

統(tǒng)計仿真過程中系統(tǒng)的CPU利用率，測試結果如圖8所示。由測試結果可知，系統(tǒng)CPU利用率在55%至60%之間，仿真過程中CPU利用率分布比較均衡，沒有出現(xiàn)大的峰值，說明CAN總線收發(fā)任務調度均衡，沒有出現(xiàn)任務扎堆運行造成CPU利用率瞬間增大的情況。

圖8　CPU利用率測試結果

如圖9所示是CAN總線收發(fā)任務的調度情況。圖9中橫軸是仿真運行時間，縱軸是收發(fā)任務名稱，每個旗子符號代表任務執(zhí)行。圖9中RxFCC_MINS是1553B接收任務，RxFCC_BINS、RxFCC_Servo以及RxFCC_AirBrake是串口接收任務，可以看出發(fā)送任務按照接口協(xié)議周期執(zhí)行，在一個基本周期內任務執(zhí)行時間不同，根據(jù)接口類型分時執(zhí)行，說明收發(fā)任務均勻分布，沒有出現(xiàn)發(fā)送數(shù)據(jù)競爭，總線調度機制可以有效的避免數(shù)據(jù)沖突的情況。

圖9　CAN總線收發(fā)任務調度情況

5　結語

本文以基于CAN總線的某樣例無人機飛行仿真系統(tǒng)為硬件平臺，設計了基于主節(jié)點時間的主從靜態(tài)分時調度機制、接口資源注冊機制以及狀態(tài)檢測機制。最終實現(xiàn)CPU單元對資源接口的統(tǒng)一調度，靈活地對接口資源的增減進行管理。同時通過文中的分析和試驗，表明總線時間調度能有效的調度數(shù)據(jù)收發(fā)，避免數(shù)據(jù)沖突；多板卡能夠穩(wěn)定、可靠地協(xié)同工作，完成對仿真對象的仿真模擬，整個仿真系統(tǒng)可以為無人機飛行仿真測試提供正確可靠的驗證平臺。

[1]李謙. 基于PC104+VxWorks的無人機仿真系統(tǒng)設計、實現(xiàn)[D]. 西安：西北工業(yè)大學，2007.

[2]伍智峰. 分布式飛行仿真技術研究[D]. 西安：西北工業(yè)大學，2003.

[3]馮磊. 基于RTW的分布式實時仿真系統(tǒng)研究與實現(xiàn)[D]. 長沙：國防科技大學，2005 .

[4]向孝龍，陳欣,等. 基于RTW和VxWorks的無人機仿真系統(tǒng)設計與實現(xiàn)[J]. 計算機測量與控制，2014,22(4) :1291-1293

[5]張宏偉，王樹新,等. 基于CAN總線的自治水下機器人控制系統(tǒng)[J]. 機器人，2006, 28(4) :248-252

[6]鄭雷. 無人機余度飛行控制計算機設計及研究[D]. 南京：南京航空航天大學，2011.

[7]余偉，郭斌,等. 嵌入式多板卡協(xié)同工作及熱備份系統(tǒng)研究[J]. 信息安全與通信保密，2013，5:102-104

[8]米毅. 基于CAN總線的小型飛行控制系統(tǒng)硬件設計與實現(xiàn)[D]. 南京：南京航空航天大學，2009.

[9]羅峰，孫澤昌. 汽車CAN總線系統(tǒng)原理、設計與應用[M]. 北京：電子工業(yè)出版社，2011.

[10]張穎超，楊宇峰,等. 基于CAN總線的溫室監(jiān)測系統(tǒng)的通信設計[J]. 控制工程，2009, 16(1):103-106

[11]曹桂平,等. VxWorks設備驅動開發(fā)詳解[M]. 北京：電子工業(yè)出版社，2011.

Design of CAN Bus Scheduling and Registration Mechanism for UAV Simulation System

Jia Zhenyu , Li Chuntao , Li Yan

(College of Automation, Nanjing University of Aeronautics & Astronautics, Nanjing210016,China)

The UAV Simulation System has the characteristics of large amount of data and real-time requirements. The experimental platform is based on the hardware of a sample flight simulation system which communication is based on CAN bus. According to the characteristics of CAN bus, the mechanism of bus time scheduling and state detection is designed, which can guarantee the real-time performance of the communication, and provides a correct and effective verification platform for the simulation test. And as interfaces of traditional simulation system are fixed, it is not easy to be upgraded. The registration mechanism of interfaces is designed to improve flexibility of the system, which is easy to develop the simulation system.

CAN bus；flight simulation system；time scheduling；state detection；interface registration

2015-08-11；

2015-09-11。

賈振宇(1991-)，男，山東菏澤人，研究生，主要從事飛行器控制方向的研究。

李春濤(1975-)，男，山東臨沂人，副研究員，主要從事無人機飛行控制方向的研究。

1671-4598(2016)01-0171-04

10.16526/j.cnki.11-4762/tp.2016.01.048

TP273.5

A