基于中间件的装备跨平台软件设计

杨柳 汪相国 黄勇韬

（中国电子科技集团公司第二十九研究所 四川省成都市 610036）

1 引言

伴随作战环境、作战对象和作战样式的跨越式发展，装备从单一功能的个体演进为攻防兼备的综合协同作战平台单元。当前面向特定的硬件平台开发的专用软件，软硬件紧耦合，不能满足综合协同作战平台单元开放式集成、灵活部署、快速升级的需求。装备软件一旦设计定型，就不能迁移部署，限制了系统功能的横向扩展。硬件升级以后，软件移植适配工作量大，系统纵向升级效率低。进一步由于人工智能信号处理算法的仿真验证平台通常为X86 处理器和Windows 操作系统，而实际装备运行在PowerPC 或ARM 嵌入式处理器和实时操作系统。这就需要屏蔽平台差异，确保算法的仿真验证效能在实际电磁环境中具备一致性。

装备软件跨平台设计是上述问题的有效解决方案。最基础的跨平台技术为IEEE POSIX 标准，但国产操作系统对POSIX 标准不完全兼容，诸如任务创建、信号量创建、文件管理等关键接口实现均不同。在类UNIX 系统中有POCO、Boost 等开源跨平台软件中间件，这些库代码规模均在10W 行以上，编译后的执行体10MB 以上。对于装备计算处理资源受限条件，规模偏重，挤占装备应用软件运行内存。并且均不提供消息通信服务，软件开发人员仍需关注底层数据传输细节。

面向异构运行环境，本文提出了基于中间件的装备软件跨平台框架。采用该框架，在飞腾FT2000A 处理器和PowerPC 处理器组成的混合计算处理硬件平台上进行了工程实现和应用验证。

2 软件中间件概述

当系统越来越复杂后，必然会向分布式方向发展。软件中间件通过提供简单、一致、集成的分布式编程环境，简化分布式应用软件的设计和部署。对象管理组织（OMG）发布的CORBA 和DDS 中间件技术标准，引领了软件中间件技术发展趋势，解决了分布式对象间跨网络、跨操作系统、跨编程语言的数据交互问题。CORBA 同时也提供了基于对象请求代理的分布式对象访问服务。DDS 则是利用以数据为驱动的消息发布-订阅模型，具备完善的数据传输Qos策略。

ZeroMQ通信中间件对套接字、网络帧、路由进行了抽象，支持在进程内、进程间和跨机器的多种消息传递模式。这些模式包括管道、请求-应答、发布-订阅。上述几种中间件在软件化雷达、航空电子任务系统、火控系统均有应用案例，提升了装备互联互通和快速反应能力。

3 跨平台软件框架设计

3.1 整体架构

吸收“开放式、分层解耦、面向服务”的思想，充分考虑“低时延、大带宽、高可靠”的通信需求，采用软件中间件技术，提出了装备软件整体架构。该架构通过对计算处理器和操作系统抽象封装，构建了统一的跨平台软件框架，最大化顶层应用APP 跨平台开发和运行能力。软件整体架构分为5 层，各层次功能介绍如下：

（1）外设传感器层：装备内部各种硬件模块，包括：射频前端、数字接收模块、信号处理模块等。装备外部的综合显控任务系统、环控设备、导航设备等。它们通过光电接口挂接到物理总线，总线上的节点可以动态改变，组网灵活。

（2）计算处理层：封装底层硬件细节，实现对外设传感器的操作和管理，由通用计算处理平台GPP（General Proccess Platform）及运行其上的板级支持包和各种总线驱动程序组成。对每一类物理通讯接口，该层向数据传输服务DTS(Data Transmission Service)提供标准的初始化和读写接口，并且输出格式化统一定义的数据帧，向各个物理设备开展个性化的物理总线驱动适配。

（3）操作系统层：包含操作系统和数据库软件，提供各类操作系统服务、文件系统服务和数据库持久化存储服务。

（4）中间件层：运行在计算处理平台上的统一软件框架，将其命名为装备跨平台软件框架ECSF(Equipment Cross-platform Software Framework)。它为应用层提供通用软件服务，是实现应用APP 跨平台移植和复用的关键。

（5）领域应用层：装备软件应用APP 的聚合，按功能模块划分，包括系统管控APP、敌我识别APP、信号处理APP、数据融合APP 等。

3.2 框架组成

软件框架由数据传输服务、应用APP 管理服务、虚拟操作系统服务三个模块组成，分别在不同维度支撑应用APP跨平台的设计开发和分布式运行。根据整体架构中的相关需求分配，框架的实现如图1所示。

