一、DO-178C概述：适航背景、软件等级划分、与DO-178B的差异
1.1 为什么要有DO-178C？——适航背景
做航空软件，跟做普通软件完全是两码事。
你写个手机App，崩溃了最多重启一下。但飞机上的软件要是出问题，那可是人命关天。我入行时带我的老工程师说过一句话，我一直记着：「航空软件不是写出来的，是证明出来的。」
适航，就是航空器能够安全飞行的资质证明。各国民航局（比如美国的FAA、欧洲的EASA、咱们中国的CAAC）都要求：飞机上的任何软硬件，必须证明自己足够安全，才能上天。
DO-178C，全称是《机载系统和设备合格审定中的软件考虑》，由RTCA（美国航空无线电技术委员会）和EUROCAE（欧洲民用航空设备组织）联合发布。它不是什么法律，但民航局把它当作「可接受的手段」——说白了，你按DO-178C做，局方就认；你不按它做，就得自己证明你的方法同样安全。嗯，后者难度极大，我几乎没见过谁这么干。
核心思想：DO-178C不是教你怎么写出好代码，而是教你怎么证明你的代码是安全的。
1.2 软件等级划分——你的软件有多重要？
飞机上那么多软件，不是每个都同等重要。DO-178C把软件按故障后果分了五个等级，叫DAL（Design Assurance Level，设计保证等级）。
| 等级 | 故障后果 | 通俗理解 | 典型例子 |
|---|---|---|---|
| A级 | 灾难性的 | 软件一坏，飞机就掉 | 飞控系统、发动机控制 |
| B级 | 危险的 | 严重威胁安全，但还能挣扎一下 | 起落架收放、防冰系统 |
| C级 | 重大的 | 影响任务，但不会直接摔飞机 | 座舱显示、导航系统 |
| D级 | 轻微的 | 有点小麻烦，不影响安全 | 客舱照明、娱乐系统 |
| E级 | 无影响的 | 坏了也没人知道 | 维护日志记录 |
等级越高，要求越严。A级软件，你写的每一行代码都要被测试覆盖，每一个分支都要跑到，每一个需求都要追溯到代码。我做过一个A级项目，光文档就堆了半屋子。
避坑指南：我曾经见过一个团队，把C级软件按A级标准做，结果进度严重超期。反过来，也有团队低估了B级软件的难度，测试覆盖率不够，被局方打回来重做。记住：等级不是越高越好，合适最重要。
1.3 DO-178C vs DO-178B——到底改了啥？
DO-178B是1992年发布的，用了快20年。到了2011年，技术变了，工具多了，开发方法也进化了，于是有了DO-178C。很多人问我：「B和C差别大吗？」我的回答是：核心思想没变，但细节上多了不少新东西。
1.3.1 最大的变化：工具鉴定
DO-178B里也提工具，但说得比较模糊。DO-178C专门加了一个附件（附篇A），把工具分成了三类：
- 工具鉴定等级1（TQL-1）：工具的输出不经过人工检查，直接用于生成代码或测试。比如自动代码生成器。这类工具要求最高，必须证明它自己不会引入错误。
- 工具鉴定等级2（TQL-2）：工具的输出会被人检查或测试验证。比如静态分析工具。要求中等。
- 工具鉴定等级3（TQL-3）：工具只辅助开发，不直接影响安全。比如文档生成工具。要求最低。
我个人习惯，在项目启动时就先列清楚要用哪些工具，然后跟局方确认它们的鉴定等级。否则做到一半发现工具没鉴定，那可就麻烦了。
1.3.2 新增了基于模型的设计
DO-178B那个年代，大家主要手写代码。到了C版，基于模型的设计（Model-Based Design）已经很普遍了。你想想看，用Simulink画个模型，然后自动生成代码，这比手写快多了。但问题来了：模型本身算不算「软件」？DO-178C明确回答：算。模型也需要验证、测试、配置管理。
注意：模型不是随便画画的。我曾经审核过一个项目，他们的模型里到处都是死逻辑和不可达状态，结果自动生成的代码里全是垃圾。模型的质量，直接决定代码的质量。
1.3.3 形式化方法被正式接纳
DO-178B对形式化方法（Formal Methods）基本没提。DO-178C把它作为一种可选的技术手段，用于替代部分测试。说白了，如果你能用数学证明你的代码没有某些类型的错误，那就不用跑那么多测试用例了。不过说实话，我在实际项目中很少见到纯形式化方法，太费劲了。但它在一些关键安全属性（比如没有除零错误、没有数组越界）上确实好用。
1.3.4 对象导向技术有了指导
DO-178B时代，C语言是主流。到了C版，C++、Ada这些面向对象语言用得越来越多。DO-178C专门加了一个附件（附篇B），讲面向对象技术的注意事项。比如：继承、多态、动态绑定这些特性，在航空软件里怎么用才安全。
我记得有个项目，团队用了C++的虚函数，结果测试时发现覆盖率死活达不到要求——因为有些分支在运行时根本不会被执行。后来我们不得不重构代码，把虚函数改成条件判断。嗯，航空软件里，有时候「笨」一点反而更安全。
1.3.5 参数化数据项
这个变化比较细，但很重要。DO-178C把「参数化数据项」单独拎出来，意思是那些在运行时可以修改的配置参数（比如PID控制器的增益系数），也需要纳入配置管理和验证。以前很多人觉得「改个参数而已，不用走流程」，结果出过不少事故。
1.4 一张图看懂DO-178C的核心逻辑
1.5 我的几点体会
做了十几年航空软件，我最大的感受是：DO-178C不是束缚，而是保护。它保护的不只是乘客，也是我们这些开发者。按流程走，每一步都有据可查，出了问题也能快速定位。我见过不按流程做的项目，最后出了问题，谁也说不清楚责任，那才叫一个乱。
另外，别把DO-178C当成「考试」。它不是让你一次性通过就完事了，而是贯穿整个项目生命周期的持续活动。从需求分析到代码实现，从测试到发布，每一步都要想着「我能不能证明这是对的」。
一句话总结：DO-178C的核心，就是用系统化的工程方法，把软件的安全性「做出来」并且「证明出来」。
公众号:蓝海资料掘金营，微信deep3321