艦載機飛行控制系統總線接口策略

楊絢，魏小勇，崔德龍

航空工業第一飛機設計研究院，西安 710089

由于艦載機空間布局緊湊，飛控系統機載設備可采用集中式的硬件架構方式，將各個飛控子系統集中布局，采用一個總線接口模塊端(BIM)板與多個控制與管理模塊端(CPM)板組合的方式實現對飛控系統計算機的架構。飛控總線接口設計是集中式飛控計算機的重要組成部分，負責外部設備與飛控計算機之間的數據傳輸，外部設備向飛控計算機輸入數據用于飛行控制律的計算，得到的控制指令通過總線接口發送至相應的控制器。飛控數據總線接口軟件用以實現外部傳感器數據、飛機控制數據等的傳輸和更新，這些數據與其他應用軟件，如余度管理、機內自檢、飛行管理、飛行控制律等軟件都有數據交聯。因此，為保證數據的完整性和可靠性，對飛控數據總線接口的策略研究是十分必要的。

近年來，許多學者開展了機載總線數據傳輸方面的研究。寧新建[1]討論了航空總線的總線特征、數據格式、通信過程控制、總線接口等；逯計劃[2]介紹了傳統總線和新一代總線技術的幾種典型技術，分析了其優勢和缺點；孟銳等[3]介紹了幾種常用的航空總線，并重點介紹了ARINC659總線；馬貴斌等[4]介紹、比較和分析了國內外現階段應用的幾種軍用數據總線的構架及其優缺點；ARINC659總線[5-6]具有容錯性、高可用性和高完整性的特點；張銳等[7]利用ARINC659 作為余度管理軟件中數據交叉傳輸的總線，以提高飛行控制計算機系統中的可靠性；張阿莉等[8]針對新型飛控采集器采集數據流數增多、試飛模式改變的問題，對原有飛行控制系統總線數據處理軟件進行優化設計，軟件有效解決了多流、多表號飛行控制系統總線數據處理問題；陳新華和支高飛[9]描述了利用通用采集系統板卡搭建模擬飛控數據測試系統，并通過開發模擬飛控信號隔離器實現了被試設備與采集器之間的交聯； Yedavallir等[10]指出數據傳輸中節點的瞬時故障、數據損壞、傳輸錯誤或編碼/解碼錯誤都可能會引起數據丟包；閆莉和王勇[11]采用電子設計自動化(EDA)方法，設計并實現了符合機載串行數字傳輸的某型飛機機載總線多通道模塊接口；邢達波等[12]對某型飛機網絡化架構中出現的數據丟包現象進行分析，通過對KAD/SWI/108進行重新軟件編程，消除了數據丟包現象；張毅和張勇[13]介紹了某型號飛機飛控系統試驗的數據采集處理系統軟件,包括數據采集、數據存儲、數據分析及事后處理；靳鴻等[14]針對機載數據記錄儀總線通訊存在數據傳輸不穩定、數據失真等問題，提出一種1553B總線接口設計與實現方法，并進行了1553B總線接口硬件設計，使記錄儀能夠完整、準確地接收和響應消息數據；劉明等[15]設計了一種數字飛控采集器，符合機載環境要求；李聲飛[16]為提高數據傳輸可靠性，提出一種適用于機載平臺的總線接口，有效降低了通信誤碼率，提高了數據傳輸的可靠性和魯棒性；付莉和趙民[17]設計了一種數據通信系統實現無人機系統的飛行操縱和機載任務設備控制；宋軍強等[18]考慮航空發動機分布式控制系統中丟包問題，提出增益重構補償策略，保證了存在數據丟包的發動機分布式控制系統的性能和穩定性。劉語喬等[19]為了解決RS422總線數據處理問題，基于某飛機平臺，研究了總線數據處理各個環節的關鍵技術問題；王凱等[20]針對機載航空設備通信特點，介紹了一種可配置的多通道通信軟件設計，提供了簡單的接口層以便應用軟件開發，易于擴展和部署。

外部設備發送數據至串行通信設備，串行通信設備每個周期將接收的數據寫入到BIM端，并采用ARINC659總線進行BIM端到CPM端的數據更新，然后飛控軟件在CPM端讀取數據并解析。由于外部設備、串行通信設備、ARINC659總線、飛控軟件等的運行頻率各有差異，會導致數據包不完整甚至丟失的現象，本文針對數據接口的讀/寫沖突問題進行研究，分析不同原因導致的不同實驗現象，并提出相應的解決方案。

1 接口數據傳輸原理

