DO-178简介

本文翻译自维基百科。

DO-178A

不常用

DO-178B

最常用

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

DO-178C

最新版，准备代替DO-178B

DO-178C，机载系统和设备认证中的软件考虑因素是FAA、EASA和加拿大运输部等认证机构批准所有基于商业软件的航空航天系统的主要文件。该文件由RTCA, Incorporated与EUROCAE共同发布，并取代DO-178B。新文件名为 DO-178C/ED-12C，于 2011 年 11 月完成，并于 2011 年 12 月获得 RTCA 批准。它于 2012 年 1 月开始销售和使用。

除FAR 33 / JAR E 外，联邦航空条例不直接提及软件适航性。2013 年 7 月 19 日，FAA 批准了AC 20-115C，将 DO-178C 指定为公认的“可接受的方式，但不是唯一的方式，用于表明机载系统和设备的软件方面符合适用的 FAR 适航法规认证。”

背景

自DO-178B发布以来，DER（FAA指定工程代表）强烈呼吁澄清/细化 DO-178B 的高级要求、低级要求和派生的关键概念之间的定义和界限系统需求和系统设计（参见ARP4754）以及软件需求和软件设计（DO-178B 的领域）之间的退出/进入标准的更好定义。其他关注点包括基于模型的开发范式中验证的含义以及用模型模拟或形式化方法替换部分或全部软件测试活动的考虑。DO-178C 和配套文件的发布DO-278A（地面系统）、DO-248C（每个 DO-178C 目标的基本原理的附加信息）、DO-330（工具鉴定）、DO-331（建模）、DO-332（面向对象）和 DO-创建了 333（正式方法）来解决所指出的问题。SC-205 成员与 SAE S-18 委员会合作，以确保 ARP4754A 和上述 DO-xxx 文件提供具有补充标准的统一和链接过程。

总体而言，DO-178C 保留了 DO-178B 的大部分文本，这引起了人们的担忧，即 DO-178B 的问题，例如低级要求概念的模糊性，可能无法完全解决。

委员会组织

RTCA/EUROCAE 联合委员会的工作分为七个小组：

SG1：SCWG 文档集成
SG2：问题和理由
SG3：工具鉴定
SG4：基于模型的开发和验证
SG5：面向对象技术
SG6：形式方法
SG7：安全相关注意事项

基于模型的开发和验证小组 (SG4) 是最大的工作组。所有工作都通过一个协作工作管理机制的网站收集和协调。工作工件和草稿文件被保存在仅限小组成员使用的受限区域内。

这项工作的重点是使 DO-178B/ED-12B 在当前软件开发实践、工具和技术方面保持最新。

软件级别

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

灾难性的 - 故障可能导致死亡，通常是飞机丢失。
危险- 故障对安全或性能有很大的负面影响，或由于身体不适或更高的工作量而降低机组人员操作飞机的能力，或导致乘客严重或致命的伤害。
重大- 故障显着降低安全裕度或显着增加船员工作量。可能导致乘客不适（甚至轻伤）。
轻微- 故障会略微降低安全裕度或略微增加船员的工作量。示例可能包括造成乘客不便或例行飞行计划更改。
无影响- 故障对安全、飞机运行或机组工作量没有影响。

DO-178C 本身并不旨在保证软件安全方面。设计中的安全属性以及作为功能实现的安全属性必须接受额外的强制性系统安全任务，以驱动并显示满足明确安全要求的客观证据。认证机构要求并且 DO-178C 指定使用这些综合分析方法建立正确的 DAL 以建立软件级 AE。“软件级别建立了证明合规性所需的严格性”，符合 DO-178C。任何命令、控制和监视安全关键功能的软件都应获得最高 DAL - A 级。

要满足的目标数量（一些具有独立性）由软件级别 AE 确定。短语“具有独立性”指的是责任分离，其中验证和确认过程的客观性通过它们与软件开发团队的“独立性”来确保。对于必须满足独立性的目标，验证项目（例如需求或源代码）的人可能不是项目的作者，并且必须清楚地记录这种分离。

