第2章：DO-178C标准总览

各位同学，今天我们聊聊DO-178C的全貌。说实话，我刚入行那会儿，看到这个标准的第一反应是——好厚一本。但干久了你会发现，它其实就是一本「安全飞行指南」。

2.1 DO-178C的历史沿革

DO-178的故事要从上世纪80年代讲起。那时候航空电子系统开始大规模用软件，但出了不少问题。我记得有个老工程师跟我讲过，早期有个飞控软件因为一个定时器溢出，差点让飞机在空中「发呆」。

于是1982年，RTCA（航空无线电技术委员会）发布了第一版DO-178。那时候还比较粗糙，主要是个框架。到了1992年，DO-178B出来了，这才真正成了行业标杆。我参与的第一个适航项目就是按178B做的，那时候还没有面向对象的概念，代码全是C语言，结构化编程。

2011年，DO-178C发布。为什么要升级？说白了，技术变了。模型设计、自动代码生成、形式化方法这些新玩意儿，178B管不住了。我有个朋友在空客做A350的飞控，他们用模型开发，178B根本没法直接套用，得跟局方谈「等效安全」。178C把这些都规范了，省了很多扯皮的事。

2.2 与其他标准的关系

你可能会问，DO-178C是不是孤立的？当然不是。它跟几个兄弟标准关系密切。

2.2.1 DO-254：硬件也逃不掉

DO-254是硬件的适航标准。为什么飞控软件要懂硬件标准？我举个例子。有一次我们在做飞控计算机的认证，软件跑在FPGA上。局方问：「你这个FPGA的逻辑怎么验证的？」软件团队说这是硬件的事，硬件团队说这是软件配置。最后两边都挨批了。

DO-178C和DO-254的关系，说白了就是「软硬一体」。飞控系统里，软件跑在硬件上，硬件出问题软件也扛不住。所以现在很多项目都搞「联合认证」，软件和硬件团队坐在一起，把接口、时序、资源占用这些事说清楚。

2.2.2 DO-331：模型开发的专属标准

DO-331是DO-178C的补充，专门针对模型开发。现在很多飞控都用Simulink建模，然后自动生成代码。DO-331就是告诉你：模型怎么建才算合规，自动生成的代码怎么验证。

我个人习惯，用模型开发时一定保留模型评审的记录。局方检查时，光有代码不行，你得证明模型本身是对的。有一次项目，我们模型里有个状态机画错了，自动生成的代码也跟着错。幸亏模型评审时发现了，不然飞上去就麻烦了。

2.3 软件等级划分（A/B/C/D/E）

这是DO-178C最核心的概念之一。软件等级，说白了就是「这个软件出问题会死多少人」。

等级划分的依据是故障条件（Failure Condition）的严重程度。局方有个表格，我直接给你们看：

等级	故障条件	后果描述	我见过的例子
A级	灾难性的	飞机坠毁，多人死亡	飞控主控软件、自动驾驶核心
B级	危险的	严重受伤，飞机严重损坏	飞行管理系统的部分功能
C级	重大的	乘客不适，系统降级	座舱显示系统、部分告警功能
D级	轻微的	轻微不便，无安全影响	客舱娱乐系统、部分维护日志
E级	无影响的	对飞机功能无影响	飞行后数据分析软件

你想想看，A级软件的要求有多严？独立验证、100%语句覆盖、100%分支覆盖、MC/DC覆盖……每一项都是硬骨头。我做过一个A级飞控项目，光测试用例就写了上万条，评审会开了三个月。

D级和E级就轻松多了。E级甚至不需要跟局方打交道，自己内部搞定就行。但要注意，等级是「就高不就低」的。如果一个功能同时影响A级和C级，那整个功能都得按A级做。

2.4 知识体系总览

下面这张图是我自己画的，把DO-178C的核心脉络理清楚了。你看一眼，心里就有数了。

这张图你看懂了吗？核心是DO-178C，左边是它的历史，右边是它跟其他标准的关系，下面是软件等级。每一块后面我们都会细讲。

2.5 我的几点体会

做了这么多年适航认证，我总结了几条经验，分享给你们：

1. 等级不是越高越好。 有人觉得A级最安全，就什么都往A级做。结果成本翻了好几倍，周期拉长，最后项目黄了。合理分配等级，才是真本事。
2. 标准是工具，不是枷锁。 DO-178C给了你方法，但没规定你必须怎么做。我见过用形式化方法做A级认证的，也见过用传统测试做B级认证的。关键是你得证明你的方法有效。
3. 早跟局方沟通。 别等到做完了才去找局方。我有个项目，前期跟局方开了三次会，把等级划分、认证策略都敲定了。后面做起来顺风顺水。另一个项目，闷头做了一年，局方一看说「你们这个等级分错了」，全盘重来。

好了，这一章就到这里。记住，DO-178C不是一本死板的教条，它是无数航空人用血泪换来的经验总结。你理解得越深，做项目就越顺手。