STPA 深度 — STAMP/CAST 三件套 + UCA 14 类 + ISO 26262 整合

功能安全L2别名 STPA deep · STAMP · CAST · UCA 14 sub-types · Loss Scenario causal · STPA ISO 26262 integration · STPA SOTIF · L3 Highway Pilot STPA · Leveson Handbook 2018

本质与导读

本质 STPA 不替代 HARA,是它的上游 + 互补:先用 control structure 系统化追问 UCA(系统级 / 软件 / 人机交互 hazard),再交 HARA 评 ASIL,比传统 brainstorm 多挖 3-5 倍且有兜底。一份 STPA 输出可同时喂 ISO 26262 / SOTIF / ISO 21434 三套标准,省约 60% 重复工作。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. STAMP / STPA / CAST 三件套

工程师最容易混淆这三个名词 — 它们不是同一层级。STAMP 是世界观 framework,STPA / CAST 是它的两个实操工具:STPA 用于设计期"避免事故",CAST 用于事故后"分析根因"。下图把三者关系画清。

STAMP / STPA / CAST 三件套关系

1.1 STAMP — 世界观,不是方法

STAMP(System-Theoretic Accident Model and Process,Leveson 2004)给出一个根本假设转变:"事故 = 控制不足",而不是"事故 = 组件失效"。传统 FTA / FMEA 假设系统失效来自单个组件失效;STAMP 说很多事故根本没有组件 fail — 比如软件 bug + 系统状态错配,每个组件都"正常运作",但组合起来出 hazard。

1.2 STPA — 前向 / 设计期

STPA 用于产品开发阶段(系统架构 → HARA → FSC 这段),输出 Safety Constraint(可直接转成 ISO 26262 的 Safety Goal / FSR)。重点在"避免事故发生"。

1.3 CAST — 后向 / 事故后

CAST(Causal Analysis using System Theory)是 STAMP 的另一个工具 — 用于已发生事故的复盘。和 NTSB 传统的 "find root cause" 调查思路不同,CAST 关注 control structure 在事故发生时的退化路径(哪个 controller 给了 UCA、哪个 feedback 失效)。汽车行业 OTA 召回 + 事故调查越来越多用 CAST 替代传统根因分析。

来源:UL SIS — Intro to STAMP/STPA/CAST

2. UCA 4 类 → 14 sub-types

Shallow page 讲了 UCA 4 大类(未给 / 错给 / 时序错 / 持续错)—— 这 4 大类正是 Leveson 2018 Handbook 规范定义的全部(Handbook 原文只有 4 类,不含 "sub-type" 一词)。但实操中 4 大类太粗 — 一个 Highway Pilot 项目用 4 类提问会漏一半 UCA。本页据工程经验把 4 类进一步拆成 14 sub-types(practitioner 提问细化,非 Handbook 原文),这是工程组实际做 STPA 时的提问模板。

UCA 4 → 14 sub-types

2.1 14 sub-types 完整分类

14 sub-types 按时序分布:Not Providing 偏静态(action 没出现),Causes Hazard 偏语义(action 给错对象 / 错条件),Wrong Timing 偏时间(action 时机错),Stop/Duration 偏持续性(action 持续状态错):

① Not Providing(3 sub-types) — 1.1 完全不给 / 1.2 给但被压制 / 1.3 给但延迟到无效
② Providing Causes Hazard(4 sub-types) — 2.1 错条件下给 / 2.2 错对象给 / 2.3 错幅度(过/欠) / 2.4 错方向给
③ Wrong Timing/Order(3 sub-types) — 3.1 太早 / 3.2 太晚 / 3.3 顺序错
④ Stop/Duration(4 sub-types) — 4.1 持续过长 / 4.2 结束过早 / 4.3 未在条件解除时停 / 4.4 启停频繁震荡

2.2 AEB "刹车 = 0.8g" 控制动作的 4 类示例

用 Highway Pilot AEB 系统的"主动制动"控制动作示范 — 每类提问都对应一个真实的 fail mode:

① 不给 — 前方有突发障碍物,AEB 算法漏检 → 撞 — classifier 把行人识为路标
② 错条件 — 高速公路超车换道时 AEB 误激活 — 把旁侧并道车识为前方威胁
③ 太晚 — 检测到了但延迟 150ms → 制动距离不够 — sensor fusion 帧间延迟累积
④ 持续过长 — 障碍物已消失但 AEB 持续 → 后车追尾 — state machine 未收到 clear 信号

