第一章：课程导论与认证全景

DO-178C 的起源：从一次惨痛教训说起

说起 DO-178C，我得先跟你聊聊它的“前世今生”。上世纪 80 年代，航空电子系统开始大规模数字化。那时候，软件在飞机上的角色越来越重，但相应的安全标准却几乎是空白。

我记得有个经典案例——某型飞机的飞控软件出了 bug，导致试飞时出现剧烈振荡。调查发现，问题出在需求定义不清晰，代码和需求根本对不上。说白了，就是“写代码的人不知道自己要实现什么”。

这件事之后，美国航空无线电技术委员会（RTCA）和欧洲民航设备组织（EUROCAE）坐不住了。他们联合起草了第一版 DO-178，也就是 1982 年的版本。嗯，那时候我还没入行，但听前辈们讲，那版标准更像是一份“建议清单”，远没有今天这么严谨。

到了 1992 年，DO-178B 发布。这版标准奠定了现代机载软件认证的基石。它引入了“软件等级”的概念，把安全关键性分成了 A 到 E 五个级别。A 级软件出问题会导致灾难性事故，E 级则基本不影响安全。这个分级思路，直到今天还在用。

DO-178C 与 DO-178B 的核心差异

2011 年，DO-178C 正式发布。很多人问我：“B 版用得好好的，为什么要升级到 C 版？”

原因其实很简单——技术变了。B 版发布后的二十年里，出现了很多新东西：基于模型的开发、形式化方法、面向对象技术……B 版对这些要么没覆盖，要么语焉不详。C 版就是来补这个窟窿的。

我挑几个最关键的差异说说：

• 工具鉴定更严格：C 版把工具分成了三类——工具鉴定、工具验证、工具开发。以前用工具生成的代码，很多人觉得“工具出的肯定没问题”。但 C 版明确告诉你：工具本身也需要认证。我在项目中遇到过，一个代码生成工具因为版本升级，导致生成的代码多了一条死循环。嗯，从那以后我再也不敢盲目信任工具了。
• 基于模型的设计有了正式地位：B 版时代，模型更多是“画着玩玩”。C 版则把模型当作一种正式的开发产物，模型本身也要做需求分析和验证。说白了，模型不再是“文档的配图”，而是和代码平起平坐的交付物。
• 形式化方法被纳入：C 版引入了“形式化方法”作为补充手段。如果你用数学证明的方式验证了某个关键算法，可以替代部分测试。当然，这个门槛很高，我做了十五年认证，真正用形式化方法的项目不超过三个。
• 可追溯性要求更细：B 版也要求可追溯，但 C 版把“双向追溯”写进了核心要求。从高层需求到低层需求，再到代码和测试用例，必须能正向反向都能追。我曾经帮一个客户补追溯矩阵，发现他们 30% 的测试用例找不到对应的需求。你想想看，这要是被局方发现，整个认证都得重来。

DO-178C 的江湖地位

在机载软件安全认证这个圈子里，DO-178C 就是“圣经”。

为什么这么说？因为全球几乎所有民航局——FAA、EASA、CAAC——都认可它。你开发的飞控软件、导航软件、发动机管理软件，只要想装到飞机上，就必须过 DO-178C 这一关。

我个人的体会是，DO-178C 不仅仅是一份标准，它更像一套“安全思维方法论”。它逼着你在开发之前想清楚：我的需求到底对不对？我的设计能不能满足需求？我的测试有没有覆盖所有风险点？

举个例子。有一次我评审一个项目的需求文档，发现有一条需求写的是“系统应在 100 毫秒内响应”。我问开发人员：“这个 100 毫秒是怎么来的？”他说：“感觉差不多。”我当场就让他回去重新分析。DO-178C 要求每个需求必须有明确的来源和依据，不能靠“感觉”。

知识体系框架

下面这张图是我自己整理的 DO-178C 核心知识体系。它把整个认证过程分成了三个层次：计划层、执行层、证据层。你想想看，做认证就像盖房子——先有蓝图（计划），然后施工（执行），最后验收（证据）。

这张图我每次培训都会拿出来讲。它帮你把整个认证过程串起来——计划层定规矩，执行层干活，证据层交作业。三层缺一不可。

我的个人感悟

做了十五年 DO-178C 认证，我最大的体会是：这个标准不教你“怎么写代码”，它教你“怎么证明你的代码是安全的”。

很多人觉得认证就是“填表格、写文档”。其实不是。真正的认证思维，是让你在开发过程中始终保持一种“被审查”的心态。每写一行代码，你都要问自己：这个需求在哪？测试用例在哪？覆盖率够不够？

嗯，这种思维习惯养成了，你写出来的软件质量自然就高。我带的团队里，凡是认真按 DO-178C 流程走下来的项目，后期 bug 率都低得惊人。这不是巧合，是方法论的力量。