基于FACE的无人机飞行管理功能数据模型构建

白杰

航空电子系统发展经历了分立式航电系统、联合式航电系统、综合模块化航电系统几个阶段，逐渐向着开放式、通用化方向发展。FACE标准规范化了可移植组件间信息传输格式，建立了标准的接口，减少了组件间的数据转换，数据模型作为软件层间交流的标准模式，为平台间软件模块的通用提供了解决方案。本文在研究FACE架构及数据模型的基础上，构建了基于FACE标准的无人机飞行管理功能数据模型。

随着高性能计算机的发展，航电系统架构由“专用”系统向“开放”系统转变，综合化、模块化的程度逐步加深。模块化开放式系统采用模块化的、接口定义明确的行业接口标准的系统设计，在软件架构方面，目前的平台软件架构层次不够清晰，不够系统化；另外，目前的方案没有系统配置功能，不能根据不同的需求来定制不同的安全级别。因此，需要在整个软件层面建立一套层次化、系统化的可移植的架构标准，使系统更少的依赖于专利产品，可以通过更多的竞争降低价格，降低项目的风险，获得多生产厂商的支持。

FACE架构功能简介

未来机载能力环境（ Future AirborneCapability Environment，FACE）是由美国海军航空兵电子项目办公室在2012设计出并由FACE协会使用的技术标准，相继发布了1.0、2.O版本，2014年发布了2.1版本。该技术标准用于软件通用操作环境的开发，从而在整个军事航空界推进可移植性以及软件产品线的创建。FACE解决方案扩展了模块化开放式系统的设计思想，它将一些基于软件的功能“分层”以组件形式开发。该组件通过定义好的接口向其他组件开放，并且对特定关键接口及“分层”接口之间的差异进行了定义。

FACE标准作为处于硬件之上的软件通用操作环境标准，采用层次化架构设计，包括：操作系统层、输入/输出（l/O）服务层、特殊平台服务层（PSS）、传输服务层（TSS）、可移植组件层（PCS）通过这种分层设计，很好地解决了应用程序的可移植性的问题。同时，由于可移植组件的设计和层间接口标准化，其可移植性不光存在于可移植组件层，其他层也具有可移植性。

（1）操作系统层

操作系统位于所有部分的底层，给其他层软件提供接口。

（2）I/0服务层

I/O服务层的软件负责系统设备驱动和特定平台服务层间的数据传输。这层是与底层的供应商提供驱动交流的适配器模式，给上层FACE标準化的接口提供转化后的数据。当编码废弃或者是驱动改变的情况发生时，I/O层只需更改适配器即可。由于改变所带来的影响都被封装在了适配器中，所以其它层软件不需要另外的改变。

（3）特定平台服务层

特定平台服务层包含传统软件架构中与特定平台设备ICD紧耦合的那部分，规范或者封装与FCAE系统相关的设备管理业务，提供的数据通过传输层传输给可移植组件，作为其平台数据源。

（4）传输服务层

传输服务层是数据的中间传输层，使FACE应用不需知道数据终端在什么地方，就可以达到数据传输到目的。同时可以通过这层中间层，降低特定平台服务层中组件变化给可移植组件层组件带来的影响。

（5）可移植组件层

可移植组件层封装了FACE系统的逻辑控制业务和与平台无关的航电通用功能，由一系列可移植FACE应用和通用服务组成，当这些服务一起工作时提供平台级别的能力。

可移植组件集（Uop）

在不同平台上使用相同功能时，可能因为供应商不同需要重新开发，显然这样是不划算的。如果任务级别功能具备可移植性，那么在需求发生改变时，就可以减少源代码的更改，整合和维护等工作量也会相应减少。FACE Uop的构建符合以下标准：

（1）包括所有相关软件、非标准编程语言运行库、库、程序语言框架。

（2）提供一个或多个服务或任务级别功能。

（3）一个FACE Uop只能存在于一个层或者子层中，不能跨层存在。但是可以将一些Uop打包成一个可以跨层存在的逻辑实体。

（4）一个FACE Uop只能单独存在于一个分区中，如果Uop中包含编程语言运行库或程序框架时，那么他们在一个单独的分区中通过多重Uop执行。当Uop移植到另外的分区、平台上时，编程语言运行库或程序框架随之移植。

（6） FACE Uop之间在进行数据传输是必须使用TS接口、I/O服务接口、编程语言运行库、程序框架接口、操作系统接口之一。

（7） Uop的子集在FACE不同层中执行，在进行数据传输时，语言运行库应符合FACE相应接口。

（8）不同层中Uop之间进行通信时使用相应接口。

（9）非标准框架或者编程语言运行库经常包含于Uop中，并且符合FACE定义接口。

对于UoP间通信情况，见图]。Uop内部组件间通信可以使用TS接口或直接通信。F-Uop中软件实体间使用TS接口进行通信时，就不再需要使用专用内部通信方式。通过对整体应用的解耦，分解成更多的Uop，可以将已存在的销售商产品线迁移成更高度的模块化产品，同时多种通信方式降低了转化难度。

数据模型

FACE层间通过指令、请求、位置信息、高度信息、电压、电流等数据进行数据交互，但是很多时候，由于数据繁多庞大，不同厂商设备或者应用中数据格式、单位、范围等定义不同造成接口不匹配问题，浪费开发时间。数据模型为软件层间的交流提供了标准模式。通过严格定义唯一性模型，能保证它们不可被复制且能容易的添加其他的数据参数，便于开发者区分全部信息，在需要改变时，能以最少改变被处理成符合FACE数据模型的部分，消除了许多开发过程中多个供应商之间横向接口不匹配的问题。

FACE数据结构实现过程依次为：概念到逻辑；逻辑到平台；平台到可移植单元；可移植单元到代码，如图2所示。

