Human Factors and Software Safety Analysis 深度

FMEA 的强项是系统化枚举某个组件或功能块的失效方式,再检查 local effect、next-level propagation 和 system effect。汽车 E/E 中这正适合追主驱逆变器相电流采样 stuck、BMS 绝缘监测漂移、制动域 CAN 信号丢失、MCU reset line 短路等失效。

但这一步只能回答 "某个失效如何导致危险",不能回答 "危险全集是否完整"。例如 HV 维修人员触电可能来自互锁诊断失效,也可能来自正常放电等待时间不足、维修流程未隔离、工具绝缘等级错误或标签误导。只做 FMEA 会抓到前者,但可能漏掉后四类。

FMECA 比 FMEA 多了 criticality 排序,可以把 failure mode 按严重度和发生可能性排列。这个排序很适合决定先追哪些 single-point failure、哪些诊断覆盖要加证据、哪些失效需要进入 FTA 或 fault injection。

排序不等于风险接受。Bahr 的总流程要求 risk acceptance 由预先定义的 gate 决定,因此 FMECA 的高 criticality 行应该回写 hazard log、safety requirement 和 verification plan,而不是在 FMECA 表里被单独关闭。

培训在 hazard reduction precedence 中靠后,因为它依赖人记住并稳定执行。汽车项目里,若 HV 下电后的安全状态靠维修人员记住等待时间、插入绝缘盖、再手工测量,这不是不可用,但它不是强 barrier。更强的控制是机械防错、状态机 interlock、自动放电监测、工具授权和可追溯 permit。

Human factors analysis 应先问任务是否被设计成可执行:操作步骤是否超过现场认知负荷,界面是否把危险状态显示成低风险颜色,报警是否可区分,维修入口是否能防止跳步,异常状态下是否有明确 safe stop。

如果风险控制只能落在 procedure,它仍然要有 verification。验证不是 "已培训" 四个字,而是任务演练、tabletop exercise、现场观察、错误注入、响应时间测量和记录抽查。对 ADAS 接管、远程诊断授权、EOL 高压测试、充电桩维护等场景,procedure 的执行质量直接影响 event tree 中某个 barrier 的 failure probability。

软件安全分析的入口不应是代码行,而是 hazard-derived requirement。先问安全目标要求软件在什么条件下禁止、降级、报警或进入 safe state,再检查架构有没有隔离、监控和故障反应。代码和测试是下游证据。

汽车 E/E 的典型链条是:hazard analysis 定义 dangerous behavior,TSR 分配给 ECU 或软件功能,软件 safety requirement 定义状态机约束,架构分配到 component,单元和集成测试覆盖正常与异常路径,运行时监控在现场兜底。

Bahr 提到 software testing 和 IVV,其工程含义是验证链必须独立地挑战设计假设。IVV 不是把测试报告盖章,而是从 hazard、requirement、architecture、interface、code、test case 和 anomaly report 之间做 traceability 反查。

对汽车项目,IVV 的高价值动作包括:用 hazard list 反推测试缺口,用 software FMEA 检查状态机遗漏,用 fault injection 验证 diagnostic response,用 field feedback 检查 OTA 后是否引入新的 unsafe interaction。

Bahr 的 FMEA 流程强调 single-point failure。汽车 E/E 项目里,单点不只可能是硬件器件,也可能是人工切换阀、维护授权流程、软件全局状态变量、公共电源、共享时钟或诊断服务入口。分析时必须问:这个单点失效是组件本身、系统配置、人的任务路径,还是软件架构形成的共同点。

局部效应只说明失效在本层造成什么现象;传播路径说明它如何越过接口成为系统 hazard。很多安全评审失败不是因为局部效应没写,而是没有说明 next-level propagation:一个传感器 fault 怎样影响扭矩请求,一个 HMI ambiguity 怎样影响司机接管,一个 bootloader bug 怎样影响安全监控。

如果 hazard list 只是 FMEA 失效模式的摘录,团队会漏掉正常操作能量、误用、维护、环境和组织因素。修复方式是先做 PHA / HARA / O&SHA 定义 hazard,再用 FMEA 追高优先级失效原因。

"operator failed to follow procedure" 通常只是现象。评审应继续问界面、培训、可用时间、工具、环境、工作负荷、组织压力和监督机制。若不追 latent condition,整改只会变成培训和通报。

测试只能证明某些路径被执行过,不能自动证明需求正确、架构隔离充分、工具链可信或现场监控有效。软件 safety case 必须覆盖 requirement correctness、architecture constraints、implementation controls、verification coverage 和 runtime response。