DO-178C

本文翻译自维基百科。

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 的正式方法补充” - 解决补充（但不是替代）测试的正式方法