圖1所示為飛控軟件數據輸入接口原理圖，外部設備(如慣性測量組件、作動器控制器、組合導航、差分衛星接收機等)以不同的頻率(200、100、50、25 Hz等)發送數據，對應的串行通信設備以字符或塊為單位每5 ms接收并處理外部設備輸入的數據，每20 ms將接收到的外部數據發送到659數據交換區BIM端輸入數據區，659背板總線每2.5 ms完成BIM端輸入數據區到CPM端輸入數據區的數據更新，最后由通用處理模塊(軟件)每20 ms將CPM端輸入數據區的數據接收并處理，隨后經過余度表決、數據處理等模塊，進入到飛行控制律模塊。

圖1 數據輸入接口原理圖Fig.1 Schematic diagram of data input interface

飛行控制與管理接口軟件具有如下特點：

1) 外部設備的數據刷新頻率不同。

2) 串行通信設備都以5 ms為周期接收數據，并以20 ms為周期將數據發送至659背板總線的BIM端。

3) 采用659背板總線進行BIM端到CPM端的數據交換，2.5 ms進行一次，刷新速率快。

4) 通用處理模塊以20 ms為周期處理CPM端的數據。

以慣性測量組件的輸入為例，如圖2所示，慣性測量組件設備的發送頻率為200 Hz，即5 ms發送一次，串行通信設備每5 ms接收一次，放入緩沖區，每20 ms接收約4個數據包，將其發送至ARINC659總線的BIM數據存儲區，通過659背板總線將BIM數據存儲區的數據更新至CPM端規定的存儲區內，然后通用處理軟件即可對CPM端存儲區內的數據進行采集并處理。

圖2 慣性測量組件數據輸入原理Fig.2 Principle of data input for inertial measurement components

在時鐘完全匹配的情況下，如圖3所示，在一個20 ms任務中，串行通信設備在t0時刻將輸入數據寫入BIM數據區，通用處理模塊在t1時刻從CPM數據區讀取數據，數據寫入和讀取的速率能夠完全匹配。在每個周期任務里，飛控軟件都能夠獲取設備的最新數據，用于之后的控制律計算。

串行通信設備每20 ms將數據發送到BIM輸入數據區，而CPM也是每20 ms處理CPM輸入數據區的數據，659背板總線進行BIM到CPM的數據傳輸時間相對于串行通信設備和CPM周期運行時間很短，可忽略其影響。串行通信設備發送數據周期和CPM端的運行周期一致，但是兩個設備采用各自的時鐘，可能會出現時鐘周期長短不一致或者時鐘漂移，引起數據讀/寫沖突，實驗證明會出現丟失數據包的現象，因此軟件運行所處理的數據的時效性和完整性得不到保證，這對實時性要求高的飛控系統來說是不能接受的；另一方面，對于數據更新較慢的外設而言，通用處理軟件因無法判斷存儲區中數據的是否被更新，可能會重復解析內存中的數據，對上述2種實驗現象，進行分析并給出解決方案。

圖3 數據讀/寫時序圖Fig.3 Sequence diagram of data read/write

2 研究內容

針對飛控系統數據不完整傳輸和數據重復解析兩類問題展開研究。

2.1 數據包設計

不同的外設數據刷新的頻率不一樣，慣性測量組件5 ms刷新一次，串行通信設備每20 ms將采集的數據發送至BIM端，通用處理模塊(軟件)在CPM端采集到的數據總是更新的數據包；而數據鏈通信每40 ms刷新一次數據，通用處理模塊(軟件)依然是每20 ms訪問一次CPM端的數據區，如圖4所示，這樣會使得軟件將CPM端數據鏈存儲區的數據處理兩次，這無疑浪費了軟件的運行時間。

理想情況是在寫入BIM數據區的時鐘和讀取CPM數據區的時鐘完全同步的前提下，工程實踐中可能會出現時鐘偏差，如圖5所示，“寫入”和“讀取”的時鐘偏差為Δt，在試驗時發現數據區會出現未更新完全的情況，即在“寫入”未完時，進行“讀取”，導致數據包中前半部分數據為更新的數據，后半部分數據為前一拍處理過的未更新的數據。但是通用處理模塊(軟件)并不能夠識別數據包是否為全新狀態，只要存儲區中有數據，軟件就會對其進行處理。

為避免上述讀寫同時進行和對數據包重復解析的問題，在串行通信設備將數據包寫入BIM數據區時，在數據包的末端增加數據包編號，以判斷數據區中的數據包是否為完全更新的數據包。此外，為明確數據包中有效數據的長度，在數據包前增加了兩個字節存放“數據長度”變量。如圖6虛線框中所示，為優化之后的BIM端/CPM端數據存儲區的格式。

圖4 數據鏈數據寫入/讀取時序圖Fig.4 Sequence diagram of DTL read/write

圖5 數據讀取/寫入沖突Fig.5 Conflict of data read/write