概念模型包括基本的概念，这些概念包括整体的属性和整体间的关系。

逻辑数据模型实体由概念数据模型实体创建而来。一个概念数据模型实体可能由多个逻辑数据模型实体实现。逻辑数据模型基础元素通过提炼概念数据模型元素创建，包括单位、度量、坐标系、值域、约束条件和度量精度等详细信息。

平台数据模型中的实体与逻辑数据模型中的实体相关。数据模型实体由逻辑数据模型实体创建而来。平台数据模型支持的物理数据类型符合接口定义语言（IDL）数据类型：布尔型、字符型、枚举等。从平台数据模型映射到程序语言有标准的语言映射规范。语言连结为通过TS接口传输的信息数据结构提供了识别功能，保证了组件在API上的可移植性。

Uop模型为Uop提供了信息接口识别功能。在Uop中，信息接口识别为端口，为了识别信息类型，在平台数据模型中信息接口表现为视图。平台数据模型中的视图在UOP中表现为通过TSS API传输的信息。

FACE数据模型语言连结是对PDM映射到程序语言的一系列设置。不同的语言，映射过程不同。语言连接定义了如何从平台数据模型视图生成代码。

基于数据模型的组件接口实现

典型无人机飞行管理功能主要实现飞控计算机、起落架控制装置、电气系统设备的控制管理。功能实现包括飞行管理组件、飞控控制组件、起落架控制组件、电气控制组件、传输服务组件和1553B服务组件，组件间通信示意图如下：

概念模型

飞行管理组件从飞控控制处接收起落架收放、刹车控制盒加电断电请求，获得高度、经纬度等数据；向起落架控制发送起落架收、起落架放两个标准化的指令，接收起落架状态信息；向电气控制发送刹车控制盒断电、刹车控制盒加电、空速加温器供电指令。将飞行管理功能作为Uop进行建模，概念模型如下：

飞行管理接收飞控计算机的请求、数据，向飞控计算机返回指令执行状态，向起落架控制发送指令，接收起落架控制返回的状态，向电气控制发送指令，接收电气控制返回的状态，所以这七个元素可作为概念元素。

逻辑模型

飞行管理向起落架控制发送的指令是复合测量值，由信息ID和指令编码两个独立测量值组成，均为枚举量，代表不同指令内容。其他指令、请求逻辑模型构建类似。

起落架控制向飞行管理返回状态，狀态是复合测量值，由信息ID、指令编码、执行结果、工作状态，校验和组成，除校验和之外几个参数均为枚举量。

飞控控制向飞行管理发送空速管加温器加电、起落架收、起落架放、刹车控制盒加电、刹车控制盒断电请求，三个请求均为复合测量值，包括信息ID、指令编码两个独立测量值。

飞控控制向飞行管理发送高度数据，高度数据为独立测量值，详细信息如图6所示：

飞行管理接收请求后返回请求执行状态，状态是复合测量值，包括信息ID、请求编码、执行结果、工作状态。

飞行管理向起电气控制发送空速管加温器加电指令、起落架收、起落架放指令，指令为复合测量值，由信息ID和指令编码两个独立测量值组成，均为枚举值，代表不同指令内容。

电气控制向飞行管理返回状态，状态是复合测量值，由信息ID（枚举值）、指令编码、执行结果、工作状态和校验和组成。

平台模型

下一步为指令的消息ID、指令编码，请求的消息ID、请求编码，状态的消息ID、指令编码等测量值创建平台展示，创建展示测量值的IDL实例。复合测量值使用IDL结构体实现。

对各组件接收请求或指令后返回状态创建平台展示，返回状态为复合测量值，使用IDL结构体实现，使用IDL实现状态复合测量值中的信息ID、指令/请求编码、执行结果、工作状态和校验和测量值。

首先是飞行管理向起落架控制指令的平台模型创建，指令使用IDL结构体实现，两个独立测量值由IDL实现，定义其数据类型（其他指令平台构建过程类似），详细信息见图7：

飞行管理向电气控制发送指令的平台模型创建过程同上。

飞控计算机向飞行管理发送的请求使用IDL结构体实现，信息ID和请求编码两个独立测量值由IDL实现，分别定义其数据类型，定义枚举量的个数及含义。

飞控计算机向飞行管理发送的高度数据创建平台展示，使用IDL实现高度测量值，详细信息如下：

然后对各组件接收请求或指令后返回状态创建平台展示，返回状态为复合测量值，使用IDL结构体实现，使用IDL实现状态复合测量值中的信息ID、指令/请求编码、执行结果、工作状态和校验和测量值。

Uop模型

当测量值映射到IDL概念后，就可以创建组件中输入和输出的信息平台视图。飞行管理从飞控计算机处获得请求和高度数据，从起落架控制和电气控制处获得状态信息，对电气控制和起落架控制发出指令，对飞控计算机返回状态。为飞行管理Uop建模和确定其特征，为每个输入输出定义端口，描述使用端口通信的信息，将信息类型映射到端口。详细信息如下：

使用相应软件实现代码的映射，即可完成可移植组件层与特定平台服务层的接口的标准化。

总结

基于FACE的无人机飞行管理功能构建的数据模型，为软件层间提供了标准的交流模式，数据模型使软件分析、设计之初就是标准的模式，从而保障后续的设计、实践、维护中软件的复用性，更好地兼容平台，使航电软件更加类似于智能手机应用，在不影响其他系统的情况下非常方便增加或减少一个给定的应用，为在多个平台上复用提供了可能。基于FACE的航电软件数据模型构建，对提高软件开发质量，增强架构中应用、层间数据传输的标准性、可复用性，进而降低开发成本，节约开发时间有重要指导意义。