软件等级与安全目标：从系统安全性评估到DO-178C等级的确定
在机载软件适航认证的语境中，软件等级（Software Level）并非一个孤立的“研发难度标签”，而是系统安全性评估（System Safety Assessment, SSA）在软件层面的直接映射。它决定了开发保证等级（DAL）、验证严格度、文档交付物数量以及最终适航审查的深度。理解软件等级的本质，需要先跳出软件本身，从飞机级功能失效的因果链出发。本章将系统阐述软件等级A/B/C/D/E的确定方法、安全目标（如失效概率）与等级之间的量化关系，以及如何通过ARP4754A与ARP4761的工程实践完成等级分配。
上图展示了从飞机级功能到软件等级的核心推导链路。整个流程始于飞机级功能危害评估（FHA），经由失效状态分类，最终映射到软件等级。值得注意的是，软件等级并非由软件自身复杂度决定，而是由其所承载的失效状态严重性决定。一个极其简单的软件（如仅包含几十行代码的燃油泵控制逻辑），如果其失效可能导致灾难性后果，则必须按Level A开发；反之，一个功能复杂的维护诊断软件，若失效仅影响便利性，则可能只需Level D或E。
核心原理：失效状态分类与安全目标的量化逻辑
软件等级的确定根植于系统安全性评估的量化框架。ARP4761定义了失效状态的五个严重性类别，每一类对应一个定量的概率目标和开发保证等级（DAL）。这一映射关系是行业共识，也是适航当局（如FAA、EASA）审查的基础。
| 失效状态分类 | 对飞机/乘员的影响 | 概率目标（每飞行小时） | 软件等级 (DAL) | DO-178C目标数量 |
|---|---|---|---|---|
| Catastrophic (灾难性) | 飞机失事，多人死亡 | ≤ 1×10⁻⁹ | A | 71个目标全部满足 |
| Hazardous (危险) | 飞机受损，少数人受伤 | ≤ 1×10⁻⁷ | B | 69个目标（减少2个） |
| Major (重大) | 乘客不适，飞机性能显著降低 | ≤ 1×10⁻⁵ | C | 62个目标 |
| Minor (轻微) | 乘客不便，操作受限 | 无定量要求 | D | 26个目标 |
| No Effect (无影响) | 无安全影响 | 无要求 | E | 无目标（不适用） |
上述概率目标并非软件单独承担的，而是整个系统（包括硬件、机械、人为因素）的综合失效概率。软件作为系统的一部分，其等级分配遵循“最坏情况”原则：如果软件失效会导致某个失效状态发生，则该软件至少需要达到该失效状态对应的DAL。例如，若一个软件模块的失效既可能导致Major状态，也可能导致Hazardous状态，则必须按Hazardous对应的Level B开发。
判断方法或操作流程：从FHA到软件等级的六步法
在实际型号开发中，确定软件等级通常遵循以下标准流程。该流程在ARP4754A（民用飞机与系统开发指南）和ARP4761（民用机载系统安全性评估过程指南）中有详细描述。
- 飞机级功能危害评估（Aircraft FHA）：在飞机概念设计阶段，识别所有飞机级功能，分析其失效状态及严重性分类。输出物为飞机级FHA报告。
- 初步系统安全评估（PSSA）：将飞机级安全需求分配到各系统。通过故障树分析（FTA）、失效模式与影响分析（FMEA）等工具，确定系统架构如何满足飞机级安全目标。此阶段会初步分配DAL到各系统及子系统。
- 系统级FHA：针对每个系统（如飞控、液压、航电）进行更细粒度的功能危害评估，识别系统级失效状态。
- 系统安全性评估（SSA）：在系统设计定型后，通过定量分析（如故障树、马尔可夫分析）验证系统实际失效概率是否满足PSSA分配的目标。若满足，则确认DAL分配；若不满足，则需修改设计或提高DAL。
- 软件等级分配：根据SSA确认的系统级DAL，将软件等级分配给系统中的每个软件项。分配原则是：软件等级 = 其可能导致的最高严重性失效状态对应的DAL。
- 软件计划阶段确认：在DO-178C的PSAC（软件适航计划）中明确每个软件项的等级，并提交适航当局批准。等级一旦确定，后续所有开发、验证、配置管理活动均需按此等级执行。
关键操作要点：在PSSA阶段，DAL分配往往采用“自上而下”与“自下而上”结合的方式。自上而下指从飞机级目标逐级分解；自下而上指通过FMEA识别单点失效，若单点失效导致灾难性后果，则该部件必须为Level A。此外，共因分析（CCA）用于识别可能导致多个独立通道同时失效的共同因素（如共用电源、冷却系统），这些因素会直接影响DAL的分配。
案例拆解：自动飞行系统（AFS）的软件等级确定
以某型民用飞机的自动飞行系统（AFS）为例，演示软件等级确定的完整闭环。该系统包含三个主要软件组件：自动驾驶计算机（APC）、飞行指引计算机（FGC）和推力管理计算机（TMC）。
背景与约束：该飞机需通过FAA第25部适航认证。AFS功能包括自动驾驶、高度保持、垂直导航、自动油门等。系统架构采用双通道冗余（APC-A/APC-B），每个通道独立供电、独立传感器输入。
初始现象与目标：飞机级FHA识别出“自动驾驶在进近阶段非指令性脱开”为Hazardous失效状态（概率目标≤1×10⁻⁷/飞行小时）。系统级PSSA进一步分析，该失效状态可能由APC软件故障、FGC软件故障或两者共同导致。
关键输入数据：
- 飞机级FHA：自动驾驶非指令脱开 → Hazardous → DAL B
- 系统架构：双通道独立，单通道失效不会导致灾难性后果
- FMEA分析：APC-A和APC-B的软件存在共模失效风险（共用同一版本软件）
- CCA分析：两个通道共用同一电源汇流条，存在共因失效风险
分析判断过程：由于APC-A和APC-B运行相同版本的软件，若该软件存在设计缺陷，会导致双通道同时失效，直接引发Hazardous状态。因此，尽管系统架构是双冗余，但软件本身成为单点失效。根据ARP4754A的DAL分配原则，该软件必须分配为Level B（对应Hazardous）。进一步，若FGC软件失效仅导致飞行指引功能丧失（Major状态），则FGC软件可分配为Level C。TMC软件失效导致自动油门异常，若仅影响舒适性（Minor），则分配为Level D。
实际操作步骤：
- 在PSSA中建立故障树，量化APC软件失效概率需求（≤1×10⁻⁷/飞行小时）。
- 通过CCA识别共模点，确认APC软件需按Level B开发。
- 在PSAC中明确APC软件为Level B，FGC为Level C，TMC为Level D。
- 开发过程中，APC软件需满足DO-178C Level B的全部69个目标，包括更严格的MC/DC覆盖率（语句、判定、条件、修正条件/判定覆盖）。
结果对比与复盘：若未进行CCA分析，可能会错误地将APC软件分配为Level C（因为双通道冗余看似降低了风险），这将导致验证不足，在适航审查中被拒绝。通过正确的等级分配，APC软件增加了结构覆盖率分析和形式化方法的使用，虽然开发成本增加约30%，但确保了安全性目标的可达性。复盘经验：软件等级分配必须考虑共因失效，不能简单依赖硬件冗余来降低软件等级。
常见误区与总结复盘
误区一：将软件复杂度与软件等级挂钩。许多开发团队认为“功能简单、代码量少”的软件等级应该低。实际上，一个控制发动机燃油切断的简单逻辑，若失效导致双发停车，则必须为Level A。等级只与失效后果相关，与代码行数无关。
误区二：忽视共因失效对等级的影响。如上述案例所示，即使系统架构冗余，若软件版本相同或存在共享资源，软件等级不能降低。CCA（共因分析）是等级确定中不可跳过的环节。
误区三：混淆“系统DAL”与“软件等级”。系统DAL是分配给整个系统的，而软件等级是针对系统中每个软件项的。一个系统可能包含多个软件项，各自等级不同。例如，一个Level B的系统中，其维护诊断软件可能仅为Level D。
误区四：认为Level E软件无需任何保证。虽然DO-178C对Level E不适用，但ARP4754A仍要求进行基本的功能验证。Level E软件通常指那些失效不会影响飞机安全性的软件，但仍需进行需求确认和基本测试。
总结复盘：软件等级的确定是一个严谨的系统工程过程，其核心逻辑是“失效后果驱动”。从飞机级FHA到系统级SSA，每一步都需要量化分析和文档记录。适航审查时，审查代表会重点关注等级分配的合理性，特别是共因失效分析和单点失效识别。开发团队应在项目早期就建立安全性评估与软件开发的沟通机制，确保等级分配结果能够及时、准确地传递到软件计划中。此外，当系统设计发生变更（如增加新功能、改变架构）时，必须重新评估软件等级，这通常通过配置管理流程中的“安全性影响分析”来完成。