DO-178B

系列索引：VAPS XT入门系列索引

本文翻译自维基百科。

DO-178B，机载系统和设备认证中的软件注意事项是处理某些机载系统中使用的安全关键软件的安全性的指南。它由航空无线电技术委员会(RTCA) 的安全关键工作组 RTCA SC-167 和欧洲民用航空设备组织(EUROCAE)的 WG-12联合开发。RTCA 将该文件发布为RTCA/DO-178B，而 EUROCAE 将该文件发布为ED-12B。虽然在技术上是一个指导方针，但它是开发航空电子软件系统的事实上的标准，直到它在 2012 年被DO-178C取代.

美国联邦航空管理局(FAA) 应用 DO-178B 作为其用于指导的文件，以确定软件是否在机载环境中可靠运行，当寻求认证的技术标准指令(TSO) 规定时。在美国，将 TSO 引入适航认证过程，并扩展 DO-178B，明确规定在联邦法规(CFR) 的第 14 篇：航空和空间，也称为联邦航空法规，第 21 部分，O 小节。

软件级别

软件级别，也称为ARP4754中定义的设计保证级别(DAL) 或项目开发保证级别(IDAL) （DO- 178C仅提及 IDAL 与软件级别同义），由安全评估过程确定，并且通过检查系统中故障条件的影响进行危害分析。故障条件按其对飞机、机组人员和乘客的影响进行分类。

• 灾难性的——失败可能会导致崩溃。安全飞行和着陆飞机所需的关键功能出现错误或丧失。
• 危险——故障对安全或性能有很大的负面影响，或由于身体不适或更高的工作量而降低机组人员操作飞机的能力，或导致乘客严重或致命的伤害。（安全重要）
• 重大– 故障很严重，但影响小于危险故障（例如，导致乘客不适而不是受伤）或显着增加机组工作量（与安全相关）
• 轻微故障 – 故障很明显，但影响小于重大故障（例如，造成乘客不便或例行飞行计划更改）
• 无影响——故障对安全、飞机运行或机组工作量没有影响。

DO-178B 本身并不旨在保证软件安全方面。设计中的安全属性并作为功能实现，必须接受额外的强制性系统安全任务，以驱动并显示满足明确安全要求的客观证据。通常分配 IEEE STD-1228-1994 软件安全计划，并按顺序步骤完成软件安全分析任务（需求分析、顶层设计分析、详细设计分析、代码级分析、测试分析和变更分析）。这些软件安全任务和工件是系统安全评估 (SSA) 中记录的危害严重性和 DAL 确定过程的不可或缺的支持部分。认证机构要求并且 DO-178B 指定使用这些综合分析方法建立正确的 DAL 以建立软件级 AE。任何命令、控制和监视安全关键功能的软件都应获得最高的 DAL - A 级。驱动系统安全评估的软件安全分析确定了驱动 DO-178B 中适当严格级别的 DAL。系统安全评估结合方法如SAE ARP 4754A确定缓解后 DAL，如果冗余、设计安全特性和其他架构形式的危害缓解符合安全分析驱动的要求，则可能允许降低 DO-178B 软件级别目标。因此，DO-178B 的中心主题是在建立前提安全要求之后的设计保证和验证。

要满足的目标数量（最终具有独立性）由软件级别 AE 确定。短语“具有独立性”指的是责任分离，其中验证和确认过程的客观性通过它们与软件开发团队的“独立性”来确保。对于必须满足独立性的目标，验证项目（例如需求或源代码）的人可能不是项目的作者，并且必须清楚地记录这种分离。在某些情况下，自动化工具可能等同于独立性。但是，如果它替代人工审查，则该工具本身必须是合格的。

等级	故障条件	目标	具有独立性	失败率
A	灾难性的	66	25	$10^{-9}$ /h
B	危险的	65	14	$10^{-7}$ /h
C	主要的	57	2	$10^{-5}$ /h
D	次要的	28	2	$10^{-3}$ /h
E	没有效果	0	0	不适用

流程和文件

根据软件级别（A 到 D——E 级不在 DO-178B 的范围内），流程旨在支持目标。流程在 DO-178B 中被描述为抽象的工作领域，由实际项目的规划者来定义和记录如何执行流程的细节。在实际项目中，必须显示将在流程上下文中完成的实际活动以支持目标。这些活动由项目规划者定义为规划过程的一部分。

DO-178B 的这种基于目标的特性在遵循不同风格的软件生命周期方面具有很大的灵活性。一旦定义了过程中的活动，通常期望项目尊重其过程中记录的活动。此外，根据 DO-178B，流程（及其具体活动）必须具有明确定义的进入和退出标准，并且项目必须表明它在执行流程中的活动时遵守了这些标准。

