2、适航与软件认证基础：适航概念、民航规章体系与软件等级确定
适航（Airworthiness）是航空器安全运行的法定属性，指航空器、发动机、螺旋桨或部件符合经批准的类型设计且处于安全可用状态。在DO-178C语境下，软件认证并非孤立的技术活动，而是适航审定体系在机载软件领域的延伸。理解适航概念、规章体系（FAR/CS-25）、软件等级（DAL A-E）的确定方法，以及DO-178C与适航当局的关系，是开展机载软件研制与取证工作的前提。本章将系统梳理这些基础概念，并重点解析DAL等级确定的操作路径。
上图展示了适航软件认证的总体逻辑：适航当局制定规章与指导材料，规章通过功能危害评估（FHA）确定失效条件严重性，进而映射到软件等级（DAL），最终由DO-178C提供满足适航要求的目标体系与过程指南。下面逐一展开。
2.1 适航概念与民航规章体系
2.1.1 适航的法定含义与认证框架
适航（Airworthiness）包含两个层面：初始适航（型号合格审定、生产许可）与持续适航（运行维护、适航指令）。对于机载软件而言，关注重点是初始适航中的型号合格审定（Type Certification）。适航规章（如FAR/CS-25）第1309条（系统设计与安装）是机载软件适航要求的源头条款，它要求：飞机系统及其设备必须设计成在发生任何失效条件时，不会产生灾难性后果，且概率与严重性相匹配。
民航规章体系呈金字塔结构：顶层是法律（如美国联邦航空法、欧洲基本法规），中间是规章（FAR/CS），底层是指导材料（AC、AMC、Order、Policy）。DO-178C本身并非法律或规章，而是被FAA接受为符合性方法（Means of Compliance）的行业标准。FAA在Order 8110.49中明确：使用DO-178C作为软件审定的指导材料，但申请人也可提出替代方法，需经当局批准。
| 层级 | 美国体系 | 欧洲体系 | 中国体系 | 作用 |
|---|---|---|---|---|
| 法律 | 联邦航空法（49 USC） | 欧洲议会法规 2018/1139 | 民航法 | 确立适航管理法律基础 |
| 规章 | FAR（联邦航空规章） | CS（适航审定规范） | CCAR（中国民航规章） | 规定适航标准与程序 |
| 指导材料 | AC/Order/Policy | AMC/GM/CM | AC/AP/咨询通告 | 解释符合性方法 |
| 行业标准 | DO-178C/DO-254等 | EUROCAE ED-12C等 | 等同采用DO/ED标准 | 提供具体工程方法 |
2.1.2 FAR/CS-25.1309与软件的关系
FAR 25.1309（或CS 25.1309）是机载软件适航要求的核心条款。其关键要求包括：
- 飞机系统在发生任何失效条件时，必须满足安全性要求，且失效概率与失效条件严重性成反比。
- 系统设计必须保证在可能的失效条件下，对机组警告、飞行机组操作、应急程序等有明确要求。
- 对于软件，条款要求其设计保证等级（DAL）必须与所执行功能的失效条件严重性一致。
AC 25.1309-1B（FAA）和AMC 25.1309（EASA）提供了失效条件分类与概率要求的定量指南。例如：灾难性失效条件要求概率小于10⁻⁹/飞行小时，且需表明不存在单点失效。软件等级（DAL）正是从这些失效条件中推导出来的。
关键理解：DO-178C不是法规，而是“被接受的符合性方法”。当申请人声明符合DO-178C时，适航当局通常接受其作为满足25.1309软件部分的证据。但当局保留审查和质疑的权利，尤其在目标裁剪、工具鉴定、构型管理等方面。
2.2 软件等级（DAL A-E）的定义与确定方法
2.2.1 DAL等级定义
软件等级（DAL，Design Assurance Level）根据软件功能失效对飞机、机组和乘客的影响程度分为A到E五个等级：
- DAL A（灾难性）：失效会阻止飞机继续安全飞行和着陆，如飞行控制计算机、自动着陆系统。
- DAL B（危险/严重-主要）：失效会降低飞机能力或机组处理不利运行条件的能力，如发动机全权限数字控制（FADEC）、导航数据库。
- DAL C（主要）：失效会显著降低飞机能力或机组处理不利条件的能力，但存在可接受的裕度，如飞行管理系统的部分功能、客舱压力控制。
- DAL D（次要）：失效会轻微降低飞机能力，如客舱照明控制、部分娱乐系统。
- DAL E（无影响）：失效不影响飞机适航性，如部分非安全相关客舱系统。
2.2.2 DAL确定的标准流程
DAL的确定不是软件工程师自行决定的，而是通过系统安全性评估（SSA）过程自上而下推导。标准流程如下：
- 功能危害评估（FHA）：在飞机级和系统级识别功能失效条件，评估其严重性（灾难性、危险、主要、次要、无影响）。
- 初步系统安全性评估（PSSA）：将飞机级失效条件分配到系统架构，建立安全性需求，确定每个系统组件的失效概率目标。
- 系统安全性评估（SSA）：在系统设计完成后，验证系统架构满足安全性需求，确认每个软件组件的DAL等级。
- DAL分配：根据失效条件严重性，将DAL分配给软件组件。若一个软件组件同时影响多个失效条件，取最高等级。
DAL确定过程中，需考虑架构缓解措施（如监控/保护机制、多通道冗余、隔离机制）。若系统通过架构设计降低了失效条件严重性，则软件DAL可相应降低。例如，一个原本可能造成灾难性后果的功能，若通过独立监控器保护，其软件DAL可从A降至B或C。
| 失效条件严重性 | 允许概率（/飞行小时） | 软件DAL | DO-178C目标数 | 独立性要求 |
|---|---|---|---|---|
| 灾难性 | <10⁻⁹ | A | 71 | 全部独立 |
| 危险/严重-主要 | <10⁻⁷ | B | 69 | 大部分独立 |
| 主要 | <10⁻⁵ | C | 62 | 部分独立 |
| 次要 | <10⁻³ | D | 26 | 无独立要求 |
| 无影响 | 无要求 | E | 0 | 不适用 |
2.2.3 案例拆解：飞行控制计算机的DAL确定
以某运输类飞机的飞行控制计算机（FCC）为例，说明DAL确定过程。
背景与约束：该飞机采用电传飞行控制系统，FCC是核心控制单元。适航规章要求FCC失效不得导致灾难性后果。飞机级FHA识别出“失去飞行控制”为灾难性失效条件，概率要求<10⁻⁹/飞行小时。
初始现象与目标：系统架构采用三余度FCC（三个独立通道），每个通道包含相同的软件。目标是确定每个FCC通道软件的DAL等级。
分析判断过程：
- 若三个通道同时失效，则发生灾难性失效。每个通道的失效概率目标为10⁻⁹/3 ≈ 3.3×10⁻¹⁰/飞行小时（假设均分）。
- 由于三余度架构提供了容错能力，单个通道失效不会直接导致灾难性后果，但会降低系统冗余度。
- 进一步分析：若一个通道失效，剩余两个通道仍可安全控制飞机，但若再有一个通道失效，则可能失去控制。因此，单通道失效条件被分类为“危险”级别。
- 根据AC 25.1309-1B，危险失效条件对应DAL B。但考虑到FCC是飞行关键系统，且软件失效可能同时影响多个通道（共因失效），当局通常要求FCC软件为DAL A。
实际操作步骤：最终，该FCC软件被确定为DAL A。理由如下：
- 软件共因失效（如需求理解错误、编译器错误）可能同时影响所有通道，无法通过余度架构缓解。
- DO-178C DAL A要求全部71个目标且全部独立验证，能最大程度降低软件设计错误风险。
- 系统安全性评估（SSA）确认：即使三余度架构降低了单通道失效影响，但软件共因失效仍可能造成灾难性后果，因此必须按DAL A开发。
结果与复盘：该案例表明，DAL确定需综合考虑架构缓解、共因失效、当局审查意见。不能简单按“单通道失效影响”来确定DAL，而需评估软件失效的所有可能传播路径。经验教训：在项目早期就应开展FHA/PSSA，与适航当局沟通DAL分配方案，避免后期返工。
常见误区：① 将DAL等级与软件复杂度直接挂钩（DAL只与失效影响相关，与代码行数无关）；② 认为采用多通道冗余就一定能降低DAL（需证明通道间独立性，包括软硬件隔离、物理隔离、共因失效分析）；③ 忽视工具鉴定对DAL的影响（开发工具和验证工具的鉴定等级与DAL相关）。
2.3 DO-178C与适航当局的关系
2.3.1 DO-178C的定位与认可机制
DO-178C由RTCA（美国航空无线电技术委员会）和EUROCAE联合制定，是机载软件开发的行业共识标准。适航当局（FAA、EASA、CAAC等）通过发布指导文件（如FAA Order 8110.49、EASA AMC 20-115C）正式认可DO-178C作为满足适航规章的符合性方法。但需注意：
- DO-178C是“可接受的方法”，不是唯一方法。申请人可提出替代方法，但需证明其达到等效安全水平。
- 当局保留对软件生命周期数据的审查权，包括计划、需求、设计、验证结果、构型管理记录等。
- DO-178C的“目标”（Objectives）是审查重点。当局通过检查目标是否满足来评估符合性。
2.3.2 适航当局在软件认证中的角色
适航当局在软件认证过程中扮演多重角色：
- 审定计划审批：审查PSAC（软件合格审定计划），确认软件等级、生命周期、标准符合性方法。
- 阶段审查（Stage of Involvement）：在软件计划阶段、需求阶段、设计阶段、验证阶段等关键节点进行审查。
- 问题报告处理：审查软件问题报告（SPR）和软件变更报告（SCR），确认问题分类和处理方式。
- 最终符合性判定：在型号合格审定中，确认软件符合DO-178C目标，签发批准。
当局通常采用“基于目标”的审查方式，即检查DO-178C中定义的目标是否被满足，而非逐行审查代码。这要求申请人提供清晰、完整、可追溯的生命周期数据。
2.3.3 与当局协作的实践要点
在DO-178C项目实践中，与适航当局的协作应遵循以下原则：
- 早期沟通：在PSAC编制阶段就与当局沟通软件等级、工具鉴定策略、符合性方法。
- 明确接口：确定当局审查的深度和频率，建立问题沟通渠道。
- 数据可读性：确保生命周期数据（需求、设计、测试用例、评审记录）以当局可理解的方式组织。
- 变更管理：软件变更需按DO-178C §11.2的流程进行，并通知当局。
- 工具鉴定：若使用工具（如自动代码生成器、静态分析工具），需按DO-330进行工具鉴定，并提交当局批准。
经验提醒：DO-178C与适航当局的关系可概括为“标准提供方法，当局判定符合性”。项目团队应避免两种极端：一是将DO-178C视为“文档生成器”，只重形式不重实质；二是忽视当局的个性化要求，认为满足DO-178C就万事大吉。最佳实践是：以DO-178C为基线，结合当局的具体指导材料（如FAA Order 8110.49的审查清单），建立项目定制的符合性矩阵。
2.4 常见误区与总结复盘
在适航与软件认证基础部分，以下误区值得特别关注：
- 误区一：混淆DAL与开发保证等级。DAL是系统安全性评估的结果，而DO-178C中的“软件等级”是DAL在软件领域的映射。两者概念不同，但常被混用。
- 误区二：忽视FHA/PSSA的输入质量。DAL确定依赖FHA/PSSA的准确性。若FHA遗漏了某些失效条件，或PSSA的架构假设不合理，DAL分配可能偏低，导致审定失败。
- 误区三：认为DAL E软件无需任何保证。虽然DAL E无DO-178C目标，但仍需进行基本的需求管理和配置管理，且需在PSAC中明确其开发保证方法。
- 误区四：工具鉴定与DAL脱节。工具鉴定等级（TQL）与软件DAL相关。例如，DAL A软件使用的自动代码生成器需达到TQL-1，而DAL C软件可能只需TQL-4。
总结复盘：本章核心在于建立“规章→失效条件→DAL→DO-178C目标”的完整链条。适航当局通过规章设定安全目标，DO-178C提供实现目标的工程方法，而DAL则是连接两者的桥梁。在实际项目中，建议团队在启动阶段就完成以下工作：① 梳理适用的适航规章和指导材料；② 开展初步FHA/PSSA，确定候选DAL；③ 与当局沟通DAL分配和符合性方法；④ 编制PSAC并明确生命周期数据要求。这些基础工作将直接影响后续软件开发的深度和成本。