适航认证基础：适航的定义、适航标准体系与认证流程
适航认证是飞控软件进入民用航空市场的“准生证”。对于从事飞控软件开发的工程师而言，理解适航的底层逻辑、标准体系的层级关系以及认证过程中各相关方的职责边界，是确保项目从启动之初就走在合规轨道上的前提。本章将围绕“什么是适航”“依据什么标准”“如何开展认证”“谁在过程中扮演什么角色”四个核心问题展开，建立飞控软件适航认证的整体认知框架。
2.1 适航的定义与本质
2.1.1 核心原理：适航是一种可证明的安全性状态
适航（Airworthiness）并非一个抽象的法律术语，而是指航空器（包括其系统、部件和软件）在预期运行环境和使用限制内，能够安全地完成起飞、飞行、着陆全过程的整体属性。适航包含两个层面：初始适航（设计、制造与交付阶段）和持续适航（运营、维护与改装阶段）。对于飞控软件而言，适航意味着软件在目标硬件上运行时，其行为满足系统安全性需求，且这种满足是通过可追溯、可验证、可重复的过程证据来支撑的。
适航的本质是“基于风险的过程保证”，而非单纯的“测试通过”。它要求申请人证明：软件需求正确、实现与需求一致、验证活动充分、异常行为可控。这种证明必须形成完整的“符合性证据链”，从系统级安全性需求（如FHA、SSA）逐层分解到软件级需求，再通过编码、测试、评审等活动闭环。
2.1.2 判断方法：如何界定“适航”是否达成
判断一个飞控软件是否“适航”，可以从以下四个维度进行核查：
- 需求追溯性：每条软件需求是否都能追溯到系统级安全性需求或功能需求？是否存在无来源的“孤儿需求”？
- 设计一致性：软件架构、详细设计是否与需求描述一致？是否存在设计实现与需求偏离且未经过评审的情况？
- 验证充分性：是否按照DO-178C规定的验证等级（A/B/C/D）完成了对应的测试、评审和分析？语句覆盖、分支覆盖、MC/DC覆盖是否达标？
- 配置管理完整性：源代码、目标码、文档、测试用例、工具链版本是否受控？能否从交付物回溯到开发环境？
如果上述四个维度均能给出肯定回答，且相关证据已通过局方或DER的审查，则可以认为该软件达到了适航状态。
2.1.3 小型场景化说明
假设某飞控软件在俯仰控制律中引入了一个新的滤波算法。适航视角下，工程师不能仅凭“仿真测试通过”就认为满足适航要求。需要完成的工作包括：更新系统安全性评估（确认新算法不会引入新的失效模式）、编写软件需求（描述算法输入输出、边界行为）、进行编码实现（遵循编码标准）、执行单元测试与集成测试（覆盖正常与异常路径）、更新适航符合性说明。这一系列活动的目的，是让局方能够“看到”软件是安全的，而不是“相信”它是安全的。
2.2 适航标准体系：FAR/CS-25与DO-178C的层级关系
2.2.1 核心原理：从顶层规章到技术指南的分解
适航标准体系呈现金字塔结构。顶层是各国或地区的适航规章，如美国联邦航空条例第25部（FAR 25）和欧洲航空安全局的审定规范（CS-25），它们规定了运输类飞机的适航要求，属于法律效力层面的文件。第二层是可接受的符合性方法（AMC）或咨询通告（AC），如AMC 25.1309，提供了如何满足规章要求的指导。第三层是技术标准与工业指南，如DO-178C《机载系统和设备合格审定中的软件考虑》，它并非法律，但被局方接受为一种可接受的符合性方法。
对于飞控软件，DO-178C是核心标准。它定义了软件生命周期过程、目标（Objectives）、证据（Evidence）和软件等级（A/B/C/D）。FAR/CS-25中的25.1309条款（设备、系统及安装）是软件适航的顶层需求，要求系统在发生失效时满足安全性目标（如灾难性失效概率小于10⁻⁹/飞行小时）。DO-178C则提供了如何通过软件工程过程来支持这一目标。
| 层级 | 文件示例 | 性质 | 对飞控软件的影响 |
|---|---|---|---|
| 规章 | FAR 25 / CS-25 | 法律强制 | 规定飞机级安全性目标，如25.1309 |
| 符合性方法 | AMC 25.1309 / AC 25.1309-1A | 可接受方法 | 解释如何证明系统安全性 |
| 工业标准 | DO-178C / DO-331（模型开发） | 技术指南 | 定义软件生命周期与目标 |
| 公司流程 | 企业开发流程手册 | 内部规范 | 将标准落地为具体操作 |
2.2.2 判断方法：如何选择适用的标准与等级
飞控软件通常属于A级（灾难性失效影响）或B级（危险级失效影响）。确定软件等级的依据是系统安全性评估（SSA）中定义的失效条件等级。工程师需要检查系统需求文档中的“失效条件分类表”，确认软件所承担的功能失效后对飞机的影响。例如，主飞行控制计算机的软件通常为A级，而座舱照明控制软件可能为D级。
选择标准时，需确认项目适用的适航规章（如中国民航局CCAR-25部与FAR 25基本一致），并明确局方是否接受DO-178C作为符合性方法。若使用模型化开发，还需考虑DO-331补充标准。
2.2.3 案例拆解：某飞控系统软件等级确定过程
某支线客机飞控系统包含主飞行控制计算机（PFCC）和自动飞行控制计算机（AFCC）。在系统安全性评估中，PFCC的功能失效被判定为“灾难性”，AFCC的失效被判定为“危险级”。因此，PFCC软件等级为A级，AFCC软件等级为B级。项目组据此制定了不同的验证策略：A级软件要求进行MC/DC覆盖分析，而B级软件仅要求语句覆盖和分支覆盖。这一决策直接影响了测试用例数量和开发成本。
复盘经验：软件等级的确定应在项目启动初期完成，并形成正式的安全性评估报告。若后期系统设计变更导致失效条件等级变化，需重新评估软件等级并调整验证活动，否则可能导致适航审查不通过。
2.3 适航认证流程与相关方角色
2.3.1 核心原理：认证是“申请人举证、局方验证”的过程
适航认证不是局方“检验”产品，而是申请人通过提交符合性证据，证明产品满足适航要求，局方负责审查证据并做出最终批准。这一过程的核心是信任与验证的平衡。申请人需要建立完整的设计保证体系（DAS），确保所有活动符合标准；局方则通过审查、测试目击、现场检查等方式验证申请人的声明。
飞控软件的认证流程通常嵌入在飞机型号合格审定（TC）或补充型号合格审定（STC）项目中。主要阶段包括：申请受理、审定基础确定、符合性计划制定、符合性数据提交、问题纪要（PI）处理、最终颁证。软件适航审查（SOI#1~#4）是其中的关键节点。
2.3.2 操作流程：软件适航审查的四个阶段
- SOI#1（计划评审）：审查软件计划（PSAC）、开发计划、验证计划、配置管理计划、质量保证计划。确认计划符合DO-178C要求。
- SOI#2（开发评审）：审查软件需求、设计、编码活动是否符合计划。检查需求追溯性、编码标准执行情况。
- SOI#3（验证评审）：审查测试用例、测试结果、覆盖分析。确认验证活动充分，覆盖率达到等级要求。
- SOI#4（最终评审）：审查软件构型索引、适航符合性声明。确认所有问题已关闭，软件可用于装机。
2.3.3 相关方角色与职责
| 角色 | 核心职责 | 典型活动 | 常见误区 |
|---|---|---|---|
| 申请人 | 建立设计保证体系，提交符合性证据 | 编写PSAC、执行开发与验证、提交SOI评审 | 将DER视为“保证人”，而非“审查者” |
| 局方（FAA/EASA/CAAC） | 制定审定基础，审查证据，颁发型号合格证 | 开展SOI评审、试飞目击、签发问题纪要 | 过度依赖DER，放弃独立判断 |
| DER（委任工程代表） | 代表局方进行技术审查，签署符合性声明 | 审查软件数据、批准符合性报告 | DER签字前未充分审查，导致后续返工 |
2.3.4 实战场景：SOI#2审查中的问题纪要处理
某项目在SOI#2审查中，局方代表发现软件详细设计文档中有一处需求追溯性断裂：某条低层需求无法追溯到高层需求。申请人立即组织分析，发现是需求管理工具中链接丢失。项目组在3个工作日内完成了追溯性修复，并提交了更新后的追溯矩阵。局方确认问题关闭，但要求申请人在后续项目中增加需求追溯性的自动化检查工具，防止类似问题复发。
复盘经验：问题纪要（PI）的处理应遵循“分析根因、纠正措施、预防措施、验证有效性”四步法。仅修复当前问题而不采取预防措施，会被视为系统性缺陷，影响后续审查信任度。
2.4 常见误区与总结复盘
2.4.1 常见误区清单
- 误区一：认为适航认证只是“走流程”，忽视过程证据的积累。实际上，局方审查的是“过程+结果”的双重符合性。
- 误区二：将DO-178C的文档模板当作“填空”，导致文档内容与实际开发活动脱节。
- 误区三：软件等级确定后不随系统设计变更而更新。系统安全性评估是动态过程，软件等级可能随之调整。
- 误区四：忽视DER的独立审查角色。DER虽然由申请人推荐，但其职责是代表局方，而非申请人的“顾问”。
2.4.2 总结复盘
适航认证的基础在于对“适航”本质的深刻理解——它是一种基于风险的过程保证。标准体系提供了从规章到技术指南的完整框架，而认证流程则是将这一框架落地的具体路径。飞控软件工程师需要建立“证据思维”：每一项开发活动都应考虑“如果局方来审查，我能否提供完整的证据链？”这种思维方式的转变，比掌握具体工具更重要。
在实际项目中，建议从启动阶段就引入适航审查视角，定期进行内部“预审查”，模拟局方提问。同时，保持与DER的早期沟通，在计划阶段就确认符合性方法，避免后期重大返工。适航认证不是项目的终点，而是产品安全性的证明——只有将适航要求内化为开发习惯，才能真正实现“一次做对”。