机载软件的高保证性和可重用性

DO-178C和FACE（未来机载能力环境）方法形成了一个自然的结合，使开发人员能够结合军事和商业领域的机载软件生产的最佳实践。通过根据 DO-178C 及其补充文件中提供的指南开发和验证软件组件，FACE 组件提供商可以实现其 FACE 可移植性目标，同时实现高 DAL ［设计保证级别］ 可靠性和安全性。

FACE ［未来机载能力环境］ 方法是一种政府-行业软件标准和商业战略，用于获取负担得起的软件系统，旨在促进全球国防计划中便携式功能的创新和快速集成，从而降低系统生命周期成本。但是，FACE技术标准并未直接解决质量或适用性问题。特别是，尽管FACE技术标准定义了与保证相关的语言子集（“安全功能集”），但软件组件遵守这些子集之一并不一定意味着达到了相关的保证水平。在军事背景下证明这种保证涉及遵循MIL-HDBK-516C（适航认证标准）或MIL-STD-882E（安全实践）等标准的指导。

就这些标准而言，它们并不完全关注软件问题，也没有解决现代技术（如基于模型的工程、面向对象编程和形式化方法）提供的挑战（或机遇）。FACE组件开发人员可以利用的一种方法可以帮助实现相关的保证水平，方法是遵循RTCA DO-178C标准（及其补充）中针对商用机载系统所体现的原则。这些标准以软件为重点，涵盖现代技术，识别潜在问题及其解决方案。即使没有进行DO-178C的正式认证，这些标准也可以帮助开发人员满足最苛刻的可靠性和安全性保证要求，同时通过重复使用FACE应用程序组件实现成本节约。当使用编程语言技术（如 Ada 和 SPARK）时，这些优势会得到放大，这些技术最能支持高保证系统的开发和验证。

人脸技术标准

FACE技术标准是在The Open Group FACE联盟的支持下制定的开放标准，当前版本是3.0版;几个早期版本（2.0、2.1、2.1.1）也在使用中，并且受支持。FACE 技术标准定义了一个由五个段（图 1）和数据架构组成的参考架构：

操作系统段 （OSS） 为其他段提供软件基础，包括分区、进程/线程管理和内存管理等服务。

输入/输出服务段 （IOSS） 定义从 PSSS 到平台 IO 设备的接口。

特定于平台的服务段（PSSS）定义了从PCS到IOSS的接口，例如图形支持。

传输服务段 （TSS） 定义 FACE 组件之间的通信接口。

便携式组件段 （PCS） 提供应用程序功能，并通过仅使用其他段中定义的接口来实现可移植性。

图1|FACE技术标准定义了一个由五个段和一个数据架构组成的参考架构。

FACE 参考架构的基础是 OSS，它通过 ARINC 653 和 POSIX API ［应用程序编程

接口］ 公开标准接口。编程语言的运行时库通常也是 OSS 的一部分，尽管它们不是通过 API 调用（可能无法在不同的编译器实现中移植）而是通过源语言语法调用的。

由于符合 FACE 标准的组件可以部署在具有不同安全和/或安保要求的上下文中，因此 FACE 技术标准为 OSS 接口定义了几个配置文件：

通用 – 对于不需要高级别保证的组件：不保证实时确定性，可选时间分区，需要空间分区。

安全 – 对于需要安全保证的组件：实时确定性，需要时间/空间分区。子配置文件安全基础和安全扩展反映了允许的 API。

安全性 – 对于需要安全和安保保证的组件：实时确定性，需要时间/空间分区。

FACE组件可以通过语言语法实现运行时功能，而不是在ARINC 653或POSIX API上显式调用，因此FACE技术标准定义了类似于OSS配置文件的语言限制（“功能集”）。为 C、C++、Ada 和 Java 定义了通用、安全扩展、安全基础和安全功能集。（FACE技术标准版3.0定义了Ada 95的安全和安保功能集;版本 3.1 为 Ada 2012 添加了这些集。

