FACE组件:可以互换但不完全等同

新闻动态

FACE组件:可以互换但不完全等同

- 风河公司Alex Wilson、Rapita系统公司Steven H. Vander Leest

引言

The Future Airborne Capability Environment (FACE™)联盟将在2021年3月举办年度技术交流会议和展览会。做为活动前导,Wind River和Rapita Systems正在普及一些关于FACE架构的背景知识,重点介绍我们关于可移植单元(UoP)的“一站式”生态系统,以及基于FACE技术标准的测试、集成和认证的系统工具。第一篇文章介绍了“操作系统部分如何适应FACE架构”,这是该系列的第二篇博文。

美国国防部一直致力于推动开放式架构解决方案的应用,以便行业能够以更短的时间、更低的成本用到更好的航空电子硬件。这种解决方案的一个来源是the Future Airborne Capability Environment (FACE™)联盟,该联盟发布了一个开放式架构技术标准以及在航空电子系统中实现该标准的商业模型。FACE联盟发布的出版物也是公开可用的,可以免费下载。

本文是该系列的第二篇博文,我们将重点讨论开放式架构中模块化的好处,并讨论不同供应商提供的不同产品的特性,还会重点讨论FACE架构的操作系统部分(OSS)组件。就OSS而言,Wind River公司在保持模块化的同时又极具竞争优势。这种优势部分来源于一个丰富的工具生态系统,它可用于验证系统的性能并为适航性提供可信的证据。由于OSS是架构的基础,因此它的生态系统必须与操作系统紧密结合。例如,多核航空电子系统的飞行认证要求确保多核干扰信道已得到抑制。The Rapita Systems CAST-32A Compliance Package通过验证和核实系统的工具及组件提供了这种保证。

FACE模块化使模块互换成为可能

FACE标准的模块化概念提供了一个参考体系结构,该参考体系结构基于段(Segment),将不同的段集成即可满足最终系统的需求。每个段的内容,包括应用程序代码在内,是可以变化的,这就允许系统架构师灵活地设计和构建基于兼容模块的最终系统。FACE标准定义了这些段之间的逻辑接口,以实现模块化。这促进了软件组件的重用,并使跨军事系统的通用功能实现成为可能。通过使用已定义的API标准(如我们之前的博文中所述),可以方便地在不同供应商开发的符合要求的系统之间移植组件。

为了确保段(Segment) 能够以模块化的方式应用,以适用的FACE标准对组件进行测试就显得至关重要。可以通过检查组件是否符合作为“一致性单元”或“UoC”的FACE技术标准来验证一致性。(术语“可移植单元(Unit of Portability)”有时用来代替“一致性单元(Unit of Conformance)”,以突出这些组件的可移植性。) 具体做法是:运行FACE Conformance Test Suite,通过FACE Verification Authority和FACE Certification Authority的审查来实现一致性认证,并在FACE Registry上向FACE Library Administrator注册结果。

以下是两个根据不同FACE Profile测试的“一致性单元”(UoC)一致性合格证书的例子:

如果系统架构师开始设计一个系统,并且需要使用一个具有特定配置文件的操作系统,那么他们可以查看FACE Registry并选择一个已经根据该配置文件进行认证的“一致性单元”(UoC)。FACE技术标准有多个历史版本,因此注册的每个产品都会指定一个版本号。所示证书标示了“一致性单元”(UoC)的“通用配置文件”和“安全基础配置文件”,它们都符合“技术标准3.0”。

系统架构师通常会选择几个“一致性单元”(UoC)集成到最终软件系统中。需要注意的是,多个“一致性单元”(UoC)可以在同一个处理器地址空间中共存,因此对这些“一致性单元”(UoC)集成方面的考虑和协调显得非常重要,集成时对于性能和干扰方面的挑战尤其如此。FACE一致性测试仅就OSS配置文件对“一致性单元”(UoC)进行检查,并且只在单元内部进行,并不涉及所有的软件功能或性能。需要强调一点,如果您同时调用几个“一致性单元”(UoC),那么您还需要在这些单元之间进行通信,这就需要使用FACE Transport Services接口。下图展示了符合FACE技术标准3.0规范的UoC通信。

模块可互换性的好处

