IO服务在综合化航空电子系统中的应用

梁白鸥

(中国西南电子技术研究所，成都 610036)

IO服务在综合化航空电子系统中的应用

梁白鸥

(中国西南电子技术研究所，成都 610036)

为了隔离应用程序与航空总线驱动程序的关联，提高应用程序的可移植性，实现了跨平台、通用、异步、松耦合、一对多的IO服务。IO服务通过总线插件技术、总线通道的反射创建技术、XML配置技术，实现了IO服务的通用化。通过订购发布机制实现了总线通道与使用者之间的松耦合和一对多的关系，同时订购数据转发引入了组播技术，使得一对多的数据转发效率得到提升。在实际综合化航空电子系统中，IO服务与ICE中间件相结合，增加了软件架构设计的灵活性，提高了软件的移植性，降低了软件复杂度和调试难度。

IO服务；订购发布；C++反射创建；FACE；ICE；插件技术

引 言

在综合化航空电子系统[1]中，存在着大量不同种类的航空总线，如1553总线、RS485、RapidIO、离散线、CAN总线、Arinc429总线等，这些总线通常有与硬件关联关系非常强、所在硬件运行的操作系统固定、所在硬件资源少等特点。以上问题导致在软件设计、编码和后期联试时常常遇到以下问题：

① 由于总线与硬件关系密切，使得软件部署位置固定，限制了软件架构的设计；

② 由于总线所在硬件运行的操作系统固定(常常为VxWroks、ReWorks)，使得软件必须运行在对应的操作系统上，后期的调试和开发难度加大；

③ 由于所在硬件资源少，使得软件开发人员常常为了抢占某些硬件资源而烦恼。

然而随着航空系统的综合化，软件的复杂程度越来越高，上述问题愈加凸显。为了解决这些问题，在借鉴FACE[2](Future Airborne Capability Environment)技术的基础上，设计了基于订购发布机制[3]的IO服务软件框架，该框架支持二次开发，同时引入插件机制[4]、C++反射创建技术[5]、XML配置技术，使得IO服务软件框架不依赖具体的总线类别,最终实现了一套跨平台、通用、异步、松耦合的IO服务。

1 IO服务的设计

1.1 IO服务的定位

IO服务通过订购发布消息机制，为应用程序访问硬件提供了一种标准化接口，隔离了应用程序与航空总线驱动程序的关联。IO服务主要用于低速总线的访问，对于高速总线，IO服务可能会存在瓶颈。在一个系统中,IO服务可以存在多份。IO服务在系统中与设备和硬件之间的关系如图1所示。

图1 IO服务的外部连接关系

1.2 IO服务的层次模型

为了实现跨平台,具有通用性和可扩展性，IO服务设计初衷为：

① 能在不同操作系统(Windows、Linux、VxWorks、ReWorks)上运行；

② 能适配不同的总线，IO服务框架本身不依赖任何总线所使用的外部库；

③ IO服务既能作为软件框架提供二次开发，又能提供编译好的可执行程序直接运行。如在Windows和Linux上，总线作为插件嵌入到已编译好的可执行程序中运行；在VxWorks和ReWorks上，应用程序使用IO服务框架进行二次开发；

采用订购发布机制达到各个通信实体之间异步、松耦合、一对多的关系。

为了达到以上设计目的，最终将IO服务设计为如图2所示的层次模型。

图2 IO服务层次模型

图4 总线插件的逻辑结构

① 跨平台封装层实现对各个操作系统API的封装，对上提供统一的接口；

② 通信封装层实现了对各个总线API的简单封装；

③ 通道服务框架实现了对上提供访问各个通信总线的统一接口；

④ 总线插件则是在通道服务框架基础之上实现各个总线统一的访问接口，便于IO服务动态加载；

⑤ 订购通道主要封装了订购端的一些网络操作；

