📚 课程目录第2章验证交付的起点

2. 验证交付的起点

在航空嵌入式软件验证交付中，真正决定后续验证是否“可交付”的，并不是测试用例写得多漂亮，而是需求从系统层向软件层分配的那一刻是否清晰、完整、可追踪。系统需求描述的是飞机或系统级功能与性能，例如“在液压压力低于阈值时，于 200 ms 内点亮告警灯”；软件需求则必须回答“软件接收哪个信号、用什么周期采样、在哪个任务中判断、输出什么离散量、故障时如何降级”。如果这一步含糊，后续的代码、测试、覆盖分析和适航证据都会失去锚点。

系统需求到软件需求的分配：从“系统行为”落到“软件行为”

需求分配不是把系统需求复制到软件文档里，而是把系统级功能拆解为软件能够实现、能够验证的条目。以“液压低压告警”为例，系统需求可能只有一条：当液压压力低于 18 MPa 持续 100 ms 时，告警灯应在 200 ms 内点亮。分配到软件后，至少应形成以下可验证条目：软件通过 ARINC 429 标签接收液压压力字，更新周期 20 ms；软件对压力值进行有效性检查，无效时置故障标志；软件在连续 5 个周期内检测压力小于 18 MPa 后置告警请求；软件通过离散量输出驱动告警灯，输出刷新周期 10 ms；软件在检测到自身计算故障时进入安全状态，告警灯保持点亮。

这里的关键是“可验证性”。每条软件需求都应包含明确的输入、处理条件、输出和时序约束。例如“软件应处理液压压力”不可验证；“软件应在收到有效压力字后 40 ms 内完成阈值比较并更新告警请求”才可验证。分配过程中还要识别派生需求：系统需求没有直接写，但软件实现必须补充的内容，如数据有效性范围、初始化状态、故障注入接口、周期任务调度预算等。派生需求必须回标到系统需求，否则会在追溯链上形成断点。

分配时建议使用“系统需求 ID → 软件需求 ID → 验证方法”的三元组。验证方法至少标注为：测试、分析、检查、演示。航空嵌入式软件中，时序和故障降级类需求通常必须用测试或分析覆盖，不能只靠检查。

需求可追溯性建立：双向链路与覆盖判断

可追溯性不是一张装饰性的矩阵，而是验证交付的“证据骨架”。它至少包含三条链路：系统需求到软件需求的正向分配、软件需求到系统需求的反向回标、软件需求到测试用例的验证覆盖。实际项目中，推荐用需求管理工具或受控表格维护唯一 ID，例如 SYS-HYD-001、SW-HYD-001、TC-HYD-001。每条软件需求必须能回答三个问题：我从哪条系统需求来？我由哪些测试用例验证？我是否被完整覆盖？

覆盖判断不能只看“有没有用例”，而要看用例是否覆盖了需求的全部判定条件。以“连续 5 个周期低于 18 MPa”为例，测试至少应包含：4 个周期低于阈值后恢复，不应告警；5 个周期连续低于阈值，应告警；压力在阈值附近抖动，不应误告警；压力字无效，应进入故障处理。若只写一条“低压告警测试”，追溯矩阵虽然显示“已覆盖”，但实际验证是不完整的。因此，追溯矩阵中应增加“覆盖条件”或“判定覆盖说明”列，记录每个用例覆盖了需求的哪些条件分支。

需求评审检查单：把“评审”变成可执行的判定

需求评审最容易流于形式：大家看一遍，说“没问题”，然后签字。要让它真正拦住缺陷，必须把检查项写成可判定的问题。以下检查单可直接用于软件需求评审，重点覆盖分配完整性、可验证性、追溯性和安全性。

检查项	判定标准	常见缺陷示例
分配完整性	每条系统需求至少分配到一条软件需求，无遗漏、无多余	系统需求要求故障降级，软件需求未提降级行为
可验证性	每条软件需求有明确输入、条件、输出和时序，可用测试或分析验证	“软件应快速响应”无法判定
追溯性	软件需求有唯一 ID，且能正向、反向追溯到系统需求	派生需求未回标，追溯链断裂
接口一致性	信号名、单位、范围、刷新周期与 ICD 一致	压力单位 MPa 与 ICD 中 psi 混用
故障与安全	无效数据、超时、计算故障均有明确处理路径	只写正常路径，未定义故障时输出状态
时序预算	采样、判断、输出周期满足系统级响应时间	20 ms 采样 + 5 周期判断 = 100 ms，加输出 10 ms，仍小于 200 ms

实战任务：完成一条需求分配与追溯闭环

下面给出一个可直接执行的课堂任务。任务对象为“液压低压告警”软件需求分配，要求完成从系统需求到软件需求、再到测试用例的追溯闭环，并填写评审检查单。

任务输入：系统需求 SYS-HYD-001：当液压压力低于 18 MPa 持续 100 ms 时，告警灯应在 200 ms 内点亮；压力字通过 ARINC 429 接收，更新周期 20 ms；告警灯由离散量输出驱动，刷新周期 10 ms。

任务步骤：

将 SYS-HYD-001 拆解为至少 5 条软件需求，覆盖采样、有效性检查、阈值判断、输出驱动和故障降级。
为每条软件需求分配唯一 ID，并填写其来源系统需求 ID。
为每条软件需求设计至少 1 个测试用例，标注覆盖条件和验证方法。
用评审检查单逐项检查，记录发现的问题并修正。

参考输出示例：

SW-HYD-001：软件应以 20 ms 周期接收 ARINC 429 液压压力字，并校验标签与 SSM 有效性。
  来源：SYS-HYD-001
  验证：TC-HYD-001 注入有效/无效压力字，检查更新周期与有效性标志。

SW-HYD-002：软件应在压力字有效时，将压力值转换为 MPa 并与 18 MPa 比较。
  来源：SYS-HYD-001
  验证：TC-HYD-002 注入 17.9 MPa、18.0 MPa、18.1 MPa，检查比较结果。

SW-HYD-003：软件应在连续 5 个 20 ms 周期检测到压力低于 18 MPa 后，置告警请求。
  来源：SYS-HYD-001
  验证：TC-HYD-003 注入 4 周期低压后恢复，不应告警；注入 5 周期低压，应告警。

SW-HYD-004：软件应以 10 ms 周期刷新离散量输出，驱动告警灯。
  来源：SYS-HYD-001
  验证：TC-HYD-004 测量告警请求到输出翻转的时间，应不大于 200 ms。

SW-HYD-005：当压力字无效或软件计算故障时，软件应保持告警灯点亮并置故障标志。
  来源：SYS-HYD-001
  验证：TC-HYD-005 注入无效字与故障，检查输出状态与故障标志。

完成上述任务后，用追溯矩阵检查：SYS-HYD-001 是否被 SW-HYD-001 至 005 完整覆盖；每条软件需求是否都有测试用例；测试用例是否覆盖了正常、边界、故障三类条件。若发现某条软件需求没有对应测试，或某个测试没有回标到需求，就说明追溯链存在断点，必须回到需求分配阶段修正。只有这条链路闭合，后续的代码实现、单元测试、集成测试和适航证据才具备可交付的基础。