浅析DO-178B

背景

​ 民航发展，适航先行。二战后，美国和苏联两超级大国均开始研制大型民用客机，代表机型如波音707, 图-154. 在经过了数十年的市场洗礼，目前民机市场已被波音和空客两家寡头所垄断，而鲜能见到苏联客机的踪影。追其根本原因，也正是民航业最为重要的因素：飞机的安全性是否能够得到保障。保证飞机安全性的背后，需要一整套完善的适航体系去建立和实施。美国FAA所建立起的严格的适航审定程序保证了波音客机的安全，而号称‘飞行棺材’的图-154，由于安全性的考虑，中国在2002年已停止使用。

局方的适航规章

Regulatory documents 规范性文件

• Federal aviation regulation, 如FAR 23 通用航空，FAR 25 民用航空，FAR 27 直升机，FAR 29大型直升机
• Airworthness Directives ADs 适航指令，指的是如果在飞机的运营阶段出现了缺陷，那么就要在限定的时间内把缺陷解决掉

Non regulatory documents 规范性文件

• Advisory circulars ACs 咨询通告

机载系统

​ 机载设备需要得到局方的审定合格，颁发相应的证件后方可投入使用。如下图所示，虚线以上为系统层面的开发：ARP 4761 针对该系统承担的功能进行安全性评估，分析该系统失效会对整机产生怎样的影响；APR 4754 进行系统架构设计，确定每个功能模块的System level（SW level 和 HW level均依据SYS level来确定）。

​ 针对机载软件开发，FAA 咨询通告(advisory circular) AC 20-115, Airborne Software Assurance 认证了采用DO-178来指导机载软件开发从而获得FAA对机载软件的适航审定。

DO-178B是由RTCA/EUROCAE在92年联合颁布的一份针对机载设备的软件开发的指导性文件。

• DO-178B目的是，产生无错误的软件(produce error-free software)。但要注意，没有完美的软件，DO-178B只能尽可能的避免错误。

• DO-178B是流程导向(process-oriented)的指导性文件，而不是流程文件。

• DO-178B定义了SW level，定义了objective（目标数）。软件等级不同，需要满足的目标数也不同。

  ​DO-178b的目录结构如下图所示，围绕机载软件的生命周期可分成三部分：(4)SW planning process, (5)SW development process, Integral process(软件验证，配置管理，质量保证)。Annex A 描述了每个阶段需要满足的目标objective。(2)和(10)是机载软件开发以外的内容。

Ch2 系统层面考虑

该章定义了五个软件等级，软件等级的不同，会影响到以下三点：

• 满足的目标数不同 number of objectives（DO-178B定义了66个目标）
• 配置管理力度(configuration control)不同，分为CC1和CC2
• 独立性(independence)需求不同 。（独立性指，一个产物的作者和验证者不能是同一个人，比如需求的作者author和评审者reviewer不能是同一个人；代码的作者，评审者，测试者不能是同一个人）

系统架构对软件等级的影响，例如：

• 分区partition，分区度越高，软件等级就可以分的更细，软件等级更改的代价就越小。比如某level A function和level B function有很多数据交互，甚至内存都需要共用，那么level B function就可能需要改为level A。
• 安全监控safety monitoring，这是一种设计模式。比如更改某个大型的level A function，设计成一个level A的监控软件加一个level B的 function。这种将function的安全等级降一级会大大减少我们的effort。

Ch3 软件生命周期

定义了软件生命周期过程：SW planning process， SW development process，integral process.

Ch4 软件计划过程：定义产品如何被开发

五大plan如下：

• PSAC (plan for software aspects of certification)
• SDP(Software Development Plan)
• SVP(Software Verification Plan)
• SCMP(Software Configuration Management Plan)
• SQAP(Software Quality Assurance Plan)

注：对于一个新项目，一定要做PSAC。对于已有的项目，在此基础上进行版本升级，则需要做CIA(change impact analysis)来评估是否需要做PSAC.

