梁白鷗

(中國西南電子技術研究所，成都 610036)

IO服務在綜合化航空電子系統(tǒng)中的應用

梁白鷗

(中國西南電子技術研究所，成都 610036)

為了隔離應用程序與航空總線驅(qū)動程序的關聯(lián)，提高應用程序的可移植性，實現(xiàn)了跨平臺、通用、異步、松耦合、一對多的IO服務。IO服務通過總線插件技術、總線通道的反射創(chuàng)建技術、XML配置技術，實現(xiàn)了IO服務的通用化。通過訂購發(fā)布機制實現(xiàn)了總線通道與使用者之間的松耦合和一對多的關系，同時訂購數(shù)據(jù)轉(zhuǎn)發(fā)引入了組播技術，使得一對多的數(shù)據(jù)轉(zhuǎn)發(fā)效率得到提升。在實際綜合化航空電子系統(tǒng)中，IO服務與ICE中間件相結(jié)合，增加了軟件架構(gòu)設計的靈活性，提高了軟件的移植性，降低了軟件復雜度和調(diào)試難度。

IO服務；訂購發(fā)布；C++反射創(chuàng)建；FACE；ICE；插件技術

引 言

在綜合化航空電子系統(tǒng)[1]中，存在著大量不同種類的航空總線，如1553總線、RS485、RapidIO、離散線、CAN總線、Arinc429總線等，這些總線通常有與硬件關聯(lián)關系非常強、所在硬件運行的操作系統(tǒng)固定、所在硬件資源少等特點。以上問題導致在軟件設計、編碼和后期聯(lián)試時常常遇到以下問題：

① 由于總線與硬件關系密切，使得軟件部署位置固定，限制了軟件架構(gòu)的設計；

② 由于總線所在硬件運行的操作系統(tǒng)固定(常常為VxWroks、ReWorks)，使得軟件必須運行在對應的操作系統(tǒng)上，后期的調(diào)試和開發(fā)難度加大；

③ 由于所在硬件資源少，使得軟件開發(fā)人員常常為了搶占某些硬件資源而煩惱。

然而隨著航空系統(tǒng)的綜合化，軟件的復雜程度越來越高，上述問題愈加凸顯。為了解決這些問題，在借鑒FACE[2](Future Airborne Capability Environment)技術的基礎上，設計了基于訂購發(fā)布機制[3]的IO服務軟件框架，該框架支持二次開發(fā)，同時引入插件機制[4]、C++反射創(chuàng)建技術[5]、XML配置技術，使得IO服務軟件框架不依賴具體的總線類別,最終實現(xiàn)了一套跨平臺、通用、異步、松耦合的IO服務。

1 IO服務的設計

1.1 IO服務的定位

IO服務通過訂購發(fā)布消息機制，為應用程序訪問硬件提供了一種標準化接口，隔離了應用程序與航空總線驅(qū)動程序的關聯(lián)。IO服務主要用于低速總線的訪問，對于高速總線，IO服務可能會存在瓶頸。在一個系統(tǒng)中,IO服務可以存在多份。IO服務在系統(tǒng)中與設備和硬件之間的關系如圖1所示。

圖1 IO服務的外部連接關系

1.2 IO服務的層次模型

為了實現(xiàn)跨平臺,具有通用性和可擴展性，IO服務設計初衷為：

① 能在不同操作系統(tǒng)(Windows、Linux、VxWorks、ReWorks)上運行；

② 能適配不同的總線，IO服務框架本身不依賴任何總線所使用的外部庫；

③ IO服務既能作為軟件框架提供二次開發(fā)，又能提供編譯好的可執(zhí)行程序直接運行。如在Windows和Linux上，總線作為插件嵌入到已編譯好的可執(zhí)行程序中運行；在VxWorks和ReWorks上，應用程序使用IO服務框架進行二次開發(fā)；

采用訂購發(fā)布機制達到各個通信實體之間異步、松耦合、一對多的關系。

為了達到以上設計目的，最終將IO服務設計為如圖2所示的層次模型。

圖2 IO服務層次模型

圖4 總線插件的邏輯結(jié)構(gòu)

① 跨平臺封裝層實現(xiàn)對各個操作系統(tǒng)API的封裝，對上提供統(tǒng)一的接口；

