表决逻辑本身的故障会抵消冗余带来的可靠性
别名: 表决器故障 · voter reliability
概念解释
表决器把多个冗余通道汇聚成一个单一的最终决定，这个汇聚动作本身也是由具体的硬件、软件和一套需求逻辑实现的，因此表决器自己出错——无论是硬件损坏、软件缺陷、还是需求本身写错了——都可能成为一个新的、共同的单点故障。三条通道各自都完全可靠，如果把它们组合起来的那一步逻辑错了，冗余带来的可靠性收益会被这一步全部抵消。
机制
集中式的表决器通常共享同一路电源、同一个时钟源、同一套数据解析代码和同一条输出路径——这意味着表决器内部一旦出现一个错误的判定阈值、一个时序上的缺陷，这个错误会同时作用于所有输入通道，不会像通道级故障那样只影响其中一路。这是一个容易被忽略的架构盲点：设计者往往把大量精力投入到让三条输入通道彼此独立，却把汇聚这三条通道的那一个逻辑当成理所当然正确的"最后一步"，实际上这一步恰恰是整个冗余架构里最集中的环节。监视表决器本身、把表决逻辑分布到多个独立实现、或者用不同方式重复实现表决算法，都是为了降低这种集中风险的手段，但这些手段各自都会引入新的问题——多个表决实现之间万一给出不一致的结果，谁的结果该被最终采信，又需要一层新的仲裁。
边界
不是所有架构都存在一个可以单独指出来的物理表决器——在某些设计里，"表决"这个功能被分散实现在多个执行器各自的本地逻辑里，或者隐含在某个通信协议的仲裁规则中，这时候审查表决风险不能只盯着一块看得见的表决器硬件去找。另外，用两套或三套表决实现互相校验，如果这几套实现复制的是同一段有缺陷的逻辑代码，看起来是多重表决，实际上和单一表决器共享同一个错误，并不能带来真正的独立性。
怎么落地
把表决功能本身也作为一个独立的项目纳入故障树分析和安全完整性等级的分配范围，专门审查它的需求定义、时序逻辑、数值溢出处理、以及在表决器自身故障时应该输出什么样的失效状态。
- 验证办法：注入表决器卡死、故意让表决逻辑得出错误的多数判定、以及输入数据到达顺序被打乱这三类故障，验证系统是否会依赖旁路或降级路径来兜底；重点检查这条旁路或降级路径本身是否又引入了比表决器故障更大的新风险，不能默认"有备份逻辑"就等于"更安全"。