作者 | 蔡喁 上海控安可信软件创新研究院副院长

版块 | 鉴源论坛 · 观擎

社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

01

源头和现状​​​​​​​

在越来越多的国产机载系统研制中，操作系统软件的选择对后续开展研制以及适航举证活动带来很大的影响。与其他行业不同的是，民用飞机的适航对飞机上所有安装的功能及其组成部分都有着具体的适航符合性要求。这就使得研制单位因为采用第三方开发的操作系统从而无法免除适航符合性责任。另一方面，前期的文章中我们也已经介绍过，民用飞机保证安全的核心手段，是详尽的安全性分析【详见：浅谈民用飞机机载系统的安全性】。对每种可能的功能根据其失效后果精确地分析可能的产生原因，针对每种可能的失效源头，分别适用不同的适航要求。操作系统作为机载软件的底层，其功能异常往往会引起上层应用软件异常，进而引发飞机功能异常，因此，研制单位在系统中使用的操作系统不但应该具体分析其潜在的安全影响，而且还是机载软件适航标准DO-178B/C所适用的对象。

实际上，DO-178B/C标准并没有将应用程序和包括操作系统在内的底层软件模块区分对待，也就是说，所有装载在飞机上可能引起功能异常的代码，均需满足相应的适航符合性要求。除操作系统外，函数库、以代码形式呈现的BSP组件等模块实际上也是需要满足适航要求的，也就是在采用DO-178B/C标准表明符合性的机载项目中，嵌入式操作系统也需要满足标准对于软件计划过程、软件开发过程、软件综合过程（验证、构型、质量、审定）的目标【详见：民用飞机机载软件是如何表明适航符合性的】。

由于民机软件适航标准较高的要求，实际上使得大部分嵌入式操作系统没有或者无法应用于民用飞机中。目前国内外民用飞机中常见的操作系统研发模式有两种，按照航空标准专门研制或由第三方专业操作系统开发单位对实时操作系统进行适航改造。在上世纪90年代到本世纪初，部分研制单位通过自己开发操作系统的方式来确保底层软件完全可适航。典型的代表有霍尼韦尔公司的DEOS、HeartOS系统等。其中DEOS系统在上世纪90年代取得了DO-178B A级软件的适航认可。在那个航空机载软件有自己的编程语言（Ada）的年代，采用自研满足适航标准的操作系统似乎也是一种高效的解决方案。实际上，在那个时期，机载系统厂商不仅自研操作系统，很多研制单位甚至会自己定制处理器。本世纪初，随着美军表对强制使用Ada语言要求的废除，越来越多的研制单位选择采用C语言开发，这也就减少了对Ada编译环境以及实时内核等的需求，同时，其他嵌入式领域内基于C语言的工具和库极大地降低了机载软件的开发成本，但也推高了航空专用操作系统的开发和维护难度。自此，由机载研制单位开发专用操作系统逐渐减少。

面对航空市场，通用操作系统提供商从另一条路径实现其操作系统的适航化。那就是将通用操作系统按照DO-178B/C标准进行生命周期改造，并提供相关适航符合性证据。目前，包括WindRiver、GreenHill在内的嵌入式操作系统研发企业，同时也包括中航工业操作系统研发单位均采取这种方法实现对民机机载研制环境的支持。所谓的适航鉴定包指的是操作系统研制单位，在其开发操作系统的过程中严格按照DO-178B/C的生命周期过程进行开发，并保留和记录了所有用于表明DO-178B/C适航标准符合性的生命周期数据证据，从而确保在应用程序开发和适航取证过程中无需反复对操作系统进行验证和审查。国际上也有将开源或者简单操作系统逆向工程的方法，补齐对应的需求、设计等生命周期数据并通过基线迭代的方法表明操作系统适航符合性的例子。

实际上，适航鉴定包是操作系统开发方的一种说法，不论是中国、美国还是欧洲的民航局方几乎没有给操作系统单独颁发适航认可的先例。哪怕是相同的操作系统运用在不同的机载系统中，或者运行在不同的硬件环境上，其潜在的失效源头、影响等并不一定相同，从而造成适航审定无法将操作系统和应用软件分开。特别是，不同系统中调用和使用操作系统的方式也存在差异，这也造成了操作系统很难单独地评价其适航符合性。换句话来说，在每一个机载系统审定项目中（包括TC和TSO），操作系统必须和应用软件一同表明符合性。适航鉴定包的主要意义在于通过实现固化的生命周期证据，在每个取证项目中减少了大量重复举证的成本。同时，较为成熟的操作系统也有助于提高局方审查信心，减少审查开销。

02

如何简单快速预计操作系统适航性

针对国内外大大小小的数百个实时操作系统，研制单位往往难以判断其满足适航要求的程度以及后续举证的复杂度。笔者在适航审查工作中，往往通过以下几个要素快速判断操作系统适航风险的大小。这些问题并不足以判断操作系统的适航符合性，但作为挑选可用的操作系统提供了较为快速的评价判断参考。

· 操作系统是否有完善的需求定义，特别是对其自身性能和使用边界的精确定义？

· 是否能够按照基于需求的测试原则实现软件结构覆盖要求？

· 操作系统是否包含其他第三方的库函数或者必须依赖某些黑盒组件？

· 操作系统在当前项目的硬件平台上是否开展过完整的软硬件集成验证？

· 操作系统当前构型是否稳定，是否对其使用问题和缺陷开展的长期的跟踪？

· 操作系统研制单位或应用开发单位至少一个是否熟悉DO-178B/C标准的要求？