② 通信封裝層實現(xiàn)了對各個總線API的簡單封裝；

③ 通道服務框架實現(xiàn)了對上提供訪問各個通信總線的統(tǒng)一接口；

④ 總線插件則是在通道服務框架基礎之上實現(xiàn)各個總線統(tǒng)一的訪問接口，便于IO服務動態(tài)加載；

⑤ 訂購通道主要封裝了訂購端的一些網(wǎng)絡操作；

⑥ IO服務框架則實現(xiàn)了動態(tài)加載各個總線插件，并將其轉(zhuǎn)換為發(fā)布者，處理訂購，取消訂購的消息，協(xié)商數(shù)據(jù)轉(zhuǎn)發(fā)的IP和端口、轉(zhuǎn)發(fā)數(shù)據(jù)等功能；

⑦ IO服務應用程序則是Windows和Linux上可運行的軟件，可通過XML配置文件來配置IO服務。

1.3 總線插件的設計

航空總線類型繁多，且同一總線的硬件廠商、型號也不盡相同，因此給上層軟件開發(fā)人員提供的SDK開發(fā)包、驅(qū)動也都不一樣，要將IO服務做到通用化，必須將總線插件化。

總線在物理存儲上被定義為一個插件,在Windows操作系統(tǒng)上為dll文件，在Linux操作系統(tǒng)上為so文件。IO服務軟件在啟動時，動態(tài)加載不同總線的插件，使得IO服務框架不具體依賴某一類型的總線開發(fā)包，如圖3所示。

圖3 總線插件的物理結(jié)構(gòu)

總線在邏輯上被抽象為通道(Channel)。IO服務框架提供CChannel接口類，不同總線繼承該基類，并實現(xiàn)其中的Open、Close、SendData接口，同時框架提供了CChannelUser類，該類作為CChannel的觀察者，將總線收到的數(shù)據(jù)、發(fā)送的數(shù)據(jù)以及總線產(chǎn)生的事件信息通知到上層使用者?？偩€插件的邏輯架構(gòu)如圖4所示。

1.4 總線通道的反射創(chuàng)建

在上述的總線邏輯結(jié)構(gòu)中，如何通用化地創(chuàng)建各個通道的對象，成了IO服務通用化的關鍵技術之一。常規(guī)的方法是通過多條if-else語句顯示創(chuàng)建的各個總線對象，但這樣一來，IO服務就顯式地依賴各個總線的實現(xiàn)。為了解決該問題，采用了C++反射技術，即通過字符串的方式，動態(tài)創(chuàng)建C++對象。

具體實現(xiàn)方式為，總線插件在加載到IO服務的內(nèi)存空間中后，每個dll將總線通道的元對象信息[6](反射類的類名、類型信息以該類的創(chuàng)建對象接口)自動注冊到一個元對象管理器中。創(chuàng)建總線通道對象時，根據(jù)類名或別名，在元對象管理器中找到總線通道的創(chuàng)建對象接口，通過創(chuàng)建對象的接口創(chuàng)建總線通道對象指針，具體流程如圖5所示。

圖5 總線通道的反射創(chuàng)建流程

在反射創(chuàng)建技術基礎之上，IO服務框架實現(xiàn)了根據(jù)XML來配置各個總線通道，配置的內(nèi)容包括總線所需的輸入信息、總線通道的類型信息等。最終實現(xiàn)了根據(jù)XML自動創(chuàng)建各個總線通道，從根本上達到了IO服務軟件與具體總線插件分離的目的。

1.5 訂購發(fā)布機制

總線通道創(chuàng)建成功之后，如何將通道的數(shù)據(jù)轉(zhuǎn)發(fā)給用戶，以及用戶的數(shù)據(jù)轉(zhuǎn)發(fā)給總線通道，成為IO服務通用化的另外一個關鍵技術。在實際情況中,總線通道的數(shù)據(jù)很有可能被多個使用者使用，因此總線通道數(shù)據(jù)和使用者是一對多的關系。為了解決該問題，IO服務框架采用了訂購發(fā)布機制。

