适航认证基础：从适航定义到DO-178C的规章关联
适航认证是航空产品进入市场前必须跨越的法律与技术门槛。对于从事机载软件开发的工程师而言，理解“适航”的本质、审定体系的运作方式，以及DO-178C与适航规章（FAR/CS-25）之间的映射关系，是确保软件研制路径正确的前提。本章将从适航的定义出发，梳理审定体系的层级结构，并重点剖析软件在型号合格审定中的角色，以及DO-178C如何作为可接受的手段满足规章要求。
2.1 适航的定义与本质
适航（Airworthiness） 的经典定义是：航空器（包括其部件和系统）在预期的运行环境和使用限制内，始终处于安全可运行的状态。这一定义包含三个核心要素：安全水平（可接受的风险）、运行限制（飞行包线、环境条件）和持续保持（维护与适航性管理）。适航不是一次性的静态结果，而是贯穿设计、制造、运营、维修全寿命周期的动态属性。
从法律角度看，适航是国家对民用航空产品安全性的最低强制要求。任何民用航空器要投入运营，必须获得适航当局颁发的相应证件。适航的本质是风险控制——将航空产品可能对乘员、地面人员和公众造成的风险降低到可接受的水平。这个“可接受水平”并非零风险，而是基于当前技术水平和经济可行性的平衡。
2.2 适航审定体系的结构与运作
适航审定体系是局方（FAA、EASA或中国民航局CAAC）依据法规对航空产品进行审查、批准和持续监督的完整制度框架。该体系分为三个层级：法规层（适航规章）、管理层（审定程序与政策）和执行层（型号合格审定、生产审定、适航审定）。
对于机载软件而言，最核心的审定活动是型号合格审定（Type Certification）。在型号合格证（TC）或补充型号合格证（STC）的取证过程中，局方会依据审定基础（Applicable Airworthiness Requirements）对飞机及其系统进行审查。软件作为机载系统的重要组成部分，其适航性通过系统级的安全性分析（如FHA、SSA）和软件自身的研制保证活动来共同证明。
| 审定层级 | 主要文件/证件 | 对软件的影响 |
|---|---|---|
| 法规层 | FAR/CS-25（运输类飞机适航标准） | §25.1309（设备、系统及安装）、§25.1701（审定要求）等条款提出安全性目标 |
| 管理层 | AC 20-115D / AMC 20-115D（局方咨询通告） | 明确DO-178C作为软件合格审定的可接受符合性方法 |
| 执行层 | TC/STC/AC（型号合格证/补充型号合格证/适航证） | 软件研制保证等级（DAL）的确定与局方审查 |
2.3 适航认证与软件的关系
软件在航空产品中的角色已经从辅助功能演变为关键安全功能的核心载体。电传飞控、自动油门、导航计算、发动机控制等关键功能均依赖软件实现。然而，软件与硬件不同，它不会磨损、不会老化，其失效模式是系统性失效（Systematic Failure）——即设计缺陷或实现错误，而非随机物理故障。
这一本质差异决定了适航认证对软件的要求与硬件截然不同。硬件适航关注故障概率（随机失效），而软件适航关注研制过程的正确性与完整性。因此，适航规章并未直接规定软件的具体实现方法，而是通过系统级的安全性目标（如§25.1309）间接提出要求。局方通过发布咨询通告（AC/AMC），将DO-178C作为满足这些安全性目标的可接受符合性方法。
2.4 DO-178C与FAR/CS-25的关联机制
DO-178C（机载系统与设备合格审定中的软件考虑）由RTCA（美国航空无线电技术委员会）制定，其欧洲对应文件为EUROCAE ED-12C。该标准的核心思想是：软件的安全性水平取决于其所在系统的失效条件等级，而软件研制保证等级（Software Level，A/B/C/D/E）与系统失效条件（灾难性/危险/重大/轻微/无安全影响）一一对应。
DO-178C与FAR/CS-25的关联通过以下链条实现：
- 系统级安全性评估（SSA）：依据ARP4754A/ARP4761，确定每个系统功能的失效条件等级；
- 软件等级分配：根据失效条件等级，确定软件等级（A级对应灾难性，B级对应危险，C级对应重大，D级对应轻微，E级对应无安全影响）；
- DO-178C目标满足：按照软件等级，满足DO-178C中规定的相应目标（Objectives）；
- 局方审查：通过软件适航审查（SOI #1-#4），证明符合性。
2.5 案例拆解：某飞控计算机软件适航取证
背景与约束：某航空电子供应商为某型运输类飞机开发主飞行控制计算机（PFCC）软件。该软件控制飞机的俯仰、滚转和偏航通道，属于关键安全功能。审定基础为FAR/CS-25.1309，系统安全性评估确定其失效条件为“灾难性”，因此软件等级为A级。
初始目标：通过FAA和EASA的联合审查，获得软件适航批准（SOI #4通过），并随飞机取得型号合格证。
关键输入数据：
- 系统需求：约1200条，其中软件高等级需求（HLR）约450条；
- 软件架构：3个冗余通道，每个通道包含监控与命令路径；
- 开发环境：基于模型设计（MATLAB/Simulink），自动代码生成；
- 验证资源：目标机测试环境（HIL）+ 桌面仿真环境。
分析判断过程：项目组首先依据DO-178C的A级目标清单（共71个目标）进行差距分析，发现以下关键难点：
- 基于模型设计的工具鉴定（Tool Qualification）需求；
- 结构覆盖率分析需达到修正条件/判定覆盖率（MC/DC）100%；
- 多版本异构冗余软件的差异分析（Dissimilarity）。
实际操作步骤：
- 制定软件合格审定计划（PSAC），明确开发、验证、配置管理和质量保证过程；
- 对自动代码生成工具进行工具鉴定，达到TQL-1等级；
- 建立需求追溯矩阵，确保每条HLR和LLR均可追溯至系统需求；
- 执行基于需求的测试（RBT），并补充鲁棒性测试（异常输入、边界值）；
- 使用结构覆盖率分析工具，迭代补充测试用例直至MC/DC 100%覆盖；
- 提交软件完结综述（SAS）和软件配置索引（SCI），配合局方完成SOI #1-#4审查。
结果对比：项目最终通过审查，软件A级适航批准获得。相比未采用DO-178C流程的同类项目，缺陷密度降低了约60%，但开发成本增加了约40%（主要来自验证和文档工作）。
风险与代价：最大的风险是MC/DC覆盖率不达标导致审查延期。项目组在第一次覆盖率分析时发现仅有92%的MC/DC覆盖，额外增加了2个月的测试时间。复盘经验：应在编码阶段就同步设计测试用例，而非在代码完成后才补测试。
2.6 总结与复盘
适航认证基础的核心逻辑可以概括为：规章提出“什么安全水平”，系统评估确定“哪里需要多安全”，DO-178C规定“如何证明达到了该安全水平”。软件工程师需要跳出“写代码”的思维定式，从系统安全性、规章符合性和过程保证的角度理解自己的工作。
在实际项目中，建议团队在项目启动初期就完成以下工作：
- 明确软件等级（DAL）及其对应的DO-178C目标；
- 建立与局方的沟通渠道，尽早确认审定基础；
- 制定切实可行的PSAC，并严格按计划执行；
- 将验证活动前置，避免“编码-测试-补测”的恶性循环。
适航认证不是束缚，而是保障航空安全的系统工程方法论。理解其本质，才能在实践中既满足合规要求，又高效地交付安全可靠的机载软件。