2.3 量化产出

一个 L3 Highway Pilot 项目 STPA 通常产 25-40 条有效 UCA(控制动作数 × 14 sub-types,但其中很多组合无意义需筛掉)。这是工程组配 1-2 个 STPA 专家 2-3 周的工作量。

3. L3 Highway Pilot 5 层 Control Structure

STPA 的 control structure 不是随便画的电路图 — 它有严格的画法约定:每个 controller 向下发 control action(实线箭头),向上接 feedback(虚线箭头),UCA 提问只针对实线箭头。L3 Highway Pilot 的标准画法是 5 层。

L3 Highway Pilot 分层 Control Structure

3.1 5 层的角色分工

5 层从上到下分别是:驾驶员(L3 可离开路面 ≤ 10s)→ Mission Planner(ASIL B,路径 + 变道 + TOR)→ Motion Controller(ASIL D,ACC + LKC + AEB)→ Actuators(brake / steering / drive)→ Vehicle + Environment。最上层向下发控制动作,逐层细化,最底层是被控对象。

3.2 关键画法 — Feedback 只能虚线

Control 实线 + Feedback 虚线不是美学,而是 UCA 提问规则:STPA 只对实线箭头提 14 类 UCA。Feedback 虚线另成一类问题(Inadequate Feedback,见 §4.3)。新手最常犯的错是把 feedback 画成实线 → UCA 表里出现大量伪 UCA。

3.3 ASIL 异构在 Control Structure 上的体现

Mission Planner 是 ASIL B(性能优先),Motion Controller 是 ASIL D(safety 优先) — 这对应 Primary-Secondary 的 asymmetric architecture(见 fail-operational-architecture-deep §2.2)。STPA 的 Control Structure 必须把 ASIL 异构画出来,因为不同 ASIL 的 UCA 后果不同。

4. Loss Scenario 5 类因果机制

每条 UCA 必须追溯到 5 类因果机制 — 这是 STPA 从"找 hazard"过渡到"设计安全机制"的关键步骤。Shallow page 只列了 5 类名字,deep page 给出具体例子和对应的 Safety Constraint(可直接转成 FSC / TSC 安全需求)。

Loss Scenario 5 类因果机制

4.1 五类因果机制 + 设计需求映射

以 UCA "AEB 不给制动(Cat ①)" 为例,5 类因果各自对应不同设计需求:

① Controller Algorithm 错 — classifier 把行人识为路标 → SC: classifier diverse + 异常 mode + rule-based 兜底
② Inadequate Inputs — camera 被雨水遮挡 → SC: multi-sensor fusion(camera + LiDAR + radar),单 sensor 失效不能让 UCA 触发
③ Process Model 错 — 认为已通过路口实际还没 → SC: GNSS + HD map + IMU 三源定位,交叉校验 process model 一致性
④ Inadequate Feedback — LiDAR 帧丢失 → SC: 心跳超时 + plausibility + ASIL D 通道,丢帧 → fallback ACC
⑤ Actuator 失效 — brake hydraulic 漏液 → SC: DREHB 3 层冗余 + plausibility 自检 + 单轮失效 3-wheel 仍能停(详见 fail-operational-architecture-deep §4)

4.2 SC → FSC / TSC 接入

每个 Safety Constraint 反向变成 FSC / TSC 里的具体安全需求,接入 ISO 26262 Part 3-4 流程。SC 的写法很重要 — 必须是 "系统不能 X" 的负向命题(可验证),而不是 "系统应该 Y" 的正向描述(难证伪)。

5. STPA × ISO 26262 — 6 步整合工作流

STPA 不替代 HARA — 它是 HARA 的前置步骤。Abdulkhaleq et al. 2017(arXiv 1703.03657)给出 fully-automated vehicle 的完整 6 步整合工作流,这是当前 L3+ ADAS 项目的标准做法。

STPA × ISO 26262 — 6 步整合工作流

5.1 6 步工作流

工作流分 STPA 侧(前期 / 系统级)+ ISO 26262 侧(后续 / V-Cycle),中间用"Bridge"环节把 STPA UCA 归一化为 ISO Hazard 形式:

① Define Loss + Hazard(STPA)— L1 = 人员死亡 / L2 = 车辆损坏 / ...
② Build Control Structure(STPA)— Driver → Planner → Motion → Actuator 5 层
③ Identify UCA(STPA)— 4 → 14 sub-types,每条 Control Action 系统化提问
④ Loss Scenario 5 类因(STPA)— 算法 / 输入 / Process Model / Feedback / Actuator
⑤ HARA — ASIL 评级(ISO 26262)— UCA + Hazard → S/E/C → ASIL
⑥ Safety Goal + FSC + TSC(ISO 26262)— Safety Constraint → 安全需求 → V&V test case

5.2 Bridge 环节 — UCA 怎么变 Hazard

STPA 的 UCA 表达是"X 给了不当 control action",ISO 26262 的 Hazard 表达是"系统出现 unintended 行为造成 harm"。Bridge 环节做格式归一:每条 UCA → 一个或多个 Hazard,然后进 HARA 走 S/E/C 评级。

5.3 Abdulkhaleq et al. 案例实际产出量

一个 fully-automated vehicle 项目用 STPA 找出:

Loss / Accident: 24 类
Hazard: 176 个
UCA: 27 条
Loss Scenario: 129 个

来源:arXiv 1703.03657 — Using STPA in Compliance with ISO 26262

系统化产出比传统 HARA brainstorm 多 3-5 倍 hazard,但提问质量更高 — 有 control structure 兜底,不会漏需求 / 软件 / 人机层 hazard。

6. STPA × SOTIF × ISO 21434 — L3+ 三件套联合用法

L3+ ADAS 必须同时跑 3 套标准:ISO 26262(组件失效)+ SOTIF / ISO 21448(性能不足)+ ISO 21434(网络安全)。如果各跑各的会有 60% 重复工作,Bosch / Continental 实操是一次 STPA 喂三套。

STPA × SOTIF × ISO 21434 — 三件套联合

6.1 三套标准从 STPA 各取什么

三套标准各自的 hazard 定义不同 — 26262 关注组件失效造成的 harm,SOTIF 关注没坏但性能不足,21434 关注被攻击触发的 hazard — 但都能在同一份 STPA 输出里找到对应映射:

ISO 26262 — 从 STPA 取 Loss Scenario 5 类因 → HARA,UCA → Safety Goal 候选,Control Structure → 系统架构
SOTIF (21448) — 从 STPA 取 Performance UCA,Triggering Condition,Loss Scenario ② 输入类
ISO 21434 — 从 STPA 取 UCA → Attack Vector,Feedback link → CAN 注入路径,Process Model → state spoof

6.2 三件套合并方法

实操中:一份 UCA 表 → 标 "FS / SOTIF / CS" 三栏,各自归类。同一条 UCA 可同时属于多套标准 — 比如"AEB 在错条件下激活"既是 ISO 26262 hazard(误激活造成 harm)又是 SOTIF hazard(传感器误识)还可能是 ISO 21434 hazard(攻击者注入伪信号)。

UCA 的 5 类 Loss Scenario 因子也天然覆盖三套:

FS 覆盖 ① 算法 / ② 输入 / ④ feedback / ⑤ actuator
SOTIF 覆盖 ② 输入 / ③ Process Model
CS 覆盖 ④ feedback / ③ Process Model

三个标准产生的 safety / performance / security constraint 落到同一份 TSC,节省 60% 重复工作。

来源:STPA + SOTIF — Applying STPA in the Context of SOTIF (ResearchGate 351348419)

7. 量产 STPA 工程实战 — 5 个反模式

L3+ 项目反复栽在以下 5 个 STPA 反模式 — 都是工程组以为做了 STPA 但其实白做。

反模式	真相	评审会拒的话术
Control Structure 画成系统框图	缺乏 control action / feedback 区分	实线箭头都是什么 control action? feedback 在哪?
UCA 提问停在 4 大类、不做工程细化	每条 Control Action 只问一遍 4 类,漏掉错对象 / 错幅度 / 启停震荡等具体 fail mode	每条 Control Action 的 sub-type 级提问展开在哪?
Loss Scenario 不到 5 类	只列 controller algorithm 一种因	输入 / process model / feedback / actuator 4 类怎么覆盖?
Safety Constraint 写成正向命题	"系统应该 X" 难证伪	SC 必须是负向 — "系统不能 X"
STPA 与 HARA 平行做	没整合,各自走各的流程	UCA 怎么进 HARA? Bridge 环节在哪?

