Bahr-style System Safety Engineering and Risk Assessment 深度

System safety 关注系统是否对人员、环境、设备和任务保持安全; risk assessment 则把不同方案的概率、后果、成本、社会接受度和业务影响放到同一个决策框架里。前者产出 hazard、cause、control 和 verification;后者决定 residual risk 是否值得接受、是否还要投入资源继续降低。

Bahr 反复强调系统不只是设备本体,还包括人、流程、软件、硬件、设施、支持设备、运行环境和外部接口。对汽车 E/E 项目来说,这意味着 item definition 不能只画 ECU 方框;还要写清 driver、maintenance、诊断仪、OTA、供应链、生产测试和退役维修这些会改变 hazard 的上下文。

这种边界观能补上很多 ISO 26262 项目的盲区。HARA 常从驾驶场景出发,FMEDA 常从 BOM 出发,FTA 常从顶事件出发;Bahr-style 工作流要求在这些分析之前先回答"系统的真实交互面在哪里",否则工具再精细也只是在错误边界内自洽。

Bahr 的 hazard analysis 方法可以压缩成五步: define system、identify hazards、evaluate hazards、resolve hazards、follow up。关键不在步骤名字,而在最后两步把分析从"知识发现"变成"工程闭环"。

Bahr 把事故看作 preliminary event、initiating event、intermediate event、ameliorative event 到 consequence 的演化链。这个链条提醒汽车工程师:危险不一定从元件失效开始,也可能从工作时长、维修状态、信息延迟、错误程序、错误人机界面或外部环境开始。

经典工程公式可把风险粗略写成 $R = P \cdot C$,其中 $P$ 是发生概率,$C$ 是后果严重度。Bahr 的风险章节提醒读者:真正的接受度还受自愿性、可控性、是否灾难性、是否新技术、是否被公众理解等因素影响,所以安全沟通和 acceptance authority 也是工程流程的一部分。

这对汽车尤其重要。相同的随机硬件失效率,放在车窗舒适功能和 steer-by-wire 横向控制里,公众、监管和 OEM 的接受度完全不同;相同的技术风险,在量产召回、试验车封闭道路、OTA 灰度发布和售后维修中也不能用同一套阈值机械处理。

如果一个危险能通过架构或物理设计消除,就不该先写培训和警告。比如高压互锁开盖暴露风险,优先级应是机械互锁和能量释放设计,其次是检测与断电,再其次才是标签和维修程序;把最后一层当主控制,本质上是在要求未来所有人永远不犯错。

Hazard control 只有在定义了可验证的状态后才可审计。"进入安全状态"不是状态,"三相关断后母线电压低于阈值且扭矩命令锁定为零"才是状态。Bahr-style 流程要求把控制措施写到能被测试、能被验收、能被追踪关闭。

这也是它和单纯 risk matrix 的区别。矩阵只能告诉你风险等级高低,不能告诉你控制是否存在、是否有效、是否已验证、是否在变更后仍有效;hazard log 必须承载这些 closure 字段。

工具选择的第一问不是"公司模板要求什么",而是"现在缺哪类证据"。如果缺系统边界和 hazard 清单,先做 PHL / PHA / STPA;如果缺顶事件路径,做 FTA;如果缺元件失效模式和单点故障,做 FMEA/FMECA 或 FMEDA;如果缺流程偏差,做 HAZOP;如果缺人机任务证据,做人因任务分析。

组合工具不是把所有模板都填一遍。更健康的做法是先用宽工具找范围,再用深工具钻高风险路径:STPA 或 PHA 找出危险控制动作和场景,再把高优先级 hazard 交给 HARA 评级;FTA 拆顶事件路径,再用 FMEDA 给基本事件失效率和诊断覆盖;bow tie 用于向管理层说明 prevention barrier 与 mitigation barrier 的完整性。

这种主从关系能控制成本。Bahr 反复提醒不要 fault tree everything,也不要把昂贵的 FMEA/FMECA 铺到全系统每个角落;深分析应该被 hazard priority 触发,而不是被模板焦虑触发。

如果 acceptance criteria 在结果出来后才调整,评审就会怀疑团队是在为既有设计找理由。Bahr-style 流程要求在分析开始前定义 risk class、damage state、probability band、severity band、acceptance authority 和升级规则。

一个 robust hazard log 至少要记录 hazard、cause、risk before、control、owner、due date、verification method、risk after、acceptance authority 和 change impact。没有 owner 和 verification 的 hazard log 只是清单,不是闭环。

汽车项目里,这张表应跨越需求、架构、硬件、软件、测试、生产、售后和供应商接口。否则 HARA 里的 hazard 会停在概念阶段,FTA / FMEDA 的发现会停在工程师电脑里,field incident 又无法反向更新 safety case。

Bahr 在 SMS 章节强调 closed-loop process、review、audit 和 change management。对汽车 E/E 来说,一次供应商替代料、一次软件阈值修改、一次 PCB layout 改版、一次 OTA 策略改变,都可能让已关闭的 hazard 重新打开。

所以"已关闭"不是永久状态,而是在当前配置、当前运行环境、当前证据下有效。配置控制和变更影响分析是 safety case 的生命线,不是文档管理的行政动作。

现有页面已经详细解释单项方法,本页只负责它们之间的编排逻辑。读者先从本页理解"什么时候该用哪把工具,产物如何闭环",再进入对应 deep 页学习具体算法、表格和量化公式。

ISO 26262 项目容易把 HARA、FMEDA、FTA 写成相互独立的交付物。Bahr-style 视角会追问三件事:第一,这些交付物是否共享同一个系统边界;第二,每条高风险 hazard 是否能追到控制和验证;第三,field data、near miss、audit finding 和 design change 是否能反向更新分析。

这三个问题比再多填一张模板更有杀伤力。它们直接指向 safety case 的可信度:不仅证明当时做过分析,还证明组织有能力在系统生命周期内持续管理风险。

最典型的反模式是"做了某个工具,所以安全了"。比如做了 FTA 就认为底层失效模式充分,做了 FMEDA 就认为系统级交互充分,做了 HARA 就认为人因和运行维护充分,做了 IV&V 就认为软件安全充分。工具只能回答它被设计来回答的问题。

第二个反模式是把 risk matrix 当成控制措施。矩阵能排序,不能降低风险;真正降低风险的是设计改变、安全机制、报警、程序、培训、维护、测试和审计。矩阵之后没有控制和验证,风险等级只是颜色。

第三个反模式是高风险 hazard 主要靠 procedure、warning 或 training 关闭。Bahr 的 precedence 明确把这类控制放在最后,因为它们对人、组织、时间和文化高度敏感。高 ASIL 或高后果场景如果只能靠程序控制,必须把"为什么无法采用更高层控制"写成显式论证。

第四个反模式是 hazard once closed, always closed。实际系统会被修改、老化、维修、升级、外包、换料、换人、换运行环境;安全闭环必须能被这些变化重新触发。没有 change impact analysis 的 closed hazard 是静态文档,不是活的 safety case。