适航基础与法规体系：适航的概念、FAA/EASA/CAAC的适航要求，以及DO-178C与DO-178B、DO-178A的差异和演进

适航的基本概念与核心原理

适航（Airworthiness）在航空领域具有严格的法律定义：一架航空器或航空产品处于符合其经批准的类型设计状态，并且处于安全可运行的状态。这个定义包含两个关键维度——设计适航与持续适航。设计适航关注产品在型号合格审定阶段是否满足适用的适航标准；持续适航则关注产品投入运营后，通过维修、检查、改装等手段维持其符合性。对于机载软件而言，适航意味着软件在目标硬件环境上运行时，其行为必须符合预期的安全等级要求，且这种符合性需要被系统性地论证和记录。

适航管理的底层逻辑是“基于风险的监管”。监管机构并不直接审查每一行代码，而是通过审查开发过程和最终产物来建立置信度。软件失效可能导致的后果越严重，所需的置信度就越高。这种置信度通过软件等级（Software Level）来量化——A级软件失效会导致灾难性后果，E级软件失效无安全影响。DO-178C将软件等级与失效条件类别直接挂钩，并据此规定了不同等级下必须满足的目标数量与独立性要求。

FAA、EASA、CAAC的适航要求对比

全球三大适航监管体系——美国联邦航空管理局（FAA）、欧洲航空安全局（EASA）和中国民用航空局（CAAC）——在适航管理上既有高度相似性，又存在具体差异。理解这些差异对于面向全球市场的航空产品开发至关重要。

从实际操作角度看，三大体系对DO-178C的接受程度是一致的，但在审查深度、文档格式、工具鉴定认可、以及COTS软件的处理方式上存在细微差别。例如，FAA更倾向于接受基于风险的“目标符合性”论证，而EASA在部分项目中会要求更详细的“过程符合性”证据。CAAC近年来在C919等项目中积累了丰富的审查经验，其审查风格正在向FAA/EASA靠拢，但仍保留了对国产化率和自主可控的特殊要求。

DO-178C与DO-178B、DO-178A的差异与演进

DO-178标准家族经历了从DO-178A（1985年）到DO-178B（1992年）再到DO-178C（2011年）的演进。每一次版本更新都反映了软件工程实践和适航审管理念的重大变革。

从DO-178A到DO-178B：从“过程导向”到“目标导向”

DO-178A采用“软件生命周期”模型，将软件划分为6个等级，并规定了每个等级必须执行的生命周期活动。这种“过程导向”的方法虽然易于理解，但过于僵化——它假设所有项目都遵循相同的瀑布式开发流程，无法适应快速迭代和新技术应用。DO-178B引入了革命性的“目标导向”理念：不再规定“你必须做什么”，而是规定“你必须达成什么目标”。DO-178B定义了66个目标，每个目标关联到特定的生命周期活动、产物和验证方法。开发者可以自由选择开发流程，只要能够证明所有适用目标已被满足。

从DO-178B到DO-178C：应对新技术与澄清歧义

DO-178C在DO-178B的基础上进行了系统性修订，主要变化体现在以下五个方面：

1. 目标数量与结构优化：DO-178C将目标从66个调整为71个，并重新组织了目标的层级结构。每个目标都明确关联到“软件生命周期过程”、“计划”、“标准”和“评审/验证”活动，使符合性论证更加清晰。
2. 补充标准（Supplements）：DO-178C首次引入了技术补充标准——DO-331（基于模型的开发和验证）、DO-332（面向对象技术及相关技术）、DO-333（形式方法）。这些补充标准不是独立的标准，而是与DO-178C配合使用，为特定技术提供额外的目标和活动指导。
3. 工具鉴定（Tool Qualification）：DO-178C将工具鉴定等级（TQL）从DO-178B的5级简化为3级（TQL-1至TQL-3），并明确了工具鉴定与软件等级之间的映射关系。TQL-1适用于可能消除或减少验证活动的工具，TQL-3适用于仅影响开发活动的工具。
4. 商用现货（COTS）软件：DO-178C增加了对COTS软件（如实时操作系统、通信协议栈）的专门指导，明确了COTS软件的使用者需要承担的符合性责任，包括服务历史（Service History）数据的利用条件。
5. 参数数据项（Parameter Data Item）：DO-178C引入了“参数数据项”的概念，允许将某些配置参数从源代码中分离出来，作为独立的数据项进行管理和验证。这为飞机级参数调整提供了灵活性。

DO-178C的核心改进：更清晰的“目标符合性”论证

