Fail-Safe 故障安全

真正的 Fail-Safe（失效安全/故障安全）是一套完整的系统设计思想，目标只有一个：系统发生故障时，不以危险的方式失效。

一、 Fail-Safe

1.1 传统控制逻辑的安全盲区

我们先看一个常见的简单控制链路：

上位机 → 控制器 → 继电器 → 电磁阀/电机/激光器

软件执行 turn_on()，数字输出置1，继电器吸合，设备运行。

如果此时软件进入死循环、线程卡死、进程崩溃、甚至CPU死机，会发生什么？

数字输出会保持最后一次的状态，继电器持续吸合，危险设备持续运行------控制系统已经失效，但危险输出仍然有效。

这就是最典型的安全盲区：Failure → Hazardous State（故障导向危险状态）。

而 Fail-Safe 的目标是把这条链路反转：

Failure → Fault Detection → Safety Function → Safe State

即：故障发生后，先被检测到，再触发安全功能，最终进入安全状态。

举个典型的链路：

软件卡死 → 100ms 无心跳信号 → 独立安全控制器检测超时 → 撤销使能信号 → 安全继电器释放 → 触发STO → 电机转矩切断

最终结果：Failure → Safe State

1.2 标准定义：NIST 与 IEC

• NIST 定义：当系统发生或检测到故障时，以一种能够防止对人员、财产或系统资源造成损害的方式终止系统功能。
• IEC 61508 定义：针对电气、电子和可编程电子（E/E/PE）安全相关系统，从风险分析、安全功能、安全完整性到验证、运行和维护，建立完整的生命周期安全管理体系，即 Functional Safety（功能安全）。

功能安全不评价"设备本身安不安全"，而是评价某个安全功能在需要时能否可靠执行。

1.3 锚点：Safe State（安全状态）

Fail-Safe 的重点是 Safe State------针对特定危险，系统发生故障时应进入的状态。

不同设备的安全状态完全不同，必须基于风险评估定义：

设备类型	常见误区	真正的 Safe State
水平输送电机	断电即安全	转矩 OFF（自由停车）
垂直升降机构	断电即安全	电机停转 + 机械制动器抱闸 + 转矩移除
加热器	断电即安全	加热输出 OFF
激光器	断电即安全	激光发射禁用
气动夹具	泄压即安全	保持夹持压力（防止工件坠落伤人）
真空吸盘搬运	泄压即安全	维持真空吸附
压力容器	保压即安全	打开泄压阀

所以 Fail-Safe 的第一步绝不是 if(error) all_output = 0;，而是先完成：

Hazard 识别 → Safe State 定义 → Safety Function 设计

二、安全概念辨析

很多人会把可靠性、容错、故障安全等概念混为一谈，它们的目标和实现方式完全不同。

2.1 概念对比

概念	目标	典型场景
Reliability（可靠性）	尽量让系统不要坏	提升器件寿命、降低故障率
Fault Tolerance（容错）	坏一个部件，系统还能正常工作	双机热备、冗余服务器
Fail-Safe（失效安全）	坏了之后，系统进入安全状态	安全继电器、STO、看门狗跳闸
Fail-Operational（故障可运行）	坏了之后，关键功能仍能继续执行	飞机飞控、冗余动力系统
Fail-Secure（故障保全）	坏了之后，仍维持安全/访问控制状态	门禁锁断电保持锁闭
Failover（故障切换）	主系统坏了自动切备用	双机主备切换、冗余电源

2.2 关键区分：容错 ≠ 故障安全

• 双机热备，A机故障切B机继续运行 → Fault Tolerance / Failover
• 控制器故障，接触器断开，电机停止 → Fail-Safe

NIST 也明确区分：fail-safe 侧重故障后避免损害，fail-secure 侧重故障后维持安全属性（如访问控制）。

三、功能安全的设计与机制

3.1 De-Energize to Trip（失电跳闸原则）

维持运行需要持续提供能量；能量消失时，自动进入安全状态。

错误的设计思路：

DO = 0 → Stop
DO = 1 → Run

