ISO 21448 SOTIF — 预期功能安全

这一节先把“两个标准处理不同失效”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

ISO 26262 的 hazard 触发源是fault(随机硬件 / 系统性失效);SOTIF 的 hazard 触发源是 triggering condition(导致功能局限暴露的输入 / 工况)。

例 ADAS AEB(自动紧急刹车):

• 摄像头 ASIC 内部故障 → ISO 26262
• 大雨水珠遮挡 + 弱光 → 摄像头识别率掉 → SOTIF
• 司机以为 AEB 也能识别动物 → 撞到鹿 → SOTIF(误用)
• 训练集偏差导致漏识别黑色 SUV → SOTIF

两边的 hazard 都关联同一组 SG,但分析方法和缓解措施不同。

例:摄像头在 -40°C 启动时图像噪声大,识别率 < 80%。SM:启动时延迟 3s 让传感器自检 + 降级 ADAS 功能。

例:AI 模型在训练集没见过的"特殊形状的车"上识别率低。SM:多传感器融合(摄像头 + 雷达 + 激光雷达 cross-check)/ 不确定时降级到司机接管。

例:雷达在金属护栏附近多径反射误报。SM:与摄像头 fusion / 多帧时间一致性 check / OEM 路线优化。

例:用户在 L2 ADAS 下睡觉,DMS(司机监控)不工作。SM:DMS 强制激活 / 司机不响应 → 减速靠边停 / 更明显的警告。

收集所有已识别的 triggering condition + 对应车辆响应。典型 L3 项目:

• 1000+ 仿真场景(基础)
• 10000+ 路采场景(回灌仿真)
• N-million km 道路测试(高速 / 城市 / 复杂工况)

这一节先把“仿真 + HIL + 实车”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

L4/L5 自动驾驶要求统计学论证——比人类驾驶事故率低 X% → 需要 N 亿公里证据。RAND 研究:要证 L4 比人类驾驶事故率低 20% 需要约 110 亿英里测试(检测的效应量越小、所需里程越大;证"低 50%/安全 2×"这类更大效应反而只需约 50 亿英里)。这促使行业用仿真 + reduced-order model 替代纯路测。

系统声明:AEB-P 在行人 TTC ≤ 1.8 s 时施加 ≥ 0.7g 制动减速,优先级高于驾驶员加速指令。运行设计域(ODD):车速 V ≤ 60 km/h、城市/郊区道路、日光或人工照明、行人完全位于前向传感器视野内(±20° 横向)。ODD 外系统退出并告警,不保证功能。

SOTIF 分析的输入是导致"性能局限暴露"的前因,而非故障。下表列出 AEB-P 的 5 类典型 triggering condition:

SOTIF 目标是把 Area 3(未知不安全)的暴露率降到可接受水平:

• TC-01(逆光)→ Area 2(Known Unsafe):已在验证中识别。SM:增加逆光检测算法,在辐照超限时主动降级为 AEB-P Level 1(告警,不制动)并在仪表板显示。
• TC-02(复合降雨夜间)→ Area 2:已识别,两传感器置信度同时 < 阈值则降级退出,HMI 告警。
• TC-03(部分遮挡)→ Area 2 + 残余 Area 3:检出延迟 200ms 令有效 TTC 缩短为 1.6s;以 V = 60 km/h 计算,仍需制动距离 20.3m(0.7g),而可用距离 26.7m(1.6s × 16.7 m/s)—— 余量 6.5m,典型速度下仍安全;但 V = 60 km/h + TC-01 逆光叠加 + 遮挡使感知延迟扩大至 > 400ms 时余量收至 0,滑入 Area 3,需靠路测发现。
• TC-04(训练集偏差)→ Area 2(经数据扩增后);上线前须用 ODD-specific 数据验证覆盖率 > 95%。
• TC-05(ODD 超越)→ Area 1(Known Safe for system):功能本就退出并告警,但属合理可预见误用——设计出路:退出时强制 1 次视觉 + 声音双路告警,确认驾驶员认知。

ISO 21448:2022 §9 要求验证论证"Area 3 暴露下的危害事件率已充分降低",实践中采用四层级联:

Kalra & Paddock 的 RAND 2016 研究表明,若要通过纯路测在统计意义上证明 L4/L5 AV 比人驾驶安全 20%,需要约 110 亿英里测试数据,按 100 辆全天候行驶估算需超过百年,这正是仿真 + field monitoring 组合无可替代的原因——路测只能发现 Area 2 边界变体,Area 3 的系统性覆盖必须靠场景生成 + 统计论证。

实际项目里,AEB-P 的完整安全论证由三层构成:

1. ISO 26262 层:AEB-P 失效(MCU stuck / 传感器硬故障)→ ASIL C(S3+E3+C2, 典型值),通过 FMEDA 和架构分解覆盖随机硬件失效。
2. SOTIF 层(ISO 21448):上述 TC-01~TC-05 均由功能局限驱动,不涉及故障;通过 4 层验证论证 Area 3 可接受。
3. 网络安全层(ISO 21434):攻击者可能伪造雷达点云注入误触发;通过 TARA + 秘钥管理 + V2X 签名覆盖。

三层 Safety Case 共用 V-Cycle / Safety Plan 框架,共用同一 Safety Manager,独立出具 Safety Report。SOTIF 层不输出 ASIL 等级——ISO 21448:2022 在范围界定章节明确 SOTIF 目标不等同于 ASIL 赋级,给 triggering condition 标注 ASIL 是常见误解。

