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 · 更新 2026-07-10

本质与导读

本质 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.1 的 ④ 类因)。新手最常犯的错是把 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 整合工作流

STPA 不替代 HARA — 它是 HARA 的前置步骤。Abdulkhaleq et al. 2017(arXiv 1703.03657)给出 fully-automated vehicle 的完整 STPA↔ISO 26262 整合工作流,这是当前 L3+ ADAS 项目的标准做法。工作流是 STPA 侧 4 步 + ISO 26262 侧 4 步,中间靠 Bridge 环节衔接(下图 8 个方框)。

STPA × ISO 26262 整合工作流

5.1 STPA 4 步 + ISO 4 步

工作流分 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 → 安全需求
⑦ HW + SW 设计 + FMEDA(ISO 26262)— 满足 Safety Constraint
⑧ V&V + Validation(ISO 26262)— 每条 SC 必有 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. 案例实际产出量

Continental 的 fully-automated vehicle 项目用 STPA 找出(arXiv 1703.03657 原文实测数字):

System-level Accident / Loss: 24 类
Hazard: 176 个
UCA: 27 条
Unsafe 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,据 Tier-1(Bosch / Continental)工程组实操经验估计可省约 60% 重复工作(共享 Loss/Hazard/Control Structure 三份底稿)。

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

7. L3 Highway Pilot AEB 端到端 STPA Worked Design

前 6 节把 STPA 方法拆开讲,这一节用一台真实级别的 L3 Highway Pilot(对标 Mercedes-Benz DRIVE PILOT — 全球首个 UN R157 认证的 SAE L3 量产系统)把"控制动作 → UCA → Loss Scenario → Safety Constraint → Safety Goal"整链走一遍。聚焦纵向紧急制动(AEB),与浅页 §6 的 L2 LKAS 横向 worked design 互补(一横一纵)。

7.1 Item + 真实传感器 / 执行器配置

Worked design 的起点是 Item Definition 加真实器件清单——器件的物理参数(探测距离 / 帧率 / 冗余)直接决定后面 UCA 与 FTTI 预算能否成立。

项	配置(对标量产 L3)
Item / ODD	L3 Highway Pilot,Autobahn 拥堵 / 巡航 ≤ 95 km/h(UN R157;DRIVE PILOT 2024 上限)
主雷达	Continental ARS540 4D imaging radar:77 GHz,探测 300 m,±60° FoV,range/doppler/azimuth/elevation 四维
LiDAR	Valeo SCALA 2:tire-debris 级目标探测约 80 m
相机	前视多功能相机(车道线 + 目标分类)
制动	冗余制动(主 + 备通道,fail-operational);AEB 减速上限 0.8g ≈ 7.85 m/s²
冗余	冗余转向 + 冗余电源网(DRIVE PILOT 架构)
分析对象	Motion Controller(ASIL D)→ 制动执行器的控制动作 "AEB 紧急制动"

7.2 CA "AEB 紧急制动" 的 5 条核心 UCA

从这一条控制动作出发,按 §2 的 4 类(细化到 14 sub-types)系统提问,得 5 条高优先 UCA——每条关联一个 Hazard 并标出对应 sub-type。

UCA ID	类型(sub-type)	不安全条件	Hazard
UCA-A1	① 不给(1.1)	前车急 cut-in、TTC < 1.5 s,融合已检出,Motion Controller 未发制动	H(追尾)
UCA-A2	② 错条件(2.1)	巡航中把龙门架 / 井盖等高处静止金属误判为障碍 → ghost braking	H(后车追尾)
UCA-A3	③ 太晚(3.2)	检出但决策 + 建压延迟超 FTTI,制动距离不足	H(追尾)
UCA-A4	④ 持续过长(4.3)	误检目标已消失但制动持续未解除	H(后车追尾)
UCA-A5	③ 时序错(3.3)	TOR 后驾驶员已接管加速超车,AEB 仍按旧 process model 触发	H(控制冲突)

UCA-A2(ghost braking)与 UCA-A1(漏检)是同一 CA 的精度 / 召回两难——300 m 雷达探距远大于 95 km/h 的约 52 m 需求停距(见 §7.4),所以物理探测不是瓶颈,"该刹 vs 不该刹"的判定阈值才是核心矛盾。