这种设计下，如果输出晶体管击穿、PC卡死最后输出为1，设备会永久运行。

正确的安全设计 ：

运行需要持续的"使能证明"，一旦使能信号消失，硬件自动回到安全状态。

典型实现：Enable 信号 + Watchdog + 输出诊断 + 反馈触点 + 安全继电器 / STO

转变：从"需要发一个 Stop 命令" 变成"需要持续证明系统仍然具备 Run 的条件"

3.2 Watchdog 与 Heartbeat

3.2.1 Watchdog

Watchdog 的逻辑是：将"证据缺失"判定为"故障"。

Linux 内核硬件看门狗的典型模式：用户态周期性喂狗 → 内核驱动 → 硬件看门狗。一旦软件故障停止喂狗，超时触发系统复位。

3.2.2 系统看门狗 ≠ 安全看门狗

• PC 硬件看门狗 → PC 重启，属于可用性恢复手段
• 危险执行器的安全看门狗 → 直接切断危险输出，位于靠近执行器的位置

⚠️ 典型误区：PC 卡死之后，看门狗5秒后重启，期间电机已经运行35秒，完全达不到安全要求。

3.2.3 Heartbeat

基础错误示范：

bool heartbeat = true; // 固定电平

如果线路短接到24V，心跳永久为1，控制器会误认为系统一直健康。

工业级正确设计：

• 方波跳变：0 → 1 → 0 → 1 周期性翻转
• 递增计数器：101 → 102 → 103 → ...
• 完整帧：序列号 + CRC + 超时校验 + 源/目的ID

可以检测：信号冻结、重复包、丢包、乱序、数据破坏、错误节点、通信中断。

工业安全总线 PROFIsafe 正是基于此原理，在普通以太网之上增加安全通信层，用于连接安全PLC与安全驱动。

3.3 双通道冗余与共因故障（CCF）

3.3.1 为什么需要双通道

单继电器触点焊死后，即使控制器发OFF，电机仍然通电。

双通道设计的目标：单一故障 ≠ 安全功能丧失

3.3.2 共因失效（Common Cause Failure, CCF）

很多人以为"双通道=安全"，但如果两个通道：

共用电源、共用连接器、共用线缆、共用CPU、同一个软件bug、同一个时钟源

那么一个共同原因会导致两个通道同时失效，这就是共因故障。

⚠️ 典型伪冗余：两个停止函数运行在同一个卡死的进程里，完全无法抵抗共因故障。

3.4 反馈闭环：Command ≠ Result

命令发送成功 ≠ 执行器已经进入安全状态

典型实现：EDM（External Device Monitoring，外部设备监控）

安全控制器发OFF命令 → 检测接触器辅助触点反馈 → 确认触点断开才判定安全；如果反馈不匹配，立即报故障。

不能因为 digitalWrite(enable, LOW); 执行成功，就认为执行器已经安全。必须做到 Command + Observation 形成闭环。

3.5 禁止意外重启原则

场景：设备运行中断电停机，恢复供电后自动启动，可能直接伤人。

Fail-Safe 要求：

• 失电 → 进入安全状态
• 复电 → 仍保持安全状态
• 必须经过操作人员确认/复位 → 进入就绪态 → 重新接收运行命令

对于断电后重启可能伤人的设备，必须防止电源恢复后机器自动重启。

3.6 Default-to-Safe 状态机设计

软件层面不要只有 ON/OFF 两态，至少应设计完整的安全状态机：

POWER_OFF → INIT → SAFE → READY → RUNNING

所有异常分支（超时、通信丢失、传感器无效、反馈不匹配、内部故障）全部默认指向 SAFE 状态，而不是保持上一次状态。

3.7 Permission-based 控制逻辑

错误写法（故障导向运行）：

if (error1) stop();
if (error2) stop();
if (error3) stop();

只有想到的错误才会停止，想不到的错误就会继续运行。

正确写法（权限导向运行）：

bool allow_run = 
    communication_ok
    && controller_ok
    && safety_chain_ok
    && actuator_ok
    && heartbeat_ok
    && !emergency_stop
    && command_valid;

