Y4.01.2Fail-operational behavior设计

失效运行指故障后系统在降级模式下继续运行

别名: 失效运行 · degraded operation

概念解释

失效运行(fail-operational)指系统在发生指定故障后,仍然提供必要的功能,通常表现为以降低的能力、性能或有限的时限继续完成任务,而不是立刻停下来。它强调的是服务的连续性,但这个连续性是有条件的——降级之后的模式仍然必须满足明确写出的安全约束,"还能动"不等于"还安全"。

机制

冗余通道、系统重构和功能隔离,是让系统能从正常模式平滑转入一个受限但仍受控的模式的技术手段,但这个转换本身对操作者是不可见的,除非界面主动呈现。这里的关键机制是:失去的能力、被禁止的动作、以及这个降级模式还能维持多久这三项信息,缺一不可地构成了操作者继续安全决策所需的全部依据——只知道"系统还在运行"而不知道这三项,操作者会不自觉地沿用故障前的操作习惯去对待一个能力已经改变的系统。如果这次降级是系统自动完成、没有任何提示的,操作者会经历一次典型的自动化惊讶(automation surprise):系统的行为符合它内部降级后的逻辑,却完全偏离操作者仍然停留在故障前的心智模型,这种偏离在时间压力下格外危险,因为操作者往往要花更长时间才能意识到规则已经变了。

边界

继续运行不总是比直接停机更安全——如果降级模式掩盖了一个仍在恶化的根本问题,让系统"看起来还行",反而会推迟本该立刻发生的干预。冗余带来的降级能力也可能受共同原因影响,比如支撑多条通道的同一个电源或同一批次的传感器同时出问题,冗余就无法按设计发挥作用。降级能力还会随后续的第二次故障、环境条件和当前处于哪个任务阶段而持续变化,不能用一个静态的"可用"标签一次性描述清楚,需要持续更新。

怎么落地

为每个关键功能定义清楚它的最小安全功能集、可能存在的多级降级台阶、每一级能维持的任务时限、以及触发终止(转入失效安全)的条件,再用实际的故障注入去验证重构逻辑和降级后的真实性能是否与设计一致。

  • 验证办法:制造一次静默的自动降级(不给操作者任何提前预警),记录操作者从系统行为异常到意识到"能力已经改变"所花费的时间;界面应持续显示已经失去的能力、剩余的冗余余量、当前受到的操作限制、以及如果再发生一次故障会导致什么后果,四项信息都能在几秒内被读出才算合格。

延伸

  • 同组Y4.01.1 失效安全指故障后系统进入预定义的安全状态 · Y4.01.3 两种策略的选择取决于停机代价与安全后果的权衡 · Y4.01.4 混合系统中不同子系统的失效策略需要显式协调
  • 相邻Y4.02 冗余与表决机制 · Y3.02 模式混淆与事故
  • 站内检索Fail-operational behavior · functional safety · safety-critical systems

同组卡片

快捷操作

分享

分享当前页面

ios_share

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