Y4.01.1Fail-safe behavior设计

失效安全指故障后系统进入预定义的安全状态

别名: 失效安全 · predetermined safe state

概念解释

失效安全(fail-safe)指系统在发生某个指定故障后,进入或保持一个经过危害分析预先定义好的安全状态,让故障停在这一步,不再演化成不可接受的后果。"安全状态"是针对具体场景定义的控制目标,不必然等于断电或整机停机——对某些设备,断电本身反而是危险的那一端。

机制

实现失效安全的常见手段是去能、弹簧复位、保护逻辑触发或物理隔离,把故障导向一条事先设计好的、受控的路径,而不是任由系统停在故障发生那一刻的任意状态。这里有一层容易被忽略的前提:把某个方向定义为"安全",依赖于对当前场景的判断,同一个物理动作在不同场景下可能翻转安全与危险的方向——弹簧复位阀门失电后关闭,对大多数隔离阀是安全的,但如果这个阀门本身是泄压阀,关闭反而会让压力无处释放,变成更危险的状态。另外,进入安全状态往往不等于危险能量已经归零——去能可能只是切断了新增能量的输入,系统内部储存的压力、动能或高温仍然存在,界面如果只显示"已进入安全状态"这个结论,而不解释这个状态下具体丢失了哪些功能、还剩什么危险,操作者可能把"停止运动"误当成"已经安全,可以靠近"。

边界

失效安全的声明必须限定在具体的故障集合、任务阶段和持续时间内——针对单一指定故障验证过的安全性,不能直接外推到多重故障同时发生的场景,多故障组合可能让原本各自独立、互不冲突的安全响应相互抵消。此外,对制动、生命支持、冷却和飞行控制这类系统,"安全状态"本身在设计上可能不是停机,而是必须维持某种最低限度的持续功能(这正是与失效运行策略的分野所在),把"失效安全"简单等同于"什么都不做最安全"是常见的误用。

怎么落地

由正式的危害分析为每一个关键功能分别定义它的安全状态和进入该状态所需的转换条件,不能用一个笼统的"安全状态"覆盖所有功能。

  • 针对断电、传感器失效、通信丢失、执行器卡死这几类典型故障分别做实际的故障注入测试,验证系统是否真的按设计进入了预定义状态,而不是停在了一个未预期的中间态;
  • 验证办法:故障注入后,核对界面持续显示的触发原因、当前状态下剩余的危险能量、以及恢复所需前提这三项信息是否与工程侧记录的实际状态完全一致,任何一项不一致都算测试失败。

延伸

  • 同组Y4.01.2 失效运行指故障后系统在降级模式下继续运行 · Y4.01.3 两种策略的选择取决于停机代价与安全后果的权衡 · Y4.01.4 混合系统中不同子系统的失效策略需要显式协调
  • 相邻Y4.02 冗余与表决机制 · Y4.07 紧急操作的可达与防误触
  • 站内检索Fail-safe behavior · functional safety · safety-critical systems

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/Y4.01.1