了解ARINC 661及其在认证环境中的优势

在过去十年中，由于认证规则（DO-178B）在军事项目上的更广泛应用，以及不断推动在更短的期限内交付，创建飞机驾驶舱显示器的任务变得越来越困难。更复杂的是，行业中的许多参与者使用自己的开发方法，除了开发人员和人为因素工程师的说明外，几乎没有关于内容的指南。

由于缺乏基于标准的方法，导致内部开发或通过使用商业工具开发的单一应用程序激增。无论进行哪种类型的更改，这些应用程序始终需要作为一个整体重新认证。在商业工具之间交换数据通常也很困难，这使得飞机制造商在飞机的生命周期内考虑更换系统的供应商或在使用不同软件架构构建的项目之间重用显示元素是一项挑战。

在90年代后期，成立了一个由行业代表组成的委员会来解决这些问题，并为飞机航空电子设备的创建制定了标准和灵活的架构，该架构成为ARINC规范661：驾驶舱显示系统与用户系统的接口。今天，ARINC 661被用于空中客车A380和A400M，波音787和AgustaWestland Merlin直升机升级等项目。

在了解了ARINC 661标准及其架构之后，我们将了解ARINC 661的驾驶舱显示系统（CDS），用户应用程序（UA）和小部件，以及它们带来的好处 - 特别是对于需要认证的项目。

ARINC 661 架构概述

虽然驾驶舱显示软件传统上被编写为独立的可执行文件，根据内部数据、规则和逻辑呈现信息和渲染图形，但 ARINC 661 在绘制图形的代码和管理逻辑以及所有可视元素的位置和状态的代码之间引入了明确的分离。这两个组件是 CDS 和 UA。

此外，ARINC 661 将 CDS 定义为运行时解释器，能够根据外部布局文件中包含的信息显示来自称为小部件的有限构建块库中的一个或多个元素。最后，ARINC 661定义了CDS和UA交换消息的标准通信协议。图 1 显示了 CDS 和 UA 之间的关系，以及它们的典型执行环境和这两个应用程序之间的通信。它还显示多个 UA 可以与 CDS 通信。在这种情况下，每个 UA 可以单独开发，并负责更新和响应显示器特定部分的事件。

图1：ARINC 661架构的主要组件：驾驶舱显示系统（CDS）和用户应用（UA）

此体系结构的一个直接好处是，对显示组合的更新是通过创建新的布局文件来完成的，而不是在统一应用程序中修改代码。在认证环境中，这意味着无需重新编译或重新认证 UA 和 CDS 代码即可进行视觉布局更改，例如重新定位或更改显示元素的视觉属性。同样的好处也适用于对应用程序逻辑流的更改，这只会导致对特定用户应用程序的更改，而 CDS 代码库和其他用户应用程序不受影响。

除了隔离的好处之外，这种方法还简化了组织内不同团队之间或分包商之间应用程序开发的分布。

近距离观察：CDS 和 UA

仔细观察典型的 ARINC 661 应用程序执行流程，CDS 会基于一个或多个称为定义文件 （DF） 的布局文件加载和显示小部件。每个 DF 都包含一个或多个图层，这些图层是需要加载的所有微件的分层列表及其初始参数，例如位置、大小和可见性。它们以二进制格式本机存储，该格式在运行时加载到 CDS 应用程序中。该标准还定义了XML交换格式，以促进DF检查，修订控制和共享。

向下移动一个级别，附加到 CDS 的物理显示器分为一个或多个子部分，简称为窗口，每个子部分可以渲染一个或多个图层。这些窗口不能有任何重叠，并将堆叠指定的图层以创建最终结果，该结果将在屏幕上显示给飞行员或操作员。图 2 说明了此层次结构。

图2：CDS 视觉层次结构

在运行时，CDS 处理试点输入并确定这些交互是否可以在本地处理（例如，当光标放在小部件上时需要突出显示 CheckButton）和/或是否应将它们传输到 UA（例如，按下 CheckButton）。在后一种情况下，事件将发送到相应的 UA，以根据当前系统状态和事件类型确定响应。UA（s）通常还会向CDS发送稳定的消息流，以更新向飞行员提供信息的所有屏幕元素的位置。

在认证方面，这种详细的显示架构大大简化了高低级要求的创建。对定义文件使用标准XML交换格式也使内容开发人员可以灵活地使用来自多个供应商的CDS系统，因为他们认为合适的工作可以加载到任何符合ARINC 661标准的CDS中。还可以通过仅更改 CDS 库中小部件的视觉外观，在新项目中重用定义文件和系统用户应用程序的大部分内容。

标准小部件库

ARINC 661 规范没有绑定到特定工具的应用程序构建组件，也没有在内部为项目创建自定义组件架构，而是引入了 42 个可用于创建显示的小部件。随着标准的第一次更新，这个数字上升到50，在补充2中上升到57，在修订版3中上升到65，在今年早些时候发布的最新版本上升到68。

小部件的复杂性各不相同，从基本的图形元素（如 GpLine 和 GpRectangle 小部件）到复杂对象（如显示来自各种数据源的地图的 MapHorz 小部件）。还有一些小部件没有任何可视化表示，用于将其他元素组合在一起并对其应用转换。最后一个类别中的一个示例是互斥容器小部件，它将多个元素分组到单个父元素下，但一次只显示其直接子元素之一。

虽然 ARINC 661 描述了小部件应该如何工作以及它们的参数是什么，但它并没有定义它们的视觉外观。这使显示器制造商可以完全自由地为给定项目实现自己的外观和感觉。标准中还有一项规定，允许开发人员创建具有定制功能和参数的自定义小部件，这些功能和参数仍遵循通用小部件创建模式。

拥有一组标准的小部件来开发显示器，使开发人员可以轻松熟悉 ARINC 661 标准并快速了解如何开发新显示器。此外，与直接与高级需求相关的整体ARINC 661架构类似，拥有一组具有良好记录功能的标准小部件有助于加速认证项目的低级详细功能需求的文档记录。

ARINC 661 的未来

虽然此体系结构的实现可能看起来有点令人生畏 - 考虑到需要建立一个兼容的CDS运行时软件体系结构，遵守规范的功能小部件库，以及促进创建定义文件及其输出到标准二进制文件的工具 - 应该注意的是，COTS工具可用于提供这些功能开箱即用。在某些情况下，这些工具甚至是合格的开发工具，可以在DO-178B下生成合格的代码。在看到一些大型商用飞机引领潮流后，许多商业和军用项目正在考虑或已经在其即将开展的项目中采用ARINC 661，以确保该标准的成功。

审核编辑：郭婷