图1：装备跨平台软件框架ECSF 类图

（1）数据传输服务：提供应用APP 之间的控制消息和数据流统一传递接口，使应用APP 之间的数据交互不仅具有松耦合特性，而且具有跨平台通信的特性。应用APP 只需要关注订阅的控制消息或数据流，而不用关注发布方的部署位置。

（2）应用APP 管理服务：提供应用APP 运行范式，应用APP 的启动和运行过程标准化，使得运行在不同计算处理平台的应用APP 具有相同的CPU 资源调度方式，实现了软件和具体的计算处理平台松耦合集成。

（3）虚拟操作系统服务：提供应用APP 访问操作系统的统一标准接口，使得应用APP 在不同操作系统之间的切换运行，简化成在对应的集成开发环境下的一键构建完成快速发布。

3.3 数据传输服务

针对大量数据传输场景，设计了控制消息和数据流隔离的分布式并行软总线，具有“大带宽、低时延、可扩展”的特点，通信模型如图2所示。通讯管理及协议转换管理器负责完成以太网和RapidIO 网络的通信自组网和拓扑管理，DDS 传输组件的节点发现和发布订阅消息注册，以及RapidIO 逻辑节点ID 分配和收发数据端口配置。

图2：分布式并行软总线通信模型

对于强实时的控制消息，消息的发布方遵循标准的应用报文格式进行打包处理，推送至控制消息总线，同步通知通讯管理及协议转换管理器进行后续处理。通讯管理及协议转换管理器从控制消息总线取出一条消息，将其按照传输报文格式进行打包处理，自适应选择传输协议。如果订阅方APP和发布方APP 部署在同一个运算平台内，选择共享内存进行交互，不会通过物理总线进行传输，提高通信效率。否则，选择DDS 方式，发送至对端的通讯管理及协议转换管理器，对传输报文进行解包处理推送至控制消息总线。

对于高频、大量的流式数据，单独设置数据流应用总线进行处理。流式数据在通讯管理及协议转换管理器打包处理后，将数据存放地址和长度构成的数据块描述信息放入消息队列，避免由于动态开辟内存导致的通信延迟。应用报文格式中的类型标明其为数据消息，自动选择RapidIO 作为跨CPU 传输的物理总线。RapidIO 总线提供的DMA 传输模式，最大支持6Gbps 的传输速率。

通讯管理及协议转换管理器可扩展至其它类型的物理总线，经过简单适配即可快速接入飞机平台。例如装备升级时，由于硬件限制，无法部署DDS 传输组件，原运算平台只有FC 总线，又希望能应用新开发的组件，节省开发时间。

3.4 应用APP管理服务

应用APP 管理服务提供应用APP 跨平台运行的标准范式，使得应用APP 在不同的运行环境中，具备相同的执行流程和结果。基于该框架，装备软件应用APP 自启动流程如图3所示。设备上电启动，首先解析系统配置文件，获取软件执行体加载路径、运行入口函数名称和消息路由关系。利用运行入口函数名称，在软件执行体中进行符号表同步搜索，定位软件运行的入口地址。然后跳转到入口地址，动态创建APP 对象，并根据配置参数，完成初始化。接下来注册控制消息和数据流，实例化APP 的输出和输出端口，分配端口逻辑ID，合并APP 内部各个进程间的消息路由关系。最后根据设定的顺序，依次启动各个APP。应用APP 状态维护消息在多个物理节点之间进行广播，实现了应用APP运行状态的相互感知和分布式启动停止控制。

图3：软件框架自启动应用APP 流程

应用APP 在运行状态中，周期性轮询控制消息队列是否非空。数据传输服务作为生产者，将订阅的消息加入消息队列。应用APP 作为消费者从消息队列中提取出全部消息，进行相应的计算处理。对于数据流的处理，区别在于单个处理周期内只取出一条数据流，并且单次最大处理时间不超过100ms。通过该设计，避免了大数据流处理长时间占用CPU资源，显著提高了软件实时性。如果接收到停止命令，执行垃圾回收处理，释放占用的CPU 和内存资源。

3.5 虚拟操作系统服务

虚拟操作系统服务对应用APP 提供统一的API 访问接口，覆盖操作系统提供的各类服务，包括线程、信号量、任务锁、文件操作相关。操作系统API 访问具有跨操作系统特性，不同操作系统的相同功能的访问接口保持一致。例如在Windows 操作系统中信号量创建的接口为CreateSemaphore，在国产锐化操作系统Reworks 该接口为SemCreate，对其进行抽象封装后，虚拟操作系统服务中提供的统一接口为VOS::SemCreate。

