2. 航空软件适航标准与闭环管理要求
航空软件之所以必须建立“需求—设计—实现—验证—证据”的闭环，根本原因在于适航审定并不直接审查软件“好不好用”，而是审查研制过程是否可计划、可追溯、可验证、可审查。围绕这一目标，DO-178C、ARP4754A、DO-330 等标准分别从机载软件生命周期、系统研制过程和工具鉴定三个层面提出要求，共同构成闭环管理的标准基础。
一、三个标准的分工与衔接
ARP4754A 面向飞机与系统研制，回答“系统需求从哪里来、如何分配到软硬件、如何验证系统满足需求”。它把安全性评估（如 ARP4761）产生的安全性目标转化为系统需求，再向下分配到软件和硬件。DO-178C 面向机载软件，回答“软件需求如何被实现并证明满足”。它接收 ARP4754A 分配下来的软件高层需求，向下展开为低层需求、源代码、目标码，并通过验证活动产生生命周期数据。DO-330 则面向“用于完成上述工作的工具”，回答“工具的输出能否被信任”，即工具鉴定问题。
三者的关系可以概括为：ARP4754A 定义系统级需求与分配，DO-178C 定义软件级实现与验证，DO-330 定义支撑工具的可信度。缺少任何一环，闭环都会出现断点——系统需求无法落到软件，或软件验证证据无法支撑系统符合性。
二、需求追溯：闭环的骨架
DO-178C 把需求追溯视为生命周期数据的核心。追溯不是“事后补一张矩阵”，而是从需求捕获开始就建立双向链接。典型做法是：每条软件高层需求（HLR）都有唯一标识，向下追溯到一条或多条低层需求（LLR），LLR 再追溯到源代码单元和测试用例；同时反向追溯，确保没有“无来源的需求”和“无需求的代码”。
以某飞控软件的高度保持功能为例，假设系统分配下来的软件高层需求为 HLR-ALT-021：“当自动驾驶接通且高度偏差超过 ±30 ft 时，俯仰指令应在 2 s 内产生修正。”这条需求向下展开为 LLR，例如偏差计算、增益调度、限幅逻辑、指令输出等。每条 LLR 对应代码函数与测试用例，测试用例又记录其覆盖的 HLR/LLR 编号。这样，当审定方抽查 HLR-ALT-021 时，可以沿追溯链看到需求、设计、代码、测试和结果证据。
追溯矩阵中常见的字段包括：需求编号、需求类型（HLR/LLR）、来源（系统需求编号）、下游对象（设计/代码/测试）、验证方法（评审/分析/测试）、验证状态、证据文件编号。字段不必多，但必须能回答“这条需求被什么证明、由谁证明、证据在哪”。
三、验证独立性：证据可信度的关键
DO-178C 对验证独立性有明确要求：验证活动应由不参与该软件项开发的人员完成。独立性不是形式上的“换个人签字”，而是要求验证者能够独立判断需求是否正确、测试是否充分、结果是否可信。对于 A 级软件，独立性要求覆盖需求评审、测试用例评审、测试执行和结果分析等环节。
实际执行中，独立性通常通过组织分工实现：开发人员完成 HLR/LLR 和代码，验证人员独立编写测试用例并执行。验证人员需要检查需求本身是否可测试、是否存在歧义、边界条件是否覆盖。例如 HLR-ALT-021 中“±30 ft”和“2 s”必须明确测量点、采样周期和容差，否则测试无法判定通过与否。
四、生命周期数据：闭环的物证
DO-178C 要求软件生命周期数据随软件等级变化。以 A 级为例，需要的数据包括：计划类（PSAC、SDP、SVP、SCMP、SQAP 等）、开发类（需求标准、设计标准、代码标准、HLR、LLR、源代码、目标码）、验证类（评审记录、测试用例、测试规程、测试结果、覆盖率分析、追溯矩阵）、配置管理类（基线记录、变更记录、问题报告）等。
这些数据不是孤立文档，而是相互引用、版本一致的证据链。例如测试结果必须引用测试用例版本，测试用例必须引用需求版本，需求版本必须与基线一致。配置管理的作用就是保证“需求—代码—测试—结果”在同一基线内可复现。
五、DO-330 工具鉴定：别让工具成为盲区
当工具的输出被用于替代、减少或自动化某个人工验证活动时，该工具需要按 DO-330 进行鉴定。工具鉴定等级（TQL）取决于工具输出对软件安全性的影响程度。例如，若测试执行工具自动判定“通过/失败”，而该判定直接作为符合性证据，则工具本身的可信度必须被证明；若工具仅用于辅助显示、最终判定仍由人工完成，则鉴定要求可降低。
工具鉴定的核心是回答两个问题：工具在什么条件下使用？工具出错时会不会导致错误证据被接受？因此，工具鉴定计划中应明确工具用途、输入输出、运行环境、鉴定等级、验证方法和限制条件。对于需求追溯工具，若其自动生成追溯矩阵并直接用于审定提交，则需证明其链接关系正确、无遗漏、无错误关联。
六、闭环管理的落地要点
把上述标准要求落到项目中，可以抓住四条主线：第一，需求必须有唯一标识和明确来源，HLR 与 LLR 之间双向可追；第二，验证活动必须独立于开发，测试用例应覆盖正常、边界和异常条件；第三，生命周期数据必须版本一致、基线可控，任何变更都要评估对需求和验证的影响；第四，工具若影响符合性证据，必须按 DO-330 确定鉴定等级并保留鉴定证据。
闭环不是一次性动作，而是贯穿整个研制周期的状态。每次需求变更、代码修改或测试更新，都应触发追溯链和证据链的同步更新。只有做到“需求有来源、实现有依据、验证有证据、变更可追溯”，软件才具备适航审定所要求的可信度。