应用 DO-178C 原则

虽然DO-178C及其补充品是为应用于商业机载系统而开发的，但这些标准不一定是特定于军用或商业航空的，并且可以用于其他安全关键领域。该指南基本上涉及三个主要目标：

可靠性 – 系统执行其应执行的操作（无故障）

安全 – 系统不做它不应该做的事情（没有危险）

良好的软件工程实践 – 配置管理、质量保证等

该标准没有规定具体的开发流程、危害评估方法或编程语言/工具，而是定义了目标，当满意时，可以确信软件满足这些目标。事实上，大多数目标都与验证过程有关：人工审查、自动分析和基于需求的测试，以适当的信心表明每个生命周期过程的输出相对于其输入是正确的。置信度（以及实现置信度所需的努力）取决于软件的设计保证级别 （DAL）。

软件组件的正式 DO-178C 认证可能很昂贵，尤其是在更高的 DAL 上。然而，在需要这种认证的商业航空领域之外，DO-178C可以更普遍地被视为生产安全关键系统的“最佳实践”规范。从这个角度来看，该指南与FACE技术标准的要求是正交的，并且是一致的。通过采用和/或调整基于软件DAL的DO-178C指南，FACE应用程序开发人员 - 更具体地说，便携式组件部门的软件开发人员 - 可以在不进行正式认证的情况下获得DO-178C提供的大部分好处。

图2|DO-178C及其补充剂是为机载系统和其他安全关键领域而开发的。

编程语言技术

DO-178C 的“软件生命周期环境规划”部分抓住了错误预防的本质：

。..选择限制引入错误机会的需求开发和设计方法、工具和编程语言，以及确保检测到引入错误的验证方法。

由于早期错误检测是降低开发和验证成本的关键，因此 FACE 应用程序开发人员需要仔细考虑使用哪种语言和工具。在具有 FACE 技术标准中定义的功能集的语言中，Ada 在编译时和运行时都强制执行最广泛的检查。Ada的形式可分析的SPARK子集更进一步，静态检测大量错误（包括不正确的信息流和缓冲区溢出），而不会产生大量的“误报”。

语言和 API 限制

DO-178C 制导对 FACE 组件开发的适用性在 FACE 功能集中得到了证明。尽管通用集可能适用于低 DAL 的软件，但 DAL C 到 A 的组件可能需要限制为简单的语言子集（安全扩展、安全基础或安全），以确保确定性执行和简单的运行时支持。确定性和简单性的要求既适用于应用程序代码本身，也适用于与应用程序隐式链接的任何运行时库（由 RTOS 或编译器供应商提供）。

例如，FACE 技术标准版 3.0 中 Ada 95 的安全扩展功能集禁止异步控制转移、动态存储释放和许多预定义的标准库;它还将并发（任务）支持限制为 Ravenscar 配置文件中定义的构造。安全基础和安全功能集进一步限制了运行时功能，将异常支持限制为“最后机会”处理程序，并禁止动态分配。遵守功能集限制（或为操作系统段配置文件定义的 POSIX 和 ARINC 653 API）有助于简化安全关键型软件的验证，同时满足 FACE 要求。

合格、值得信赖的工具

使用软件工具自动化、减少或消除活动可以降低成本并防止错误，但前提是该工具值得信赖。在DO-178C的说法中，该工具必须在适当的级别进行鉴定。DO-178C 根据工具异常的影响和软件组件的 DAL 定义了五个工具资格级别，TQL-5（最低）到 TQL-1（最高）。无论 DAL 如何，影响仅限于无法检测到错误的工具都需要根据 TQL-5 的要求进行限定。在另一个极端，输出是 DAL A 机载软件一部分的工具必须在 TQL-1 上合格。（由于工具中的异常可能会导致可执行文件中的错误代码，因此在没有此类异常的情况下需要很高的置信度。各种 TQL 的具体要求在补充 DO-178C 的 DO-330 工具资格考虑标准中定义。

