浅谈民机软件适航宝典-DO-178

已剪辑自: https://mp.weixin.qq.com/s/cyx9fSwpX35nDBkHqtO9lQ

序言

DO-178有一个不起眼的标题——“机载系统和设备合格审定中的软件考虑”，但最好不要光看表面。实际上，在业界中被普遍称为“178”的它被广泛认为是航空电子软件开发的圣经。有趣的是，自从178首次产生于80年代(当时是安全关键系统中软件相对较少的时期)，许多系统中都能看出它的影子。你仔细检查军用航空、医疗设备、铁路、汽车和核能的标准，就会发现与178惊人的相似之处。这是偶然的巧合吗?非也。178是首个这样的标准吗?这个答案无关紧要，更重要的是了解其发展历史。178通过后续的三次迭代得到了发展，产生这些变更的原因都应去理解。

还记得盲人摸象的寓言吗?每个人都摸了大象的不同部位，并试图描述他们摸到的东西，却对大象的其他部位一无所知。这是一项艰巨的任务，在航空业中也很容易落入这样的陷阱，因为飞机及其系统非常繁复，没有一个人能完全理解所有的复杂之处。换句话说，在缺少启蒙的情况下，我们都不比盲人好多少。DO-178试图建立一个框架，以便开发人员和合格审定机构能够抛弃其盲目性，以全方位的视角去工作。178确实成功地提供了这样一个框架，然而它不能保证顾及到全方位，也不能保证达到完美。难道航空电子软件不完美吗?当然不完美。DO-178不完美吗? 很难完美。事实上，借用温斯顿·丘吉尔关于民主的一句名言，“DO-178是世界上最糟糕的标准，但其它所有的标准更糟糕!”

在《航空电子合格审定 - DO-178和DO-254的实施指南》一书中，作者用了200多页的篇幅来描述DO-178是什么。对DO-178性质的描述可以更简短，例如DO-178并不符合以下几点:

•一项缺乏灵活性的国家标准，与市场规律几乎没有关系

•一项一经发布就过时了的技术标准

•一项由缺乏实践经验的人编写的国家标准

可以肯定的是，DO-178正好与上述所说的相反。一般来说，DO-178的成功是基于以下事实(至少在认知上):

•拥有一个机载软件开发的灵活框架

•能够适应几乎所有类型（无论是应用性或复杂性）的系统，并可以随着技术的进步而发展

•一份标准，它主要由充满智慧的且成功的技术人员及其同行编写，因此在使用中能获得既定利益

•一份标准，它没有告诉行业一种僵化的用于“如何”开发和验证软件的方法，而是主要把目光放在“什么”是必须的上。

•一份标准，它根据机载软件的关键性来调节至少需要多少制衡(“什么”)，由此降低了符合安全性所需的成本。

要开始了解DO-178，必须先了解其“生态系统”。例如，如果不先理解加法、减法、方程和其他一些数学概念，就无法理解微积分;而微积分只是数学生态系统的一部分。同样地，DO-178是航空电子开发和合格审定生态系统的一部分，其包括安全评估过程(ARP-4761)、航空电子系统开发(ARP-4754A)、硬件设计保证(DO-254)、环境和EMI测试(DO-160)以及许多其他相关方面。在很多方面，DO-178就像大象的腿,是大象稳定生存能力的一个必要因素:象腿不能保证其健康，但肯定能降低早亡的可能性。

DO-178的前提(对于商用航空电子设备，是合格审定机构来授权)是用户将DO-178仅仅作为航空电子合格审定链中的一个环节。如果没有安全基础，航空电子设备既不安全也不兼容。在DO-178应用之前要做什么?一般要指定一个特定项目的合格审定计划(PSCP)，它为航空电子系统定义了航空电子生态系统，其中包括DO-178的适用性。此特定项目的合格审定计划引用的生态系统通常包括ARP-4761的正式功能危害性评估(FHA)的性能，以及ARP-4754A系统级航空电子设备的需求定义。如果不考虑前面的情况就开始进行178的活动，你会体验到一些不错的实践活动，然而最后还是“得”从头再做一遍……毫无异议的是DO-178需要一个安全的基础和正式定义的系统需求。简而言之，DO-178无需验证系统需求是好是坏，通常都假设系统需求合理，并确保它们被转换并被验证为与设计等级相匹配的软件。然而，航空电子软件的质量不能优于先验系统的需求。