评审红线 STPA 输出没有指向 H…

评审红线 STPA 输出没有指向 HARA + FSC + V&V test case 的 cross-ref = 必被打回。STPA 不是独立交付物 — 是 V-Cycle 上游的输入。

8. 与其它 Part 关联

STPA 处于 V-Cycle 的最上游,跨越多个 ISO 26262 Part:

Part 3 (HARA) — STPA UCA + Loss Scenario 是 HARA 的 hazard 输入
Part 3 (FSC) — Safety Constraint 直接转 FSC 里的 Safety Goal / FSR
Part 4 (System / TSC) — Control Structure 落到系统架构,TSC 接 SC
Part 6 (Software) — UCA 的 Controller Algorithm 因 → 软件设计要求
Part 9 §7 (DFA) — Loss Scenario ⑤ Actuator + ④ Feedback 因 → 共因失效分析
ISO 21448 (SOTIF) — Performance UCA + Triggering Condition 直接喂 SOTIF
ISO 21434 (Cybersecurity) — UCA → Attack Vector,Feedback → 注入路径

核心要点

STAMP / STPA / CAST 三件套 — STAMP 是世界观 framework,STPA 是前向(设计期)方法,CAST 是后向(事故后)方法
UCA 4 → 14 sub-types — Leveson 2018 Handbook 规范只定义 4 大类;14 sub-types(Not Providing 3 + Causes Hazard 4 + Wrong Timing 3 + Stop/Duration 4)是本页 practitioner 提问细化(非 Handbook 原文),工程实操按 control action × 14 sub-types 提问
L3 Highway Pilot 5 层 Control Structure — Driver → Mission Planner(ASIL B)→ Motion Controller(ASIL D)→ Actuators → Vehicle
画法严格规则 — Control 实线 + Feedback 虚线,UCA 只对实线箭头提问
Loss Scenario 5 类因果 — Controller Algorithm / Inadequate Inputs / Process Model / Feedback / Actuator,每类对应不同 Safety Constraint
Safety Constraint 必须是负向命题 — "系统不能 X" 而不是 "系统应该 Y",可验证
STPA + ISO 26262 6 步整合 — STPA 4 步(Loss → CS → UCA → Scenario)+ Bridge + ISO 3 步(HARA → FSC → V&V),Abdulkhaleq et al. 2017(arXiv 1703.03657)案例产出 24 accidents / 176 hazards / 27 UCA / 129 scenarios
STPA × SOTIF × ISO 21434 — 一份 UCA 表标 FS/SOTIF/CS 三栏,5 类 Loss Scenario 因自然覆盖三套标准,省 60% 重复工作
STPA 不替代 HARA — STPA 是 HARA 的上游 + 互补,先 STPA 找 UCA,再 HARA 评级 ASIL

缩写表

只列本页用到的工业标准缩写;通用英语…

只列本页用到的工业标准缩写;通用英语 / 单位 / 月份 / 我们的 层/Lx tag 不列。覆盖不到的术语见正文 inline 注释。

缩写	全称	中文 / 备注
ISO	International Organization for Standardization	国际标准化组织
UL	Underwriters Laboratories	美国保险商实验室
HARA	Hazard Analysis and Risk Assessment	危害分析与风险评估,part 3
ASIL	Automotive Safety Integrity Level	ISO 26262 安全完整性等级 QM→A→B→C→D
FTA	Fault Tree Analysis	故障树分析
FMEA	Failure Mode and Effects Analysis	失效模式与影响分析
FSC	Functional Safety Concept	功能安全概念(part 3)
FSR	Functional Safety Requirement	功能安全需求
TSC	Technical Safety Concept	技术安全概念(part 4)
CAN	Controller Area Network	控制器局域网
DFA	Dependent Failure Analysis	相关失效分析(ISO 26262-9)

Cross-references

← 索引
STPA 入门(浅) — 4 步基本流程
HARA 危害分析 — ASIL 评级下游
Fail-Operational Architecture 深度 — Loss Scenario ⑤ Actuator 缓解策略
共因失效 CCF 深度 — Loss Scenario ④ Feedback + ⑤ Actuator 共因分析
ISO 21448 SOTIF 深度 — Performance UCA 上游
ISO 21434 Cybersecurity 深度 — Attack Vector 上游
功能安全工程师指南 hub — V-cycle + 全栈