⑥ IO服务框架则实现了动态加载各个总线插件，并将其转换为发布者，处理订购，取消订购的消息，协商数据转发的IP和端口、转发数据等功能；

⑦ IO服务应用程序则是Windows和Linux上可运行的软件，可通过XML配置文件来配置IO服务。

1.3 总线插件的设计

航空总线类型繁多，且同一总线的硬件厂商、型号也不尽相同，因此给上层软件开发人员提供的SDK开发包、驱动也都不一样，要将IO服务做到通用化，必须将总线插件化。

总线在物理存储上被定义为一个插件,在Windows操作系统上为dll文件，在Linux操作系统上为so文件。IO服务软件在启动时，动态加载不同总线的插件，使得IO服务框架不具体依赖某一类型的总线开发包，如图3所示。

图3 总线插件的物理结构

总线在逻辑上被抽象为通道(Channel)。IO服务框架提供CChannel接口类，不同总线继承该基类，并实现其中的Open、Close、SendData接口，同时框架提供了CChannelUser类，该类作为CChannel的观察者，将总线收到的数据、发送的数据以及总线产生的事件信息通知到上层使用者。总线插件的逻辑架构如图4所示。

1.4 总线通道的反射创建

在上述的总线逻辑结构中，如何通用化地创建各个通道的对象，成了IO服务通用化的关键技术之一。常规的方法是通过多条if-else语句显示创建的各个总线对象，但这样一来，IO服务就显式地依赖各个总线的实现。为了解决该问题，采用了C++反射技术，即通过字符串的方式，动态创建C++对象。

具体实现方式为，总线插件在加载到IO服务的内存空间中后，每个dll将总线通道的元对象信息[6](反射类的类名、类型信息以该类的创建对象接口)自动注册到一个元对象管理器中。创建总线通道对象时，根据类名或别名，在元对象管理器中找到总线通道的创建对象接口，通过创建对象的接口创建总线通道对象指针，具体流程如图5所示。

图5 总线通道的反射创建流程

在反射创建技术基础之上，IO服务框架实现了根据XML来配置各个总线通道，配置的内容包括总线所需的输入信息、总线通道的类型信息等。最终实现了根据XML自动创建各个总线通道，从根本上达到了IO服务软件与具体总线插件分离的目的。

1.5 订购发布机制

总线通道创建成功之后，如何将通道的数据转发给用户，以及用户的数据转发给总线通道，成为IO服务通用化的另外一个关键技术。在实际情况中,总线通道的数据很有可能被多个使用者使用，因此总线通道数据和使用者是一对多的关系。为了解决该问题，IO服务框架采用了订购发布机制。

订购发布机制是面向数据的应用架构，其最大的优点就是通信实体之间是一种异步的松耦合关系，并且发布者与订购者是一对多的关系。因此IO服务框架中将总线通道作为发布者，使用者作为订购者，实现了总线通道与使用者的一对多的松耦合关系，如图6所示。

图6 总线通道发布者与订购者之间的关系

另外一个问题是，当有多个订购者订购同一总线通道后，当总线通道收到数据转发给使用者时，如果数据量大且频率高时，很有可能转发将是一个瓶颈。为了解决该问题，采用了组播技术，即订购同一总线通道的订购者，可以选择是否使用组播的方式接收数据，这样总线通道在转发时，发送函数只需要调用一次，大大提高了转发效率，因此可以形成图7所示的结构。

图7 引入组播接收后的结构

在IO服务的设计中，订购者与总线通道发布者都有一个全局唯一的名字，它们之间通过组播方式进行订购/取消通信，通过名字来识别不同的通信实体，该方式简化了各个通信实体之间的配置，通过组播来协商后续真实数据通信的IP地址和端口。订购者发送的订购消息中包含了以下信息：

① 订购方式：点播订购、组播订购。

② 订购者的数据传输IP地址：如果订购者未填写IP地址，则IO服务默认使用UDP协议的源IP地址作为订购者的IP地址，并通过订购ACK消息发送给订购者。