DO-178是一份相对较小的文件，它远远小于你所提供的遵守DO-178的证明文件。据说，用于开发飞机的文件永远无法装入飞机。同样地，按照DO-178开发的文档也超出了打印源代码的页数。因为像任何安全关键软件的规章制度一样，它有必要的计划、标准、规范、设计、评审、分析、测试和审计来定义、评估和证明其一致性。军事航空、医疗设备、核能、铁路和安全关键性汽车软件也是如此。

在一个正式的框架已到位且已产生经评审和受控制的功能危害性评估和系统级需求之后，就可以考虑开始应用DO-178了。你可以先借一份DO-178的拷贝和其他辅助文件并试着理解它。在你多次阅读这些文件之后，至少能让自己认识到它们的有趣和重要性。可当它看起来似乎一切都是要严格遵守的，但又没有什么是真正要求的时候，该如何开始真正应用它并从哪里开始呢?这时你需要真正了解DO-178。

首先，你需要了解当前为DO-178开发的软件的开发保证等级(DAL)。适用于软件的计划、开发和正确性检查的严密性与它的DAL直接相关——通常被称为“关键等级“，它共有五个等级，由E级至最严格的A级，严格程度逐渐递增，如下图所示。要注意，所指定等级取决于飞机的类型；以下例子是对于Part 25飞机，如大型飞机:

为了使工作更容易，你可以简单地为软件选择自己的保证等级吗? 当然不可以。关键等级基本上是在应用DO-178以及应用适用的TSO之前通过安全评估过程结合实际操作来确定的，因为保证等级与大型“系统”的预期使用和设计相关，而软件只是其中的一部分。举个例子来说，通信通常是等级A; 二级导航通常是C级，但如果相同的VOR/ILS接收器用于Cat III型低空决断高度，则可能超过TSO的最低要求。所以，等级并不总是一成不变的。FAA尝试在Part 23 AC 23.1309-1D及其附录A部分定义等级而其他几部规章并未涉及。每个单独的系统都有一个DAL，而该系统中的软件关键等级要等于或小于其系统的DAL。小于? 是的，对于软件或者软件的一部分，它的关键等级可能低于它的系统。实际上，系统拥有多个关键等级软件的情况越来越普遍。

为什么不让所有的软件都达到A级呢?A级软件可能比低等级软件的质量更高，就像B级软件一般比C级软件质量更高一样。那么为什么不把所有软件都升级到A级呢?也许是可以实现的，但其付出的代价会更高。对于安全关键软件没有免费的午餐，安全性与付出的成本成正比。航空电子设备安全性评估过程确定每个系统需要的安全性，并指定可接受的安全等级。没必要提供额外的安全性，要达到最低要求已经十分困难。如果将门槛提高至最低要求之上，可能会让企业面临财务危机。在这种情况下，只要能够满足最低要求就足够了。

DO-178的具体目标是基于软件的关键等级，较高的DAL必须比低等级的满足更多的DO-178目标。在确定软件关键等级之后，还要浏览DO-178来确定软件必须满足哪些目标。现在可以开始你的计划，这就是DO-178与盖房子类似的地方——你已经进行了地理分析来确定地基——即你的“安全性评估”，接着你需要一个计划过程，之后再进行一个开发过程。同时还有一个并发的纠错性过程，贯穿在整个计划和开发过程中。因此，DO-178下的航空电子软件工程与建造房屋是一样的，并遵循相同三个阶段的过程方法。

DO-178和DO-254有三个完整的过程: 计划、开发和正确性检查过程:

从上图中可看出:首先要执行计划过程，紧随其后的是持续时间更久的开发过程。作为后台的最大进程，正确性检查(或QA、CM、验证和合格审定联络的综合过程)持续在进行。什么是计划、开发和正确性检查?这里做一个简短的总结。

计划过程。在开发或者重用已有或遗留的软件之前，你需要计划即将进行的活动。就像建房子一样，建设检查员首先需要检阅计划，再定期检查所建造的房子，包括地基、墙壁、电力、管道、屋顶和完工的建筑。DO-178也是类似的过程。与计划过程相关的有五个计划和三个标准:

\1. 软件合格审定计划(PSAC):软件工程将如何遵守DO-178的总体大纲。

\2. 软件质量保证计划(SQAP):详细说明DO-178的质量保证目标将如何实现。

\3. 软件配置管理计划(SCMP):详细说明DO-178的变更管理和基线/存储目标将如何在这个项目中执行。

\4. 软件开发计划(SDP):总结软件需求、设计、编码和集成如何与相关工具的使用结合起来，以满足DO-178的开发目标。

\5. 软件验证计划(SVP):总结用来满足DO-178验证目标的评审、测试、分析活动和相关的验证工具。

\1. 软件需求标准:提供从系统需求到软件高级需求和从高级到低级需求的分解和评估标准，包括派生的和安全相关的需求。

\2. 软件设计标准:提供定义和评估软件架构和设计的标准。

\3. 软件编码标准:提供实现和评估软件源代码的标准。

上述五个计划和三个标准构成了DO-178所需的计划文件。由于D级是5个DO-178等级中最不严密的，所以不需要用到3个标准;A级到C级会涉及到所有的计划和标准(E级实际上不是DO-178的等级，因为最低级无需DO-178目标)。

在特定项目的DO-178计划和标准经质量保证部门和相关合格审定机构的评审和批准之后，就可开始正式的软件开发活动。如果你以前进行过DO-178或安全关键软件项目，那么应该已经有了基本的软件工程计划和标准，你可以重用它们来构建特定项目的DO-178计划/标准。在实践中，为了节省时间并理解计划和标准中的细节，在制定计划和标准时通常会启用初步的软件需求和设计。然而在理论上，DO-178假定了一个依次进行计划、开发和验证过程的典型瀑布模型。为什么DO-178一般采用瀑布式方法? 因为是历史得到的经验。

DO-178最初是在20世纪80年代产生的，同时也出现了软件“工程”并伴随着日益复杂的系统。在20世纪90年代早期，对DO-178进行了两次修订，总体上反映了当时流行的许多软件开发最佳的实践和理念，包括CMM、军事标准和现在臭名昭著的瀑布式方法。当前几乎没有人仅仅使用纯瀑布方法，事实上如今普遍使用的方法是基于模型的开发(MBD), 还结合了DO-178 C和DO -331.

虽然DO-178实际上允许任何确定的、可验证的软件开发方法，但是瀑布式方法在许多航空电子开发从业者和审计员的脑海中根深蒂固。那么通常会使用什么瀑布式特性?

•V模型附属，用于评估每个阶段的输出

•大量文献

•需求、设计、编码、集成和测试的排序和转换

现在，回到航空电子软件开发计划。目前已经完成了基于ARP-4761强大的功能危害性评估；有了基于ARP-4754A可靠的考虑了安全性需求的系统级需求;有了良好的完全遵循DO-178的计划和标准。接着可以开始开发软件和编写代码了，首先建立一个原型，向管理层和客户展示你已经很好地掌握了。但还存在一个问题——你还无法编写真正的航空电子软件。下面我们来讨论其原因。

你还无法编写软件的原因：

不能只是对一所好房子提出一些要求，买一些建筑材料，然后邀请所有的朋友来建造梦想之家，再享用一些可口的饮料吗? 也行，然而这并不能使你合法地占有或转售这所房子。航空电子系统也是如此——虽然理论上的争议在于DO-178是否在正式情况下是“必需的”，但如果你想合法地在全世界销售你的航空电子系统，毫无疑问软件必须符合DO-178。因此很简单，在开始编写软件之前应解决上述每一个因素，当然这也有规章和商业方面的原因。