以慣性測量組件為例，如圖6所示，慣性測量組件設備每5 ms更新一次數據，每個數據包為25個字節，串行通信設備每20 ms接收4個數據包，即100個字節，發送至BIM端，在數據存儲區預留120個字節(每個接口通道的數據區都做相應的預留)作為每個周期的包數據存儲，包數據之前的2個字節存放本包數據的有效長度(不大于120個字節)，包數據之后的4個字節存放包編號。每次數據寫入時，包編號加1，從0x00000000→(+1)0x00000001→…(long long later)…→0xFFFFFFFF循環計數。軟件在運行時，識別到包編號大于上拍處理過的數據包的包編號，就對本包數據進行處理，否則，不進行處理，這樣就避免了對數據更新不完整的數據包進行處理或者對處理過的數據包進行二次處理。

圖6 BIM端/CPM端數據存儲區格式Fig.6 Format of data storage in BIM/CPM

2.2 時鐘偏差解決方法

BIM端數據存儲區每20 ms會被刷新一次，CPM處理軟件每20 ms會讀取數據存儲區的數據并進行處理。實際上，兩個不同的時鐘下，同樣的20 ms周期可能會略有偏差，寫入BIM端的時鐘可能比讀取CPM端數據的時鐘快，也可能會慢。

1) 當CPM端的時鐘略快時，如圖7(a)所示，在t0時，向BIM端寫入數據；在t1時，通用處理軟件在CPM端讀取數據；t2時刻，再次在CPM端讀取數據，但是此時數據區并未更新，會出現重復讀取的現象。由于在2.1節中引入了包編號，所以可以通過包編號的大小來判斷是否為更新的數據包，以決定是否需要處理數據。

2) 當BIM端寫入數據的時鐘略快時，會出現向BIM端寫入兩次數據包時，CPM端的數據才被處理一次。如圖7(b)所示，t0時刻在CPM端“讀取”，t1時刻在BIM端寫入數據，由于兩個20 ms之間有偏差，t2時刻又一次在BIM端寫入數據，導致上一包數據未經處理就被覆蓋，t3時刻在CPM端讀取數據時，已經丟失了t1時刻寫入的數據，所以在BIM端設置一個數據存儲區是不能夠保證數據的完整性和時效性的，因此在ARINC659總線BIM端和CPM端分別設置2個相同的數據存儲區，如圖8所示。將t1時刻和t2時刻的兩包數據分別寫入兩個存儲區，t3時刻，在CPM端讀取時，一個周期任務內對兩包數據進行解析，這樣就避免了因時鐘偏差引起的數據丟包現象。

圖7 時鐘大小偏差讀寫時序圖Fig.7 Read and write sequences determined by clock values

圖8 BIM端/CPM端數據存儲區Fig.8 Data storage in BIM/CPM

2.3 數據發送異常解決方法

上述情況都是在串口通信設備發送數據包完整時討論的，即每次從ARINC659總線CPM端讀取的數據都是完整的數據包。以慣性測量組件為例，串行通信設備每20 ms接收4個數據包即100個字節的數據，將其發送至BIM端，在CPM端讀取的數據包也為100個字節。但是在實驗中監控包編號，仍會偶爾出現丟失數據包的現象，這是因為未考慮數據傳輸過程數據包是否完整，如圖9所示，具體分析如下：

1) 外部設備傳輸數據以字符為單位一個字節一個字節的發送數據，或者是以數據塊為單位發送數據，由于時鐘偏差的存在使得不能在20 ms 內準確地發送理論長度的字節數。

2) 串行通信設備每20 ms將接收的數據包發送至BIM端，而當一個新的20 ms周期到達時，設備數據區的數據長度可能會大于或者小于理論數據長度(如慣性測量組件應發送100個字節)。

3) 向ARINC659總線BIM端寫入數據是需要一定時間的，通過ARINC659總線向CPM端傳輸數據也是需要時間的(2.5 ms)。

4) 外部設備、串行通信設備、ARINC659總線、軟件周期任務所遵循的為不同的時鐘，不可避免的會有偏差。

綜合上述幾種情況，認為每20 ms運行周期任務在CPM端讀取數據時，CPM端數據區中的數據包可能會小于理論長度，是不完整的數據包。

以慣性測量組件為例，如圖10所示，假設當20 ms到達時，串行通信設備中只接收到60個字節的數據，將這些數據打包發送至BIM端數據存儲區A1，下一個20 ms到達時，串行通信設備除接收到另一包完整數據之外，還接收到上一包的余留數據，有140個字節，而數據包最大長度只有120個字節，分兩個數據包發送，將前120個字節打包發送至數據區A2，剩余20個字節打包發送至數據區A1，此時在如圖7(b)所示的情況下，即在CPM端未來得及讀取數據區A1中的數據時，數據區A1已經被新的數據包所覆蓋，故而兩個數據存儲區仍然不能夠滿足工程需求，為此，最終將BIM端和CPM端的數據存儲區都設置為3個，如圖11所示，采用3個數據存儲區可以避免上述數據區被覆蓋造成的數據丟失現象。