03

嵌入式操作系统适航的主要难点

满足适航要求的操作系统之所以开发难度较大与民用飞机保证适航安全的思路是直接相关的。

3.1 需求定义及其追溯

在民机的适航体系中，几乎所有的设计都是从严格的需求定义开始的。操作系统（除非在某个项目中专门开发）一般来说不大可能仅仅通过来自上级的设计输入进行开发。因此在表明适航符合性过程中，其自身的需求定义往往存在难点。

· 需求定义的精确性和完整性

传统行业中，需求的定义往往存在一定的不精确性。而民用飞机的设计思路与之不同，要求对需求进行精确完整的定义。对于操作系统来说，高质量的需求定义不仅是确保自身正确实现功能和充分验证的前提，也是证明应用软件正确遵循了操作系统的约束进行开发的证据。例如提供某种接口的需求，不仅要定义接口的名称、参数、类型和使用方式，还需要明确说明这种接口的任何使用限制、性能边界、禁止行为等。笔者曾经审查过的某一系统，在其需求中详细定义了其命令所带的后缀的具体行为，但却没有描述这些后缀是否存在使用限制，在后续的分析中发现某些后缀在一起使用或者连续使用实际上会产生非预期的输出。由于需求中并没有禁止这种行为，按照民机的需求定义规则，这种功能是被允许的，在对需求的充分验证中将发现功能与需求的不一致情况。从上面例子可见，民机体系中，一系列适航活动的基础是对需求的精确完整定义。

· 需求之间的追溯

由于操作系统功能往往不是来自上级系统和应用的功能分解，实际上打破了民机领域自顶向下精确传递的研制过程。按照DO-178B/C的要求，研制单位需要证明软件高层需求与系统需求的一致性、软件低层需求与高层需求的一致性等等。实际情况下，操作系统提供的功能和接口经常超过上级设计的需要。如果严格按照追溯方法定义需求和开展验证，会造成大量未能覆盖的代码和功能，难以通过适航评审。为此，当今的操作系统往往将其适航鉴定数据包作为独立的满足DO-178B/C标准的实体，而将操作系统顶层需求以及应用开发的约束限制条件作为与应用软件的符合性界面。在界面以内通过完整的需求、设计、代码的追溯表明符合性；在界面以外，通过应用软件完全遵从设计的假设条件，按照限定的方式开发软件作为证据，最终实现内外符合性证据的组合整体表明适航符合性。换句话来说，操作系统开发单位为应用开发划定一个安全区域，并对这个区域内各种可能的情况进行验证和分析，而应用研制单位只要能能证明不超出这个安全区域就证明了其自身软件的安全性。这实际上给操作系统开发方提出了很高的要求，特别是要求能够充分地分析和定义应用的行为。

· 对于应用的假设

上文提到了操作系统设计中安全区域的概念，实际上在鉴定包的开发过程中，这种安全区域的识别和分析极具挑战。也就是说，在鉴定包开发过程中，除了通常的需求定义、软件架构、代码等生命周期数据以外，为确保应用单位能最低成本的快速复用当前鉴定包所固化的适航符合性证据，操作系统开发方需对这些证据的适用条件（场景）进行充分的分析和定义。一个好的鉴定包能够做到在其所明确定义的使用场景下，操作系统所提供的功能和呈现的性能完全在需求所定义的范围内。反之，如果假设条件定义的不完整，应用研制单位需要针对自己使用的场景重新开展分析和验证，从而使得应用研制活动中必须解决操作系统设计中的部分符合性，在降低开发效率的同时也因为不同的开发流程而造成困扰。这就会造成鉴定包的效用难以有效发挥。

3.2 验证开销

随着需求定义的越来越细、假设条件的精确化，对操作系统开展的软件验证工作量也随之增加。通常来说，按照适航要求开发的软件，其需求规模数倍于传统方式开发的软件。对应的功能验证以及鲁棒性测试开销必然成倍增长。更有甚者，由于DO-178B/C标准中，不仅要求设计精确地满足需求（且不超过需求），还要求验证相关算法的精确性。这使得很多操作系统在开展测试的同时必须进行大量的分析工作。特别是在上一节对应用的假设条件范围内，如何证明操作系统在所有可能的场景和场景组合中均能按照预期的输出将是验证工作中的难点。

3.3 硬件适配问题

一个成熟的操作系统必然涉及到在不同的应用甚至硬件环境中使用的问题，除了上文提到的应用边界外，在不同的硬件环境下（哪怕仅是存在微小的硬件构型变化），已经取得的验证证据将不再有效。通常需要开展差异评估和回归测试，或者将已经开展过的验证（测试、评审和分析）整体重新开展一遍。这对操作系统的开发也造成明显的压力。某些操作系统其针对不同硬件进行重新验证的成本数倍于操作系统本身的开发和验证。

3.4 第三方组件问题

另外，在操作系统研制中，操作系统本身，以及后续开发的应用软件往往会使用到第三方的组件。按照适航标准，研制单位需要对所有最终加载在机上的代码证明其适航符合性。相较于传统系统开发，针对第三方组件研制单位无非又回到自研、逆向以及购买第三方鉴定包的几种选择中，这一问题又进一步推高操作系统研制和取证的成本。

在浅谈操作系统的适航符合性（下）中，将详细展开讨论降低机载软硬件适航成本的潜在方法，以及国内首个完全符合适航标准的轻量级嵌入式操作系统——飞蜻FlyLite等内容。