从规章的角度来看，能够评估开发过程中的每个工件是很重要的。每个开发步骤都有进入和退出标准，这些标准与离散验收标准相关联。这种验收标准在开发标准中(需求标准、设计标准和编码标准)以及每个工件的相关检查单中定义。检查单是航空的基础，每次飞机准备起飞时，飞行员和机组人员都会根据“检查单”进行“检查”。当一架商用飞机(基本都配有一名飞行员和一名副驾驶)准备着陆时，会进行相同的流程:飞行员可能会说“准备着陆，襟翼设置为10度”，这时副驾驶通过查看襟翼设置并告知“已确认，襟翼设置为10度”。上述流程就是飞行员按照书面着陆检查单进行操作，副驾驶根据检查单检查飞行员的解释和行为。因此，可以说副驾驶对飞行员所要做的活动进行了“独立评审”。可以肯定的是，飞行员和副驾驶都已经记住了着陆检查单，并不需要在驾驶舱内真正按照书面检查单操作。真正有经验的飞行员应记住检查单，然而要注意人在压力下特别容易遗忘事物。另外需了解的是检查单是预先编写的，在实际工作期间会正式使用。纸质和电子的都无所谓，最重要的是所需活动已经在检查单的标准中指定。每个检查单都经过评审、配置和批准，这意味着对于每个操作，每个检查单都有且只有一个有效版本，DO-178也是一样的。

下面对于目标、转换准则和检查单做一个简单说明。DO-178的目标记录于DO-178正式文件末尾的附件。转换准则一般作为与目标相关的验收标准。转换与生命周期模型相关联，并与标准相反。检查单是有用的，但需要与生命周期转换准则相关联，且检查单要比转换准则低一级。

对于DO-178，你可以在检查单中根据项目的具体情况和标准对其进行调整;它还包含了适用于DO-178的成功标准。检查单会满足你每个主要工件的以下属性:

•证明对每个流程和工件都有预先、正式的验收标准细节

•证明评审要考虑检查单中包含的最低标准

•证明执行了评审和审计，并在必要时保持独立性

通过检查单要检查什么?几乎所有内容，特别是与所需DO-178目标相关的项目:计划、标准、安全、需求、设计、代码、测试和结果、工具鉴定和供应商等。

当你完成了DO-178计划、标准和检查单之后，就可以开始软件开发。这时已经通过了四个必需的阶段介入性评审(SOI)中的第一个，因为SOI#1评估的正是这些计划、标准和检查单。遵循典型瀑布式方法，执行以下活动通常是为了表明符合DO-178术语中的“转阶段”入口/出口准则。

典型的DO-178软件开发活动

上述每一项软件开发活动都将按照以下已经评审和验收的文件进行:

\1. 软件开发计划

\2. 软件需求、设计和代码标准

\3. 每项活动对应的检查单，独立评审适用的A级和B级软件开发活动。

在实践中，当前复杂的安全关键性系统（如航空电子设备）很少遵循如此严格的级联顺序，取而代之的是基于模型的开发、精益化方法、原型和不断发展的客户需求。DO - 178的妙处在于其无指定特定方法即灵活性。然而，无论你选择哪种软件开发方法，包括重用遗留软件，都必须通过评审计划、标准和检查单来提前说明该方法，接着再按所说的去执行。

在完成软件实现之后，就有了可以追踪到代码的需求，这些代码也可以反追踪到需求，且需求、设计和代码都已经过记录和评审。目前这些几乎都还没有实行，你只是为下一阶段的参与评审做好了准备，例如第二阶段。参与阶段的第二阶段用于确认设计是否符合你的计划/标准，且可通过评审检查单来证明。

参与阶段的第二阶段还应确认自己的项目配置管理和软件质量保证(SQA)审计是在整个实现过程中进行的。什么是SQA审计? DO-178是先提前计划，再证明(检查单)工作是按照计划和标准完成的。然而，关键等级越高，负责人由于风险越高，获得的信任就越少。FAA的一份书面规章(FAA Order 8110-49的第3章)中规定了FAA的参与等级(LOFI)要基于关键性，并考虑许多其他因素，如开发人员的软件合格审定经验。关键性越高，合格审定机构遇到的风险就越高，由于资源有限，他们倾向于关注那些高风险的项目，尤其是由新人执行的项目。确切地说，DO-178有不同级别的人参与评审或审计:

\1. 对一个已完成的工件(“准备接受评审”)进行技术评审，要评估它对计划、标准和检查单的遵从性。较高的关键等级会要求评审的独立性，例如，由一个与负责人身份无关的技术人员进行评审。

