故障导向安全-CSDN博客

本文链接：https://blog.csdn.net/forrestzhaoc/article/details/145348923

前天跟轨道交通信号领域的专家交流，他提到一个概念“故障导向安全”-Fail Safe，就是当故障发生时，做出的反应动作是导向安全的。

比如在地铁和高铁这种轨道交通领域，就需要降速，甚至是立即制动停车。

这一点跟互联网系统就有一些区别，互联网业务系统是允许失败，会以关键指标的成功率代表可用性，出了故障只要能快速恢复就可以。

而且在效率和成本面前，是允许牺牲一部分稳定性和安全性的，甚至是一定的资损。

这一点在人命关天的轨道交通领域就无法接受，一定是安全高于一切。

我这个朋友就告诉我说，这个领域就一个原则，不能撞。

不过，也一个例外，就是现在的电动车领域，汽车作为一个大规模量产的消费级产品，对成本非常敏感，大家都在卷价格，卷交付效率，所以现在这个领域在成本和安全的融合上说不清道不明。

这个“故障导向安全”的原则下，他给我说了这个领域里系统的两个关键设计原则，挺有意思的，第一次听说，所以分享一下：

1、默认故障策略：

系统对不确定性的处理往往会采取“默认危险状态”的保守策略，即当无法明确判断当前是否安全时，系统会优先假定存在危险，并通过后续条件逐步验证是否能够解除这种假设。

这种逻辑在障碍物检测、信号判断、设备控制等场景中非常常见。以下是DeepSeek的回答，大致是这么个意思，比我自己总结要更专业，所以直接引用了。

核心逻辑：宁可误判，不可冒险

“默认危险”假设：当传感器失效、数据矛盾或计算超时时，系统会假设存在危险（如前方有障碍物、轨道被占用）。

例如：自动驾驶汽车在摄像头被强光干扰时，默认前方有障碍物并启动制动。

“白名单”思维：只有通过严格的验证条件（如多传感器一致确认、逻辑条件全满足），系统才会解除危险假设，允许正常运行。

例如：地铁信号系统必须同时满足“轨道空闲+道岔锁闭+信号灯正常”才会开放绿灯。

DeepSeek的回答

这个原则落到具体实现里，就是系统在判断一个场景是否有故障时，默认为有故障，代码里的默认返回值就是True（有故障），然后通过一些列严格条件判断通过后，才会置为False（无故障），这样出现任何异常状况或者意想不到的状况没有走到分支流程，都会返回故障状态。

2、二取二或三取二冗余表决（2 out of 2 \ 2 out of 3）

接上面逻辑，无故障的判断也要遵从非常严格的逻辑，其中一个就是系统层面的冗余表决机制。

简单讲就是：两套系统，不同传感器，不同软件系统（相同逻辑，但是不同语言实现），异构操作系统，异构服务器（芯片异构），在相同输入的情况下，两套系统判断结果一致，才算生效。

比如在2oo2设计里，判断前方是否有障碍物，得两套系统同时判断为否，才算安全，只要有一个系统判断不成立，就默认为有障碍物，这时候就要采取对应的安全措施，比如降速继续观察，或者直接制动停车。

这有点像对同一件事情，如果2个或更多人持有相同观点，这个事情的可信度就会更高。

IEC 61508《电气/电子/可编程电子安全相关系统的功能安全性》国际标准里用MooN来表示，M表示输出，oo表示out of，N表示通道个数，D代表诊断。

“二取二”逻辑（2oo2），通过双通道冗余与严格一致性表决，确保系统故障时自动导向安全状态。系统结构是两个完全独立的硬件/软件通道（A/B），物理隔离供电，消除共因故障。每个通道独立接收相同输入信号，并行执行相同的控制逻辑运算，外部输入（如传感器信号）同时分发至双通道，双通道基于输入独立生成输出结果，互不干扰，通过专用硬件比较器或软件校验模块，对两通道输出进行逐周期比对。结果一致，输出有效控制指令（如列车加速、轨道信号开放）。不一致，立即切断执行链路，强制系统进入预设安全状态（如紧急制动、信号红灯）。典型场景：铁路信号系统、核电站反应堆紧急停堆保护、航空航天，如火箭点火。

DeepSeek的回答

2oo2的逻辑因为过于严格，这样当其中一个系统出现故障的时候，就会导致业务中断（比如停车），虽然不会造成安全事故，但是还是会影响到系统正常运行。

而且这个逻辑如果放到飞机上就不可行了，因为飞机飞在天上不可能随时停机不飞，这是不现实的，所以就出现了2oo3，三取二的逻辑，就是三套冗余系统，其中两套运行正常，且其中两套得到的结果是一致的，就认为结果可信。

所以在航空航天领域会从“故障导向安全 Fail Safe” 策略转变为“故障可运行 Fail Operational”，通过更多的冗余确保安全可运行。

比如波音777飞控计算机的三重冗余架构，每一个处理单元的电源、处理器、通信总线都是完全独立，整体冗余备份了三套，以此来达到故障可运行的目标。