此外，通用處理軟件還需對3個數據區的讀取隊列進行設計。每周期對CPM端數據區的3個包進行掃描，如果包編號大于上周期解析的數據包包編號，將本包數據拷貝至全局數組，因此每個周期最多的情況是將3包數據均拷貝至全局數組，最少的情況是沒有一包為新的數據包。之后，根據全局數組中存儲的數據包個數以及每個數據包的包編號，判斷數據包的先后到達順序，隨后數據解析。

圖9 數據傳輸過程Fig.9 Process of data transfer

圖10 BIM端/CPM端數據區覆蓋Fig.10 Data overwriting in BIM/CPM

圖11 BIM端/CPM端數據區設計Fig.11 Design of data storage in BIM/CPM

2.4 數據寫入/讀出過程的實現

綜上所述，對飛控軟件接口數據讀/寫的沖突分2種情況：① 時鐘偏差引起的寫入速度小于讀取速度；② 時鐘偏差或數據發送不完整引起的寫入速度大于讀取速度。綜合考慮不同情況下的解決方案，分析得到寫入/讀出的過程。接口數據寫入BIM端的流程如圖12所示，每個周期任務內將CPM端數據讀取至軟件中所定義的存儲區即可進行解析，讀取數據的流程如圖13所示。

圖12 接口數據寫入BIM端流程Fig.12 Procedure of writing data from interface to BIM

通過在某型艦載機飛控軟件接口數據處理模塊中試驗，并在試驗中監控，證明采用上述方法沒有發生丟包現象和重復解析。表明此方法能夠有效解決數據包不完整和數據重復解析的問題。

圖13 讀取CPM端數據流程Fig.13 Procedure of reading data from CPM

2.5 空間和時間開銷分析

通過上述2種方法來解決總線數據的時效性和完整性：① 重新設計數據包格式，增加數據包長度和數據包編號信息；② 是增加數據存儲區空間，將1個存儲區變成3個存儲區。這樣無疑增加了空間和時間的開銷。

1) 空間開銷

增加數據存儲區的方案使得飛控計算機與外設通信的每個通道的存儲空間都會增加，一方面在659總線的BIM端和CPM端都需要增加2個數據包的存儲空間，另一方面在解析數據包時也需要增加2個數據包的全局占用空間。這些都會增加軟件的空間開銷，但是這些空間開銷能夠滿足艦載機飛控系統的空間總要求，是一種以犧牲空間來保證數據完整性的方法。

2) 時間開銷

增加數據存儲區的解決方案，使得軟件在每個周期內會增加對數據存儲區的包編號的掃描過程以及對數據包的先后順序的判斷過程，但是最終解析數據也僅解析最新一包數據。在一般情況下，數據包發送的時間頻率與通用軟件解析的時間頻率基本保持一致，每一個周期只會掃描到一包有效數據進行解析；在數據包發送阻塞的情況下，可能會導致一個周期收到2包甚至3包有效數據，此時需要對數據包的先后順序進行判斷，從而得到最新的有效數據；另一方面，重新設計數據包格式，增加數據包編號，在有些周期沒有新的數據包到達的情況下，省去對數據的重復解析，也能夠節省一定的時間開銷。所以，對于時間開銷的增加更多的是在數據包發送阻塞時造成的，但是增加的開銷時間也極短暫，對于以20 ms為周期的飛控實時系統也是能夠滿足的，是一種以犧牲時間保證數據時效性和完整性的解決方法。

3 結 論

1) 在數據寫入速度大于讀取速度的情況下，設計了數據緩沖方案，實際應用中監測數據包的幀計數，有效解決了艦載機飛控系統數據傳輸過程中各種因素導致的數據包丟失問題。

2) 在數據寫入速度小于讀取速度的情況下，給出了包編號的判斷方法，有效避免軟件中數據重復解析、浪費運行時間的問題，上述方法可以作為機載軟件工程師在飛控軟件接口實際應用中的參考。

3) 數據存儲區的設計，增加了空間的開銷，數據包格式的設計和數據存儲區的設計，一方面在無新數據包的周期能夠節省時間開銷，在同時有2～3個數據包到達的周期又會增加時間開銷，但是艦載機飛控系統的硬件存儲和軟件周期能夠允許這樣的空間開銷和時間開銷，以一定的時間和空間犧牲來保證數據的時效性和完整性。

4) 對于飛控軟件的接口，可以進一步將接口軟件做到模塊化和通用化，提高接口軟件在不同型號飛機上的可移植性。