STPA — 系统理论危害分析(HARA 的互补方法)
本质与导读
本质 STPA(System-Theoretic Process Analysis)把"hazard"重新定义为"controller 对系统的不当控制",从而把 HARA 抓不住的需求 / 软件 / 系统交互类危害显式化。它不是 HARA 的替代,而是上游互补——先 STPA 找 UCA,再 HARA 评级。HSE 数据显示 44 % 危险失效源自需求阶段,HARA 这块弱,STPA 正好补。L3+ ADAS / SOTIF / Steer-by-wire 必做 STPA。
1. 为什么需要 STPA
HARA 沿着"组件 fail → 后果"思路走,基础假设是系统失效 = 组件失效。这套思路对随机硬件失效很有效,但碰到下面三类危害就漏:
- 需求不完整:规范本身没说"高速暴雨且对面车灯刺眼时 lane line 检不出怎么办" → HARA 无法找出未规定的工况。
- 软件 bug + 系统状态错配:每个组件都"正常运作",但组合起来产生 hazard(ADAS 与驾驶员的 mode 冲突)。
- 人机交互失误:driver 误激活 LKAS,或在 handover 时双方都松手 — 没有组件 fail,但 hazard 发生。
Nancy Leveson 在 MIT 提出的 STPA(2004)从控制理论出发,把系统建模成分层 Controller → Controlled Process 网络,任何 hazard 都被映射成"controller 给出了不安全的控制动作"。这种视角天然涵盖软件、人机和系统级问题。
2. STPA 4 步流程
STPA 把"找 hazard"拆成 4 步可复现的工作流。每步产出一张表,逐步细化:Loss → Hazard → UCA → Loss Scenario → Safety Constraint。
| 步骤 | 输入 | 工作 | 输出 |
|---|---|---|---|
| ① 定义 Loss + Hazard | 项目目标 | 列"绝对不能发生"的 Loss + 把 Loss 映射成 System-level Hazard | Loss / Hazard 列表 |
| ② 画 Control Structure | 系统架构 | 把系统画成分层 Controller-Controlled-Process,标 Control / Feedback 箭头 | Control Structure 图 |
| ③ 找 UCA | Control Structure | 对每条 Control Action 系统化提 4 类 UCA | UCA 表 |
| ④ Loss Scenario | UCA + 系统模型 | 对每条 UCA 追溯 5 类因果机制 | Scenario + Safety Constraint 表 |
2.1 第一步:Loss 与 Hazard
Loss = 利益相关方完全不能接受的结果。汽车 ADAS 典型 Loss:
- L-1:乘员伤亡
- L-2:行人伤亡
- L-3:车辆损毁
- L-4:法规违规
System-level Hazard = 在某种环境条件下,系统状态会导致 Loss。LKAS 的 Hazard 例:
- H-1:车辆未保持在车道内(导向 L-1/L-2)
- H-2:车辆主动偏离车道(导向 L-2)
- H-3:驾驶员控制与 ADAS 控制冲突(导向 L-1/L-2)
注意 Hazard 是系统状态,不是组件 fail。"摄像头失效"不是 Hazard;"车出车道"才是。
2.2 第二步:画 Control Structure
把系统画成分层控制图:每层是一个 Controller,它通过 Control Action 影响下层,下层通过 Feedback 把状态返回。LKAS 的 4 层结构:Driver → ADAS ECU → EPS Actuator → Vehicle Dynamics。
画图准则:
- 节点是 controller / controlled process(动作的发出者和承接者),不是"硬件盒子"。
- 实线 = Control,虚线 = Feedback。每条线都要标"传的是什么(命令 / 状态)"。
- 每个 Controller 内部隐含一个 Process Model — 它对被控对象的"认知"。Hazard 经常来自 Process Model 与现实不符。
- 一开始可以粗(4-5 层),后续在感兴趣的 controller 内部再展开。
2.3 第三步:UCA 4 类提问
对每条 Control Action,系统化提 4 类 Unsafe Control Action:
- UCA-1 未给(Not Provided):该给却没给 — 车出车道时 ECU 不发纠偏 torque
- UCA-2 错给(Wrong/Unsafe Provided):给了错方向 — 车在车道中却发反向 torque
- UCA-3 时序错(Wrong Timing):给晚了 / 给早了 / 顺序错 — 驾驶员接管后 200 ms ECU 仍施力
- UCA-4 持续时长错(Stopped Too Soon / Applied Too Long):弯道中 torque 突然 = 0 → 车前轮回正冲出弯道
UCA 表是 STPA 第一份正式交付物,每行一条 UCA,关联 Hazard 编号,衍生一条 Safety Constraint(SC)。SC 直接进入需求规范(FSR / TSR),成为 ASIL 评级的对象。
2.4 第四步:Loss Scenario
每条 UCA 都要追问"它怎么发生的",答案归类为 5 类因果机制(STPA-2 的 Causal Factors):
- A. Controller 算法错 — 控制律 bug、阈值不当、Mode 状态机漏洞
- B. Sensor 输入错 — 传感器测量错、SOTIF 边界(雨/雾)、数据延迟
- C. Process Model 错 — controller 内部模型与实际不符("以为还在车道中")
- D. Feedback 不及时 / 缺失 — 通信 timeout、采样慢、FTTI 超限
- E. Actuator 故障 — EPS 电机损坏、PWM 输出失败
注意 A-D 都不是组件 fail — 这正是 STPA 的核心增量。每条 Scenario 派生一条缓解措施(SR),按因果类别可对应到不同的工程手段:MC/DC 单测对应 A,Sensor Fusion 对应 B,Plausibility check 对应 C,E2E + Timeout 对应 D,FMEDA + 双路对应 E。
3. STPA 与 HARA 串联
STPA 不替代 HARA,而是给 HARA 喂材料。完整流程:
| 阶段 | 工具 | 产物 | ISO 26262 锚点 |
|---|---|---|---|
| 找 hazard | STPA + 头脑风暴 | UCA / SC / Loss Scenario | Part 3-5(可选,SOTIF 必做) |
| 评级 | HARA | S × E × C → ASIL | Part 3-6 |
| 分配 | FSC | 每个 SG 分到子系统 | Part 3-7 |
| 实现 | HW + SW | FMEDA / FTA / DFA | Part 5 / 6 / 9 |
做 STPA 的判断标准:
- ISO 26262 Part 3 不强制要求 STPA — 单纯 HARA 也合规
- ISO 21448 SOTIF 把 STPA 列为推荐方法 — L2+ ADAS 实际上必做
- 涉及大量软件、人机交互、复杂系统状态时,只靠 HARA 漏 hazard 的概率高
工程组通常做法:Item Definition 后先 STPA 一遍找系统级 UCA,再用 UCA + 行业 hazard checklist 一起喂入 HARA 做 ASIL 评级。
4. 常见误区
实战 STPA 最常踩的几个坑都源自把方法学和已有思维(FMEA / 软件架构)混用。下面 5 条是最容易翻车的。
- STPA 不是替代 HARA。STPA 找的是"系统该不该做这个动作",HARA 评的是"这件事多危险"。两者输入输出不同。
- Control Structure 不是 software architecture diagram。前者按"动作流"分层,后者按"组件部署"分层。一份 SW 架构图通常对应多份 Control Structure。
- UCA 不是 Failure Mode。FMEA 的 failure mode 描述"组件如何坏",UCA 描述"控制器如何给错指令"。
- Process Model 是核心抽象。如果跳过 Process Model 直接列 UCA,会漏掉 Mode 混淆、状态错配等真实 hazard 来源。
- 不要在第一轮做完美。STPA 是迭代的:第一轮覆盖主干,后续每轮发现新 UCA 就补;评审周期 6-8 周(L3+ ADAS)是常见预算。
5. 工具与产物
STPA 没有官方"必用工具"——可以纯手工 Excel / Visio,也有专门工具:
- STAMP Workbench(MIT 开源)— 自动维护 UCA-Hazard-Scenario 链
- MathWorks System Composer(2022 起)— STPA 模块,与 Simulink 联动
- NTNU XSTAMPP(开源 Java)— 适合学术
- ANSYS Medini(企业级)— 与 FMEA / FTA 一体化
不论用哪种工具,核心交付物固定:
- Loss + System Hazard 表
- Control Structure 图(分层)
- UCA 表(Control Action × 4 类)
- Loss Scenario + Safety Constraint 表
深入 STAMP/STPA/CAST…
深入 STAMP/STPA/CAST 三件套关系 + UCA 4→14 sub-types 完整分类 + L3 Highway Pilot 5 层 Control Structure + Loss Scenario 5 类因落到具体 SC + STPA × ISO 26262 6 步整合 + STPA × SOTIF × 21434 三件套联合 → STPA 深度
6. L2 LKAS 端到端 STPA Worked Design
STPA 最难内化的环节是"UCA → Loss Scenario → Safety Constraint"这条完整链路——下面用一台典型 L2 LKAS(60–180 km/h)把 4 步流程走一遍,每个分析决策都给出工程理由。
6.1 Item Definition 摘要
Item Definition 是 STPA 的起点,它确定分析边界——包含什么、接什么接口、运行在什么模式。
| 字段 | 内容 |
|---|---|
| Item 名称 | L2 LKAS(Lane Keeping Assist System) |
| 功能 | 60–180 km/h 时,通过 EPS 叠加 ≤ 3.5 Nm 方向盘修正力矩,使车辆保持在当前车道内 |
| 传感器 | 单目摄像头 80 m 前视,30 fps,单帧延迟 ≤ 40 ms |
| 执行器 | 电动助力转向(EPS),ASIL D,最大叠加力矩 3.5 Nm(ECE R79 §5.4.6 上限) |
| 接口 | 上:驾驶员(方向盘力矩 / HMI 按键);下:EPS 控制器(CAN,10 ms 周期) |
| Driver Override | 驾驶员力矩 > 1.0 Nm 连续 100 ms → LKAS 立即停止叠加力矩 |
| 不含 | EPS 内部电机控制、车道变更辅助(LCA)、AEB |
6.2 Control Structure(4 层)
LKAS 的 Control Structure 按动作流分 4 层——每层是"动作发出者",而不是"硬件盒子"。
参考 §2.2 图(01-control-structure.svg)中的通用 LKAS 4 层图:
| 层 | Controller / Process | 关键 Control Action | 关键 Feedback |
|---|---|---|---|
| L1 | 驾驶员 | 方向盘输入力矩(手动);HMI 激活/停用 LKAS | 方向盘触感(EPS 叠加力)+ 仪表盘 LDW 警告 |
| L2 | LKAS ECU(ASIL B) | CA-1:向 EPS 发"叠加力矩指令 [±3.5 Nm]";CA-2:向 HMI 发"LDW 视觉 / 音频警告" | EPS 当前实际力矩 + 转向角(CAN);Camera 车道线检测结果 |
| L3 | EPS Controller(ASIL D) | 实际驱动电机产生物理力矩 | 方向盘角度 + 电机电流 |
| L4 | Vehicle Dynamics | — | 横向位移(GPS/IMU,闭环外观测) |
Process Model 关键字段(LKAS ECU 内部状态假设):驾驶员是否手在盘上 / 车道线是否可信 / EPS 是否处于正常工况。这三个 PM 字段是 UCA 的隐性来源。
6.3 UCA 表(5 条核心 UCA)
从 CA-1("向 EPS 发叠加力矩")这一条控制动作出发,按 4 类提问得出 5 条核心 UCA。
| UCA ID | 类型 | 不安全条件 | Hazard |
|---|---|---|---|
| UCA-L-1 | UCA-1(未给) | 车辆在 ≥ 60 km/h 向右漂移越过车道线时,LKAS 未输出修正力矩 | H-1(车辆出车道) |
| UCA-L-2 | UCA-2(错给) | 驾驶员正在执行合法超车换道时,LKAS 输出反向纠正力矩阻止换道 | H-2(LKAS 主动偏道) |
| UCA-L-3 | UCA-2(错给) | 检测到驾驶员 override(力矩 > 1.0 Nm)后,LKAS 仍继续叠加力矩 | H-3(控制冲突) |
| UCA-L-4 | UCA-4(持续过长) | override 检测后 > 200 ms LKAS 仍未将叠加力矩降至 0 | H-3(控制冲突) |
| UCA-L-5 | UCA-3(时序错) | 雾天摄像头失效时,LKAS 未及时停止力矩输出并发出警报 | H-1(车辆出车道) |
6.4 UCA-L-1 Loss Scenario 全链
UCA-L-1(应给纠正力矩但未给)是最高优先级——每条因果链都导向一条可验证的 Safety Constraint。
因果 A — 控制算法错:车道线检测算法在逆光(太阳低角)场景返回 confidence = 0,LKAS 算法判"无车道"→ 静默切换到 deactivate,未发 LDW 警报。
- Safety Constraint SC-A:LKAS ECU 检测到 camera confidence < 0.6 持续 ≥ 3 帧(≤ 100 ms @ 30fps)时,须先触发 LDW 警报(不得静默退出),并在警报触发后 50 ms 内将叠加力矩降至 0 Nm。
因果 B — Sensor 输入错:摄像头透镜泥泞遮挡,图像质量标志(IQ flag)= 0;但 LKAS ECU 的 Process Model 仍以为 sensor 可用。
- Safety Constraint SC-B:Camera 须每帧输出 IQ flag;LKAS 须在 IQ flag = 0 持续 ≥ 3 帧(≤ 100 ms @ 30fps)后,于检测后 50 ms 内完成强制退出并发 LDW 警报(检测 ≤ 100 ms + 动作 50 ms 须落在 SG-1 的 FTTI 200 ms 内)。
因果 C — Process Model 陈旧:驾驶员刚刚松手(hands-off),但 LKAS override 状态机的"has_hands_on"位尚未清零(超时 500 ms),LKAS 误以为驾驶员在修正、抑制自身输出。
- Safety Constraint SC-C:override 检测状态须在力矩 < 0.3 Nm 持续 ≤ 200 ms 后自动清零(Process Model 刷新周期 ≤ 200 ms)。
因果 D — Feedback 延迟:EPS CAN 帧丢包,LKAS ECU 超过 50 ms 未收到 EPS 反馈 → watchdog 超时,LKAS 复位,力矩命令清零。
- Safety Constraint SC-D:EPS CAN 心跳超时阈值须 ≤ 50 ms;LKAS 须在心跳超时后 50 ms 内触发 LDW 警报再退出(不超过 FTTI 链路总预算)。
因果 E — 执行器故障:EPS 进入降额模式(过流保护),可提供最大力矩 < 0.5 Nm;LKAS 发出 3.5 Nm 命令但 EPS 实际输出不足。
- Safety Constraint SC-E:LKAS ECU 须监测 EPS 的 max_torque_available 字段;若 < 1.0 Nm,则于检测后 30 ms 内退出 LKAS 并发 LDW 警报。
6.5 Safety Goal 推导 + FTTI 拆分
UCA-L-1 进入 HARA 评级,运行情境 = 高速公路高速巡航场景(E4 暴露:日常通勤 > 50% 时间在高速路)。
S/E/C 评分:
| 维度 | 评分 | 工程理由 |
|---|---|---|
| S | S3 | 90 km/h 车道偏离 → 对向车道或护栏碰撞,后果致命 |
| E | E4 | 高速公路通勤 > 50% 驾驶时间,参考 SAE J2980 OS 库 |
| C | C3 | L2 complacency 场景:司机主动放松注意力,反应时间 > 1.5 s,不足 90% 能及时接管 |
ASIL:S3/E4/C3 → ASIL D(分解前;来源:ISO 26262-3:2018 Table 4,SSOT 见 topic-hara §5.1)。实际 LKAS 通常做 ASIL 分解(ISO 26262-9)= ASIL B + ASIL B(Primary torque channel + Independent monitor channel)。
Safety Goal SG-1:L…
Safety Goal SG-1:LKAS 不得在 60–180 km/h 速度范围内导致车辆非预期横向偏离当前车道边界超过 FTTI = 200 ms。
- ASIL:D(分解前)→ 实现时 ASIL B+B
- Safe State:LKAS 停止叠加力矩 + LDW 警报激活
- FTTI:200 ms
FTTI 时序分配:
| 时序段 | 含义 | 典型分配 |
|---|---|---|
| tdetect | Camera / fusion 检测异常并上报 | ≤ 50 ms(1 帧延迟 ≤ 40 ms + 融合处理 ≤ 10 ms) |
| tsw | LKAS ECU 决策并发降力矩命令 | ≤ 30 ms(3 × 10 ms 任务周期) |
| teps | EPS 力矩从最大 → 0(电气 + 机械) | ≤ 80 ms(EPS 线圈放电 + 机械回弹;OEM 内部架构约束 ≤ 100 ms) |
| talert | LDW 警报并行触发 | ≤ 40 ms(与 teps 并行) |
| 合计 | tdetect + tsw + teps | ≤ 160 ms < 200 ms FTTI,裕量 40 ms |
STPA → HARA 的增量价值:传统 HARA 通常只列"LKAS 失效 → 车辆出道"这一条 hazard。STPA 在上游额外产出了 UCA-L-2(LKAS 阻止合法换道)和 UCA-L-3/L-4(override 冲突)这两类 HARA 难以自然发现的 hazard——它们对应 H-2 和 H-3,都会走进 HARA 形成独立 Safety Goal。
7. Gotcha(5 条 — 实战 STPA 高频陷阱)
实战 STPA 中有 5 个高频陷阱,大多数来自把 STPA 的概念与 FMEA 或软件架构分析的思维混用。
Gotcha-1:Control Action 颗粒度太细或太粗。工程师有时把 Control Action 拆到信号层("CAN 帧 ID 0x201 的 Byte 2 bit 3"),失去系统级视角;或者合并成"LKAS ECU 控制一切",无法做出有效 UCA。正确颗粒度:Control Action 是一个有意义的系统动作("向 EPS 发叠加力矩命令"),而不是信号定义。一般一个 L2 ADAS item 有 5-15 条 Control Action。
Gotcha-2:Control Structure 画成软件架构图。软件架构图展示模块 / 接口,Control Structure 展示"谁控制谁"。一个典型错误:把 RTOS 任务调度画进 Control Structure——RTOS 是实现机制,不是功能 Controller。把两张图混淆后 UCA 会混进大量实现细节,漏掉系统级 hazard。检验方法:每个节点应该能回答"它发出的 Control Action 影响谁的物理行为"。
Gotcha-3:Process Model 被跳过。许多工程师跳过 Process Model 直接列 UCA——这会漏掉"Mode 混淆"类 hazard。例如:LKAS ECU 的 Process Model 有一个"驾驶员是否在监视"的隐式状态假设;一旦 L2 complacency 打破这个假设,就产生 UCA-L-1 的因果 C。不写出 Process Model,就不会想到这条。修法:建 Control Structure 时,每个 Controller 节点旁写 2-3 条 Process Model 假设。
Gotcha-4:Safety Constraint 太模糊。Safety Constraint 写成"LKAS shall be safe when camera fails"——这是意图声明,不能验证。可验证的 SC 必须包含:主语 + 触发条件(量化)+ 动作 + 时间约束。例如 SC-B:"Camera IQ flag = 0 持续 ≥ 3 帧(≤ 100 ms @ 30fps)时,LKAS 须在 50 ms 内停止力矩输出并发 LDW 警报"。SC 质量直接决定后续 FSR 可测试性。
Gotcha-5:STPA 只做一次不更新。STPA 的 Control Structure 隐含了 Item Definition 的边界假设。一旦 Item Definition 变更(例如新增 V2X 通信接口 / 添加 L2.5 功能 / 扩展速度范围至 0–200 km/h),旧 STPA 失效——新接口带入新的 Control Action 和 Feedback 通路,新 UCA 随之出现。触发规则:Item Definition 任何变更 → 先评 STPA impact(5 分钟走一遍 Control Structure,问"有没有新的 CA 或 FB 路径"),再决定是否全局更新。
8. Corner(3 条 — 边界工况下 STPA 判断如何变化)
边界工况是 STPA 最容易被压缩掉的分析区域,但恰恰在这里隐藏了系统设计的真实假设。
Corner-1:Override 边界 — 松手后多久 LKAS 恢复。驾驶员临时接管方向盘(override,力矩 > 1.0 Nm)然后松手,LKAS 应在什么时候恢复施力?太快(< 500 ms)→ 驾驶员可能仍在微调,LKAS 干扰 = UCA-L-3;太慢(> 3 s)→ 驾驶员预期 LKAS 已恢复但没有 = UCA-L-1。STPA 要求在 Control Structure 的 Process Model 里显式定义"override 后恢复窗口"的状态机,而不是留给实现层"自行决定"。Leveson STPA Handbook §4.2 明确指出状态转换必须被 PM 建模。
Corner-2:高速匝道 — 车道弯曲半径超出相机标定。车道线以较小 radius(如 R=300 m 的高速匝道)弯曲时,单目相机的 80 m 前视范围内可能出现"车道线几乎平行于车身轴"的视觉退化,导致 lane model 的曲率估计误差增大。此时 LKAS 给出的纠正力矩方向可能与真实需要相反 = UCA-L-2 的一个特殊实例。这不是"组件 fail",而是 OS 边界超出 Process Model 的适用范围,HARA 通常不会主动找出这一条,STPA 通过检查"camera Process Model 的 operational domain"会发现。
Corner-3:多国法规差异 — FTTI 要求不同。ECE R79 §5.4.7 要求 LKAS 在驾驶员 override 后 ≤ T_op(通常 ≤ 3 s)内将叠加力矩降为 0;而某些 OEM 的 Safety Goal 对 FTTI 有更严格的内部要求(≤ 200 ms)。当 LKAS 作为 SEooC 出口到不同市场时,STPA 的 Safety Constraint(SC-D)中的时间约束必须能适配最严格的法规要求——Assumptions of Use(AoU)须声明"本品 FTTI ≤ 200 ms"以覆盖最严场景。如果 AoU 只写 ECE R79 的 3 s,则出口到要求更严的客户时 SG 不成立,需重新评 STPA。
核心要点
- STPA 把 hazard 重新定义为"controller 不当控制动作(UCA)",跳出"组件 fail"思维
- 44 % 危险失效源自需求阶段(HSE 数据),HARA 在这块弱;STPA 正好补
- 4 步流程:Loss / Hazard → Control Structure → UCA → Loss Scenario
- UCA 4 类:未给 / 错给 / 时序错 / 持续时长错;每条都要列出来
- Loss Scenario 5 类因果:Algorithm / Sensor / Process Model / Feedback / Actuator;A-D 都不是组件 fail
- STPA + HARA 串联:STPA 喂 hazard 给 HARA 做 ASIL 评级,不互相替代
- SOTIF / L3+ ADAS 必做 STPA;ISO 26262 不强制但强烈推荐
- Process Model 是核心抽象,Mode 混淆和状态错配是最容易漏的 hazard 类
- L2 LKAS Worked Design(§6):5 条 UCA、因果 A-E 全链、SC 可验证格式;UCA-L-1 → HARA S3/E4/C3 → ASIL D(分解前)→ 实现 ASIL B+B;FTTI 200 ms = tdetect(50) + tsw(30) + teps(80) ≤ 160 ms,裕量 40 ms
- STPA 增量价值:比传统 HARA brainstorm 多找 H-2(LKAS 阻止合法换道)/ H-3(override 冲突)这类需求/交互类 hazard
- 5 条 Gotcha:CA 颗粒度、CS 混架构图、跳过 PM、SC 太模糊、不更新
- 3 条 Corner:Override 恢复窗口状态机 / 高速匝道 camera domain 退化 / 多国法规 FTTI 差异影响 AoU
Cross-references
- ← 索引
- topic-functional-safety — 功能安全 hub
- topic-hara — HARA 流程(STPA 的下游);Table 4 SSOT
- topic-iso26262-part3-concept — Concept Phase
- topic-iso21448-sotif — SOTIF(STPA 主要应用场景)
- topic-failure-types — 随机 vs 系统性失效
- topic-can-e2e-secoc — 通信 hazard 的缓解
- topic-asil-decomposition — ASIL D → B+B 分解实现路径
- topic-stpa-hazard-analysis-deep — STAMP/CAST 三件套 + UCA 14 sub-types + L3 Highway Pilot 深度