訂購發(fā)布機制是面向數(shù)據(jù)的應用架構(gòu)，其最大的優(yōu)點就是通信實體之間是一種異步的松耦合關系，并且發(fā)布者與訂購者是一對多的關系。因此IO服務框架中將總線通道作為發(fā)布者，使用者作為訂購者，實現(xiàn)了總線通道與使用者的一對多的松耦合關系，如圖6所示。

圖6 總線通道發(fā)布者與訂購者之間的關系

另外一個問題是，當有多個訂購者訂購同一總線通道后，當總線通道收到數(shù)據(jù)轉(zhuǎn)發(fā)給使用者時，如果數(shù)據(jù)量大且頻率高時，很有可能轉(zhuǎn)發(fā)將是一個瓶頸。為了解決該問題，采用了組播技術，即訂購同一總線通道的訂購者，可以選擇是否使用組播的方式接收數(shù)據(jù)，這樣總線通道在轉(zhuǎn)發(fā)時，發(fā)送函數(shù)只需要調(diào)用一次，大大提高了轉(zhuǎn)發(fā)效率，因此可以形成圖7所示的結(jié)構(gòu)。

圖7 引入組播接收后的結(jié)構(gòu)

在IO服務的設計中，訂購者與總線通道發(fā)布者都有一個全局唯一的名字，它們之間通過組播方式進行訂購/取消通信，通過名字來識別不同的通信實體，該方式簡化了各個通信實體之間的配置，通過組播來協(xié)商后續(xù)真實數(shù)據(jù)通信的IP地址和端口。訂購者發(fā)送的訂購消息中包含了以下信息：

① 訂購方式：點播訂購、組播訂購。

② 訂購者的數(shù)據(jù)傳輸IP地址：如果訂購者未填寫IP地址，則IO服務默認使用UDP協(xié)議的源IP地址作為訂購者的IP地址，并通過訂購ACK消息發(fā)送給訂購者。

③ 訂購者的數(shù)據(jù)傳輸端口：如果訂購者未填寫端口號，則由IO服務自動分配一個未使用的端口，通過訂購ACK消息發(fā)送給訂購者。

④ 訂購總線通道的類型：如1553、Arinc429、RapidIO、CAN、RS485等。

訂購者在收到訂購ACK消息后，如果能夠成功，則根據(jù)回傳的IP地址、端口號創(chuàng)建數(shù)據(jù)轉(zhuǎn)發(fā)點對點的UDP，通過該UDP發(fā)送接收實際傳輸?shù)臄?shù)據(jù)。

同時IO服務與訂購者之間通過心跳機制，來互相監(jiān)測對方是否在線，當IO服務發(fā)現(xiàn)訂購者不在線時，刪除訂購者相關信息；當訂購者發(fā)現(xiàn)IO服務不在線時，則周期重新訂購，直到訂購成功。

1.6 總線數(shù)據(jù)的額外信息

總線在邏輯上可被抽象為多個總線通道，比如1553總線就可以抽象為一個RT地址對應一個總線通道。這樣便于訂購者使用轉(zhuǎn)發(fā)過來的數(shù)據(jù)。但1553數(shù)據(jù)中不同消息塊是通過子地址來區(qū)分的，因此直接將數(shù)據(jù)轉(zhuǎn)發(fā)，在訂購端并不能區(qū)分接收到的消息類型。因此需要將總線的一些額外信息附加到真實的轉(zhuǎn)發(fā)數(shù)據(jù)之前,如1553總線的額外信息就包括RT地址和子地址信息。

不同總線的額外信息可能不同，因此總線的額外信息是一個變長的數(shù)據(jù)，打包和解析時通過總線類型進行區(qū)分，數(shù)據(jù)消息格式設計如下所示：

消息方向(IB)總線類型(IB)總線額外信息(變長)真實數(shù)據(jù)內(nèi)容(變長)

2 IO服務的應用

在一個綜合化航空電子系統(tǒng)項目中，由于被控設備眾多，總線種類也非常多，同時軟件配置項也非常多，因此引入了IO服務，使得軟件與硬件總線隔離，IO服務運行在國產(chǎn)實時操作系統(tǒng)ReWorks5.1上。在此基礎上，軟件架構(gòu)采用了ICE分布式中間件技術[7]，通過一個設備代理的軟件，將訂購的總線數(shù)據(jù)與ICE通信數(shù)據(jù)進行轉(zhuǎn)換，使得上層應用軟件完全看不到具體的硬件，應用軟件在ICE軟總線上運行。軟件的基本結(jié)構(gòu)如圖8所示。

