2. 需求捕获与验证需求分解
在航电硬件研制中，系统需求（如“LRU 在电源中断后 200 ms 内完成上电自检并输出有效状态字”）通常以功能、性能、接口和适航条款的形式存在，而硬件验证需求必须回答“用什么激励、在哪个测试点、观测什么量、判据是什么”。两者之间不是简单抄写，而是一次结构化的映射：把系统级的功能/性能指标拆解为可施加、可测量、可判定的硬件级条件。本节围绕映射方法、可验证性检查、追溯矩阵构建，并以一个典型航电 LRU 为例完成需求分解实战。
一、映射方法：从系统需求到硬件验证需求
映射的核心是识别系统需求中的“可观测行为”与“硬件实现要素”之间的对应关系。常用四步法：
- 提取系统需求中的功能、性能、接口、环境与安全性约束，标注每条需求的来源（如 DO-160G 温度试验、DO-254 设计保证等级）。
- 识别硬件实现要素：电源模块、处理器、FPGA/ASIC、总线收发器、离散量接口、传感器调理电路等。
- 建立“系统需求—硬件要素—验证方法”三元映射，明确每条系统需求由哪些硬件要素承载、通过何种试验或分析验证。
- 派生硬件验证需求，每条需求必须包含：激励条件、测试点、观测参数、判据、验证方法（试验/分析/检查/演示）。
例如系统需求“LRU 在 28 V 输入跌落至 18 V 时仍能维持 50 ms 正常工作”，可映射为硬件验证需求：“在 LRU 电源输入端施加 28 V→18 V 阶跃跌落，用示波器在电源模块输出电容两端测量 5 V 轨，要求跌落期间 5 V 轨不低于 4.75 V 且持续时间≥50 ms”。这里激励、测试点、观测参数、判据全部可执行。
二、需求可验证性检查
可验证性检查是防止“无法验证的需求”流入下游的关键闸门。检查项包括：
- 可测量性：是否存在物理测试点或可观测信号？若只能通过软件日志间接推断，需评估是否满足硬件验证的独立性要求。
- 判据明确性：是否给出量化门限、容差、时间窗口？避免“正常工作”“足够快”等模糊表述。
- 激励可实现性：试验设备能否产生所需激励（电压、频率、温度、振动量级）？
- 边界与异常覆盖：是否覆盖上下限、故障注入、瞬态条件？
- 追溯性：每条硬件验证需求能否回溯到至少一条系统需求或适航条款？
三、需求追溯矩阵构建
追溯矩阵（RTM）是需求分解的“账本”，通常以表格形式维护。列包括：系统需求 ID、系统需求描述、硬件验证需求 ID、验证需求描述、验证方法、测试用例 ID、测试结果、覆盖状态。行按系统需求展开，确保每条系统需求至少有一条硬件验证需求覆盖，且每条硬件验证需求都能向上追溯。
构建时注意：
- 一条系统需求可派生多条硬件验证需求（如正常、边界、故障三种工况）。
- 一条硬件验证需求也可覆盖多条系统需求（如电源纹波测试同时覆盖电压范围和电磁兼容要求）。
- 矩阵应随设计迭代更新，变更时同步检查覆盖缺口。
四、典型航电 LRU 需求分解实战
以某航电 LRU（含 28 V 电源模块、FPGA 接口控制、ARINC 429 收发器、离散量输入输出）为例，选取三条系统需求进行分解。
| 系统需求 ID | 系统需求描述 | 硬件验证需求 ID | 验证需求描述（激励/测试点/判据） | 验证方法 |
|---|---|---|---|---|
| SYS-001 | LRU 在 28 V 输入跌落至 18 V 时维持 50 ms 正常工作 | HW-001 | 输入端施加 28 V→18 V 阶跃，示波器测 5 V 轨，跌落期间≥4.75 V 且持续≥50 ms | 试验 |
| SYS-002 | ARINC 429 接收通道在 100 kbps 下误码率≤1E-7 | HW-002 | 信号源注入 100 kbps 伪随机码，测试点取收发器差分输出，连续 10 min 统计误码 | 试验 |
| SYS-003 | 离散量输入在 -55℃~+85℃ 范围内阈值漂移≤5% | HW-003 | 温箱内施加 0 V/28 V 阶跃，测试点取光耦输出，记录阈值电压并计算漂移 | 试验 |
分解后需逐条检查：HW-001 的测试点是否可达？HW-002 的误码统计是否包含同步丢失？HW-003 的温箱升降温速率是否影响阈值读数？这些检查正是可验证性检查的落地。
完成分解后，建议将追溯矩阵与测试用例管理工具关联，确保每次需求变更都能自动识别受影响的验证项。对于航电 LRU，还需特别关注 DO-254 对需求追溯的要求：每条硬件验证需求必须能向上追溯到系统需求或适航条款，向下追溯到具体测试用例和测试结果，形成完整证据链。
总结本节要点：映射方法解决“怎么拆”，可验证性检查解决“拆得对不对”，追溯矩阵解决“拆得全不全”，LRU 实战则把三者串成可执行的工程活动。下一阶段进入硬件架构设计与需求分配时，这些验证需求将直接约束接口定义和测试点布局。