FACE模块化的设计非常契合开放系统架构(OSA)的理念。OSA的方法具有以下几个方面的商业价值:

  • 更强的购买力
  • 可持续的支付能力
  • 更快的部署时间
  • 快速地进行功能扩展
  • 软件复用程度更高

有趣的是FACE联盟早期决定开发的不仅仅是技术标准,还包括一个业务标准,为FACE方法的价值主张和业务案例提供指导。它目前的版本是2.0,可以在FACE Documents网站上找到。

“一致性单元”(UoC)通过了FACE标准的一致性认证之后,系统集成商在选择这些单元时也更有信心——他们可以将任何供应商的某种UoC引入他们的系统,它应该“开箱即用”地与其他组件一起工作。这将产生诸多商业价值:组件重用、快速地进行功能扩展和更强的负担能力,因为UoC的开发成本会被分摊到多个项目中。另一个好处是系统集成的成本也会更低,因为在标准中UoC之间定义了界限清晰的层。

供应商之间产生的竞争,可以为他们带来更多的价值和能力专长,同时仍然符合FACE标准。反过来,这也使政府采购机构在寻找替代或补充解决方案时具有更强的购买力。

与此同时,这意味着政府不再局限于一家供应商,并打破了供应商锁定,政府可以自由选择最佳解决方案,而不是被迫使用同一家供应商。

对于生产产品的供应商来说,他们也获得了跨项目标准化的好处,减少了开发成本和可能影响多个计划的进度延误。组件的重用意味着更好的投资回报,并允许供应商专注于他们的核心优势和创新。

然而,拥有符合标准的功能组件并不能为您提供所需要的一切。每个组件都有不同的性能、质量、认证工件和工具,同时也都有不同的业务模型和生命周期支持解决方案。在做最后的选择时,必须把这些都考虑进去。

可互换性是最低要求

在日常生活中,可互换部件的好处是显而易见的。公制扳手都匹配公制套筒。街上合法的汽车都能在公路上行驶。对于扳手和汽车来说,这种标准化的好处是显而易见的。这种思路对于软件的好处也是显而易见的。然而,可互换部件设置了最低要求。所有的扳手都应该匹配它们的套筒,所有的汽车都应该适合道路。而且,不同扳手的强度和耐用性各不相同,不同汽车的最高速度和燃油效率也各不相同。同样,对标准化软件来说,可互换性也是最低要求。一个被证明符合FACE技术标准的OSS仅仅被证明“适合道路”。具体来说,标准规定的应用程序编程接口(API)确认了构成系统的软件组件能够正确地组合在一起并相互通信。然而,这种兼容性本身并不能说明组件的质量,比如它的速度或效率。

因此,通过符合标准(如FACE技术标准)而实现的可互换性是进入FACE市场的入场券,但这只是最低要求。满足为一个特定的FACE UoC组件而设的起始标准的供应商都处于同一个公平的竞争环境之中。例如,寻求FACE OSS的客户可能会基于以下因素做出购买决定:

  • 性能:不同供应商提供的组件在性能指标方面会有所不同,例如端到端延迟、响应时间、确定性、可靠性等。
  • 认证:符合FACE技术标准可能会提供一些对证明适航性有用的测试和工件,但这只是一个开始。供应商提供的支持飞行认证的软件包将有所不同。在这一点上,FACE EA-25小组委员会目前正在起草一份白皮书,就哪些FACE活动和工件可能有助于飞行认证证据提供更详细的建议。
  • 生态系统:各个供应商提供的工具会有很大的不同。特别是对于OSS来说,一个丰富的工具生态系统对于系统的成功开发和集成是非常重要的。FACE技术标准所提供的标准化有时意味着工具可以跨任何供应商的产品工作,但情况并不总是这样,因为工具也可能需要在后台进行连接。示例工具包括集成开发环境(IDE)、调试工具、测试工具(包括单元、系统、基于需求的测试工具)、结构覆盖分析工具、时序分析工具、需求跟踪工具等。

Wind River与Rapita Systems等生态系统合作伙伴可以帮助您构建具有您所需性能和确定性的FACE系统,以及获得经济高效的飞行授权所需的保证工件。

确保分区

FACE标准要求进行分区

FACE标准要求在其功能安全性和信息安全性配置文件中支持时间和空间分区。分区是一种在许多类型的计算系统中使用的隔离技术。这种技术支持模块化,例如在综合模块化航空电子系统(IMA)中就使用了分区技术。将不同应用程序分区所获得的分离特性对于实现FACE标准的承诺至关重要。

