面向软件定义的飞行器综合电子系统软件架构技术*

王小辉 张 涛 吕殿君 詹景坤

1.中国运载火箭技术研究院研究发展中心，北京 100076 2.西北工业大学软件与微电子学院，西安 710072

目前飞行器相关装备的研制仍采用传统的软硬件一体化研发方式，即关于飞行器软件系统的开发高度依赖于硬件系统的设计。随着飞行器工作需求的多样化，传统软硬件一体化的研发方式已无法满足更灵活的飞行器功能扩展需求，各型号飞行器研制无法做到大规模的技术复用并因软硬件的紧耦合导致系统的升级维护困难。因此，针对上述问题，一种新的软件定义飞行器技术被提出。

软件定义技术是一种通过特殊的软硬件架构设计，实现将控制层面从底层硬件抽象出来，并由软件统一完成对硬件管理和调度的技术。目前软件定义技术已在无线电、雷达和卫星等装备上具有一定的研究成果，充分实现了软件与硬件的解耦，并通过软件灵活控制和定义硬件功能[1-2]。然而，因飞行器设备的特殊性，软件定义技术在飞行器设备上的应用仍存在如下技术需求及挑战：

1)飞行器软件系统的跨平台应用。飞行器因作用目标及使用需求的不同，致使飞行器型号众多。不同型号飞行器采用的硬件平台及编程方式均存在一定的差异性，因此针对软件定义技术的应用首先需要解决飞行器硬件平台的通用化抽象管理，以支持飞行器软件系统的跨平台应用；

2)飞行器软件系统规模的进一步复杂化。现代战场已逐渐转换为信息化对抗作战，在飞行器的技术及功能需求上提出了更多要求，使得飞行器软件系统的研制规模及复杂度急剧增大。因此在飞行器新型技术及功能的研制及普及方面，有必要寻求一种面向大规模、高难度软件快速开发及维护的研发方式；

3)飞行器软件系统研制的高质量保证。飞行器属于一种技术密集型的高端精密装备，而且飞行器通常运行于复杂恶劣的工作环境，在软件定义技术下，软件系统安全性和可靠性将决定飞行器的整体运行质量。因此，在当前飞行器型号任务多，软件研发周期短的条件下，须同时保证飞行器软件系统研发的效率及质量。

针对上述问题，借鉴美国军方提出的未来机载能力环境(FACE：Future Airborne Capability Environment)标准[3]，设计并提出一种面向软件定义技术的开放式、可移植飞行器软件体系架构，并给出基于该体系架构的飞行器软件系统快速开发方法，有效解决飞行器软件系统在软件定义技术下的功能快速集成及软件技术的大规模复用。

1 开放式、可移植飞行器的软件体系架构设计

1.1 美军FACE标准

FACE技术标准是由美海军航空作战电子项目办公室提出，并由国际公开标准组织FACE联合会维护管理的一套用于军事航空系统的软件通用运行环境开发的技术标准。FACE允许将一些软件功能以组件的形式开发，并通过定义好的接口向其它组件提供这些功能调用，同时保证软件在不同硬件环境下的移植和复用。

FACE技术标准定义了用于开发应用的软件计算环境框架和接口，秉承关注点分离的理念，采用分层设计的思想将航电系统中众多与特定硬件平台相关的接口控制文件(ICD：Interface Control Document)处理封装到FACE计算平台，并在计算平台内通过一系列的适配模式将特定平台相关的ICD适配到FACE定义的标准ICD，FACE上层定义的可移植组件通过处理FACE定义的标准ICD和特定硬件平台实现解耦，实现一套软件系统可以运行于多个平台的目的，图1为FACE技术标准示意图。

图1 FACE标准示意图

FACE标准目前已逐渐面向美国和欧洲未来的商业、军事和通用航空飞行领域，产生关键技术作用和影响，2015年美国空军已开始推广标准。此外，美国海军防空系统未来也将向FACE架构进行演变；美国国防技术Elbit系统公司整合机载环境任务处理器和驾驶舱升级解决方案，正在将FACE纳入新的软件开发计划；美国陆军国防部也逐步将FACE系统纳入包括在直升机平台等陆军装备上的研究与应用中[4-5]。

1.2 开放式、可移植的飞行器软件体系架构

因FACE标准具备较高的航天适用性，本文在该标准基础上针对当前飞行器的研制特性及发展需求，通过建立一种开放式的飞行器软件系统参考架构，制定通用化、标准化的组件互联接口，支持可移植的特定能力软件应用，实现具备通用目标、安全和保密性的可移植组件组成的应用开发，有效解决飞行器载荷的快速识别、集成及功能组件的动态集成、以及飞行器软件体系架构和功能组件的复用等软件定义飞行器技术的难题。