7.3 UCA-A1 的 Loss Scenario 5 类因 + 可验证 SC

UCA-A1(该给紧急制动却没给)优先级最高。按 §4 的 5 类因逐项追溯,每类落一条负向、可验证的 Safety Constraint。

① 算法 — 融合分类器把 cut-in 车的 confidence 压在阈值下,判"无有效目标"。SC-A1:融合置信度低于阈值、但 radar 与 LiDAR 任一给出 TTC < 1.5 s 时,系统不得抑制制动请求(禁止单一传感器 veto)。
② 输入 — 逆光 + 雨,相机分类退化,radar 单通道。SC-A2:AEB 触发判定不得依赖单一传感器;ARS540 radar 与 SCALA 2 LiDAR 至少一路给出有效目标即须进入制动决策。
③ Process Model — 认为 cut-in 车仍在邻道、实际已并入本道。SC-A3:本车道占用判定须由横向位置 + 航向 + 车道线三源交叉校验,PM 刷新周期 ≤ 40 ms。
④ Feedback — radar / LiDAR 帧超时,Motion Controller 目标列表陈旧。SC-A4:感知帧心跳超时阈值 ≤ 60 ms;超时即降级到冗余感知 + 降速,不得静默维持旧目标。
⑤ Actuator — 冗余制动主通道故障,实际减速小于命令值。SC-A5:主制动通道失效须在 ≤ 30 ms 内切至备通道,备通道至少保证 0.4g 减速(≥ MRM 需求)。

7.4 Safety Goal + FTTI 预算(数字代入)

UCA-A1 进 HARA:场景 = 95 km/h Autobahn 巡航(E4),后果 = 高速追尾致命(S3),L3 complacency 下驾驶员 eyes-off、接管慢(C3)→ ASIL D(分解前;来源 ISO 26262-3:2018 Table 4,SSOT 见 topic-hara §5.1)。

Safety Goal SG-A:L…

Safety Goal SG-A:L3 Highway Pilot 在 ODD 内不得因未及时紧急制动导致本车与前车碰撞。

ASIL:D(分解前)→ 实现时 ASIL B(D) 冗余(主制动 + 独立监控)

Safe State:完成紧急制动至安全距离;若感知失效则 TOR + MRM

FTTI:≤ 300 ms(制动链路)

制动物理量代入(v = 95 km/h = 26.4 m/s,a = 0.8g = 7.85 m/s²):

量	计算	值
满减速停距	$v^{2} / (2 a) = 26. 4^{2} / (2 \times 7.85)$	44.4 m
每 100 ms 系统时延多走	$0.1 \times 26.4$	2.64 m
FTTI 反应距离(300 ms 预算)	$0.3 \times 26.4$	7.9 m
总需求距离	$7.9 + 44.4$	≈ 52 m ≪ 300 m 雷达探距

FTTI 时序分配(典型):tdetect ≤ 80 ms(1 帧感知融合)+ tdecide ≤ 40 ms(ASIL D,4 × 10 ms 任务周期)+ tbrake ≤ 180 ms(液压 / 机电建压 0 → 满减速)= ≤ 300 ms。因 tbrake 是链路里最大的一段,SC-A5 的备通道切换预算(≤ 30 ms)必须叠在 tbrake 之前,不能吃掉制动建压时间。

关键区分:UN R157 的 MRM 减速度 ≤ 4 m/s²(≈ 0.41g,受控舒适停车),与 AEB 紧急制动 0.8g 是两条不同 control action、两套 UCA——把 MRM 上限当作 AEB 上限会人为削弱避撞能力(见 §8 反模式)。

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

L3+ 项目反复栽在以下 7 个 STPA 反模式 — 都是工程组以为做了 STPA 但其实白做。前 5 条是通用反模式,后 2 条是 L3 深度整合特有。

反模式	真相	评审会拒的话术
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 环节在哪?
把 MRM 减速度(≤ 4 m/s²)当 AEB 制动上限	MRM 是受控舒适停车,AEB 是紧急避撞(约 0.8g),两条不同 control action	AEB 减速上限凭什么等于 MRM? 两条 CA 的 UCA 分开做了吗?
FS / SOTIF / CS 三标各跑各的 STPA	三份 UCA 表互不一致 + 约 60% 重复工作	一份 UCA 表标三栏了吗? 为何重复画三次 control structure?

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

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