等级	故障条件	目标	具有独立性
A	灾难性的	71	30
B	危险的	69	18
C	主要的	62	5
D	次要的	26	2
E	无安全影响	0	0

流程和文件

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

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

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

对于基于 DO-178C 的通用流程，参与阶段 (SOI) 是认证机构参与审查 EASA 在认证备忘录 SWCEH – 002：SW 批准指南和 FAA中定义的系统或子系统的最低门槛关于命令 8110.49：SW 批准指南。

可追溯性

根据 RTCA DO-178C 标准的要求，说明认证工件之间所需的双向跟踪的图表。仅 A 级需要红色迹线。A、B 和 C 级需要紫色迹线。A、B、C 和 D 级需要绿色迹线。E 级不需要任何跟踪。每个跟踪箭头上的引用分别代表对目标、活动和审查/验证标准的引用。
DO-178 要求在认证工件之间记录双向连接（称为跟踪）。例如，一个低级需求（LLR）被追溯到一个它要满足的高级需求（HLR），同时它也被追溯到旨在实现它的源代码行，测试用例旨在验证源代码在需求、测试结果等方面的正确性。然后使用可追溯性分析来确保源代码满足每个需求，每个功能需求都经过测试验证，每一行源代码有一个目的（连接到一个需求），等等。可追溯性分析访问系统的完整性。认证工件的严谨性和细节与软件级别有关。

与 DO-178B 的区别

SC-205/WG-12 负责修订 DO-178B/ED-12B，使其与当前软件开发和验证技术保持同步。从 B 到 C，文档的结构基本保持不变。示例更改包括：

提供更清晰的语言和术语，提供更多的一致性
更多目标（适用于 A、B 和 C 级）
澄清了适用于 A 级的“隐藏目标”，这是DO-178B在第 6.4.4.2b 节中暗示但未在附件 A 表中列出的。这个目标现在在 DO-178C 附件 A 表 A-7 目标 9 中明确列出：“实现了无法追溯到源代码的附加代码的验证。”
参数数据项文件 - 提供影响可执行目标代码行为的单独信息（无需更改）。一个示例是设置分区操作系统的计划和主要时间框架的配置文件。参数数据项文件必须与可执行目标代码一起验证，否则必须针对参数数据项的所有可能范围进行测试。
DO-330 “软件工具鉴定注意事项”是一个新的“独立于域的外部文档”，旨在为可接受的工具鉴定过程提供指导。虽然 DO-178B 被用作开发这个新文件的基础，但文本被改编为直接和单独适用于工具开发，并扩展到解决所有工具方面。作为独立于域的独立文档，DO-330 不仅用于支持 DO-178C/ED-12C，还用于支持DO-278 /ED-109、DO-254/ED-80和DO -200也是如此，即使对于非航空应用，例如ISO 26262或ECSS也是如此。因此，DO-178C 中删除了工具鉴定指南，取而代之的是决定何时将 DO-330 工具鉴定指南应用于 DO-178C 环境中使用的工具。
添加了技术补充以将DO-178C 文件的指导扩展到特定技术。与其扩展先前的文本以说明所有当前和未来的软件开发技术，不如提供补充以明确添加、删除或以其他方式修改核心标准的指南，以应用于特定技术或技术。这些增补中的所有指南都是在 DO-178C 中受影响的指南要素的背景下编写的，因此应被视为与该核心文件具有相同的权威级别。
- DO-331 “DO-178C 和 DO-278A 的基于模型的开发和验证补充”——解决基于模型的开发 (MBD) 和验证以及使用建模技术改进开发和验证同时避免某些建模中固有的缺陷的能力方法
- DO-332 “DO-178C 和 DO-278A 的面向对象技术和相关技术补充”——解决面向对象软件及其使用条件
- DO-333 “对 DO-178C 和 DO-278A 的正式方法补充” - 解决补充（但不是替代）测试的正式方法