随着功能强大的多核处理器的出现,使用分区来隔离关键应用程序的趋势正在加快。综合模块化航空电子系统(IMA)架构是为了克服商用飞机中的空间、重量和功率(交换)问题而开发的,在该架构中,单核处理器通过对时间和空间分区实现了在不同临界点承载应用程序的能力。这是为了满足当时某些机型对通用机身越来越高的性能要求,比如空客A380和波音787。然而,在单核系统中,多个应用程序共享CPU资源(时间切片),虽然这达到了IMA架构的目标,但也影响了分配给应用程序的性能。对于最新的多核应用程序,可以通过跨多核分配来减轻这种性能影响。同时,多核技术的应用对保证适航性提出了新的挑战。

FACE标准并不强制要求进行分区

尽管FACE技术标准要求在其几个定义的配置文件中进行分区,但该标准只需要一个到分区操作环境(ARINC 653)的接口。它不需要确保环境正确地实现了隔离机制,尽管这些机制提供了分区的主要好处。这么做是有道理的,因为FACE技术标准旨在促进互换性和模块化。它不是飞行认证的替代品,而只是一个起点。FACE EA-25适航性小组委员会目前正在撰写一份白皮书,以“确保符合FACE的软件、相关工件以及生成它们的过程……明确引用通用要求、处理方法和指导,尽可能地为适航性提供证据。”

系统集成商应该明智地从设计的最初阶段就考虑到证明适航性的重大障碍,特别是对于总体架构的核心特性,例如分区。正确实现分区后,分区简化了集成和认证,因为每个分区总是可以被视为独立工作的。然而,这种方法对分区本身有非常严格的要求。严格的分区隔离并不是可以在最后才附加的东西:它必须从一开始就作为一个基本的设计特性被包含进来。在美国和欧洲,民用飞行软件的认证遵循RTCA DO-178C/ED-12C标准。DO-297和ARINC 653标准提供了分区环境的指导,以隔离独立的软件功能。军用适航性主管当局采用类似的方法来评估软件。

对于使用多核处理器的计算平台来说,确保分区隔离的挑战更大。在单核处理器上,每次只能运行一个分区,从而提供了某种自然的隔离。在多核处理器上,分区可以同时运行在不同的核上,从而在功能之间产生多个潜在的干扰信道。多核干扰会降低分区之间的隔离性,因此必须加以抑制。这是一项相对较新的技术。美国联邦航空管理局(FAA)目前在一份意见书《CAST-32A》中提供了确保多核系统安全的指南。美国联邦航空管理局(FAA)和欧洲航空安全局(EASA)预计将在明年的某个时候发布进一步的指导意见。

结束语

符合FACE技术标准,就能证明产品具有兼容性和互换性,为竞争产品参与公平竞争奠定了基础。明智的OSS买家会要求这样的一致性,随后他们会仔细评估符合要求的产品的特性,如性能、分区的稳健性和飞行认证工件的质量。

这可能会使我们面对以下问题:在由FACE UoC组成的系统中,确保分区的步骤是什么? 什么样的最佳实践成本效益高并且能成功获得飞行认证?这是本系列下一篇博文的主题。敬请期待!

Wind River和Rapita Systems可以帮助您利用我们的“一站式”生态系统构建您的FACE系统,从Wind River OSS开始,包括基于FACE技术标准的测试、集成和认证的系统工具,如Rapita Systems验证套件和CAST-32A合规包。关注更多关于这个话题的博文,为下一个FACE TIM做准备。

关于作者

Alex Wilson是风河公司航空航天和国防市场总监,他负责欧洲、中东、非洲、亚太地区和日本的A&D市场。作为风河公司航空航天和国防工业解决方案团队的一员,Alex负责经营策略,包括产品需求、销售增长策略和生态系统开发。

Steven H. VanderLeest是Rapita Systems公司多核解决方案的首席工程师。他曾在IEEE数字航空电子系统会议和SAE Aerotech上发表有关航空电子安全与保障的文章。VanderLeest博士还是FACE EA-25适航性委员会的副主席。

注:本博文所表达的观点仅为作者个人观点,并不代表FACE联盟的官方立场。