DO-178C最深刻的变革在于它重新定义了“符合性”的含义。在DO-178B时代，开发者经常陷入“为了满足目标而机械地生成文档”的陷阱。DO-178C则强调每个目标都必须有明确的“符合性证据”——即通过评审、分析、测试或组合方式证明目标已被满足。这种证据链必须从软件计划（PSAC）开始，贯穿软件开发全生命周期，最终形成完整的软件符合性总结（SAS）。

案例拆解：某飞控系统从DO-178B到DO-178C的迁移实践

某航空电子供应商的飞控计算机项目原按DO-178B开发，已获得FAA型号合格证。现因增加新功能并计划进入欧洲市场，需要将软件升级至DO-178C并满足EASA要求。该项目面临以下约束：

• 原有软件规模约50万行C代码，软件等级为A级（灾难性失效条件）
• 开发团队分布在三个国家，使用基于模型的设计工具（Simulink/Stateflow）
• 项目周期仅18个月，预算有限
• 必须保留原有已认证的软件架构和大部分代码

初始现象与目标：团队最初认为DO-178C迁移只是文档更新，但EASA审查组在预审（SOI#1）中指出了多项不符合项，包括：缺少DO-331补充标准的应用、工具鉴定数据不完整、COTS操作系统（VxWorks 653）的服务历史数据未按DO-178C要求整理。

分析判断过程：团队进行了差距分析（Gap Analysis），将DO-178C的71个目标与现有DO-178B的66个目标逐一对比，识别出新增或强化的目标主要集中在：

1. 基于模型开发的验证目标（DO-331）——原有模型覆盖率分析不满足新要求
2. 工具鉴定目标——原有工具鉴定等级为TQL-4，新标准要求TQL-2
3. COTS软件的服务历史数据——需要补充至少2年的运营数据

实际操作步骤：

1. 制定DO-178C迁移计划（PSAC修订版），明确新增目标和活动
2. 对Simulink模型开发流程进行DO-331符合性改造：
   - 增加模型覆盖率分析（MC/DC覆盖）
   - 建立模型到需求的追溯矩阵
   - 生成模型评审检查单
3. 重新进行工具鉴定：
   - 将Simulink代码生成器从TQL-4提升至TQL-2
   - 补充工具操作需求（TOR）和工具验证用例
4. 整理VxWorks 653服务历史数据：
   - 收集过去3年的现场运营报告
   - 分析所有已知缺陷及修复措施
   - 形成服务历史评估报告
5. 执行增量验证：
   - 对新增功能执行完整验证
   - 对原有功能执行回归测试（重点覆盖受模型变更影响的部分）
6. 提交SOI#2审查，根据审查意见整改

结果对比：经过14个月的努力，项目成功通过EASA的SOI#2审查，获得补充型号合格证（STC）。相比初始计划，额外增加了约3个月的工作量，但避免了因不符合项导致的型号审定延误。关键经验是：DO-178C迁移必须从项目启动时就纳入计划，而不是作为“附加工作”处理。

风险与代价：迁移过程中最大的风险是工具鉴定升级——Simulink代码生成器的TQL-2鉴定需要额外的工具验证用例，这消耗了约2人月的工作量。另一个代价是模型覆盖率分析工具（Simulink Coverage）的引入，增加了软件工具链的复杂度。

复盘经验：DO-178C不是简单的标准升级，而是对软件工程实践的全面审视。团队需要建立“目标-证据-评审”的闭环思维，将符合性工作融入日常开发流程，而非事后补充文档。

常见误区与总结复盘

在DO-178C实施过程中，团队常陷入以下误区：

• 误区一：将DO-178C视为文档生成标准。DO-178C的核心是“目标符合性”，文档只是证据的载体。如果文档不能清晰展示目标如何被满足，再多的文档也无济于事。
• 误区二：忽视补充标准的适用性。如果项目使用了基于模型的设计、面向对象技术或形式方法，就必须应用相应的补充标准。许多团队在项目中期才发现需要补充DO-331或DO-332的工作，导致返工。
• 误区三：低估工具鉴定的工作量。工具鉴定不是简单的“填写表格”，而是需要提供工具操作需求、工具验证用例和工具验证结果。特别是TQL-1和TQL-2的工具鉴定，工作量可能超过预期。
• 误区四：COTS软件“免责”心态。使用COTS软件并不意味着可以免除适航责任。DO-178C要求COTS软件的使用者评估其服务历史、验证充分性和潜在风险，并承担相应的符合性论证责任。