\2. SQA审计是为了评估对过程的遵从性，而不一定是技术遵从性。负责人参与的过程是否符合计划和标准并遵循了转换准则(适当使用了每个过程的进入和退出标准)?

\3. 合格审定联络(如在美国的指定工程代表)审计评估先前的技术评审和SQA审计。

\4. 合格审定机构(例如EASA或FAA)审计上述各项。

可见航空电子行业的SQA与其他行业不同。这些行业通常有SQA进行技术评审和测试，DO-178的SQA只集中在两个主要活动上;首先，确定或批准项目计划和标准;接着通过审计来评估这些计划和标准是否被适当遵循。DO-178并没有规定SQA如何工作;它只是想要SQA达到最低目标，并在整个过程中始终保持。

在SOI#2得到审批之后，尽管还是有一些小的需求变更和bug修复，软件实现基本上就完成了，但还需要执行完整的软件测试。虽然在其他领域软件测试通常被认为是“艺术”，但“艺术”的问题在于它是主观的:我们无法就艺术的定义达成一致，但我们“一看到它就知道它是什么”。人类从来没有在什么是好的艺术，什么是坏的艺术上统一意见，与音乐、食物、天气一样，它们都是主观的。因此，DO-178通过软件需求的详细测试和代码的覆盖分析，将软件测试的艺术转变为一门科学。DO-178软件测试人员必须精通编写测试，以便评估逻辑是否完全满足编写的需求。DO-178还引入了“我们是否完成”的概念。如果想让软件测试变得完美，那么软件测试实际上可以有无限的排列组合。DO-178甚至对最高关键性也有限制，软件的关键等级越高，软件代码就越需要被测试覆盖，例如结构覆盖评估。

你是否听过这样一句话——“我是一名V&V工程师，有些人认为我就是专家。”？软件测试是半艺术半科学的。在DO-178中，软件测试人员需要成为软件设计和代码方面的专家。在非航空电子领域，“软件”测试人员通常对软件设计和代码的复杂性知之甚少，但在DO-178中并非如此。首先，简单介绍一下“V & V”。众所周知，V & V是验证和确认的常用缩写。不幸的是，V & V的真正含义，特别是在航空电子软件中，经常被误解，然而已经有数百本书的主题是关于V&V软件的。因此接下来的内容可能也没有很好地说明这个非常复杂的话题。

验证是对过程结果的评估，用于确定输出是否符合规范。那么对于航空电子软件来说，什么是“验证”呢? 技术人员最擅长处理定量方程，可以看看航空电子验证的公式:

V = R + T + A

对于航空电子软件，这个等式意味着:

•人工创建的工件应经过评审(通过检查单)

•软件需求和代码应经过测试

•如果测试本身不是决定性的，则需要进行额外的分析。

当然，评审、测试和分析的程度完全取决于软件的关键等级，如下所示。验证已经总结了，那确认呢? 要记住验证是评估工件是否符合规范。对于软件验证，规范就是“需求”。可如果需求写得不是很好呢? 接下来就是确认的作用:评估需求，确定它们是否优秀，优秀的标准是清晰、简洁、正确、完整和可验证性。如果你输入的是垃圾，那么输出的也一定是垃圾，对航空电子软件质量最重要的输入就是需求。那么必须确认航空电子软件需求吗? 事实上DO-178并不要求这样做，因为确认软件需求是主观的，而DO-178侧重于客观标准。根据ARP-4754A，正式过程中需求必须在系统级进行确认。非正式的话，最佳实践应在需求评审过程中确认软件需求，确认它们是正确且完整的。

如上所述，软件测试部分是艺术，部分是科学。就像软件开发一样，是不可能达到完美的。但DO-178是由行业专业人士编写的，国家介入很少，因此侧重于拥有合理的成本效益。测试软件容易花费比开发软件更多的资源。在航空电子产品的生命周期中，测试的时间肯定比开发的时间多。