圖8 IO服務的應用結(jié)構(gòu)

在引入了IO服務之后，使得開發(fā)人員更加關注軟件的邏輯功能，使得很復雜的軟件處理邏輯能在Windows上進行調(diào)試運行，大大提高了軟件開發(fā)效率，降低了調(diào)試難度。同時在引入ICE中間件技術后，使得應用軟件可以充分利用ICE提供的遠程對象調(diào)用、AMI、AMD、IceStorm、FreezeMap等技術與服務[8]，大大降低了軟件之間交互的復雜度，減少了大量重復代碼。

結(jié) 語

IO服務使得各類航空總線與業(yè)務處理相對隔離，提高了業(yè)務處理的可移植性，通過基于訂購發(fā)布消息機制，為應用程序訪問硬件提供了一種標準化接口，隔離了其與特定硬件驅(qū)動程序和操作系統(tǒng)設備驅(qū)動程序的關聯(lián)。

IO服務在采用總線插件化、總線通道反射創(chuàng)建技術以及XML配置技術后，使得IO服務更加通用獨立,可以復用于不同的項目中。采用訂購發(fā)布機制，進一步降低了使用者和總線通道的關聯(lián)關系，引入了數(shù)據(jù)轉(zhuǎn)發(fā)的組播機制，提高了數(shù)據(jù)轉(zhuǎn)發(fā)的性能。

正因為上述特性，使得軟件架構(gòu)的設計更加靈活，在實際的綜合化航空電子系統(tǒng)項目中，將 ICE中間件技術和IO服務相結(jié)合，使得軟件開發(fā)效率大大提高，軟件部署更加靈活多變，軟件可移植性更強，降低了軟件的復雜度和調(diào)試難度。

[1] 張鳳鳴,褚文奎,樊曉光，等.綜合化模塊化航空電子體系結(jié)構(gòu)研究[J].電光與控制,2009,16(9);47-51.

[2] The Open Group.Snapshot Future Airborne Capability Environment (FACE) Reference Architecture,2011.

[3] 布施曼.面向模式的軟件架構(gòu),卷1:模式系統(tǒng)[M].袁國忠,譯.北京:人民郵電出版社,2013.

[4] 陳方明,陳奇.基于插件思想的可重用軟件設計與實現(xiàn)[J].計算機工程與設計,2005,26(1):172-176.

[5] Fabio Kon,Fabio Costa,Gordon Blair,et al.The Case for Reflective Middleware[J].Communications of ACM,2002,45(6):33-38.

[6] Wang Minyi,Yao Shaowen,Zhou Mingtian.Reflective object-oriented middleware research on theories and methods[J].Computer Science,2001,28(4):78-79.

[7] 王博.Ice中間件關鍵技術研究與實現(xiàn)[D].西安:西安電子科技大學,2006.

[8] Henning M,Spruiell M.Distributed programming with ICE[EB/OL].[2016-12].www.zero.com.

梁白鷗(高級工程師)，主要研究方向為航空電子、通信系統(tǒng)軟件架構(gòu)、中間件技術等。

Implementation of IO Service in Integrated Avionics System

Liang Baiou

(Southwest China Institute of Electronic Technology,Chengdu 610036,China)

In order to isolate the correlation between the application and the aviation bus driver,a cross-platform,general,asynchronous,loosely-coupled,one-to-many IO service is proposed.The general of IO Service is implemented by the bus plugin technology,the bus channel reflective create technology and the XML configuration technology.The asynchronous and loosely-coupled of IO service are implemented by the subscriber-publisher technology.At the same time,the multicast technology is introduced,which makes the one-to-many data transmit efficiency improved.The IO service is combined with the ICE middleware technology in integrated avionics system,which increases the flexibility of software architecture design,improves the software portability,and reduces the software complexity and difficulty of software debugging.

IO service;subscriber-publisher;C++ reflective create;FACE;ICE;plugin technology

TN802

A

士然

2016-12-01)