9. Corner(3 条 — L3 边界工况下 STPA 判断如何变化)

边界工况最容易在 STPA 里被压缩掉,但 L3 的真实假设恰恰藏在这里。以下 3 条是 L3 Highway Pilot 特有、浅页 L2 worked design 覆盖不到的。

Corner-1:TOR 后 10 s 接管窗口内"谁是 controller"。UN R157 规定发出 transition demand(TOR)后须给驾驶员至少 10 s接管窗口,期间系统仍负全责。这 10 s 里 control structure 处于双 controller 叠加态——驾驶员与 Motion Controller 都可能发出控制动作。STPA 必须把这个过渡态显式建模:谁的 CA 优先? Process Model 里"driver has taken over"位何时置位? 不建模就会漏掉 UCA-A5(接管后 AEB 仍触发)这类冲突。这不是实现细节,而是 control structure 的一个独立状态。

Corner-2:4D imaging radar 的 elevation 维在远距退化。传统 3D radar 无高度分辨,靠算法把龙门架 / 交通标志牌等高处静止金属滤掉(代价:偶尔误刹);ARS540 这类 4D radar 有 elevation 维,理论上能区分"路面障碍 vs 高处结构",但在 300 m 远距 elevation 角分辨力下降、标定误差放大——ghost braking(UCA-A2)与漏检(UCA-A1)的边界随距离移动。STPA 要求把"传感器 operational domain(距离 × 角分辨)"写进 Process Model,而不是假设 4D radar 在全距离都可信。

Corner-3:MRM 这个"safe state"本身可能是新 hazard 源。UN R157 允许 MRM 在本车道内减速停车(≤ 4 m/s²)。但 STPA 的纪律是 safe state ≠ 绝对安全——在隧道、施工区、匝道汇入点本车道停车本身会导向追尾 / 二次事故。所以 MRM 触发("进入最小风险状态")本身是一条 control action,要对它再跑一轮 UCA(何时给 / 错条件给 / 停太久)。把 safe state 当分析终点、不再对它提 UCA,是 L3 STPA 的高频漏项。

10. 与其它 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 整合 — STPA 4 步(Loss → CS → UCA → Scenario)+ Bridge + ISO 4 步(HARA → SG/FSC/TSC → HW/SW+FMEDA → V&V),Abdulkhaleq et al. 2017(arXiv 1703.03657)Continental 案例产出 24 accidents / 176 hazards / 27 UCA / 129 unsafe scenarios
STPA × SOTIF × ISO 21434 — 一份 UCA 表标 FS/SOTIF/CS 三栏,5 类 Loss Scenario 因自然覆盖三套标准,实操估省约 60% 重复工作
STPA 不替代 HARA — STPA 是 HARA 的上游 + 互补,先 STPA 找 UCA,再 HARA 评级 ASIL
L3 AEB Worked Design(§7) — 对标 DRIVE PILOT / UN R157;真实器件 ARS540(77 GHz/300 m/4D)+ SCALA 2;5 条 UCA、Loss Scenario 5 因落可验证 SC;SG-A ASIL D;95 km/h 0.8g 停距 44.4 m ≪ 300 m 探距,FTTI ≤ 300 ms = tdetect(80)+tdecide(40)+tbrake(180)
7 条反模式(§8)— 通用 5 条 + L3 特有 2 条(MRM≠AEB 减速上限、三标别各跑各的)
3 条 Corner(§9)— TOR 10 s 双 controller 叠加态 / 4D radar elevation 远距退化 / MRM safe state 需再跑一轮 UCA

缩写表

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

只列本页用到的工业标准缩写;通用英语 / 单位 / 月份 / 我们的 层/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)
ALKS	Automated Lane Keeping System	自动车道保持系统(UN R157 定义的 L3 类别)
AEB	Autonomous Emergency Braking	自动紧急制动
TOR	Take-Over Request	接管请求(L3 → 驾驶员)
MRM	Minimum Risk Maneuver	最小风险策略(TOR 未响应时的自动降级)
ODD	Operational Design Domain	运行设计域
FTTI	Fault-Tolerant Time Interval	故障容错时间间隔
TTC	Time To Collision	碰撞时间
SOTIF	Safety Of The Intended Functionality	预期功能安全(ISO 21448)

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 + 全栈