📚 课程目录第4章驱动器安全需求分析

4. 驱动器安全需求分析

安全需求分析是驱动器功能安全开发的“源头工程”。它把“驱动器可能伤人”这一模糊担忧，转化为可验证、可追溯、可分配的技术要求。本节围绕四个递进环节展开：危害分析（HAZOP/HAZID）、风险评估（S/E/C 或 ISO 12100 风险图）、安全目标（Safety Goal）制定，以及安全需求分解与分配（ASIL 分解、TSR/SSR 分配）。

核心逻辑：危害 → 风险等级 → 安全目标 → 功能安全需求 → 技术安全需求 → 软硬件安全需求。每一层都必须可双向追溯，任何一层断裂都会导致安全论证失效。

一、危害分析：从“能量失控”出发识别危害

驱动器本质是能量转换与放大装置，其危害多源于能量失控。危害分析常用 HAZOP 引导词法，对“电机转矩输出”“制动控制”“位置反馈”“功率级开关”等节点逐一施加引导词，识别偏差。

无输出：电机失转矩，垂直负载坠落。
反向输出：电机反转，机械碰撞。
过大输出：过转矩导致机械过载、飞车。
持续输出：无法停机，人员被卷入。
错误时序：使能与抱闸顺序错误，抱闸烧毁或溜车。

危害分析输出的是“危害事件清单”，每条应包含：危害描述、触发条件、受影响对象（人/设备）、运行模式（自动/手动/维护）。

二、风险评估：确定 ASIL 或 PL

汽车领域按 ISO 26262 用 S（严重度）、E（暴露率）、C（可控性）三参数查表得到 ASIL A~D；工业领域按 ISO 13849 用 S、F、P 得到 PL a~e。驱动器常见参数取值如下：

参数	含义	驱动器典型取值
S	严重度	S2~S3（骨折、不可逆伤害）
E	暴露率	E3~E4（频繁或持续运行）
C	可控性	C2~C3（难以控制、几乎不可能）
结果	ASIL 等级	常见 ASIL C/D

风险评估不是一次性动作。当运行模式、负载特性、人员接近频率变化时，E 与 C 会改变，ASIL 可能降级或升级，必须重新评估。

三、安全目标制定：用“避免+防止”句式表达

安全目标是危害事件的安全状态描述，应满足：与危害一一对应、可度量、不涉及具体实现。推荐句式：“避免驱动器在 X 条件下产生 Y，防止导致 Z。”

SG-01：避免电机在使能状态下产生非预期转矩输出，
       防止垂直负载坠落造成人员伤害。
       ASIL：D   FTTI：20 ms

SG-02：避免驱动器在制动请求后仍持续输出转矩，
       防止设备无法停机导致人员被卷入。
       ASIL：C   FTTI：50 ms

每个安全目标必须绑定 FTTI（故障容错时间间隔），它是后续安全机制设计的时间预算。

四、安全需求分解与分配方法

安全目标不能直接实现，需逐层分解为功能安全需求（FSR）、技术安全需求（TSR），再分配到硬件、软件、系统三个层面。常用方法有三种：

ASIL 分解：将一个高 ASIL 目标拆为多个低 ASIL 冗余需求，如 D = C(D)+A(D)+A(D)，但需满足独立性。
功能分解：按“检测—决策—执行”三段拆分，如转矩监控、安全转矩关断（STO）、安全制动控制。
架构分配：将需求映射到具体通道，如双通道转矩比较、独立 PWM 使能路径、安全编码器接口。

下面用一张关系图展示从危害到软硬件需求的完整分解与分配链路。

五、案例与常见误区

案例：某伺服驱动器在垂直轴应用中，因使能信号与抱闸释放顺序错误，导致溜车。HAZOP 识别出“错误时序”危害，评估为 ASIL C，制定安全目标“避免抱闸释放先于转矩建立”，分解为 TSR“抱闸控制与转矩就绪信号互锁”，最终分配到 FPGA 时序逻辑与软件状态机双重实现。

常见误区：
1. 把安全目标写成实现方案，如“增加看门狗”，导致需求不可分解。
2. 忽略 FTTI，安全机制响应时间超预算，安全目标实际不可达。
3. ASIL 分解时未验证独立性，冗余通道共因失效，分解无效。
4. 需求分配后未建立追溯矩阵，后期变更无法评估影响范围。

复盘要点：危害分析要覆盖所有运行模式；风险评估参数取值要有依据；安全目标必须可度量；分解分配后必须形成需求追溯矩阵，并在每个阶段用评审、测试、故障注入验证其完整性与一致性。