注：PSAC与SAS(software accomplishment summary)相对应，但PSAC在计划阶段，SAS在收尾阶段。

注：SMCP, SQAP分别由CM组和QA组负责编写。

Ch5 软件开发过程：开发产品

对于软件开发过程，DO-178b允许使用任何手段进行软件开发，只要满足指定的目标objectives即可。典型的软件开发过程如R-D-C-I(Requirement process, Design process, Code process, Integration process).但也存在先Code process再requirement process的软件开发过程。

注：在软件计划过程已将软件开发计划(SDP)定义好，在软件开发过程就要严格的遵循，不能再做改动。

Requirements process

Derived requirement衍生需求
DO-178b开始，规定测试是基于需求的测试（requirement-based testing）（但是在178B之前并没有规定测试是基于需求，有可能是基于CODE进行测试）。在系统层面进行safety assessment 系统安全性评估都是基于需求的，也就是在系统层面保证了需求是没有问题的，因此design，coding，testing都基于需求来做。
但是并不是所有的SW requirement都是从system flow down来的， 也就是说并不是所有的SW requirement都经过了system 层面的 safety assessment，有一部分SW requirement是在开发阶段发现，sys requirement只是描述了一个general idea，但具体的实现细节需要通过设计另外的功能来support它。此时就会产生衍生需求，衍生需求是在软件层面提出来的，因此并没有进行system层面的safety assessment，所以它的安全性不可而知。对于这种情况的需求，都需要反馈到系统安全性评估过程。

Design process

Coding process: 开发源代码并输出目标文件

综合过程：确保产品正确

综合过程(Integral process)并不是在development process之后去做，它(verification，CM，QA，cert)贯穿在整个开发过程当中同时进行。比如：

• 需求开发完毕，需要找人审阅(review)，审阅的过程即软件验证过程
• 代码开发完毕，需要找人审阅，审阅的过程即软件验证过程
• 需求或代码开发完毕，需要放在某服务器上， 放在服务器上的过程即配置管理过程(CM process)

Ch6 软件验证过程

Verification有三种表现形式：Review, analysis, test.

Review: 需要checklist

Analysis

**Requirement-based test coverage analysis: **DO-178b规定所有的需求都必须有test去覆盖(cover)它。也就是每一条需求都必须有test case 能够trace到它。注：单个需求的具体实现可能很复杂，一个test可能不能完整的验证该需求，此时必须要有多个test去验证。该analysis包含两个内容：1. 是不是所有的需求都被test 追溯(trace)到；2. 是不是需求被完全验证（因为可能出现能够被test trace到，但是test只验证了需求的一部分功能的情况）

Structural coverage analysis: 需求开发完了，code根据需求开发完了，test也根据需求开发完了（也即是说code和test都是基于需求去开发的）。test是在code上跑的，如果test完全的将需求cover到了，但是在code上跑的时候发现有的条件并没有meet到，说明****code****跟需求之间是不匹配的。

**Traceability analysis: **分析系统 – 软件需求 – code – test之间的trace关系是什么样

**Regression analysis: **有的项目不是新项目，而是老的项目继承下来，此时并不想让所有的test都再跑一边，只希望把项目更改的部分进行测试。但是项目更改的部分对test影响的范围有多大，就需要做Regression analysis来分析哪些test是需要重新跑。

**C++ analysis: **在DO-178b中对面向对象有很多的限制(在SDP中就会规定，有些OO技术是不能够使用的). C++ analysis就是来保证有一些OO，比如多继承，多态等等不会出现在code中，因为多重继承很难去跟踪(trace)。

**Software change impact(CIA) analysis: **对于所有的继承的项目，第一个分析就应该是CIA.在CIA中会涉及partition, safety等问题，最后进行加权比较，得出此次版本的改动是major change还是minor change。如果是major的更改，那就要产生一个PSAC；如果是minor，说明改动很小，可以直接沿用上一个PSAC。

Timing and Memory analysis: 包含在CIA中

Test

