第三章：软件等级与失效条件
3.1 从飞机级FHA到软件等级
做DO-178C认证，第一步就是搞清楚你的软件到底有多“危险”。
我个人习惯，拿到一个新项目，先问系统工程师一个问题：“这玩意儿要是挂了，飞机还能不能飞？”
这个问题，说白了就是飞机级功能危害评估（FHA）要回答的核心。FHA会分析每个功能失效后，对飞机、机组和乘客的影响程度。影响越严重，软件等级就越高。
我遇到过不少团队，一上来就埋头写代码，结果评审时发现软件等级定错了，整个开发流程都得推倒重来。嗯，那场面，挺尴尬的。
核心逻辑：失效条件 → 飞机级影响 → 软件等级
3.2 五个等级，五条命
DO-178C把软件等级分成A到E五档。你想想看，这就像给软件上了五道不同的保险。
| 软件等级 | 失效条件 | 对飞机的影响 | 我见过的案例 |
|---|---|---|---|
| A级 | 灾难性 | 飞机坠毁，多人死亡 | 飞控计算机主控软件 |
| B级 | 危险/严重 | 飞机严重受损，可能有人死亡 | 发动机控制软件 |
| C级 | 重大 | 飞机功能降级，乘客不适 | 座舱显示系统 |
| D级 | 轻微 | 机组工作负荷增加，无安全影响 | 客舱照明控制 |
| E级 | 无影响 | 对飞机安全无任何影响 | 机上娱乐系统（非安全相关） |
这里有个坑，我提醒你注意：E级软件其实不受DO-178C约束。但很多客户会要求你按D级做，因为怕你偷偷改了代码影响其他系统。
避坑指南：我曾经见过一个项目，把客舱娱乐系统定为E级，结果它和飞控系统共享了同一个电源模块。后来FHA重新评估，直接升到了C级。记住：软件等级看的是失效后果，不是功能本身。
3.3 不同等级对需求分析的要求差异
等级不同，需求分析的“深度”和“广度”完全不同。我做了个对比，你一看就明白。
| 需求分析活动 | A级 | B级 | C级 | D级 |
|---|---|---|---|---|
| 需求完整性 | 必须100%覆盖 | 必须100%覆盖 | 必须100%覆盖 | 建议覆盖 |
| 需求可追溯性 | 双向追溯 | 双向追溯 | 单向追溯 | 可选 |
| 需求评审 | 独立评审+工具分析 | 独立评审 | 同行评审 | 自检 |
| 派生需求处理 | 必须追溯至系统需求 | 必须追溯 | 建议追溯 | 不强制 |
| 需求变更影响分析 | 全量分析 | 全量分析 | 局部分析 | 可选 |
为什么会这样？因为A级软件的失效会直接导致机毁人亡，所以每个需求都必须“说得清、追得回、验得准”。
我举个例子。A级软件的需求里，如果有一条说“当空速大于250节时，襟翼自动收回”，那你必须能追溯到系统需求里的“襟翼保护逻辑”，同时还要有测试用例证明这条需求被正确实现了。少一个环节，局方审查时就过不去。
但D级软件呢？比如客舱灯光的亮度调节，你只要写清楚“按一下按钮，亮度增加10%”就行。没人会追着你问“这个10%是怎么来的”。
我的个人经验：做A/B级项目时，我习惯在需求阶段就建立“需求-设计-测试”的三向追溯矩阵。虽然前期工作量翻倍，但到了集成测试阶段，你会发现省了至少30%的返工时间。这笔账，划算。
3.4 一张图看懂软件等级与需求分析的关系
下面这张图，是我自己总结的。每次给新团队培训，我都会先画一遍。
你看，从FHA到软件等级，再到需求分析要求，是一条清晰的链条。等级越高，要求越严。这不是谁拍脑袋定的，是血的教训换来的。
3.5 实际操作中的几个关键点
说了这么多理论，我分享几个实战中容易踩的坑。
- 等级不是一成不变的。系统设计变了，FHA就得重新做。我有个项目，中期改了架构，结果软件等级从C级升到了B级，整个验证计划都得重写。
- 派生需求也要追溯。很多团队只追溯原始需求，忽略了派生需求。局方审查时，这是高频问题点。
- 工具链的影响。A/B级项目如果用工具生成代码，工具本身也需要认证。这个成本，前期就要算进去。
再提醒一句：我曾经见过一个团队，为了省事，把所有软件都定为D级。结果FHA评审时被局方打回来，重新评估后大部分模块升到了C级，工期延误了三个月。别耍小聪明，该是什么等级就是什么等级。
好了，关于软件等级和需求分析的关系，我就讲这么多。记住一句话：等级越高，责任越大，要求越严。做DO-178C，别想着走捷径，每一步都要走得扎实。
公众号:蓝海资料掘金营，微信deep3321