2. 航空软件需求与SIL测试目标对齐
在航空软件研制中，SIL（Software-in-the-Loop）仿真测试并不是孤立的活动，它的有效性首先取决于“测什么”是否与“需求要求什么”严格对齐。若需求分解不完整、可测试性不足，或追溯关系断裂，SIL测试即使执行得再规范，也只能证明软件“跑起来了”，而无法证明软件“满足适航与系统要求”。本节围绕三个关键环节展开：需求分解、需求可测试性分析、SIL测试目标与需求追溯矩阵的建立。
一、从系统需求到软件高层需求与低层需求的分解
航空软件需求通常分为三层：系统需求（System Requirements）、软件高层需求（High-Level Requirements, HLR）和软件低层需求（Low-Level Requirements, LLR）。系统需求描述飞机/系统级功能与性能，例如“在自动驾驶接通且无线电高度低于 1500 ft 时，自动油门应限制最大推力”。软件高层需求将系统需求转化为软件功能行为，但不涉及具体实现结构；软件低层需求则进一步细化到算法、数据结构、接口时序、状态机转移和资源约束，可直接指导编码。
分解过程不是简单“抄写”，而是逐层回答“软件必须做什么、在什么条件下、达到什么指标、如何被观察”。以“自动油门推力限制”为例，系统需求可分解为：HLR-01 在自动驾驶接通且无线电高度低于 1500 ft 时，软件应输出最大推力限制标志；HLR-02 该标志应在高度条件满足后 100 ms 内生效；LLR-01 使用高度有效性标志与自动驾驶接通状态进行与逻辑判断；LLR-02 采用 20 ms 周期任务，连续 3 帧确认后置位；LLR-03 输出接口为 ARINC 429 标签 0x1A2 的第 5 位。这样，需求从“功能意图”逐步落到“可编码、可测试”的粒度。
分解时应遵循三条原则：第一，双向可追溯，每条 LLR 必须能上溯到唯一或明确的 HLR，每条 HLR 必须能上溯到系统需求；第二，不引入未授权功能，低层需求不得自行增加系统未要求的行为；第三，接口与 timing 必须显式化，避免“实时”“尽快”等不可验证表述。
二、需求可测试性分析
可测试性分析的目标，是判断每条需求是否具备“可观察、可激励、可判定、可追溯”四个属性。可观察性指软件输出或内部状态能够通过接口、日志或探针采集；可激励性指测试环境能够构造需求所描述的全部输入条件；可判定性指存在明确的期望值与容差；可追溯性指需求与测试用例之间存在唯一标识绑定。
实际分析中，常见不可测试需求包括：“软件应具有高可靠性”“在异常情况下应快速响应”“界面应友好”。这些表述缺少量化条件与判定边界。改进方式是把它们改写为可验证形式，例如“在电源中断后 200 ms 内，软件应进入安全状态，并将离散量输出 SAFE=1”。改写后，测试人员可以构造电源中断激励，采集离散量输出，并以 200 ms 为容差判定。
对于 SIL 测试，还需特别关注“仿真环境能否提供真实激励”。例如 ARINC 429 标签、AFDX 虚拟链路、离散量、模拟量、RS-422 串口等，都应在 SIL 环境中具备等效注入与采集能力。若某条需求依赖真实大气数据计算机的模拟输出，而 SIL 只能提供数字总线激励，则需在可测试性分析中标记“环境受限”，并补充替代验证方法或说明覆盖缺口。
三、SIL测试目标与需求追溯矩阵的建立方法
SIL 测试目标不是“把软件跑一遍”，而是针对每条需求或每组相关需求，定义明确的验证意图。测试目标应回答：验证哪条需求、在什么条件下、观察什么、判定标准是什么。例如针对 HLR-02，SIL 测试目标可写为：“在自动驾驶接通且 RA 从 1600 ft 下降至 1400 ft 的场景下，验证推力限制标志在条件满足后 100 ms 内由 0 变为 1。”
需求追溯矩阵（RTM）是连接需求与测试的桥梁。建立方法如下：第一步，为系统需求、HLR、LLR 分配唯一 ID，如 SR-AT-001、HLR-AT-01、LLR-AT-01；第二步，为每个 SIL 测试用例分配唯一 ID，如 TC-SIL-007；第三步，在矩阵中建立“需求→测试用例”和“测试用例→需求”的双向映射；第四步，标注覆盖状态（已覆盖、部分覆盖、未覆盖、不适用）与验证方法；第五步，随需求变更同步更新矩阵，确保追溯关系始终有效。
下表给出一个可参考的 RTM 片段，字段可根据项目裁剪，但需求ID、测试用例ID、覆盖状态和判定准则应保留。
| 系统需求ID | HLR ID | LLR ID | SIL测试用例ID | SIL测试目标 | 判定准则 | 覆盖状态 |
|---|---|---|---|---|---|---|
| SR-AT-001 | HLR-AT-01 | LLR-AT-01 | TC-SIL-007 | 验证AP接通且RA<1500 ft时推力限制标志置位 | 标志由0变1，且bit5=1 | 已覆盖 |
| SR-AT-001 | HLR-AT-02 | LLR-AT-02 | TC-SIL-008 | 验证条件满足后100 ms内标志生效 | 从条件满足到标志置位≤100 ms | 已覆盖 |
| SR-AT-002 | HLR-AT-03 | LLR-AT-04 | TC-SIL-009 | 验证RA无效时推力限制不激活 | 标志保持0，无虚假置位 | 部分覆盖（需补充RA抖动场景） |
建立 RTM 时，建议同时维护“需求覆盖率”和“测试目标覆盖率”两个指标。需求覆盖率 = 至少被一个测试用例覆盖的需求数 / 需求总数；测试目标覆盖率 = 已定义明确判定准则的测试目标数 / 测试目标总数。对于航空软件，还应关注 DO-178C 所要求的验证独立性：若测试用例由开发人员编写，则需由独立验证人员评审其与需求的追溯关系是否完整、判定准则是否充分。
综上，需求与 SIL 测试目标对齐的核心在于：分解时保持双向可追溯，分析时确保每条需求可观察、可激励、可判定，建立 RTM 时把测试目标、判定准则和覆盖状态显式记录。只有这样，SIL 仿真才能真正成为航空软件适航验证中可信、可查、可复现的一环。