if (!allow_run) {
    enter_safe_state();
}

只有所有条件明确成立，才允许运行；任何条件不满足，立即进入安全状态。

这是 Fail-Safe 最核心的软件设计原则。

四、工业驱动系统的安全功能

针对电机、伺服、机器人等运动系统，IEC 61800-5-2 定义了标准的安全功能，最核心的是 STO、SS1、SS2。

4.1 STO（Safe Torque Off，安全转矩关断）

• 定义：驱动的转矩产生输出被禁用，电机不再产生转矩
• 对应 IEC 60204-1 Stop Category 0
• 效果：电机自由减速停车（coast to stop）

⚠️ 注意：STO ≠ 立即静止。高速大惯量设备执行STO后会继续滑行，因此不能直接用于垂直轴等有坠落风险的场景。

4.2 SS1（Safe Stop 1，安全停止1）

• 逻辑：安全请求 → 受控减速 → 速度到0 → 触发STO
• 对应 IEC 60204-1 Stop Category 1
• 适用：需要快速停车、避免自由滑行的场景

4.3 SS2（Safe Stop 2，安全停止2）

• 逻辑：安全请求 → 受控减速 → 速度到0 → 进入SOS（安全操作停止，保持转矩）
• 对应 IEC 60204-1 Stop Category 2
• 适用：停机后仍需保持定位，或后续需要快速恢复的场景

4.4 其他常见驱动安全功能

SLS（安全限速）、SLT（安全限矩）、SLP（安全限位置）、SDI（安全方向）、SBC（安全制动控制）等。

五、PL 与 SIL 的对应

功能安全用量化的等级来描述安全功能的可靠程度，机械领域常用 PL，电气电子领域常用 SIL。

5.1 ISO 13849 与 PL 等级（机械控制领域）

ISO 13849-1 是机械安全控制系统的标准

它将安全性能划分为 5 个 Performance Level（PL），用每小时危险失效概率 PFH_D 衡量：

性能等级 PL	每小时危险失效概率 PFH_D
PL a	≥ 10⁻⁵ ～ < 10⁻⁴ /h
PL b	≥ 3×10⁻⁶ ～ < 10⁻⁵ /h
PL c	≥ 10⁻⁶ ～ < 3×10⁻⁶ /h
PL d	≥ 10⁻⁷ ～ < 10⁻⁶ /h
PL e	≥ 10⁻⁸ ～ < 10⁻⁷ /h

PL e 是机械领域最高的常规安全等级。

5.2 IEC 61508 与 SIL 等级（电气电子领域）

IEC 61508 是功能安全的基础通用标准，定义了 4 个 Safety Integrity Level（SIL）：

安全完整性等级 SIL	高需求/连续模式 PFH
SIL 1	≥ 10⁻⁶ ～ < 10⁻⁵ /h
SIL 2	≥ 10⁻⁷ ～ < 10⁻⁶ /h
SIL 3	≥ 10⁻⁸ ～ < 10⁻⁷ /h
SIL 4	≥ 10⁻⁹ ～ < 10⁻⁸ /h

机械行业的 IEC 62061 通常只用到 SIL 1 ~ SIL 3，SIL 4 主要用于过程工业等高风险领域。

5.3 PL 与 SIL 的数值对应关系

等级	PL 对应 PFH_D	SIL 对应 PFH	大致对应
低	PL c：10⁻⁶	SIL 1：10⁻⁶	PL c ≈ SIL 1
中	PL d：10⁻⁷	SIL 2：10⁻⁷	PL d ≈ SIL 2
高	PL e：10⁻⁸	SIL 3：10⁻⁸	PL e ≈ SIL 3

注意：这只是数值上的近似对应，两者的标准体系、适用范围、计算方法不同，不能直接等同替换。

5.4 影响性能等级的要素

1. Category（架构类别）

类别	特征
B	基本安全原则，单通道
1	采用经过验证的高可靠器件
2	单通道 + 周期测试诊断
3	冗余架构，单一故障不丢失安全功能
4	冗余 + 高诊断覆盖 + 故障累积耐受