机载软件的测试有两个目的，其中一个目的是：证明软件满足需求(Demonstrate that the software satisfies its requirements).该目标通过编写脚本实现，test要基于需求去写（基于code去写test永远都查不出问题）。注：有些软件并不一定是黑盒，可能是个灰盒，需求写的并不是很好，写脚本时候还是得参考code里面的变量名字，但是写脚本的时候要完全的忘记code是怎么写的，应完全的按照需求去写。

Requirements-Based Test Case Selection

• 正常功能测试Normal Range Test Cases, 比如打开开关，灯泡能亮
• 健壮性测试Robustness Test Cases, 对于非正常的输入，测试软件的响应。比如灯泡放在水里，灯泡是直接自动断电还是直接漏电。对于飞机来说，遇到极端情况，设备不应该直接罢工，而应能够告诉飞行员当前的功能不是正常的工作状态。

注：此处DO-178B有一个漏洞，也是开发和测试争论最多的地方，DO-178b并没有说明开发人员写需求的时候，要写的很健壮。就会让测试人员很迷茫：需求写的不健壮，但测试需要测试健壮性。会导致V&V不知如何进行健壮性测试。

** ****Test Coverage Analysis**

• Requirement Coverage Analysis
• Structural Coverage Analysis

注：上述Analysis均在Verification后期去做，当上述Analysis完成，即意味Verification结束。

结构覆盖性测试(Structural Coverage Analysis)分为以下三种：

• Statement Coverage (Levels A, B, C): 程序中的每个语句都要能够执行至少一次(Every statement in the program has been invoked at least once.)
• Decision Coverage (Levels A, B): 程序的入口 （main）和出口（不同的条件下出口不同）都必须要执行一次，程序中每一个decision的可能情况都必须至少执行一次。(Every point of entry and exit in the program has been invoked at least once and every decision in the program has taken on all possible outcomes at least once.)
• Modified Condition/Decision Coverage (Level A) (MCDC): Every point of entry and exit in the program has been invoked at least once; Every decision in the program has taken all possible outcomes at least once; Every condition in a decision in the program has taken all possible outcomes

注：decision, 程序中每一个做判断的地方都是一个decision。比如if…else，switch case中，if(A)，那么对于A的true和false，程序应该都能执行到。

注：对于level C，对于if(A)，程序只能执行A==true的情况，那么是允许的，因为满足了Statement Coverage，即使没有满足Decision Coverage

注：condition，if(A&&B),A是一个condition，B是一个condition，A&&B就组成了一个decision；也就是A的true和false两种情况都必须能够执行到

**Structural Coverage Analysis Resolution: **如发现了结构覆盖性漏洞，应该怎么做

• Inadequate test cases/procedures 首先看test是否有问题
• Inadequate requirements 看需求
• Dead code 是否是死代码，有些开发人员实现 了以后才要实现的功能，但是当前load并不需要。V&V发现了死代码后，要提JIRA要求将dead code删掉或注释掉
• Deactivated code 是否是非激活代码（在当前的机型或者引擎，不论是什么配置下，都不会被执行的代码）。航空业的许多技术是迭代发展的，比如波音很多机型的代码沿用了以前的机型，比如787沿用了777，但是777上实现的某功能，不想在787上实现，因此当787沿用777代码的时候，这部分代码就成了非激活代码

注：非激活码和死代码的区别，非激活代码在某个版本中是有需求对应，而死代码没有需求对应

Ch7 软件配置管理过程

SCM软件配置管理过程将会一直在机载设备的服役期间持续的进行。比如当即在设备出现了严重事故，会有NTSB进行数据的查阅，甚至要把相关人员带去调查。

软件配置管理过程包含以下的活动：
Configuration identification 有唯一的ID能够识别
Baselines and traceability 有些数据需要打基线
Problem reporting, tracking and corrective action
Change control and review
Configuration status accounting
Archive, retrieval and release
Software load control
Software life cycle environment control

对于数据项的配置管理的力度，分成两种CC1, CC2。CC1，所有的activity都需要满足；CC2, 都没有change review（即修改后不需要有人review）。对于数据项需要满足何种控制力度，是在PSAC第7章 life cycle data中定义。