根据不同的操作系统分支，进入具体实现对象XX_OSImpl，兼容的操作系统包括：Windows、Vxworks、锐华、天脉系列。具体实现对象XX_OSImpl 的细节对应用APP 不可见，可以方便扩展到其它操作系统，并且静态内存占用约100KB，灵活高效。

4 工程实现与应用验证

4.1 计算处理硬件平台

计算处理硬件平台遵循OpenVPX 规范设计，用于信号处理、数据处理等通用处理运算。为了兼容异构处理架构，满足多种个性需求，采用载扣板结构。载板由交换芯片、主控FPGA 和光模块组成，不实现特定的计算架构，支持多个扣板实现不同的计算需求。两块交换芯片可通过光连接或电连接加入全交换网络，实现信号接入，分别绑定SRIO 协议和以太网协议。扣板由两片飞腾FT-2000A 处理器和两片飞思卡尔T2080 处理器组成，混合异构多核处理器满足工程实现的高负荷计算要求。

计算处理硬件平台内部的每片处理器均有一个4X 的SRIO 接口和两个1000Mbps 的以太网网卡，为跨平台软件框架的高速数据传输提供硬件支持。通用载板组合不同处理架构的扣板可实现不同功能的计算处理单元，扣板上处理器也可灵活增加或减少，匹配各种场景下的运算性能和运算量需求。

4.2 雷达告警器软件跨平台运行

将提出的框架应用到雷达告警器设计，开发的告警系统软件包括系统综合管控APP、信号分选与识别APP、信号融合APP，部署在前述硬件平台的构型如图4所示。其中P+V 表示运行环境为PPC 架构的T2080 处理器和风河操作系统，F+R 则表示运行环境为ARM 架构的国产FT2000A处理器和锐华操作系统。

图4：雷达告警器软件部署构型1

系统综合管控APP 负责从信号处理初级处理单元周期提取经过稀释和去交错处理的原始脉冲描述字数据流。依靠框架提供的数据传输服务，发送给信号分选与识别APP，进行分离和参数匹配处理，确认辐射源的平台类型和工作模式等特征。信号融合APP 负责对威胁目标进行消失活动管理，统一编号后发送给系统综合管控APP。系统综合管控APP对威胁目标进行格式转换后，通过专用的FC 总线，发送给航电任务处理机显示雷达辐射源态势。

为应对新体制雷达对象，需要对上述基础业务模型进行升级。首先对重点频段雷达信号进行单独处理，构成告警侦察综合系统。同时需要利用多机协同的方位信息，对辐射源进行精测向处理。依赖本框架提供的跨平台开发和运行能力，可以快速切换应用APP 的运行环境，形成扩展业务模型，如图5所示。

图5：雷达告警器软件部署构型2

软件总线化使得应用APP 之间通过平台无关的消息接口进行交互，应用APP 部署位置发生变换后，原有的通信模式保持不变。如果采用传统的TCP 套接字通信，则需要重新配置服务器和客户端IP 地址。

4.3 信号处理算法跨平台验证

基于该框架在某型装备研制中，实现了在Windows 桌面平台对飞行记录数据的回放，发现信号处理算法逻辑中存在的问题。通过在Windows 平台修正、完成验证，早期部署到实装的风河Vxworks5.5 上，最后切换运行到国产天脉1 平台上。具体方法如下：

（1）在微软Visual Studio 2010 环境中编译生成信号处理APP 软件exe 执行体；

（2）在Windows 平台上部署运行信号处理APP 软件，将飞行数据输入给软件；

（3）在Windows 平台上进行可视化的运行和分析；

（4）发现软件问题和待优化的核心算法逻辑，在Windows 平台上修改后闭环验证；

（5）在Windows 平台验证完毕后，在Tornado 集成开发环境中编译生成信号处理APP 软件out 执行体，部署运行在装备中的进口Vxworks5.5 平台；

（6）在LamdaE 集成开发环境中编译生成信号处理APP 软件rel 执行体，部署运行在装备中的国产天脉1 平台。

5 结论

本文基于中间件技术，构建了装备跨平台软件框架，将应用程序、数据传输总线、基础硬件架构分层隔离，增强了应用程序的可移植性，实现了一次开发、多平台部署运行，低成本兼容硬件处理平台的替代换型。由于跨平台复用的软件标准接口封装和代码重用，不需要额外的软件测试工作，软件可维护性良好。后续可对该框架进行功能扩展，研究增加消息队列的持久化存储和远程通信的序列化和反序列化。