4. 危害识别与风险评估在DAS中的落地

在驾驶辅助系统（DAS）的SOTIF工程中，危害识别与风险评估不是一次性动作，而是贯穿概念、开发、验证与运行阶段的持续活动。ISO 26262的HARA回答“功能失效会造成多大伤害”，ISO 21448的SOTIF则进一步追问“功能正常但性能不足或场景理解错误时，是否仍会产生不合理风险”。两者在Bosch的工程实践中并非彼此替代，而是通过明确的接口协同工作。

HAZOP与STPA：两种危害识别方法的定位差异

HAZOP（危险与可操作性分析）以“引导词+设计意图”的方式系统扫描偏差。在DAS中，典型引导词包括“无/过小/过大/反向/过早/过晚/持续”。例如对AEB的“制动请求”这一设计意图，可导出“无制动请求”“制动请求过晚”“制动请求过大”等偏差，再结合车辆状态与场景条件判断后果。HAZOP的优点是结构化、可追溯、便于跨专业评审，适合对已知功能链路做穷举式检查；局限在于它依赖设计意图的完整描述，对“功能正常但场景超出设计假设”这类SOTIF问题覆盖不足。

STPA（系统理论过程分析）从控制结构出发，先建立“控制器—执行器—被控过程—反馈”的控制回路，再识别不安全控制动作（UCA）。在DAS中，控制器可能是ACC纵向控制、LKA横向控制或感知融合模块，被控过程是车辆运动状态，反馈来自传感器与驾驶员。STPA关注的是控制动作在特定上下文下是否不安全，例如“ACC在弯道中保持过高设定车速”本身不是失效，但在曲率大、附着低时构成UCA。STPA更适合发现组件交互、模式切换、人机共驾边界中的SOTIF危害，但需要与HARA的风险参数结合才能完成ASIL或风险等级判定。

场景级危害分析：把危害事件放回运行场景

场景级危害分析的核心，是避免孤立地评价某个功能，而是把“危害事件”与“运行场景”做交叉。Bosch常用做法是建立场景要素矩阵：道路几何（直道、弯道、坡道、匝道）、环境条件（昼/夜、雨/雾、逆光）、交通参与者（前车、cut-in、行人、骑行者）、自车状态（车速、载荷、传感器可用性）。对每个危害事件，标注其可能出现的场景组合，并给出暴露度E、严重度S、可控性C的初步估计。

以ACC“未识别静止前车”为例，若仅在高速公路直道、白天、干燥路面评估，暴露度较低；但若扩展到黄昏逆光、弯道出口、前车静止排队，暴露度与可控性都会显著恶化。此时HARA给出的ASIL等级可能仍为B或C，但SOTIF分析会进一步指出：该危害事件在“逆光+弯道”场景下属于区域2（未知不安全），需要通过场景扩展测试与感知性能边界分析来收敛。

SOTIF相关危害事件分类：区域模型的实际用法

ISO 21448用四个区域描述危害事件：区域1为已知不安全，通常由功能失效或已知性能不足导致；区域2为未知不安全，是SOTIF活动的重点；区域3为已知安全，已通过验证确认；区域4为未知安全，属于理论上的安全余量。工程上不必追求区域4，而应把区域2持续转化为区域3。

分类时建议同时记录三个字段：危害事件描述、触发条件（功能失效/性能不足/场景超出假设）、当前验证状态。例如“LKA在车道线磨损路段误触发转向”属于性能不足导致的区域2；“AEB因雷达遮挡未触发”属于功能失效导致的区域1。两者后续措施不同：前者需要扩充场景库与感知边界测试，后者需要诊断与降级策略。

Bosch HARA与SOTIF分析的接口

在Bosch流程中，HARA与SOTIF分析共享同一份危害事件清单，但使用不同的评估维度。HARA输出安全目标与ASIL等级，SOTIF输出性能边界、场景覆盖度与残余风险。接口的关键在于：HARA的“可控性C”需要引入驾驶员在环的响应时间与场景复杂度；SOTIF的“暴露度E”需要与HARA的暴露度定义保持一致，避免同一场景在两套分析中得出矛盾结论。

实际操作中，可建立一张接口表，字段包括：危害事件ID、HARA的S/E/C与ASIL、SOTIF的区域分类、触发条件、验证活动、残余风险接受准则。例如某AEB危害事件HARA评定为ASIL B，SOTIF区域为区域2，则验证活动应包含逆光、湿滑、弯道等场景的感知性能测试，并以“漏检率低于设定阈值”作为残余风险接受准则。该表不是额外文档，而是HARA与SOTIF工作产品的连接件，确保安全目标与性能边界在同一场景语境下闭合。