Ch8 软件质量保证过程

SW Quality Assurance process 确保软件开发符合开始制订的计划(五大plan, PSAC, SDP, SVP, SCMP, SQAP)和标准(SW Requirement Standard, SW Design Standard, SW Coding Standard)。QA工程师贯穿于整个软件生命周期，确保软件生命周期的产物满足178b的目标。

对于SW Quality Assurance Process，其独立性要求最高，LEVEL A-D的软件都需要满足独立性，如Table A-9所示。

Ch9 适航联动 局方和申请人的桥梁

适航联动(Certification Liaison Process)建立起局方和申请人沟通的桥梁。

TSO件可以在多个机型通用，是霍尼去做认证

TC件只能跟着机型去认证，MRO去做认证

Ch12 额外考虑

工具鉴定(Tool Qualification), 如果某工具，1. 能够减少，消除，自动化执行软件生命周期中的一些过程. 2. 该工具的输出没有经过Verification process。满足以上两点，则该工具需要进行工具鉴定。

如果工具的输出被验证，比如MBD（模型）自动生成的代码会被人工review，那么工具不需要鉴定

如果工具出现的错误，如果这个错误会进入到代码中，那么就需要进行开发工具鉴定；如果这个错误不会引入到代码中（比如测试的不全），那么就需要进行验证工具鉴定。

由于对开发工具的鉴定会很麻烦，有一个取巧的方法，针对开发工具A自动生成的代码，开发出另外的一套验证工具B对A自动生成的代码进行验证。此时，因为A tool生成的代码会被B tool review，因此A不需要进行工具鉴定；但B需要进行验证工具鉴定。由于验证工具鉴定比开发工具鉴定容易些，因此这种方法很取巧。

Annex A 十张附表 66个目标

Des: 描述该目标是什么，如上图，可执行目标码需要满足low level requirement
Ref: 是具体要怎样实施改目标（当我们在看Des时候看不懂说的是什么时，就需要通过Ref去看详细说明）
Applicability: 1. 圈说明当前目标使用于该软件等级，2. 实心代表独立性要求
Des: 针对于这个objective会有什么样的产物；通过output来检验SW满足的该objective
Ref: 在看Des时候看不懂说的是什么，就需要通过Ref去看详细的了解
CC: 产物(output)按照软件等级要进行不同程度的控制力度；D空表明该目标不适用与level D

Level A需要满足所有的66个目标，其中25个目标要满足独立性需求
分析：软件从level E变成C最大的变化是，目标增加很多0到57，独立性没有很大变化，因此更多关注是满足目标；软件从level B变成A最大的变化是，目标增加很少，独立性很大变化，因此B到A更多关注是独立性
总结：高级别软件更关注独立性，低级别软件更关注满足目标

注：独立性，一个产物的作者和验证者不能是同一个人，比如一个需求的作者和评审者不能是同一个人；代码的作者，评审者和测试者不能是同一个人。某些公司对独立性会有额外的要求，比如写需球和写代码的人不能是同一个人（这个在178b中并没有要求）。注意此处强调的是人，如果作者和验证者是同一个组织架构下的，比如都是开发组的，则是没有问题的。178B只是强调人不同即可。

注：针对QA，其所有的目标都必须是独立的。这也是为什么QA是独立于开发，测试的角色。因为QA是贯穿整个生命周期的角色，如果让一个开发者去充当了QA，那么在开发者在到了自己的开发工作时，还需要找其他的人进行QA工作。因为针对于QA，其所有的目标都必须的独立的。

注：Level E不需要满足178b的目标

相关规章

DO-248B, Final Report for Clarification of DO-178B “Software Considerations in Airborne Systems and Equipment Considerations,” October 12, 2001 对于178B的Q&A

FAA Order 8110.49, Software Approval Guidelines, Change 1, Sept. 28, 2011 对178b更详细的阐述，是用来指导局方如何按照178b进行机载软件审核