Event-Tree Risk Evaluation 深度
本质与导读
本质 Event tree risk evaluation 不是从元件失效开始画树,而是在 scenario 和 initiating event 已经定义之后,逐个检查 barrier 成功或失败会把系统带到哪个 damage state。它把 FTA / FMEA / FMEDA 给出的概率、工程后果估值和预先约定的 acceptance gate 接成一条决策链:哪些风险必须改设计,哪些要管理层接受,哪些可以记录为 residual risk。
主线坐标:横轨 · 功能安全(跨站) · Bahr-style PRA / risk evaluation。
学习目标
读完本页后,你应该能把 Bahr 第 13-14 章里的 probabilistic risk assessment 流程转成汽车 E/E 项目的 event-tree 评估产物。
- 解释 risk triplet: scenario、probability / frequency、consequence。
- 说明 event tree 为什么从 scenario / initiating event 之后开始,而不是替代 HARA、FTA 或 FMEA。
- 把 barrier、success / failure branch、damage state、consequence valuation 和 risk expectation 连成同一张表。
- 判断 FTA、FMEA、FMEDA、HRA 和现场数据分别能给 event tree 提供哪类概率。
- 解释为什么应在 event-tree 层按 risk contribution 剪枝,而不是只按输入故障概率剪枝。
- 用 risk profile 和 decision matrix 做 accept / reject / modify 的残余风险门控。
- 把方法映射到 HV charging、traction inverter、ADAS/L3、生产维护 hazard 和 safety case residual risk。
1. 风险三元组
Bahr 在第 13 章引用 Kaplan 和 Garrick 的风险定义,把风险问题压成三个问题:会发生什么场景、它有多可能、如果发生后果是什么。工程上可以把它写成三元组,而不是一个孤立颜色或一个孤立 FIT 数。
| 三元组元素 | Bahr-style 问题 | 汽车 E/E 写法 |
|---|---|---|
| Scenario | 什么会偏离正常任务并造成 hazard exposure | HV 充电插枪状态下接触器误闭合、主驱意外正扭矩、L3 横向控制误保持 |
| Probability / frequency | 这个场景或分支路径多常出现 | initiating event 频率、barrier fail probability、demand rate、field rate |
| Consequence | 该路径终止在哪个 damage state | 人员伤害、车辆损坏、任务中断、法规不符合、召回成本 |
常见的简化式是 $R = P \cdot C$,但它只表达期望损失的一个切面。Bahr 的重点是:同一数值风险在自愿性、可控性、新技术、灾难性、公众理解程度不同的语境下,接受门槛可能不同。因此 event tree 的输出不应只停在一个期望值,还要进入 risk profile 和 decision matrix。
1.1 不要从数字开始
Chapter 13 的风险评估流程先定义 objectives、scope、damage states 和 system boundary,再进入 initiating event 和 event tree。这个顺序对汽车项目很关键:如果 damage state 没定义清楚,同一条分支到底是 "critical" 还是 "catastrophic" 会在评审时被重新解释;如果系统边界漏掉维修、生产测试或 OTA,后面的概率再精细也只是在错误范围内精确。
风险三元组还迫使团队把 HARA 与 PRA 区分开。HARA 给出 hazard、operational situation、ASIL 和 safety goal;PRA / event tree 进一步问:给定这个 initiating event 已经出现,哪些 barrier 会成功或失败,每条路径最终贡献多少风险。
2. Event tree 的入口
Event tree 的入口不是 "某个电阻失效",而是一个已经被定义和量化的 initiating event。Bahr 在 Chapter 14 先要求识别 accident scenarios and initiating events,再进入 event trees,因为 event tree 研究的是系统对一个触发事件的响应和后果展开。
2.1 Scenario 先于 initiating event
Scenario 是要管理的危险故事,initiating event 是把系统从正常任务推离的触发。比如 "HV 充电中人员触电" 是 scenario,而 "连接器锁止信号 stuck high 导致充电允许误判" 可以是一个 initiating event。一个 scenario 可以有多个 initiating event,每个 initiating event 通常需要一棵 event tree。
这也是 event tree 与 FTA 的分工。FTA 可以把 "连接器锁止误判" 这个顶事件向下拆成传感器 stuck、线束短路、MCU 输入诊断漏检和软件条件错误;event tree 则从这个顶事件已经发生开始,检查后续 barrier 是否阻止或缓解触电后果。
2.2 Barrier 是路径节点
Barrier 可以是预防型,也可以是缓解型。预防型 barrier 试图阻止 initiating event 发展成 hazard exposure,例如互锁、冗余判据、状态机 inhibit、继电器粘连诊断;缓解型 barrier 在暴露已经开始后降低后果,例如降扭、主动放电、机械制动、报警和维修隔离程序。
每个 barrier 在 event tree 里变成 success / failure 分支。分支概率可以来自 FTA 顶事件概率、FMEDA 的 residual failure rate、FMEA 的失效模式频度、HRA 的人误概率、试验统计或现场数据。关键是记录概率来源和适用条件,不要把不同 duty cycle、环境或 demand 频率的数直接混用。
3. FTA / FMEA / FMEDA 如何供数
Bahr 明确把 Chapters 5-9 的安全分析工具放在 PRA 前段:hazard analysis 找 scenario,FMEA 找组件触发,Fault tree 给 initiating event 或 barrier breach 的概率。Event tree 本身不替代这些工具,它是把它们的概率结果接到后果路径上的汇流器。
| 输入工具 | 给 event tree 的数据 | 典型误用 |
|---|---|---|
| HARA / PHA | scenario、damage state、需要关注的 exposure | 直接把 ASIL 当成概率 |
| FTA | initiating event probability、barrier fail probability、minimal cut set | 只按低概率 cut set 剪掉高后果路径 |
| FMEA / FMEDA | component failure mode、FIT、diagnostic coverage、residual rate | 把元件 FIT 直接等同于场景频率 |
| HRA / task analysis | 操作失误、维修漏检、响应失败概率 | 把培训当成高置信硬件 barrier |
| Test / field data | demand rate、diagnostic detection rate、repair interval | 忽略样本量和运行环境差异 |
3.1 Initiating probability 与 barrier probability 不同
Initiating event probability 描述 "这棵树为什么被触发"。Barrier probability 描述 "触发后某层控制是否成功"。两者混淆会造成双算或漏算:如果 FTA 顶事件已经把互锁失效包含进去,再在 event tree 中把同一个互锁作为 barrier failure 乘一次,结果会过度保守;如果 FTA 顶事件没包含互锁,但 event tree 又默认 barrier success probability 为 1,结果会漏掉真实残余风险。
汽车项目里建议给每个概率标上角色: IE-P、B1-F、B2-F、C-Value。评审时先检查角色是否重复,再检查数值大小。
3.2 最小割集只控制入口数量
Bahr 提醒可以用 FTA minimal cut set 减少 initiating events,但不能只按 cut set 概率在输入端粗暴剪枝。低概率 cut set 若连接到高后果 damage state,其 risk expectation 可能超过高概率低后果路径。
更稳妥的顺序是:先把重要 initiating event 接成 event tree,计算每个 terminal branch 的概率与后果,再按 total risk contribution 剪枝。这样保留的是 "对决策有影响的路径",不是 "概率看起来大的路径"。
4. Damage state 与 consequence valuation
Event tree 的每条 terminal branch 都要落到 damage state。Bahr 的示例使用 catastrophic、critical、minor、negligible 这类等级,但同时强调必须在本项目里定义清楚这些词到底代表什么。
4.1 Damage state 要可审计
Damage state 不能只写 "严重"。它应同时说明人员、环境、设备、任务和业务影响的边界。汽车项目里,同一个 HV fault 可能有不同终态:无伤害但充电中断、维修人员轻伤、车辆热事件、充电桩损坏、法规事件或召回触发。
| Damage state | 汽车 E/E 例子 | 估值口径 |
|---|---|---|
| Catastrophic | 高速 L3 误控制导致不可控碰撞、HV 暴露导致死亡 | 人身伤亡、法规、召回和品牌影响 |
| Critical | 热事件、严重伤害、车辆失去关键控制 | 医疗、维修、停驶、索赔 |
| Minor | 功能降级、单次任务失败、可恢复损坏 | 保修、拖车、客户补偿 |
| Negligible | 诊断告警、短时不可用、无安全暴露 | 维修工时、可用性损失 |
4.2 期望风险不是唯一输出
对每条分支,可以计算期望风险:
其中 $p$ 是 terminal branch probability,$V$ 是该 damage state 的 consequence value。$V$ 可以是美元、人员伤害权重、停线小时、任务损失或合规惩罚。Bahr 的重点不是强迫所有后果都货币化,而是要求在同一评估内使用一致的 consequence valuation,让路径之间可以比较。
期望值要配合 profile 看。一个低频高后果路径和一个高频低后果路径可能有接近的期望值,但前者通常需要更高层级的 acceptance authority,也更可能触发法规、公众和安全案例关注。
5. Risk profile 与剪枝
Risk profile 是把 event tree 的 terminal branches 投到可视化比较空间。Bahr 建议至少看两类 profile:frequency versus damage state,以及 frequency versus dollars-at-risk / risk expectation。它们用于回答 "哪些路径值得改设计",不是证明一个绝对数字永远正确。
5.1 在 event-tree 层剪枝
只看输入概率会误导。假设路径 A 的概率是 $10^{-6}$,后果价值是 $10^8$;路径 B 的概率是 $10^{-3}$,后果价值是 $10^3$。路径 A 的期望风险是 $100$,路径 B 是 $1$。如果因为 A 的概率小而在 FTA 输入端删掉,就删掉了真正支配风险的路径。
Event-tree 层剪枝应至少满足三条规则:先算 terminal branch risk contribution;记录被剪枝路径的后果上界;对 catastrophic / high-severity branch 设置单独保留门槛。这样剪枝是为决策降复杂度,不是为降低报告里的风险数字。
5.2 风险数只用于相对比较
Bahr 反复提醒风险数字不应被当成绝对真值。实际概率有数据来源、环境修正、专家判断和模型不确定性;后果估值也有法律、品牌、公众和任务口径差异。工程上更可靠的表达是 "方案 B 相比方案 A 降低主导路径约一个数量级",而不是 "本系统风险精确等于某个小数"。
这对 automotive safety case 很有用。PRA 结果可以支持 residual risk argument,但不能替代需求验证、独立性分析和现场监控。安全案例里应写清 risk profile 的 assumptions、data source、uncertainty 和 acceptance authority。
6. Decision matrix 与 acceptance gate
Chapter 14 的最后一步是把 risk profile 进入 risk management matrix 和 risk decision matrix。矩阵必须在分析前定义,否则团队很容易在看到结果后移动门槛。
| Gate | 工程含义 | 汽车项目动作 |
|---|---|---|
| Unacceptable | 高后果或高频路径不能保留 | 改设计、暂停发布、冻结 SOP 或禁止作业 |
| Undesirable | 风险不能自然关闭,但可由高层权衡 | 制定 mitigation plan,需要 safety manager / chief engineer 接受 |
| Acceptable with review | 残余风险可接受,但要留证据和监控 | 进入 safety case residual risk,设置 field monitoring |
| Acceptable | 对当前 scope 无需额外动作 | 记录依据,变更时重开评估 |
6.1 Gate 要连接 owner
Acceptance gate 不是颜色。每个 gate 都要对应 owner、证据要求、升级路径和关闭条件。比如 "Undesirable" 不能只写黄色,应写成:需要功能安全经理和项目总工共同接受;必须有 mitigation plan、验证计划、生产和售后限制;下一次设计变更或 field incident 后重评。
对 ISO 26262 交付物,这个 gate 可以成为 safety case 的 residual risk 表。HARA 给出 SG 和 ASIL,FTA/FMEDA 给出随机硬件路径,系统验证给出控制有效性,PRA 给出残余路径排序和管理接受证据。
6.2 Cost-benefit 不等于买风险
Bahr 用风险期望值和成本收益分析说明资源如何投向真正主导风险的路径。它不是允许用经济收益掩盖不可接受风险,而是帮助团队选择最有效的控制。若某条路径处于 unacceptable gate,第一动作是改设计或停止活动;只有进入可容忍区域后,成本收益和 ALARP 论证才有意义。
7. Automotive mapping
把 Bahr 的 event tree 放到汽车 E/E,核心是用 scenario-driven 的视角补上 "HARA 到 FTA/FMEDA 到 safety case" 之间的概率决策层。
7.1 HV charging
Scenario 可以是 "充电连接状态下人员接触 HV 能量"。Initiating events 包括插枪锁止误判、接触器粘连、绝缘监测漏报、维修旁路未恢复。Barrier 可以是 CP / PP plausibility、HVIL、IMD、预充与接触器互检、主动放电、机械防触电结构和维修 LOTO。
Event tree 的价值在于把不同终态分开:充电中断、DTC 和无伤害;维修人员轻伤;充电桩损坏;人员严重伤害。FTA 可以给接触器误闭合或 HVIL 误判概率,FMEDA 给诊断残余率,HRA 给维修旁路漏恢复概率。
7.2 Traction inverter
Scenario 可以是 "非预期驱动扭矩导致车辆运动"。Initiating events 包括 torque command corruption、PWM stuck active、current sensor drift、resolver angle fault 和 ASC path unavailable。Barrier 包括 E2E、lockstep、range and plausibility checks、gate driver DESAT / STO、ASC、mechanical brake request 和 driver warning。
Event tree 能显示一条很常见的事实:主导风险不一定来自最高 FIT 元件,而可能来自一个低概率但绕过多层 barrier 的路径。若 barrier probability 来自 FMEDA,要确保 diagnostic coverage 的检测时间与 event tree 的 hazard evolution time 相容。
7.3 ADAS / L3
Scenario 可以是 "L3 highway pilot 在系统边界外继续控制"。Initiating events 包括 perception false negative、ODD boundary misclassification、planner unsafe trajectory、handover request missed。Barrier 包括 ODD monitor、independent plausibility, minimal risk maneuver、driver monitoring、fallback controller 和 HMI escalation。
这类 event tree 往往不适合假装全量精确 FIT 化。更实际的做法是把 field exposure、scenario simulation、SOTIF residual scenario、driver response distribution 和 safety case assumptions 放入同一个 profile,用 relative risk 和 acceptance gate 做决策。
7.4 Production / maintenance hazard
Bahr 的 people / process / technology / infrastructure 边界尤其适合生产和维修 hazard。Scenario 可以是 "EOL 测试工位高压残余未释放" 或 "维修后 interlock bypass 留在车辆上"。Initiating events 可能来自工装程序错误、人员误操作、诊断仪版本不匹配或返修流程跳步。
Barrier 不应只写培训。Event tree 应同时包含物理隔离、工装互锁、双人复核、软件锁定、DTC 检查和作业后验证。若高后果路径主要靠 procedure success 关闭,decision matrix 应强制升级。
7.5 Safety case residual risk
Safety case 需要证明 residual risk 在定义 scope 内可接受。Event tree 提供的是 residual risk 的结构化说明:哪些 scenario 被分析,哪些 barrier 有证据,哪些 terminal branches 留存,哪些被剪枝,哪些进入 management acceptance。
这让 safety case 不只说 "FMEDA 通过" 或 "FTA 通过",而能说明 "在这个 initiating event 发生后,这些 barrier 的组合把 catastrophic terminal branch 降到可接受区;剩余 undesirable branch 已由指定 authority 接受并有监控计划"。
8. 反模式
Event tree 很容易被画成漂亮但无决策力的图。以下反模式应在评审时直接拦下。
8.1 从 barrier 开始画树
如果团队先列控制措施,再倒推 scenario,树会天然证明既有设计合理。正确顺序是先定义 scenario 和 initiating event,再问系统真实有哪些 barrier,每个 barrier 的失效概率和证据是什么。
8.2 把 success probability 默认写成 1
Bahr 的示例里某些正常操作分支可按 success probability 1 处理,但这不是通用模板。汽车项目中,normal operation 本身可能就是 hazard source,例如错误标定导致正常状态机允许危险扭矩。每个 success branch 都要说明为什么可近似为 1。
8.3 低概率路径早删
输入概率小不等于风险小。先删 cut set 或低频 initiating event,可能把高后果路径从报告里消失。剪枝应在 terminal risk contribution 层完成,并保留剪枝依据。
8.4 Matrix 后补
看到结果后再定义 decision matrix,等于让分析为既有结论服务。Acceptance criteria、risk owner 和 escalation rule 必须在 event tree 量化前冻结。
缩写表
本页缩写只覆盖 event-tree risk evaluation 里会反复出现的术语,单项工具的详细缩写进入对应 deep 页。
| 缩写 | 全称 | 含义 |
|---|---|---|
| ETA | Event Tree Analysis | 从 initiating event 展开 barrier success / failure 与终态后果 |
| PRA | Probabilistic Risk Assessment | 以概率、后果和决策准则评价风险的流程 |
| PSA | Probabilistic Safety Assessment | 欧洲语境中常见的 PRA 近义说法 |
| IE | Initiating Event | 触发 scenario 偏离正常任务的事件 |
| HRA | Human Reliability Analysis | 人因任务和人误概率分析 |
| REV | Risk Expectation Value | 分支概率与 consequence value 的乘积或求和 |
| ALARP | As Low As Reasonably Practicable | 风险已降到合理可行的低水平 |
核心要点
Event tree risk evaluation 的工程价值,在于把危险路径从 "发生原因" 推到 "后果与接受决策",并让多个安全分析工具的输出进入同一张残余风险图。
- 风险三元组是 scenario、probability / frequency、consequence;缺任一项都不能做有效 risk evaluation。
- Event tree 从 scenario / initiating event 之后开始,研究 barrier 成功或失败后的 terminal damage state。
- FTA、FMEA、FMEDA、HRA 和 field data 是 event tree 的概率输入,不是 event tree 的替代品。
- Barrier 可以预防也可以缓解;每个 barrier 分支都要有概率来源、适用条件和证据。
- Damage state 必须项目内定义,可用人员伤害、设备损坏、任务损失、停线时间或法规影响估值。
- Risk expectation value 用于比较,不应被当成绝对真值;profile 和 uncertainty 说明同样重要。
- 剪枝应在 event-tree terminal branch 层按 risk contribution 做,不能只按 FTA input probability 做。
- Decision matrix 和 acceptance gate 必须在分析前定义,并绑定 owner、证据要求和升级路径。
- 汽车 safety case 可把 event tree 作为 residual risk 论证的桥:从 HARA scenario 到 FTA/FMEDA 概率,再到 management acceptance。
Engineering Objects
引用此页的结构化 Engineering Object 用于把 event-tree 风险评价接到需求、验证和 safety case 证据链。
- method ·
method_event_tree_risk_evaluation— scenario → initiating event → barrier branches → damage state → acceptance gate。 - artifact ·
artifact_event_tree_risk_profile— 每个 initiating event 的 terminal branch probability、consequence value、risk contribution 和 profile。 - gate ·
gate_residual_risk_acceptance_matrix— 预先定义的 accept / reject / modify 决策矩阵。 - interface ·
interface_fta_fmeda_to_eta_probability— FTA/FMEA/FMEDA/HRA 概率输入到 event tree 的口径控制。
Cross-references
- ← 索引
- Bahr-style System Safety Engineering and Risk Assessment — 本页是其 Chapter 13-14 risk evaluation 分支的深挖。
- Fault Tree Analysis 深度 — 给 event tree 提供 initiating event 或 barrier breach 的概率。
- FMEDA 深度 — 给 barrier residual failure rate、diagnostic coverage 和随机硬件残余率。
- HARA — 给 scenario、damage state 和 safety goal 的车规入口。
- Safety Case — 承接 event tree 的 residual risk acceptance 与证据组织。
- PMHF 定量建模深度 — 随机硬件概率量化与 FTA/Markov/FMEDA 的衔接。
来源: Nicholas J. Bahr, System Safety Engineering and Risk Assessment: A Practical Approach, Second Edition, Chapter 13 Risk Assessment and Chapter 14 Risk Evaluation;本页为工程综合与改写,未复制书中长段落。