本文设计的开放式、可移植飞行器软件体系架构如图2所示，该架构采用分段的设计方式，各分段主要包括操作系统段(OSS)、I/O服务段(IOSS)、特定平台服务段(PSSS)、传输服务段(TSS)及可移植组件段(PCS)共5个部分。并通过标准化各分段之间的传输服务接口以及统一分段之间的消息传输格式，将外部硬件设备环境与软件系统架构相隔离，进而提高软件应用功能的可移植性。此外，各分段通过定义的操作系统接口(OS)、输入/输出服务接口(IO)以及传输服务接口(TS)共3种标准化接口完成相互间的数据通信传输。

图2 开放式、可移植飞行器软件体系架构

1)操作系统段

操作系统段位于体系架构底层，是其它分段的运行基础，用于承载各型号的飞行器操作系统、编程语言运行时以及应用程序框架，为飞行器的软件应用程序提供一个可执行运行环境，并负责对计算平台的访问控制。

2)I/O服务段

I/O服务段实现飞行器软件系统与各型号飞行器硬件设备驱动程序的对接， I/O服务段将对接硬件和设备驱动程序抽象为I/O服务，实现通过特定平台服务段和I/O设备之间的IOS接口进行通信。I/O服务段为各型号飞行器使用的每一种总线通信方式定义一个专门的I/O服务，并采用适配器的设计模式完成对对应设备的访问。I/O服务负责解析和组装标准格式的I/O数据块，获取总线传输所需的参数与特殊机制，从而完成与平台特定服务段服务间的数据交互。

3)特定平台服务段

特定平台服务段可对外部设备数据的生成逻辑进行抽象建模。针对各型号飞行器外部硬件设备定义了一组通用的应用数据格式。特定平台服务可被视为外部硬件设备的抽象代理，其实现方式与其抽象的外部硬件设备紧密相关。特定平台服务能理解对应设备总线接口控制文件的数据组成，并完成应用数据块和接口定义数据块之间的格式转换，从而实现了应用数据与总线接口数据的解耦。

4)传输服务段

传输服务段主要为可移植应用软件和特定平台服务提供应用数据块的分发传递和格式转换功能。通过传输服务，飞行器应用软件和特定平台服务只需关注与自身相关的应用数据的通用处理方式，无需关注数据交互时的具体传递细节，从而实现了应用数据处理逻辑与应用数据传输过程的解耦。

5)可移植组件段

可移植组件段由一系列的可移植的标准化飞行器系统功能组件和通用服务组成，用于提供平台级的能力。与传统的飞行器应用软件相比，这部分软件只包含纯业务逻辑部分，可在任意不同的飞行器硬件计算平台和飞行器系统运行环境上进行部署，且至多只需进行重新编译，或者运行软件库、编程语言时需对库以及应用框架进行重新链接，充分体现标准组件化方式飞行器系统功能的移植灵活性。

6)操作系统接口

操作系统接口在整个体系架构中，为其它服务段中的组件提供了使用操作系统内部服务及操作系统段相关功能的标准化手段，该接口支持实时分区操作系统及健康管理等应用程序接口(API)。操作系统接口完成飞行器软件系统与操作系统的解耦，实现跨操作系统可移植。

7)I/O服务接口

I/O服务接口在整个体系架构中，为特定平台服务段中的组件提供了与接口硬件设备驱动程序通信的标准方法，该接口采用针对各型号飞行器标准化定义的I/O消息模型进行传输。I/O服务接口完成飞行器软件系统与飞行器硬件平台一定程度的解耦，实现特定I/O服务的可移植。

8)传输服务接口

传输服务接口在整个体系架构中，为特定平台服务段与可移植组件段提供了一个标准化的手段来使用传输服务段提供的通信服务，该接口采用针对各类型飞行器标准化的消息数据格式进行通信。传输服务接口完成飞行器软件系统架构组成的解耦，实现组件可移植、系统架构复用及组件的快速集成。

通过上述分段的系统设计方式，采用针对飞行器硬件平台、硬件设备、操作系统、软件系统及功能组件的通用化、标准化处理，实现飞行器软件系统各层级的全面解耦，构建一种开放式、可移植的飞行器软件系统架构。利用该系统架构可以通过对飞行器关键功能的可移植组件化，实现跨型号飞行器平台间的关键功能的快速集成与复用，有效促进飞行器功能及技术的快速研制及大规模复用。

2 面向软件定义的快速集成开发方法

为进一步完善面向软件定义的开放式、可移植的飞行器软件体系架构技术，以及随着飞行器工作需求的多样化，各型号飞行器研制无法做到大规模的技术复用，因软硬件的紧耦合导致系统升级维护的困难。本文结合飞行器软件系统实际研制需求，围绕软定义技术开发思想，提出一种基于开放式、可移植体系架构面向软件定义的飞行器软件系统及功能快速集成的开发方法。该套开发方法的整体设计如图3所示。

