STPA — 系统理论危害分析(HARA 的互补方法)

功能安全L3别名 STPA · System-Theoretic Process Analysis · UCA · Loss Scenario · Leveson · 系统理论危害分析

本质与导读

本质: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 给出了不安全的控制动作"。这种视角天然涵盖软件、人机和系统级问题。

HARA vs STPA — 两套互补的危害分析框架

2. STPA 4 步流程

STPA 把"找 hazard"拆成 4 步可复现的工作流。每步产出一张表,逐步细化:Loss → Hazard → UCA → Loss Scenario → Safety Constraint。

步骤输入工作输出
① 定义 Loss + Hazard项目目标列"绝对不能发生"的 Loss + 把 Loss 映射成 System-level HazardLoss / Hazard 列表
② 画 Control Structure系统架构把系统画成分层 Controller-Controlled-Process,标 Control / Feedback 箭头Control Structure 图
③ 找 UCAControl Structure对每条 Control Action 系统化提 4 类 UCAUCA 表
④ Loss ScenarioUCA + 系统模型对每条 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。

Control Structure — LKAS 4 层结构示例

画图准则:

  • 节点是 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 4 类提问 + 表格交付物

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 输出失败

Loss Scenario — UCA-1 的 5 类因果链

注意 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 锚点
找 hazardSTPA + 头脑风暴UCA / SC / Loss ScenarioPart 3-5(可选,SOTIF 必做)
评级HARAS × E × C → ASILPart 3-6
分配FSC每个 SG 分到子系统Part 3-7
实现HW + SWFMEDA / FTA / DFAPart 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 一体化

不论用哪种工具,核心交付物固定:

  1. Loss + System Hazard 表
  2. Control Structure 图(分层)
  3. UCA 表(Control Action × 4 类)
  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 深度

核心要点
  • STPA 把 hazard 重新定义为 controller 不当控制,跳出"组件 fail"思维。
  • 44 % 危险失效源自需求阶段(HSE 数据),HARA 在这块弱;STPA 正好补。
  • 4 步流程:Loss / Hazard → Control Structure → UCA → Loss Scenario。
  • UCA 4 类:未给 / 错给 / 时序错 / 持续时长错。每条都要列出来。
  • Loss Scenario 5 类因果:Algorithm / Sensor / Process Model / Feedback / Actuator。
  • STPA + HARA 串联:STPA 喂 hazard 给 HARA 做 ASIL 评级,不互相替代。
  • SOTIF / L3+ ADAS 必做 STPA;ISO 26262 不强制但强烈推荐。
  • Process Model 是核心抽象,Mode 混淆和状态错配是最容易漏的 hazard 类。

Cross-references