③ 订购者的数据传输端口：如果订购者未填写端口号，则由IO服务自动分配一个未使用的端口，通过订购ACK消息发送给订购者。

④ 订购总线通道的类型：如1553、Arinc429、RapidIO、CAN、RS485等。

订购者在收到订购ACK消息后，如果能够成功，则根据回传的IP地址、端口号创建数据转发点对点的UDP，通过该UDP发送接收实际传输的数据。

同时IO服务与订购者之间通过心跳机制，来互相监测对方是否在线，当IO服务发现订购者不在线时，删除订购者相关信息；当订购者发现IO服务不在线时，则周期重新订购，直到订购成功。

1.6 总线数据的额外信息

总线在逻辑上可被抽象为多个总线通道，比如1553总线就可以抽象为一个RT地址对应一个总线通道。这样便于订购者使用转发过来的数据。但1553数据中不同消息块是通过子地址来区分的，因此直接将数据转发，在订购端并不能区分接收到的消息类型。因此需要将总线的一些额外信息附加到真实的转发数据之前,如1553总线的额外信息就包括RT地址和子地址信息。

不同总线的额外信息可能不同，因此总线的额外信息是一个变长的数据，打包和解析时通过总线类型进行区分，数据消息格式设计如下所示：

消息方向(IB)总线类型(IB)总线额外信息(变长)真实数据内容(变长)

2 IO服务的应用

在一个综合化航空电子系统项目中，由于被控设备众多，总线种类也非常多，同时软件配置项也非常多，因此引入了IO服务，使得软件与硬件总线隔离，IO服务运行在国产实时操作系统ReWorks5.1上。在此基础上，软件架构采用了ICE分布式中间件技术[7]，通过一个设备代理的软件，将订购的总线数据与ICE通信数据进行转换，使得上层应用软件完全看不到具体的硬件，应用软件在ICE软总线上运行。软件的基本结构如图8所示。

图8 IO服务的应用结构

在引入了IO服务之后，使得开发人员更加关注软件的逻辑功能，使得很复杂的软件处理逻辑能在Windows上进行调试运行，大大提高了软件开发效率，降低了调试难度。同时在引入ICE中间件技术后，使得应用软件可以充分利用ICE提供的远程对象调用、AMI、AMD、IceStorm、FreezeMap等技术与服务[8]，大大降低了软件之间交互的复杂度，减少了大量重复代码。

结 语

IO服务使得各类航空总线与业务处理相对隔离，提高了业务处理的可移植性，通过基于订购发布消息机制，为应用程序访问硬件提供了一种标准化接口，隔离了其与特定硬件驱动程序和操作系统设备驱动程序的关联。

IO服务在采用总线插件化、总线通道反射创建技术以及XML配置技术后，使得IO服务更加通用独立,可以复用于不同的项目中。采用订购发布机制，进一步降低了使用者和总线通道的关联关系，引入了数据转发的组播机制，提高了数据转发的性能。

正因为上述特性，使得软件架构的设计更加灵活，在实际的综合化航空电子系统项目中，将 ICE中间件技术和IO服务相结合，使得软件开发效率大大提高，软件部署更加灵活多变，软件可移植性更强，降低了软件的复杂度和调试难度。

[1] 张凤鸣,褚文奎,樊晓光，等.综合化模块化航空电子体系结构研究[J].电光与控制,2009,16(9);47-51.

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

[3] 布施曼.面向模式的软件架构,卷1:模式系统[M].袁国忠,译.北京:人民邮电出版社,2013.

[4] 陈方明,陈奇.基于插件思想的可重用软件设计与实现[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中间件关键技术研究与实现[D].西安:西安电子科技大学,2006.

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

梁白鸥(高级工程师)，主要研究方向为航空电子、通信系统软件架构、中间件技术等。

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)