|
1.FACE 简介
FACE 是 Future Airborne Capability Environment 的缩写，意思是未来机载能力环境 。
FACE 的目的是建立一个航空电子机载系统的集成框架，以便能够让不同的子系统的供应商方便对接，提高资源的复用机会，最终目标是是降低航空电子设备能力的开发成本、集成成本和交付时间 .
FACE 已经被美国海军航空空战电子项目办公室 (PMA-209) 、陆军项目执行办公室 (PEO) 航空 (AVN) 、陆军航空和导弹研究、开发和工程中心 (AMRDEC) 和空军研究实验室 (AFRL) 所采用。
本文章将对 FACE 架构的内容做个概要介绍，包括如下内容：
• FACE 的逻辑架构的分段
• FACE 的标准化接口
• FACE 的数据架构
• FACE 的参考架构段的示例
• 编译语言运行时
• 组件框架
• 操作系统段的Ｐｒｏｆｉｌｅ
• UoC 和 UoP （一致性单元和可移植单元）
2.FACE 架构的分段
FACE 参考体系结构由发生变化的逻辑段组成。这些段连接在一起创建的结构是 FACE 参考体系结构的基础。
FACE 参考架构的五分段如下：
1.操作系统段 Operating System Segment (OSS)
2.输入 / 输出服务段 Input/Output Services Segment (IOSS)
3.平台特定服务部段 Platform-Specific Services Segment (PSSS)
4.运输服务段 Transport Services Segment (TSS)
5.可移植组件段 Portable Components Segment (PCS) 
如下是各个架构段的功能
| 操作系统段（ Operating System Segment ， OSS ）
|
提供系统服务，能够适配各种操作系统，并提供常见的基础服务，例如运行调度、网络服务、设备服务、组件管理和配置服务。 |
| 输入 / 输出服务段（ Input/Output Services Segment ， IOSS ）
|
提供硬件驱动程序的抽象，关注接口数据，而不是硬件和软件驱动程序。
|
| 特定于平台的服务段 （ Platform-Specific Services Segment ， PSSS ）
|
提供平台相关的服务，包括：
• 平台特定的设备服务 (PSDS) ： 支持数据管理和平台专用接口控制文档 (ICD) 与 FACE UoP 提供模型 (USM) 之间的转换。
• 特定于平台的公共服务 (PSCS) ： 包括日志服务、设备协议中介 (DPM) 服务、流媒体、运行状况监视和故障管理 (HMFM) 以及配置服务。
• 特定于平台的图形服务 (PSGS) ： 从 FACE 参考体系结构中的软件组件中抽象出图形处理单元 (GPU) 和其他图形设备的接口细节。 |
| 运输服务段（ Transport Services Segment ， TSS ）
|
提供通信服务。将传输机制和数据访问从软件组件中抽象出来，以便使用不同的传输方式集成到不同的体系结构和平台中。 TSS PCS 和 / 或 PSSS UoCs 之间的数据分发。 TSS 功能包括但不限于软件组件接口信息的分发和路由、优先级、可寻址性、关联、抽象、转换和组件状态持久性。 |
| 可移植组件单段（ Portable Components Segment ， PCS ）
|
提供功能和业务逻辑的软件组件组成。 PCS 组件要具有可移植性和互操作性，所以与硬件无关，也不能绑定到任何数据传输或操作系统实现。
|
3.FACE 的标准化接口
FACE 参考体系结构定义了一组标准化的接口，提供了 FACE 体系结构段之间的连接。 FACE 参考体系结构中的标准化接口是操作系统段接口 (OSS 接口 ) 、输入 / 输出服务接口 (IOS 接口 ) 、传输服务接口和面向组件的支持接口。对这些标准化接口的软件引用可以在初始化、启动、运行时等状态下建立。
| 接口类型 | 说明 |
| 操作系统段接口 | OSS 接口为软件使用操作系统内的服务和与 OSS 相关的其他功能提供了一种标准化的方法。 OSS 接口由 OSS UoC 提供给其他网段的 UoC 。该接口包括 arinc653, POSIX® 和 HMFM api 。 OSS 接口可选地包括以下一种或多种网络功能 : 编程语言运行时、组件框架、生命周期管理和配置服务接口。
|
| 输入 / 输出服务接口
| IOS 接口为软件组件与设备驱动程序通信提供了一种标准化的方式。该接口支持几种常见的 I/O 总线体系结构。 |
| 传输服务接口
| 传输服务接口为软件使用 TSS 提供的通信服务提供了一种标准化的方法。特定类型 (TS) 接口由 TSS 内的软件组件提供，用于与 PSSS 和 PCS 内的软件组件之间的通信。 FACE 数据体系结构管理遍历传输服务接口的数据的表示。 |
| 面向组件的支持接口
| 面向组件的支持接口包括可注入接口和生命周期管理服务接口，这些接口是面向组件支持的横切关注点的 FACE 标准化接口。 |
| 可注射的接口 |
可注入接口为集成软件提供了一种标准化的方法来解决软件组件之间固有的使用 / 提供接口依赖关系。为了让软件组件使用接口，它必须与至少一个提供该接口的软件组件集成在同一地址空间中。可注入接口实现了软件开发的依赖注入习惯用法。 |
| 生命周期管理服务接口 |
生命周期管理 (LCM) 服务接口为软件组件提供了一种标准化的方法来支持与组件框架一致的行为 : 初始化、配置、框架启动 / 拆除和操作状态转换。 LCM 服务接口可由任何 FACE 参考体系结构段中的软件组件选择性地提供，并可由系统集成实现或任何 FACE 参考体系结构段中的软件组件选择性地使用。 |
1.1 FACE 数据架构
FACE 规范中明确定义了 FACE 数据架构， FACE 数据架构的定义包括如下部分 : 
• FACE 数据模型语言利用 Open UDDL ( 开放通用领域描述语言 ) 来定义 FACE 的 SDM ( 共享数据模型 ) 和 UoP ( 可移植性单元 ) 的 USM ( 提供的模型 )
• 定义 FACE 数据模型语言，由 EMOF ( 基本元对象设施 ) 元模型和一组 OCL ( 对象约束语言 ) 约束指定
• 定义一种模板语言来指定跨关键 FACE 接口的数据元素的表示
• 定义 FACE 数据模型语言绑定规范，描述如何将 Open UDDL 技术标准中指定的元素映射到每种支持的编程语言的数据类型和 / 或结构
• 提供 SDM ，允许在所有 FACE 一致性数据模型中使用标准化定义
• 定义 USM 的构建规则
每个使用 TS 接口的 PCS UoC 、 PSSS UoC 或 TSS UoC 都附带一个与 FACE SDM 一致的 USM ，并根据 FACE 数据模型语言定义其接口。特定于领域的数据模型 (domain - specific Data Model, DSDM) 捕获与感兴趣的领域相关的内容，可以用作 USM 的基础。 DSDM 必须与 FACE SDM 一致。
FACE 数据模型语言
FACE 数据模型语言在概念、逻辑和平台级别强制采用多级方法对实体及其关联进行建模，从而支持渐进和不同程度的抽象。实体、它们的特征和关联为定义 UoPs 之间数据交换的视图规范提供了上下文。 
FACE 数据模型语言支持抽象 UoPs 的建模，为采购或基于 FACE 技术标准定义元素提供规范机制，并在其他参考体系结构中使用。为了解决 UoPs 之间的集成问题， FACE 数据模型语言提供了一些元素，用于描述要在传输服务实例中体现的高级连接、路由和转换。
FACE 技术标准包含 FACE 数据模型语言的不同表示 :
• 从元模型生成的文本列表 ;
• 从元模型导出的可扩展标记语言 (XML) 元数据交换 (XML) 清单，需要符合相应的 EMOF 。
数据架构治理
《 FACE SDM 治理计划》规定了 FACE SDM 配置控制委员会 (CCB) 的权限和运行参数。 FACE SDM 治理计划通过扩展管理增长，并确保新 SDM 元素的必要一致性。 SDM 由基本元素和概念数据模型 (CDM) 、逻辑数据模型 (LDM) 和平台数据模型 (PDM) 中的任何扩展组成。 FACE SDM 治理计划为 FACE SDM CCB 、供应商和系统集成商详细描述了一个完整的过程、一套规则以及角色和职责。
1.2 FACE 的参考体系结构段示例
如下是一个基于 FACE 架构的应用示例： 
示例说明：
有一个简单的系统，接收来自全球定位系统 (GPS) 设备的导航数据，通过 MIL-STD-1553 接口硬件向显示器提供自有船舶位置符号。该软件被实现为几个为重用和可移植性而设计的组件。
下面描述 示例系统内部各个 FACE 部分之间的关系：
| 位置 |
功能 |
| 外部设备 |
在 FACE Boundary 之下， GPS 设备收集传感器数据，并以特定于设备的格式将导航数据传递到符合 MIL-STD-1553 的总线上。设备驱动程序被写入特定的 MIL-STD-1553 硬件，数据格式是特定于 GPS 设备的。
|
| OSS |
在“ FACE Boundary” 内， OSS 提供了一套公开的 API 和 FACE 的操作系统服务。这可以支持符合 FACE 的操作系统接口规范的软件在不多个不同的 FACE 操作系统实现之上运行。
|
| IOSS |
使用通用的操作系统 API 可以访问来自设备驱动程序的数据，在访问的时候可以由 IOSS 中的服务将唯一实现转换为标准化格式，以抽象 MIL-STD-1553 设备的唯一性。这种抽象允许使用相同外部设备的软件部署在使用不同 I/O 设备的系统上。
|
| PSSS |
I/O 服务通过 FACE 技术标准定义的标准化接口将这些数据传递给 PSSS ，在本例中是 GPS 平台设备服务。此设备服务提供特定 GPS 通信的抽象，通常在该设备的 ICD 中描述，并根据 FACE 数据体系结构将此数据转换为标准结构和语义。
|
| TSS |
该数据由 Transport Service Capability 和 Distribution Capability 根据配置传输到需要该数据进行处理的软件组件，在本例中是 Own Ship Position PCS 组件。在这个例子中，传输服务利用 OSS 提供的传输机制，特别是 POSIX 套接字。所有进出 PCS 的数据都通过 TSS 路由。
|
| PCS |
这个 Own Ship Position 组件计算图形符号，并使用定义良好的图形语言通过传输服务将其发送回来。在本例中， TSS 被配置为将这些图形消息分发到 PSSS 中的特定于平台的图形服务。然后，特定于平台的图形服务通过图形驱动程序绘制到显示器。
|
这个场景强调了如何使用 FACE 参考体系结构来隔离对系统的更改。例如：
• 如果将 GPS 设备替换为不同的 GPS ，则将替换或修改相关的平台设备服务。
• 如果 MIL-STD-1553 总线被更改，那么 I/O 服务将被替换或修改。
• 如果传输机制被更改，则传输服务将被替换或修改。
在所有这些情况下，可移植组件都与这些更改隔离。
1.3 编程语言运行时（ Programming Language Run-Times ）
为了实现 FACE 参考架构的目标，编程语言运行时也需要考虑。 FACE 技术标准对编程语言进行了限制。使用标准化的编程语言是建立可移植性的基础。 FACE 编程语言运行时机制选择 C 、 C++ 、 Ada 和 Java 这类比较通用的编程语言作为可选的编程语言。编程语言运行时可以作为 OSS 的一部分提供，或者包含在驻留在另一个部分的软件组件中。
操作系统和软件组件之间的接口可以用编程语言运行时代替或增强。 POSIX API 集通常以编程语言运行时的形式提供。
1.4 组件框架 （ Component Frameworks ）
FACE 技术标准支持组件框架的使用。组件框架为软件组件提供支持功能。在 FACE 参考架构中使用组件框架有三种方法 :
• OSS (Operating System Segment) 提供的组件框架
组件框架是作为 OSS 的一部分提供的。由 OSS 提供的组件框架扩展了 OSS 接口，以包含组件框架自己的 API 。 OSS 提供的组件框架仅限于 OSS 接口要求中指定的组件框架，
• PCS 或 PSSS UoC 内部的组件框架
完整的组件框架是 PCS 或 PSSS UoC 的组成部分，并遵循允许的 PCS 和 PSSS 接口。这种方法利用了组件框架开发的便利性，并允许 FACE 对齐，但可能会对性能、集成和 / 或资源产生影响。
• 实现了 FACE 参考架构的组件框架
跨多个 FACE 段使用的组件框架实现了框架支持能力 (FSC) 。 FSC 是一个抽象，它将组件框架接口转换为面向 FACE 的接口。 
OSS 和 TSS 支持通用框架，允许被开发的软件同时符合组件框架和 FACE 技术标准。
1.5 操作系统段 Profile
FACE 参考架构定义了三个 FACE OSS Profile ，以便裁剪操作系统 (OS) API 、编程语言、编程语言特性、运行时、框架和图形功能，以满足不同级别的关键软件组件的需求。三个 FACE OSS Profile 是 :
• Security
• Safety
• Base
• Extended
• General Purpose |
OS API 和每个 profile 的限制如下图所示：
Figure 3: FACE OSS Profile Diagram
下面对各个 FACE OSS Profile 说明：
| FACE OSS Profile |
说明 |
| Security profile |
将操作系统 api 限制为最小的有用集，允许评估在单个地址空间 ( 例如， POSIX 进程或 ARINC 653 分区 ) 中执行的高保证安全功能。 Security Profile 需要 ARINC 653 支持。
|
| Safety Profile |
Safety Profile 的限制比 Security Profile 少，并将操作系统 API 限制为具有安全认证族谱的 API 。 Safety Profile 由两个子 Profile 组成：
• Safety Base Sub-profile 支持单个 POSIX 进程应用程序，具有比 Security Profile 更广泛的操作系统 API 集。
• Safety Extended Sub-profile 包括所有的 Safety Base Sub-profile OS APIs ，以及额外的 OS APIs 和对多个 POSIX 进程的可选支持。
Safety Profile 需要 ARINC 653 支持。
|
| General Purpose Profile |
General Purpose Profile 是约束最少的 Profile ，它支持满足实时确定性或非实时非确定性需求的操作系统 api ，具体取决于系统或子系统的实现。 ARINC 653 支持和多个 POSIX 进程是可选的
|
提示：尽管 Security 和 Safety Profiles 的命名反映了它们的主要设计重点，但它们的使用并不局限于具有这些需求的服务 ( 即，没有 safety 或者 security 设计关注点的软件组件可以被限制仅使用这些 Profile 之一的操作系统 API) 。
1.6 UoC 和 UoP （一致性单元和可移植性单元）
一致性单元 (UoC) 是一个软件组件或特定于领域的数据模型，旨在满足 FACE 技术标准中定义的适用需求。它在其开发的任何阶段都被引用为 UoC ，并在完成 FACE 一致性过程后成为 FACE 认证的 UoC 。 FACE 技术标准包含每个 FACE 段和每个 FACE OSS Porfile 中的 UoC 的单独要求。
可移植性单元 (UoP) 是驻留在 PCS 或 PSSS 中的 UoC 。 
图． PCS 中 UoC 之间和 UoC 内部的通信
UoC 包可用于包含由多个 UoC 组成的功能。可以按照 FACE 的 UoC 规范要求开发符合 FACE 技术标准的 UoC 封装。
后记
希望您读了此文后有所受益。
如果您有经验乐于分享，欢迎投稿给我们。
如果您对我们的培训、咨询和工具感兴趣：
课程：
工具：
咨询方案：
如果您希望了解更多信息：
作者简介：
| 俎涛，火龙果软件工程创始人， 2001 年创立了火龙果软件工程， 2004 年创立了 IBM Rational 用户组. 1998 年，曾作为骨干参与国家重点研究课题《面向特定领域基于组件的软件复用》，有幸比较深入的学习和使用的 UML 进行领域建模、提炼可复用组件和架构.在后来的研发项目中，一直采用模型进行分析设计，积累了一些心得和经验.在以往的经历中，最大的感触是汇聚了很多精英人才的软件工程和系统工程领域居然几十年都是一种凌乱迷蒙的状态，从自己的经历所得，觉得清晰的模型，才是拨开工程迷雾的关键所在，所以不断研究和应用各种建模技术，并从自己的工程实践中提炼经验，形成对于自己可持续的方法论，例如《 Nature Model Language- 自然建模语言》《基于模型的三维研发管理》《 iProcess 过程改进方法》《基于模型的需求管理》《模型驱动的架构设计》《基于模型的质量管理》《基于模型的人员能力管理》，目前正在作为产品经理和架构师，进行 MBSE （基于模型的系统工程）平台的研发，希望建立要给基于模型的工程解决方案，后续会不断写些文章，希望能给同行一些借鉴.
|
| 
