4. 安全相关硬件与软件
伺服功能安全验证不能只盯着驱动器本体。真正决定安全功能能否落地的，是围绕驱动器的安全相关硬件与软件链路：安全编码器提供可信位置与速度，安全PLC完成逻辑运算与安全输出，安全继电器承担强制断开与触点冗余，安全总线（PROFIsafe、FSoE）负责安全数据在控制器与驱动器之间的可靠传输。本节从验证视角出发，梳理这四类对象的验证要点与常见误区。
一、核心原理：安全链路的分层可信
功能安全的核心是“安全功能在故障条件下仍能执行”。在伺服系统中，安全链路通常分为四层：感知层（安全编码器）、逻辑层（安全PLC）、执行层（安全继电器/安全输出）、通信层（安全总线）。每一层都必须满足自身的诊断覆盖率（DC）、安全失效分数（SFF）与硬件故障裕度（HFT），并通过安全总线把各层状态汇聚到统一的安全逻辑中。
验证的本质，是证明“单点故障不会导致安全功能丧失，且故障能被诊断到规定时间内”。因此验证不是简单测通断，而是围绕故障注入、诊断响应时间、残余风险展开。
二、方法流程：四类对象的验证要点
安全编码器验证：重点验证双通道信号的一致性、CRC校验有效性、超速阈值触发、位置偏差诊断。测试时应人为制造单通道断线、信号抖动、码盘污染等故障，确认编码器能在规定时间内输出安全状态（如STO触发或安全速度限制）。
安全PLC验证：重点验证双CPU比较机制、看门狗复位、安全输出表决、程序执行时间监控。可通过强制修改安全程序变量、模拟CPU停摆、注入时钟漂移等方式，确认PLC能进入安全状态并记录诊断事件。
安全继电器验证：重点验证强制导向触点的机械联动、冗余断开路径、触点粘连检测、反馈回路监控。测试时应模拟触点粘连、线圈断线、反馈回路断开，确认继电器能可靠断开并输出诊断信号。
安全总线验证：PROFIsafe与FSoE的验证要点包括：安全报文CRC校验、序号连续性、超时监控、地址唯一性、看门狗时间配置。应通过断开总线、注入错误CRC、重放旧报文、修改站地址等方式，确认总线能检测通信故障并触发安全响应。
验证流程建议：
- 明确安全功能需求（SFR）与目标SIL/PL等级。
- 绘制安全链路图，标注每层的诊断点与响应时间。
- 逐层进行故障注入测试，记录诊断覆盖率与响应时间。
- 进行跨层协同测试，验证安全总线在故障下的行为。
- 汇总验证证据，形成安全功能验证报告。
三、案例/场景：安全总线故障注入测试
某伺服系统采用PROFIsafe总线连接安全PLC与驱动器，目标SIL2。验证时，测试人员依次注入以下故障：
测试项1：断开PROFIsafe总线
预期：安全PLC在F_WD_Time内检测到超时，触发STO
实测：响应时间 28ms，满足 ≤ 50ms 要求
测试项2：注入错误CRC的安全报文
预期：接收端丢弃报文并计数，连续错误后进入安全状态
实测：连续3帧错误后触发安全响应，响应时间 35ms
测试项3：重放旧序号报文
预期：序号不连续被检测，触发安全响应
实测：检测到序号回退，立即触发STO
测试项4：修改F_Dest_Add站地址
预期：地址不匹配，安全连接无法建立
实测：连接建立失败，驱动器保持安全状态该案例说明，安全总线验证不能只看“通信正常”，更要看“通信异常时是否安全”。PROFIsafe与FSoE虽然协议不同，但验证逻辑一致：CRC、序号、超时、地址四要素缺一不可。
四、误区/复盘：常见验证盲区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 只测正常通信，不测故障注入 | 无法证明诊断覆盖率 | 必须进行断线、CRC错误、超时、重放等故障注入 |
| 忽略安全编码器单通道故障 | 单点故障可能导致安全功能丧失 | 验证双通道一致性及单通道故障下的安全响应 |
| 安全继电器只测线圈通断 | 触点粘连无法被发现 | 验证强制导向触点与反馈回路监控 |
| 安全PLC程序未做时间监控 | 程序跑飞后无法进入安全状态 | 验证看门狗与执行时间监控 |
| 安全总线看门狗时间配置过长 | 响应时间超出安全要求 | 根据SFR计算并验证F_WD_Time |
复盘要点：安全相关硬件与软件的验证，核心不是“功能是否实现”，而是“故障是否被诊断、安全状态是否被触发、响应时间是否达标”。安全编码器、安全PLC、安全继电器、安全总线四者构成完整安全链路，任何一层的验证缺失都会导致整体安全功能不可信。建议在验证计划中为每一层单独设置故障注入用例，并在跨层测试中验证安全总线的端到端响应时间。
综上，安全编码器验证感知可信，安全PLC验证逻辑可信，安全继电器验证执行可信，安全总线验证通信可信。四者协同，才能构成伺服功能安全的完整证据链。