3. 硬件验证计划与验证矩阵设计
硬件验证计划（Hardware Verification Plan, HVP）是把“要验证什么、怎么验证、验证到什么程度、由谁在什么条件下完成”固化为可执行、可追溯、可审查的技术文件。它上承系统需求与安全性目标，下接验证规程、测试用例与证据包，是航空航天电子硬件从设计走向适航符合性的关键枢纽。验证计划不是一次性文档，而是随需求基线、设计状态和试验结果迭代更新的受控记录。
验证计划编制要素
一份可执行的验证计划通常包含以下要素：验证对象与构型（硬件件号、软件版本、FPGA 配置、接口定义）、需求追溯关系（每条需求对应验证项编号）、验证方法（分析/试验/演示/检查）、验证层级（单元、LRU、系统集成）、环境与设备（温度箱、振动台、电源模拟器、总线仿真卡）、通过判据（量化门限、容差、采样率、持续时间）、资源与进度、风险与偏离处理、证据与评审要求。其中“通过判据”最容易被写空，必须给出可测量的量值，例如“在 −55 ℃ 与 +70 ℃ 下，离散量输出高电平 ≥ 4.5 V，低电平 ≤ 0.5 V，连续监测 30 min 无抖动”。
编制时建议先建立需求—验证项的双向映射，再逐条分配方法。对于飞控计算机这类高完整性对象，验证计划还需明确独立性要求：关键需求的验证活动应由非设计人员执行或复核，避免“自证清白”。
验证方法选择：分析、试验、演示、检查
四种方法各有适用边界，选择依据是“能否以可接受的成本获得可信证据”。
- 分析（Analysis）：用计算、仿真、建模或已有数据推断符合性。适用于无法直接试验或试验代价极高的项目，如热应力寿命、最坏情况时序、辐射单粒子率估算。分析必须给出模型假设、输入数据来源和不确定度。
- 试验（Test）：在受控条件下对硬件施加激励并测量响应，是最强证据。适用于性能、环境适应性、电磁兼容、电源特性等。试验需定义激励剖面、测量点、采样率和判据。
- 演示（Demonstration）：在真实或接近真实场景下展示功能可用性，通常不追求精确量化。适用于操作流程、接口连通、故障告警显示等。
- 检查（Inspection）：通过目视、测量或文件审查确认物理与工艺符合性。适用于标识、布线、紧固、防护涂覆、器件降额清单核对。
方法选择不是互斥的。例如“电源掉电保持时间”可先用分析估算电容储能，再用试验实测，最后用检查确认电容规格与安装。优先级通常是：能用试验就不用分析，能用分析就不做昂贵试验，但安全性关键项应尽量保留试验证据。
验证矩阵与覆盖度评估
验证矩阵（Verification Matrix, VM）是需求与验证活动的交叉表，行是需求条目，列是验证项、方法、层级、判据、证据编号和状态。矩阵的价值在于暴露“漏验”和“重验”：某条需求没有对应验证项即为漏验；多条验证项重复覆盖同一需求且无新增证据则为冗余。
覆盖度评估常用三个指标：需求覆盖率 = 已验证需求数 / 总需求数；方法覆盖率 = 各方法覆盖的需求数 / 总需求数；证据完整率 = 已归档证据数 / 计划证据数。工程上要求需求覆盖率达到 100%，但允许部分低风险需求以分析或检查方式关闭。评估时应区分“计划覆盖”和“实际完成”，避免用计划数冒充完成数。
某飞控计算机验证计划案例
以某型无人机飞控计算机（LRU 级）为例，其需求基线共 84 条。验证计划将其中 46 条分配给试验，22 条分配给分析，9 条分配给演示，7 条分配给检查。试验项集中在环境适应性（高低温、振动、湿热）、电磁兼容（CE102、RE102）、电源特性（瞬态、掉电保持）和接口时序；分析项集中在最坏情况时序、热仿真和元器件降额；演示项集中在 BIT 告警、地面维护接口和模式切换；检查项集中在标识、紧固和防护涂覆。
矩阵中每条需求至少对应一个验证项，关键安全需求（如“舵面指令输出延迟 ≤ 5 ms”）同时安排试验 T-012 和分析 A-012 交叉确认。判据写成可测量形式：T-012 在 100 Hz 指令流下用示波器测量输入到输出的时间差，连续采集 1000 帧，取最大值，要求 ≤ 5 ms。证据编号 E-012 关联原始波形文件、测试日志和签署记录。
覆盖度评估显示需求覆盖率 100%，但证据完整率仅 78%，原因是部分环境试验尚未执行、分析报告待评审。此时验证计划状态应标记为“进行中”，不能因为矩阵行数齐全就判定验证完成。对于偏离项，如某连接器因采购周期改用替代型号，需在计划中记录偏离申请、影响分析和补充验证项，确保构型变更后追溯链不断裂。
实际编制时，建议先用需求管理工具导出需求清单，再在矩阵中逐条填写方法、判据和证据编号，最后用脚本统计覆盖度。矩阵不是越厚越好，而是要让审查者能在十分钟内定位任意一条需求的验证状态和证据位置。