那么，什么是合理的、节省成本的软件测试呢? 首先，确保您有良好的软件需求，且这些需求已得到了充分验证。接着要有附加的鲁棒性测试，它试图通过压力/性能测试、测试边界和无效值以及执行所有转换过程来查找逻辑中的错误。最后，通过结构覆盖评估来确保所有可能在实际中执行的逻辑都得到验证并按预期的方式运行。自顶向下的可追踪性被形式化，旨在证明所有记录的需求都得到了验证；而自底向上的可追踪性也包括在内，旨在证明未记录的逻辑，要注意自底向上的可追踪性并不是简单地颠倒其关系。这意味着代码的每个部分都需要追踪到需求(高、低或派生)，这与关键性所要求的程度有关。

DO-178测试的范围和相关工作是什么?下列图片可能会给你启发:

DO-178软件测试相关工作 - 最优级(A级)

首先关注**:基于需求的测试(例如功能测试)**

首先，测试是基于DO-178的需求(最新版本DO-178C更进一步，指出所有主要代码段都应追踪到至少一个需求)。由于DO-178没有为需求粒度提供主观界阈，所以需求测试依赖于需求本身。然而，DO-178通过要求对A到C级的软件进行额外的鲁棒性测试和结构覆盖率评估，弥补了潜在的薄弱需求。如果有良好的需求，那么对于B级软件，测试这些需求通常会达到必要鲁棒性用例的90%覆盖率和代码的80%覆盖率，这是由于良好的需求为底层功能和潜在的鲁棒性条件提供了详细信息;这些都可以从需求中收集，因此只需评估需求并为它们编写测试用例，测试用例就可以覆盖80-90%的必要条件。如果需求写得不是很好，那么根据那些不好的需求编写测试用例可能只会产生50-60%的必要覆盖率;在这种情况下，你需在测试结构覆盖活动期间发现缺少的需求信息(对于D级和E级不要求)，并重新添加需求。就像现实生活中的大多数事情一样，第一次就做好显然要比从头再做一次划算得多。因此，这里有一个值得分享的经验:首先在好的需求上下功夫，并结合结构化的评审和检查单。

需要注意的是，DO-178的5个关键等级要求随着等级的增加而进行更多的软件测试。对于软件开发来说，关键等级的影响较小，但对于测试来说则不然，如下图所示总结了每个DAL所需的测试。

DO-178关键等级之间在验证上的****主要差异:

测试之后，SOI#3需评估验证活动的完整性。SOI#4要结合符合性评审，该评审针对所有适用的DO-178目标的符合性，包括临时的“变更”。

您是否在DO-178符合性应用上有困惑？您是否在系统，安全性，安保性，IMA设计，工具鉴定等方面有困惑？欢迎访问公司网站，联系各地客户经理预约进一步沟通http://www.visionmc.com/AboutVision/AboutVision?name=Honour#

创景适航业务的两大板块期待为您的民机适航赋能：

1. 适航咨询

可全面涵盖民机机载系统研制过程的要求，从系统ARP 4754，安全性ARP 4761，复杂电子硬件DO-254，软件DO-178B/C，IMA DO-297，环境试验DO-160，工具鉴定DO-330，基于模型的软件研制DO-331的适航咨询，创景的系统和软件适航专家，以及与创景合作的国内及国外适航专家资源，根据民机研制单位的实际情况，能够提供贴合客户需求的适航咨询：

• DO-178B/C、DO-278、DO-254、DO-297、DO-160 培训

• 基于DO-178B/C的机载电子硬件研制咨询

• 基于DO-254的机载电子硬件研制咨询

• 基于ARP 4754A的机载系统研制咨询

• 基于ARP 4761的典型系统安全性分析咨询

• 基于DO-297的综合航电研制咨询

• 基于DO-330的工具鉴定咨询

• 基于DO-331的基于模型的软件研制

u SOI#1（软件计划阶段审定）

u SOI#2（软件开发阶段审定）

u SOI#3（软件验证阶段审定

2. 适航验证服务

创景凭借在嵌入式软件测试验证领域深耕20年的丰富经验，以及专业的工程服务团队已持续8年为高安全领域针对嵌入式软件提供验证培训与工程服务，创景的软件适航专家及工程服务团队能够为民机研制单位提供针对最严苛的民机适航DO-178B/C A级软件符合性验证服务解决方案。

• 系统V&V分析和验证方案设计

• 验证环境分析与自动化验证环境设计

• 包括语句，判定，MC/DC结构覆盖率分析