Bahr Chapter 5 Hazard Analysis 深度 — PHL/PHA/SHA/SSHA 到运营支持闭环
本质与导读
本质 Bahr 第 5 章的 hazard analysis 不是 ISO 26262 HARA 的另一种评分表,而是一套把危险从"早期想到的可能性"推进到"有原因、有影响、有控制、有验证、有状态"的工程对象链。它保护的不变量是:危险不能只在概念阶段被识别,还必须穿透 subsystem、system interface、facility、operation and support,直到 hazard log 里每条控制都被验证关闭或被有权限的人接受。
主线坐标:横轨 · 功能安全(跨行业系统安全方法 → 汽车 E/E 落地)。
学习目标
本页把 Bahr Chapter 5 的 hazard analysis 族谱压缩成汽车 E/E 可用的工作流,重点是产物如何递进,不是重复 ISO 26262 HARA 的 S/E/C 查表。
- 区分 PHL、PHA、SSHA、SHA、FHA、facility hazard analysis、O&SHA 的作用边界。
- 把 Bahr 的五步 hazard analysis process 映射成汽车项目里的 hazard log 生命周期。
- 解释为什么 subsystem 分析、system interface 分析和运营支持分析不能互相替代。
- 用汽车 E/E 例子把早期 hazard list 接到 HARA、STPA、FTA、FMEDA、FSC/TSR 和 safety case。
- 识别把 O&SHA 当硬件分析、把 risk matrix 当控制、把关闭状态当永久状态的反模式。
1. Chapter 5 的核心对象
Bahr 第 5 章先把 hazard analysis 定义成系统性、全生命周期、全接口的工程活动,再把多个分析名字展开为同一张 hazard log 在不同阶段和不同视角下的投影。对汽车 E/E 来说,关键不是背术语,而是知道哪类问题该在哪一层被发现、由谁关闭、用什么证据证明关闭。
1.1 PHL 是原始覆盖面,不是结论
PHL(Preliminary Hazard List)的价值在于早期宽覆盖。它先不急着给概率和严重度下结论,而是通过团队脑暴、事故经验、相似设计、用户操作、维护记录、规范、测试数据、能源传播路径和 generic hazard list,尽量把可能危险放进同一个候选池。
| PHL 输入 | 汽车 E/E 对应 | 它补的盲区 |
|---|---|---|
| 相似系统和事故经验 | 既往 recall、8D、field return、near miss | 防止只从新架构想象 hazard |
| 用户和操作者观察 | 驾驶员、维修工、产线操作员、救援人员 | 防止程序写法和真实操作脱节 |
| 设计与测试数据 | 原理图、layout、DFMEA、台架异常、DV/PV 记录 | 防止 hazard 脱离工程事实 |
| 能源路径 | HV bus、12 V、热、机械动能、化学能、软件控制能 | 防止只按组件清单列危险 |
| 生命周期阶段 | 开发、生产、运输、维修、OTA、退役 | 防止量产后和支持活动漏项 |
PHL 的输出不应直接被当成 safety goal。它更像一张覆盖面索引:后续 PHA、SSHA、SHA、O&SHA 都要回到这张索引,逐条判断可信性、严重度、概率、原因、影响和控制状态。
1.2 PHA 把早期清单变成设计输入
PHA(Preliminary Hazard Analysis)是系统早期的第一次正式 hazard assessment。它开始识别 safety-critical areas、初始风险等级、安全设计准则和适用的安全要求,因此它比 PHL 多了"如何影响设计"这一层。
在汽车项目里,PHA 适合放在 item definition 和概念架构之间。它不替代 ISO 26262 HARA,但能在 HARA 前把危险类别、能量源、跨域接口和历史问题先铺开,避免 HARA workshop 只围绕少数驾驶场景临场发挥。
1.3 SSHA 和 SHA 是同一张表的两个尺度
SSHA(Subsystem Hazard Analysis)把每个 major subsystem 拉开看,关注子系统内部的失效、故障、流程、程序和人因错误;SHA(System Hazard Analysis)则把焦点上移到系统级 hazard、跨子系统接口和外部系统影响。Bahr 的要点很直接:术语不同,本质仍是同一个 hazard analysis process。
| 分析 | 关注尺度 | 汽车 E/E 例子 | 典型输出 |
|---|---|---|---|
| SSHA | ECU、传感器、执行器、软件模块、供电子系统 | SBC watchdog、inverter gate driver、current sensor、ASIL MCU | subsystem hazard、local control、verification |
| SHA | 整车 item、域控、车辆环境、外部交通和维修接口 | torque request path、brake blending、HVIL、OTA aftersales flow | interface hazard、system control、closure evidence |
| Interface slice | 子系统之间的耦合路径 | CAN timeout、shared 12 V、clock/reset、diagnostic arbitration | dependent cause、assumption、owner split |
这一区分能防止两个常见错误:只做 SSHA 会漏掉接口耦合和外部系统影响;只做 SHA 会把子系统内部的具体控制和验证责任写得太虚。
2. Hazard log 是 Chapter 5 的主产物
Bahr 用 worksheet 展示的不是文档格式偏好,而是一个闭环数据模型。hazard description、causal factor、effect、risk index、control recommendation、control effect、reference、verification、status 和 notes 这些字段,共同回答"这条危险为什么存在、怎样降低、证据在哪里、是否关闭"。
2.1 每个 cause 要可单独追踪
同一个 hazard 往往有多个 causal factor,而且这些原因可能独立、相关或由共同条件触发。Bahr 特别强调不能因为控制了一个原因就以为控制了整个 hazard;工程上应把 cause 拆成可追踪条目,每条都有控制建议和验证证据。
| Hazard log 字段 | 为什么必须有 | 汽车 E/E 字段落点 |
|---|---|---|
| Hazard description | 让评审者理解危险本身 | hazardous event、unsafe control action、top event |
| Potential causal factors | 指向真正可控制的原因 | failure mode、software condition、operator action |
| Potential effects | 展示传播和紧耦合后果 | vehicle effect、harm、mission loss、environment effect |
| HRI / risk class | 排序和升级决策 | ASIL、risk priority、acceptance gate |
| Control recommendation | 从批评转向工程动作 | FSC、TSR、HSR、SSR、procedure、training |
| Verification of control | 证明控制充分且在位 | test、inspection、analysis、review、audit |
| Status of control | 关闭、开放、进行中 | safety case claim status、Polarion state |
这张表和 ISO 26262 的 work product 可以互相映射,但不能完全等同。HARA 给出安全目标和 ASIL,FMEDA 给随机硬件故障指标,FTA 给顶事件路径;hazard log 负责把这些证据拉回同一个 closure 状态。
2.2 验证和确认是两件事
Chapter 5 里最容易被忽视的句子是:控制措施既要被验证已经在位,也要被确认确实能控制 hazard。汽车 E/E 里这对应两个不同问题:实现是否真的存在,以及这个实现是否足够。
例如逆变器给非预期扭矩 hazard 加了 STO 路径,只看到原理图有关断引脚并不足够。还要证明诊断延迟、驱动关断、功率器件实际退能和整车扭矩响应都满足 FTTI;否则控制"存在",但未必"足够"。
2.3 Safety assessment 是 worksheet 的解释层
worksheet 是逐条证据,safety assessment 是把证据解释给决策者看的结果章节。它应说明采用的方法、风险定义、假设、可信 hazard 判据、控制如何降低风险、哪些控制已经验证、哪些仍开放、以及 hazard analysis 如何接入 safety management system。
汽车项目可以把这层看成 safety case 的材料入口。单条 hazard log 记录适合工程追踪;assessment summary 适合 I3/FSA/OEM review,因为它把开放项、残余风险和管理接受权放在一个视图里。
3. 从系统树到汽车 E/E 覆盖图
Bahr 反复用 functional tree 组织分析,目的不是强迫某种树形画法,而是让评审者能沿着系统、子系统、接口、人员、环境、设施和支持活动逐项检查覆盖性。汽车 E/E 的等价物不是一张 BOM,而是 item boundary、功能架构、E/E 架构、运行工况、维护活动和外部接口的合并视图。
3.1 Functional tree 不是组织架构图
functional tree 应按分析问题组织,不必和公司组织、供应商边界或 ECU 物理拆分一致。它的好坏标准是:评审者能不能顺着树检查到所有功能、接口、支持设备、人员活动和运行环境。
| Bahr 视角 | 汽车 E/E 映射 | 典型 hazard |
|---|---|---|
| Hardware systems | ECU、电源、传感器、执行器、线束、功率级 | 短路、过热、误输出、失去能力 |
| Software | control algorithm、diagnostics、state machine、OTA | 错状态、阈值错误、超时处理错误 |
| People | driver、technician、operator、first responder | 误操作、误解报警、维修绕过 |
| Processes and procedures | 诊断流程、标定流程、产线测试、售后维修 | 错版本、漏复核、程序不现实 |
| Facilities | 产线、实验室、充电/高压测试、仓储 | 高压暴露、热事件、消防和通风不足 |
| Support equipment | EOL tester、诊断仪、治具、充电机、lifting tool | 测试绕过、错误供电、夹具失效 |
| Environment and interfaces | 道路、天气、交通、网络、外部系统 | exposure 变化、通信干扰、耦合失效 |
这张树会直接影响分析质量。如果 item definition 只画 ECU 和 CAN,那么维修高压暴露、OTA 误配置、产线 HV 测试、救援人员触电这类 hazard 从一开始就没有入口。
3.2 FHA 不等于 LLC 的基波近似
本页的 FHA 指 Fault Hazard Analysis 或 Functional Hazard Analysis 语境下的 hazard 分析入口,不是电力电子 LLC 页面里的 First-Harmonic Approximation。Bahr 在 Chapter 5 中把 fault-focused hazard analysis 视作 basic hazard analysis 的一个抽取版本,其重点是某类 fault 如何产生 hazard。
汽车 E/E 中,FHA 适合用于把功能失效和 hazard 做早期连接:例如 torque command missing、wrong torque direction、brake request delayed、HV isolation lost。之后这些条目再进入 HARA 评 ASIL,或进入 STPA 做 unsafe control action 细化。
4. Facility hazard analysis 把工厂和实验室纳入同一闭环
Bahr 将 facility hazard analysis 单独展开,因为设施不是产品本体,但会真实改变人员伤害、环境排放、设备损坏、任务中断和公众影响。汽车 E/E 若只做车上 item safety,会漏掉高压实验室、产线 EOL、老化房、仓储和售后作业里的高后果 hazard。
4.1 设施风险要随设计评审滚动更新
facility hazard analysis 使用相同的 hazard analysis process,但强调从概念到处置的设施生命周期。Bahr 建议在设计成熟度节点持续回访分析;汽车项目中可映射为 layout 方案、设备采购、安装调试、验收、量产爬坡和改造阶段的滚动更新。
| 设施节点 | 汽车 E/E 场景 | 应关注的 hazard |
|---|---|---|
| HV lab / dyno | 800 V inverter、OBC、battery simulator | 触电、arc flash、冷却泄漏、急停不可达 |
| EOL and calibration | ECU flashing、HV test、insulation test | 错软件、错参数、测试绕过、夹具误接 |
| Battery and cell area | pack storage、thermal abuse、charging | 热失控、消防隔离、通风和排烟 |
| Warehouse and transport | spare pack、air shipment、return material | 损伤后继续运输、标签和隔离不足 |
| Service workshop | HV repair、diagnostic tool、field retrofit | interlock bypass、能量未释放、程序不现实 |
设施分析的工程输出不只是整改清单,还应进入同一 hazard log。否则产品 safety case 里写了高压安全,但实验室和售后环境里没有对应控制,组织层风险仍未关闭。
4.2 Facility risk indicator 是资源分配工具
Chapter 5 中 facility risk indicator 的意义是让组织按设施对使命和人员的风险分配分析深度。汽车企业同样不应把办公室、普通仓库、高压实验室、电池热滥用间和整车转鼓试验室用同一审查强度处理。
这不是降低标准,而是把高强度审查集中在高后果区域。对高压测试间,需要急停、互锁、隔离、通风、消防、权限、演练和验收测试;对低风险办公区,常规 EHS 控制和应急流程可能已经足够。
5. O&SHA 把操作真实世界接进分析
O&SHA(Operating and Support Hazard Analysis)聚焦系统运行和支持活动中由人员、任务序列、程序、环境和人机接口触发的 hazard。它不是 human factors analysis 的同义词,也不是硬件 hazard analysis 的替代品;它是把"系统由人操作和维护"这件事实接入同一 hazard analysis。
5.1 O&SHA 不能替代硬件分析
Bahr 对 O&SHA 的警告很适合汽车项目:很多工程师会用运营支持分析代替硬件分析,这是错误的。O&SHA 擅长发现程序、任务顺序、人员协同、维护和支持活动中的危险,但它不会自动发现功率器件、结构、传感器、制动硬件或线束设计缺陷。
| O&SHA 关注 | 汽车 E/E 例子 | 需要配合的硬件/系统分析 |
|---|---|---|
| 任务顺序 | HV pack 下电、放电、拆接 connector | HVIL、discharge circuit、interlock verification |
| 并行任务限制 | 一人刷写,一人台架上电,一人改线束 | configuration control、test bench safety |
| planned and unplanned operation | OTA rollback、售后救援、事故后拖车 | SHA、cybersecurity、SOTIF trigger review |
| 人机环境接口 | 诊断仪提示、DTC 文案、维修照明、噪声 | HMI review、service tool validation |
| 支持设备 | lifting tool、charger、EOL fixture、breakout box | SSHA、facility hazard analysis |
正确做法是组合:硬件/系统分析找物理和接口危险,O&SHA 找真实操作如何触发或放大这些危险。二者共享 hazard log,而不是各写一套互不相认的表。
5.2 真实操作比书面程序更重要
O&SHA 的关键证据来自现场观察,因为书面程序经常无法反映真实工作。汽车售后和试验现场尤其如此:维修人员可能跳过等待时间,台架工程师可能复用临时线束,产线可能用旁路治具赶节拍,这些现实行为才是 hazard analysis 应该覆盖的对象。
O&SHA worksheet 比普通 hazard worksheet 多了 task description 和 events leading up to hazard state。这个差异很重要:它把控制点从"事后防护"前移到任务链中,让工程师选择在哪个事件节点切断 hazard sequence。
5.3 程序控制要接受低优先级地位
Bahr 的 hazard reduction precedence 把 procedure and training 放在最后一层,因为它们依赖人长期正确执行。O&SHA 会产生很多程序和培训类控制,但这些控制不应自动成为高后果 hazard 的主控制。
汽车 E/E 的判断规则可以很硬:如果某条 ASIL D 或高后果 hazard 主要靠维修工"记得不要这样做"关闭,那不是 closure,而是一个需要重新设计的开放项。只有当设计消除、安全装置、告警和隔离都不可行或不足时,程序控制才作为残余层进入 acceptance。
6. 汽车 E/E 接入方式
把 Bahr Chapter 5 接进 ISO 26262 项目时,不要把它变成另一套 HARA 模板。更好的定位是:PHL/PHA/SSHA/SHA/FHA/facility/O&SHA 提供 hazard discovery 和 closure 数据模型,HARA/STPA/FTA/FMEDA 提供标准化评级、因果展开和定量证据。
6.1 建议的产物流
产物流的目标是让每条 hazard 从早期清单进入对应分析,再带着控制和验证状态回到同一张 hazard log。这样 safety case 看到的不是一堆分散文件,而是一条可追溯闭环。
| 阶段 | Bahr 对象 | 汽车 E/E 对接 | 退出条件 |
|---|---|---|---|
| 概念前期 | PHL | item boundary、historical data、STPA loss/hazard seeds | 候选 hazard 有分类和来源 |
| 概念架构 | PHA / FHA | HARA pre-workshop、functional failure list | 高风险区域和初始控制策略明确 |
| 系统设计 | SHA | FSC、TSR、interface analysis、DFA | 系统级 hazard 有 owner 和 control |
| 子系统设计 | SSHA | HSR/SSR、DFMEA、FMEDA、SW safety analysis | 子系统控制和验证方法明确 |
| 设施和支持 | facility HA / O&SHA | HV lab、EOL、service、OTA operation | 运营支持 hazard 进入同一 closure |
| 验证和发布 | hazard log / assessment | safety case、FSA、release gate | 控制在位、有效、残余风险已处理 |
这个流转能补上 ISO 26262 项目常见断点:HARA 只在概念阶段热闹,到了 subsystem、facility、service、field change 后没有活的 hazard tracking。
6.2 与现有 HARA 页的分工
现有 HARA 页讲 ISO 26262 如何把 hazardous event 按 S/E/C 评 ASIL 并产出 Safety Goal。本页讲的是 HARA 之前和之后的系统安全对象:hazard 从哪里来、如何分层展开、如何跨运营支持闭环、如何证明控制已经关闭。
因此,汽车团队可以按以下方式组合:用 PHL/PHA/STPA 扩大 hazard coverage,用 HARA 定 ASIL 和 SG,用 SHA/SSHA 把 SG 落到接口和子系统控制,用 FTA/FMEDA/DFA 证明因果和硬件指标,用 facility/O&SHA 覆盖产线、实验室、售后和支持活动,最后用 hazard log 和 safety case 统一关闭。
7. 反模式
Chapter 5 的实践价值很大一部分来自它能暴露"文档看起来完整,工程对象没有闭环"的问题。下面这些反模式在汽车 E/E 项目里很常见,也最容易在审计、事故复盘或 field change 中被放大。
7.1 PHL 直接变 Safety Goal
PHL 是宽覆盖输入,不是风险结论。把早期脑暴条目直接改写成 Safety Goal,会跳过原因、影响、可信性、风险优先级和控制验证,导致后续需求看似完整但没有 hazard closure 依据。
7.2 只做子系统,不看接口
很多危险不在某个 ECU 内部,而在接口和耦合中出现:共享电源、网络延迟、诊断仲裁、机械执行器惯性、驾驶员反馈、维修状态和外部交通环境。只做 SSHA 会让这些跨边界 hazard 没有 owner。
7.3 用 O&SHA 替代硬件设计控制
O&SHA 发现"人会怎么操作",但不能替代硬件安全机制。高压维修只靠 procedure,而没有互锁、能量释放、可见状态、工具防错和验收测试,就是把最低优先级控制当主控制。
7.4 Hazard 状态关闭后不再重开
Chapter 5 强调系统修改、扩展、重配置或运行条件变化后要更新 hazard analysis。汽车 E/E 中,换料、软件标定、OTA 策略、产线夹具、供应商变更、服务流程改变都可能重开已关闭 hazard。
缩写表
本页缩写只覆盖 Bahr Chapter 5 的 hazard analysis 族谱和汽车接入所需术语,单项 ISO 26262 缩写见对应页面。
| 缩写 | 全称 | 本页含义 |
|---|---|---|
| FHA | Fault Hazard Analysis / Functional Hazard Analysis | fault 或功能失效导向的 hazard 分析入口,非 LLC 基波近似 |
| FRI | Facility Risk Indicator | 设施相对风险排序,用于分配分析深度 |
| HRI | Hazard Risk Index | severity 和 probability 合成的风险优先级 |
| O&SHA | Operating and Support Hazard Analysis | 运行和支持活动 hazard 分析 |
| PHA | Preliminary Hazard Analysis | 早期正式 hazard assessment |
| PHL | Preliminary Hazard List | 早期宽覆盖 hazard 候选清单 |
| SHA | System Hazard Analysis | 系统级和跨接口 hazard 分析 |
| SSHA | Subsystem Hazard Analysis | 子系统级 hazard 分析 |
核心要点
Bahr Chapter 5 对汽车 E/E 的核心贡献,是把 hazard analysis 从单次 workshop 变成一条可追踪的数据流。
- PHL 负责宽覆盖,PHA 负责早期风险和设计输入,SSHA 负责子系统内部,SHA 负责跨接口,FHA 负责 fault 或功能失效入口,facility/O&SHA 负责设施和运营支持。
- Bahr 的 worksheet 字段本质是 hazard log 数据模型:hazard、cause、effect、risk、control、reference、verification、status。
- 控制措施必须同时证明"在位"和"足够";只看到需求或原理图不等于 hazard closed。
- functional tree 的目的不是画组织图,而是给覆盖性审查提供路径。
- Facility hazard analysis 把高压实验室、产线 EOL、仓储、售后维修等车外风险纳入同一闭环。
- O&SHA 只能补运营支持视角,不能替代硬件、软件和系统 hazard analysis。
- 汽车项目应把 PHL/PHA/STPA 的发现、HARA 的 ASIL/SG、SHA/SSHA 的控制、FTA/FMEDA 的证据和 O&SHA 的任务控制统一进 hazard log。
- 变更会重开 hazard;关闭状态只对当前配置、当前证据和当前运行语境有效。
Engineering Objects
这些对象是把 Bahr Chapter 5 落到汽车 E/E 工程系统时应当显式建模和追踪的实体。
preliminary_hazard_list:早期宽覆盖危险池,记录来源、类别和生命周期阶段。hazard_analysis_worksheet:承载 cause、effect、risk、control、verification、status 的主记录。functional_tree:按系统、子系统、接口、人员、设施、支持设备和环境组织覆盖性检查。hazard_control_record:把控制建议、控制类型、owner、验证方法和残余风险连起来。facility_hazard_record:产线、实验室、仓储、售后设施里的 hazard closure 记录。operation_support_task:O&SHA 的任务序列、真实操作、事件链和控制切入点。safety_assessment_summary:面向评审和 acceptance authority 的 worksheet 解释层。change_reopen_trigger:换料、软件、layout、OTA、工艺、维修流程改变后的 hazard 重开条件。
Cross-references
- ← 索引
- Bahr-style System Safety Engineering and Risk Assessment — 上层系统安全闭环,本页展开其 Chapter 5 hazard analysis 族谱。
- HARA — ISO 26262 的 S/E/C/ASIL 和 Safety Goal 方法,与本页的 discovery/closure 数据流互补。
- STPA 深度 — 用 control structure 扩大 PHL/PHA 前端 hazard coverage。
- Fault Tree Analysis 深度 — 对高优先级 hazard 的顶事件因果路径做向下展开。
- FMEDA 深度 — 对 SSHA/SHA 中硬件相关 cause 提供随机硬件定量证据。
- DFA / FMEDA / FTA — ISO 26262 安全分析方法与 Bahr-style hazard log 的下游证据关系。
- Safety Case — 把 hazard closure、验证证据和 residual risk acceptance 组织成论证。
来源: Nicholas J. Bahr, System Safety Engineering and Risk Assessment: A Practical Approach, Second Edition, Chapter 5 "Hazard Analysis";本页为工程综合与改写,未复制书中长段落。