该方法首先依据开放式、可移植飞行器软件系统体系架构进一步制定各项研制规范及标准，规范化面向软件定义技术的飞行器软件系统开发过程；其次，针对传统飞行器软件系统研制，参与角色重新划分为飞行器软件集成单位和承研单位，引入飞行器体系架构认证专家；最后，构建用于标准通用功能服务收集和复用的开放式可移植飞行器软件系统模型组件库。

2.1 面向软件定义的快速集成开发规范及标准

面向软件定义的快速集成开发规范及标准包括如下几项内容：

1)业务指南。用于说明开放式、可移植飞行器软件系统体系架构的设计及开发原理，并向软件承研单位提供飞行器软件开发指引；

2)共享数据模型。用于收集并定义飞行器技术领域的各类型数据元素，形成一个完整的共享数据模型字典，有利于功能软件的标准化开发；

3)技术标准。面向开放式、可移植飞行器软件系统体系架构的技术开发细节描述，规范软件承研单位的标准化功能组件开发；

图3 整体设计图

4)参考实现指南。该指南建立一套标准的飞行器软件系统体系架构，便于软件承研单位参考；

5)符合性策略。详细描述了开放式、可移植飞行器软件系统体系架构软件开发的约束规范，用于测试认证标准功能组件；

6)库策略。模型组件库策略充分定义了符合标准的可移植功能组件的入库要求及发布、保存标准；

7)约定指南。明确了开放式可移植飞行器软件系统体系架构模型组件的使用标准和指引。

2.2 面向软件定义的快速集成开发过程

1)软件集成单位通过向飞行器工作功能需求方了解研制需求后，首先可以直接通过开放式、可移植飞行器软件系统模型组件库检索是否有满足需求的通用可移植标准服务组件，若有则提取该组件并向目标型号飞行器进行集成，即快速完成产品研发；

2)若模型组件库中没有符合需求的服务组件，则启动组件开发流程。软件集成单位向承研单位提供研制需求，由承研单位依据技术标准实施标准功能组件的开发；

3)软件承研单位完成标准功能组件的开发后，一方面提供给软件集成单位，完成型号飞行器产品的研发；另一方面，向体系架构认证专家提交该标准功能组件，由专家完成符合性测试验证后，将该标准组件完成入库保存处理，随后发布该功能组件，便于后续类似需求飞行器型号产品的快速研制。

通过构建开放式、可移植的标准功能组件，可以实现飞行器系统功能模块在不同型号飞行器平台间的大规模复用。此外，通过构建模型组件库，逐步积累标准组件，极大促进后续型号飞行器研制的技术复用，提升飞行器研制效率并保证飞行器研制质量。

3 开放式、可移植软件架构应用验证

雷达探测系统是飞行器的重要组成部分，本文以其为对象，开展开放式、可移植软件架构的应用验证。飞行器雷达针对不同探测目的，具备多样性，如地面探测、目标探测等；此外，同一类型雷达下仍具备多种型号，以适配不同型号的飞行器及飞行任务。

一套雷达软件系统主要包含如下功能：通信协议的指令解析、雷达工作状态配置、中断处理响应、数据打包存储及传输、数据处理等。对于雷达系统的软件部分而言，其处理过程具有相似性。但因雷达硬件组成及探测方式不同，处理的信号数据类型及算法具备差异性。

因此，在开放式、可移植软件架构下以2种不同类型毫米波雷达控制软件的研制进行验证，其中A型毫米波雷达采用脉冲体制，B型毫米波雷达采用连续波体制。

如图4所示，首先在开放式、可移植软件架构下，针对A型毫米波雷达，经过标准化组件开发，完成测试后保存至标准化组件库；其次，在B型毫米波雷达的软件研制过程中，优先在标准化组件库中寻找可复用组件，如指令解析、状态配置、中断响应等，利用架构优势实现可移植功能组件的复用；最后，因脉冲体制与连续波体制的不同以及两型雷达探测目的的不同，针对B型雷达的信号处理及探测数据处理方面进行组件新研，完成研制后标准化入库，以备后续复用。

图4 两型号毫米波雷达软件研制图

在完成雷达控制软件研制后，分别对研制过程从代码量、研制时间及测试质量等方面进行统计分析。B型毫米波雷达软件因实现了部分组件的复用，与传统完全新研软件相比，在相同人力投入下研制时间缩短了约30%，且测试阶段发现的软件bug率降低约50%。

上述实验验证了将毫米波雷达的软件组件进行标准化统一后在开放式、可移植架构下的可复用性开发，将有效支持飞行器软件系统的高质量快速集成。

4 结束语

提出一种开放式、可移植的飞行器软件系统体系架构及一套基于该架构体系的软件快速集成开发方法，以推进软件定义技术在当前飞行器系统研制上的应用，实现飞行器软件系统及功能组件的标准通用化开发及大规模复用，提升了飞行器软件系统的研制效率。在下一步的研究中，将细化提出的体系架构技术，并开展集成开发环境的研制。