3. MTTF_D（平均危险失效时间）：每个通道的危险故障平均间隔时间，分为低、中、高三档。
4. DC_avg（平均诊断覆盖率）：系统能检测到的危险故障占比，分为无、低、中、高四档。
5. CCF（共因失效抑制）：抵抗共因故障的能力，通过8项措施评分，≥65分合格。
6. 软件与系统性故障：软件开发流程、系统性失效防护措施。

最终通过马尔可夫模型计算出整体 PFH_D，对应到相应的 PL 等级。

六、工业上位机系统的合理安全架构

对于 C++/C#/ROS2 等上位机软件，运行在通用 Windows/Linux 平台上，绝对不能把人员安全只依赖在应用层代码上。

6.1 分层安全架构

┌──────────────────────────────────────────────────┐
│  Normal Control Domain（正常控制域）         │
│  PC / Windows / Linux                          │
│  C++ / C# / ROS2 / UI / 视觉 / AI              │
└───────────────────────┬──────────────────────┘
                        │
                command + heartbeat
                        │
═══════════════════════════════════════════════════╕
  Safety Boundary（安全边界）
╘══════════════════════════════════════════════════╛
                        │
                        ▼
         ┌──────────────────────┐
         │ PLC / 安全PLC / MCU  │
         │  安全逻辑与监控       │
         └───────────┬──────────┘
                     │
                Safety Relay / STO
                     │
                     ▼
                执行器 / 电机

同时急停按钮直接接入安全回路，不经过上位机。

6.2 设计原则

• 上位机负责业务逻辑、轨迹规划、人机交互
• PLC/MCU 负责实时安全监控、心跳检测、安全逻辑
• 安全继电器/STO 负责最终危险能量切断
• 形成独立的 Safety Path，所有安全逻辑不依赖上位机操作系统

这样，AI 算法卡死、UI 无响应、ROS 崩溃、Windows 蓝屏、网络断开，都不会导致危险输出无限维持。

6.3 误区检查表

常见认知	正误	说明
try/catch 能处理所有故障	❌	死锁、死机、掉电、断网都执行不到异常处理
看门狗重启电脑就安全	❌	PC看门狗是可用性手段，危险执行器需要独立安全看门狗
保持最后状态是正常逻辑	❌	对危险输出，通信丢失保持最后状态往往最危险
安全逻辑都在同一个CPU/线程	❌	无法抵抗共因故障
发STOP命令=进入安全状态	❌	命令不等于结果，需要反馈闭环
STO=电机立即停	❌	STO是撤转矩，大惯量会滑行
断电安全，复电自动运行	❌	必须防止意外重启
双通道=PL e / SIL3	❌	还需可靠性、诊断、CCF、软件、验证全部达标
有急停就是功能安全	❌	急停只是安全功能之一
不用先定义Safe State	❌	没有目标，所有安全机制都没有意义

七、系统安全的方法论

7.1 功能安全生命周期

功能安全是完整的生命周期过程，不是一段代码：

危害分析 → 风险评估 → 安全需求 → 安全功能定义 → 目标PL/SIL
    ↓
架构设计 → 硬件设计 → 软件设计 → 验证 → 确认
    ↓
调试 → 运行 → 维护 → 变更 → 再验证

7.2 四个核心问题（建立安全思维的抓手）

做工业安全设计，先把这四个问题想明白：

1. 危险是什么？（Hazard Identification）
2. 安全状态是什么？（Safe State Definition）
3. 上位机彻底失效时，谁还能把设备拉到安全状态？（Independent Safety Path）
4. 那个安全机制自己坏了，还能不能检测出来？（Diagnostic Coverage）

想清楚这四个问题，watchdog、心跳、安全继电器、STO、双通道、反馈、PL/SIL 这些概念就会全部串联起来。

---

写在最后

Fail-Safe 是一整套从危害分析到落地验证的系统工程思想。它的底层逻辑非常朴素：永远不要假设系统正常工作，要为所有可能的故障预设安全退路。

对于工业上位机开发者而言，最重要是先建立"故障导向安全"的设计思维，在控制链路中埋下独立的安全防线。