4. 容错机制分类与验证映射

星载计算机的容错能力不是单一技术，而是由多种机制按层次组合而成。理解这些机制的分类，并建立“机制—故障模型—验证关注点”的映射关系，是设计综合验证方案的前提。本节从故障作用的对象出发，把容错机制划分为硬件冗余、信息冗余、时间冗余、软件容错和可重构机制五类，并逐一说明其原理、典型实现以及验证时应重点考察的内容。

一、分类的出发点：故障作用在什么对象上

任何容错机制本质上都是在“对抗”某类故障。硬件冗余对抗的是物理器件的永久或瞬态失效，信息冗余对抗的是数据在存储和传输中的位翻转，时间冗余对抗的是瞬态故障在时间维度上的偶发出现，软件容错对抗的是设计缺陷和运行中的逻辑错误，可重构机制对抗的是资源部分失效后系统能力的整体丧失。因此，验证方案必须与机制所针对的故障模型严格对应，否则会出现“测了很多，却没测到关键故障”的情况。

二、硬件冗余：验证切换与表决的真实行为

硬件冗余通过增加物理资源来掩盖失效，典型形式包括双机热备、三模冗余（TMR）和冷备切换。双机热备中，主备机同时运行，备机持续跟踪主机状态，一旦主机失效立即接管。验证时不能只看“能否切换”，而要考察切换时间是否满足任务时限、切换过程中输出是否出现毛刺、备机状态是否与主机真正同步。TMR 则依赖三路相同模块加表决器，验证重点是表决器在单路故障时能否输出正确结果，以及两路同时故障时系统是否进入安全状态。

硬件冗余验证的一个关键难点是共因失效。例如三路模块共用同一电源或同一时钟源，当电源跌落时三路同时失效，表决器无法分辨。因此验证方案中应设计共因故障注入，观察系统是否具备独立的失效检测和降级路径。教学示例中，可设定切换时间指标为不大于 50 ms，通过注入主处理器复位故障，用逻辑分析仪记录切换信号与输出总线，判断切换是否在指标内完成且输出数据连续。

三、信息冗余：从位翻转检测到纠错链路

信息冗余在数据中加入校验位或冗余副本，使系统能够检测甚至纠正错误。星载计算机中常见的有存储器 EDAC（错误检测与纠正）、总线 CRC 校验、程序代码校验和以及关键数据的多副本存储。验证信息冗余时，核心指标是检错/纠错覆盖率和错误上报的及时性。

以 EDAC 为例，若采用 SECDED（单纠错双检错）编码，验证时应分别注入单位翻转和双位翻转：单位翻转应被纠正且系统无中断，双位翻转应被检测并触发中断或记录。注入位置应覆盖数据区、校验区以及地址译码路径。对于总线 CRC，验证应关注 CRC 生成多项式是否与协议一致、错误帧是否被丢弃并重传、连续错误是否触发链路降级。信息冗余的验证往往需要精确控制注入的位和时刻，因此常借助故障注入器或软件钩子实现。

四、时间冗余：重试、重复执行与超时判定

时间冗余不增加硬件，而是通过重复执行来对抗瞬态故障。典型实现包括指令重试、任务重执行和看门狗超时复位。验证时间冗余时，需要关注三个参数：重试次数上限、单次执行超时阈值、以及重试失败后的处理策略。

例如某控制任务设定单次执行超时阈值为 20 ms，允许重试 2 次。验证时可注入一次瞬态故障使首次执行超时，观察系统是否在 20 ms 内触发重试、第二次执行是否成功、任务输出是否在总时限内恢复。若连续三次均失败，系统应进入安全模式并上报。时间冗余的验证难点在于瞬态故障的“时间窗口”控制：故障必须落在被重复执行的区间内，才能检验重试机制是否真正生效。因此注入时刻需要与任务调度周期对齐。

五、软件容错：N版本、恢复块与异常处理

软件容错针对的是设计缺陷和逻辑错误，常见方法有 N 版本编程、恢复块和异常处理。N 版本编程让多个独立开发的版本执行同一功能，再对输出进行表决；恢复块则先执行主块，检测到异常后回滚并执行备用块。验证软件容错时，重点不是“软件能否运行”，而是“版本间输出是否真正独立、裁决逻辑是否正确、异常路径是否被覆盖”。

验证 N 版本系统时，可人为在某一版本中植入一个已知缺陷，观察表决器是否能够识别并屏蔽该版本的错误输出。若两个版本同时出现相同错误，则说明独立性不足，需要检查是否共用了同一算法库或同一输入预处理。恢复块验证则应关注回滚点是否完整、备用块是否能在时限内完成、以及回滚过程中共享数据是否被污染。软件容错的验证用例应覆盖正常路径、异常路径和边界条件，尤其要覆盖异常处理分支。

六、可重构机制：动态重构与功能降级

可重构机制允许系统在检测到资源失效后，重新组织剩余资源以维持关键功能。典型形式包括 FPGA 动态重构、处理器核切换和任务迁移。验证可重构机制时，需要关注重构触发条件是否准确、重构时间是否可接受、重构后功能是否完整、以及降级后的系统边界是否明确。

以 FPGA 动态重构为例，若某功能模块所在区域发生永久故障，系统应能加载备用配置到其他区域。验证时可注入配置存储器错误或区域失效，测量从故障检测到重构完成的耗时，并检查重构后该功能是否恢复正常、其他功能是否受影响。若重构时间超过任务允许的停机窗口，则需要设计降级策略，例如暂时关闭非关键功能、保留核心控制回路。可重构验证的难点在于故障检测与重构触发之间的联动逻辑，必须确保检测不误报、重构不遗漏。

七、机制组合与验证映射的落地

实际星载计算机通常同时采用多种机制。例如，存储器使用 EDAC 对抗位翻转，处理器采用双机热备对抗永久失效，关键任务采用时间冗余对抗瞬态故障，软件采用恢复块对抗逻辑错误，FPGA 采用动态重构对抗资源失效。验证方案需要为每种机制建立独立的注入点和观测点，同时还要验证机制之间的协同关系：信息冗余检测到不可纠正错误后，是否触发硬件切换；时间冗余重试失败后，是否触发软件降级；可重构完成后，是否重新纳入表决体系。

下表给出一种可参考的验证映射示例，用于把机制、故障注入方式和观测指标对应起来。表中参数为教学示例，实际项目应根据任务剖面和可靠性指标调整。

需要强调的是，容错机制的验证不是孤立地测试每个模块，而是要在系统层面观察故障发生后系统是否按预期降级、切换或恢复。验证人员应清楚每种机制所针对的故障模型，选择匹配的注入方式，并在注入前后记录关键状态和输出，才能判断容错机制是否真正有效。