ISO 21448:2022 在引言及范围章节明确规定:SOTIF 的安全目标不等同于 ISO 26262 的安全目标,不应赋予 ASIL 等级。实践中常见"TC-02 目标:ASIL B"的写法,从标准角度无意义——ASIL 是针对故障(fault)引起的危害,而 SOTIF 管功能局限引起的危害;两套方法论的数学基础不同(一个是 FIT/PMHF,另一个是验证论证的充分性)。正确写法:为每个 triggering condition 建立 SOTIF goal(表述为"TC-02 在 ODD 内的暴露率降低至可接受水平",用验证论证覆盖)。

Area 3 的本质是"已评估分析空间之外的未知场景",因此从定义上永远不可能被证明为空——你只能缩减它。把"验证了 10 万场景"解读为"Area 3 = 0"是认知错误;正确论证是:"已识别的 Area 3 场景类型均通过扩充场景库转移至 Area 1/2,残余 Area 3 的暴露率经统计论证在可接受范围内。"Field monitoring 是唯一能持续发现 Area 3 新成员的机制。

HARA 的 hazard 触发源是 fault,输出是 FSR/SG;SOTIF 的 triggering condition 是功能局限,二者在物理上不重叠。把 HARA Table 里的"AEB-P fails to activate"当作 SOTIF 的分析起点,会漏掉"AEB-P 误触发"等双向场景——SOTIF 必须同时分析"漏检(under-trigger)"与"误触发(over-trigger)"。误触发在城市 30 km/h 时可能造成追尾,属于独立的 triggering condition 家族。

为 ISO 26262 ASIL C 故障设计的 SM 是"检测故障 → 关闭 AEB-P → 进入 fail-safe"。这个 SM 一旦触发,SOTIF 层就少了一层保护——在大雨夜间(TC-02)本已降级的状态下,再因 26262 SM 关闭功能,导致行人完全无保护。需要在联合 Safety Case 里明确分析 SM 交互:26262 的 fail-safe 动作是否影响 SOTIF 场景的暴露。

项目初期往往把"不合理使用"排出去(如"用户不会在 V > 100 km/h 时期待 AEB-P 工作")。但 ISO 21448:2022 要求评估"用户在真实行为模型下可合理预见的误用"(reasonably foreseeable misuse),上限不是使用手册禁止条款,而是用户群体中发生概率足够高的行为。AEB-P 在 G/B 级乘用车的典型误用包括:道路施工区 ODD 外使用(施工车辆吊臂进入视野 → 假阳性制动 → 追尾风险),属于必须分析的 TC。

SOTIF 验证组合(仿真场景库、路测、field monitoring 数据)都是在特定地理 ODD 下收集的。把已在德国完成 SOTIF 验证的 AEB-P 直接推向印度市场(路面涂鸦多 → TC-03 遮挡类频率不同;摩托车/三轮车密度高 → TC-04 训练集分布 shift)时,Area 3 的范围会系统性地扩大,必须补充 India-ODD 特定测试并更新场景库。

L3 系统在到达 ODD 边界或自身能力限制时发出 Takeover Request,要求司机接管。SOTIF 分析必须把"TOR 发出后 10 s 内司机未能完全接管"列为 triggering condition——此时系统处于"功能局限状态:自动驾驶算法无法继续,人类驾驶员尚未接管"的夹缝,是 L3 SOTIF 的最高风险窗口。SM 通常是 MRC(Minimal Risk Condition,如自动靠边减速停车),并要求评估 MRC 本身对后方交通的影响。

车速 V = 61 km/h(ODD 上限 60 km/h),系统依规退出 AEB-P 并发出告警;驾驶员看到告警但认为仅差 1 km/h 不影响——同时 TC-03 遮挡场景出现,行人从停车位侧面穿出。在 ODD 外 1 km/h 的点,AEB-P 无保护,但驾驶员反应时间约 1.5 s,TTC = (61/3.6) × 1.5 = 25.4 m,若行人在 20 m 处穿出则已无法制动。设计出路:仅靠 HMI 告警不够——需要评估"ODD 临界过渡区"(如 58-65 km/h)的行人暴露统计,并在 Safety Case 中加入"边界区降级"的论证(如保留告警制动能力至 65 km/h)。

大雨 30 mm/h(TC-02)+ 对向车辆灯光反射(TC-01 变体)+ V = 55 km/h:摄像头 SNR 下降 10 dB + 雷达多径干扰;单传感器降级各自在 Area 2 已有 SM(降级退出);两者同时超阈值但任意单一的置信度评估器均未达到退出阈值 → 融合层未触发降级 → 系统仍在正常工作状态但实际感知能力已跌至不可接受水平。该叠加场景极可能在 Area 3:每类 SM 都只针对单一 TC 的超限,多 TC 并发的感知能力综合评估需要专门建模。设计出路:部署 Sensor Health Monitor,融合各传感器的实时置信度指标做综合评估,任意两路同时降级超阈值则主动降级功能。

上市后 field monitoring 的数据主要来自早期部署市场(如德国、日本),对应的道路场景分布存在系统性偏差:欧洲城市行人密度 vs 亚洲交叉路口摩托车/电动车密度差异;北美宽马路 vs 日本窄巷。Field monitoring 发现的 Area 3 事件频率低,被解读为"Area 3 已充分缩小",但实际原因是新市场 ODD 尚未有足够曝光。正确处理:在 ODD 扩展到新地区时,明确设定 field monitoring 在新地区的数据采集目标(公里数或事件数),并对 Area 3 做 regional gap analysis 后方可出具联合 Safety Case。