DO-178B 的流程和进入/退出标准的灵活性使其难以在第一次实施，因为这些方面是抽象的，并且没有可以工作的活动“基础集”。DO-178B 的意图不是规定性的。实际项目有许多可能和可接受的方式来定义这些方面。这是一家公司第一次尝试在此标准下开发民用航空电子系统时可能会很困难，并为 DO-178B 培训和咨询创造了一个利基市场。

对于基于 DO-178B 的通用流程，提供了视觉摘要，包括 FAA 在“软件和复杂电子硬件的指导和工作辅助”中定义的参与阶段 (SOI)。

规划

系统要求通常输入到整个项目中。

软件级别 D 不需要最后 3 个文档（标准）。

发展

DO-178B 并非旨在作为软件开发标准；它是使用一组任务来满足目标和严格程度的软件保证。

开发过程输出文件：

• 软件需求数据 (SRD)
• 软件设计说明 (SDD)
• 源代码
• 可执行目标代码

通常需要从系统要求到所有源代码或可执行目标代码的可追溯性（取决于软件级别）。

常用的软件开发流程：

• 瀑布模型
• 螺旋模型
• V型

验证

记录此过程产生的输出：

• 软件验证案例和程序 (SVCP)
• 软件验证结果（SVR）：
  • 审查所有要求、设计和代码
  • 测试可执行目标代码
  • 代码覆盖率分析

通常需要分析从测试和结果到所有需求的所有代码和可追溯性（取决于软件级别）。

此过程通常还涉及：

• 基于需求的测试工具
• 代码覆盖分析工具

在此过程中执行的测试的其他名称可以是：

• 单元测试
• 集成测试
• 黑盒和验收测试

配置管理

配置管理过程 维护的文档：

• 软件配置指数（SCI）
• 软件生命周期环境配置指数（SECI）

此流程处理问题报告、更改和相关活动。配置管理过程通常提供以下文件的存档和修订标识：

• 源代码开发环境
• 其他开发环境（例如测试/分析工具）
• 软件集成工具
• 所有其他文件、软件和硬件

质量保证

质量保证过程的输出文件：

• 软件质量保证记录 (SQAR)
• 软件符合性审查 (SCR)
• 软件成就总结 (SAS)

此过程执行审查和审计以表明符合 DO-178B。与认证机构的接口也由质量保证过程处理。

认证联络

通常，指定工程代表(DER) 审查技术数据，作为提交给 FAA 批准的一部分。

工具

软件可以自动化、协助或以其他方式处理或帮助 DO-178B 流程。用于 DO-178B 开发的所有工具都必须是认证过程的一部分。生成嵌入式代码的工具被认定为开发工具，具有与嵌入式代码相同的约束条件。用于验证代码的工具（模拟器、测试执行工具、覆盖工具、报告工具等）必须具备验证工具的资格，这是一个轻得多的过程，包括对工具的全面黑盒测试。

第三方工具可以作为验证工具，但开发工具必须是按照 DO-178 流程开发的。以COTS形式提供此类工具的公司需要接受认证机构的审核，他们可以完全访问源代码、规范和所有认证工件。

在此范围之外，任何使用过的工具的输出都必须由人工手动验证。

• 问题管理工具可以提供变更的可追溯性。
• SCI 和 SECI 可以从版本控制工具中的日志创建。

需求管理

需求可追溯性与记录需求的生命周期有关。应该可以追溯到每个需求的起源，因此对需求所做的每个更改都应该记录在案，以实现可追溯性。甚至在部署和使用实现的特性之后对需求的使用也应该是可追溯的。

批评

VDC Research 指出，DO-178B 已经“有些过时”，因为它不能很好地适应当今工程师的需求和偏好。在同一份报告中，他们还指出DO-178C似乎已经准备好解决这个问题。

资源

• FAR 23/25 §1301/§1309
• FAR 27/29 部分
• AC 23/25.1309
• AC 20-115B
• RTCA/DO-178B
• FAA 令 8110.49 软件批准指南

价格

下载

下载地址：蓝奏云 0.5M

我从谷歌上找到的文档，公司老板的评价是

这份文档如果没有参与民机开发过程，或者对于可靠性工程没有接触过的话，吸收起来还是会有点吃力。
里面很多条款只有条件，但是没有具体可参考的执行方法

推荐《机载软件适航标准DO-178B/C研究》 9787313094698 2013-10