符合相关 TQL 的工具可以信任用于 FACE 组件开发或验证;资格证明可以证明依赖该工具是合理的，而无需手动验证工具的输出。例如，DO-178C 的目标之一是“源代码符合标准”，对于安全关键型 FACE 组件，相关标准将是相关的功能集定义（安全扩展、安全基础、安保），可能通过项目特定的限制进行增强。检查源代码是否保留在生成的子集中的合格静态分析工具可以减少验证工作。

源代码的准确性和一致性

DO-178C 中的关键验证目标之一涉及源代码的审查和分析：

准确性和一致性。目的是确定源代码的正确性和一致性，包括堆栈使用情况、内存使用情况、定点算术溢出和解析、资源争用和限制、最坏情况执行时间、异常处理、未初始化变量的使用、缓存管理、未使用的变量以及由于任务或中断冲突而导致的数据损坏。编译器（包括其选项）、链接器（包括其选项）和某些硬件功能可能会对最坏情况的执行计时产生影响，应评估这种影响。

FACE组件开发人员需要警惕这些问题，并认识到选择合适的编程语言和工具的重要性。例如，在运行时在 Ada 中检测到整数和定点溢出，并且使用 Ravenscar 配置文件进行并发（所有 Ada 功能集都允许这样做，并且受可在 DO-178C DAL A 认证的运行时库支持）可以帮助防止数据损坏。SPARK 静态分析工具可以检测未初始化变量的使用、未使用变量的出现、整数和定点溢出的可能性以及许多其他错误。

使用以前开发的软件

FACE方法基于重用;在需要高保证的情况下，问题是当软件组件在不同于最初认证的环境中使用时，如何获得足够的置信度。

一个问题是确定组件的 DAL（因此，对于 FACE 组件，要使用的 OSS 配置文件/语言功能集）以及随之而来的生命周期要求。为了获得最大的可重用性，应在设想其使用的最高 DAL 下开发和验证组件。

另一个实质性问题是如何获得信心，即在一个系统中已被证明满足相关生命周期目标的组件将满足另一个系统中的相关目标。DO-178C 为几种情况提供了具体指导：当重用涉及软件修改、飞机安装更改、应用程序或开发环境更改或升级到开发基线时。其中每个项目的基础活动都是全面的影响分析，以在整个软件生命周期中识别组件在新上下文中重新部署的影响（包括对已知问题的分析）。例如，将相同的源代码移植到新处理器将需要重新验证最坏情况的执行时间假设、足够的堆栈空间预留和类似的属性。通过使用合格的工具可以减轻这种重新验证。

专业技术

现代软件技术（如基于模型的工程、面向对象和形式化方法）为机载软件的开发人员带来了许多好处，但它们也可能导致复杂性。例如，动态绑定简化了某些设计模式，但也使演示正确的数据依赖关系变得更加困难。DO-178C的技术补充直接解决了这些问题，并展示了如何解决潜在的问题。

FACE方法侧重于离散可重用软件组件的软件可移植性，将可靠性和安全性要求委托给其他标准。DO-178C专注于系统或子系统级别的软件可靠性和安全性，将可移植性（使用先前开发的软件）视为相关问题的“附加考虑因素”，而不是要求。这两种方法是相辅相成的，是一致的。通过根据 DO-178C 及其补充文件中提供的指南开发和验证软件组件，FACE 组件提供商可以满足 FACE 可移植性目标，同时实现高 DAL 可靠性和安全性。

DO-178C指南的一个关键要素是及早发现错误。面向软件工程的语言（如 Ada 和 SPARK）由合格的工具和可认证的运行时库（如 AdaCore 提供的库）提供支持，可以简化安全认证，同时实现 FACE 组件重用。DO-178C和FACE方法形成了一个自然的结合，允许开发人员结合商业和军事领域的机载软件生产的最佳实践。

审核编辑：郭婷