第3章预期功能安全基础

第3章：预期功能安全基础：ISO 21448标准概述、触发事件、功能不足与性能局限

3.1 为什么我们需要ISO 21448？

聊到预期功能安全，我得先说说自己的一个经历。几年前我参与一个L3级自动驾驶项目，测试时发现车辆在暴雨天突然急刹车——明明前方没有任何障碍物。传统功能安全（ISO 26262）查了个遍，硬件没坏，软件没bug。后来才发现，是毫米波雷达在强降雨下把雨滴反射误判成了障碍物。

你看，这不是“系统坏了”，而是“系统在特定场景下能力不够”。这就是预期功能安全要解决的问题。

ISO 21448标准，全称是“道路车辆—预期功能安全”。它专门处理那些因系统功能不足或性能局限导致的安全问题。说白了，就是当系统本身设计没问题、硬件也没坏，但在某些场景下就是“搞不定”的时候，我们该怎么办。

核心区别一句话：

功能安全（ISO 26262）：处理系统故障（硬件随机失效、软件系统失效）
预期功能安全（ISO 21448）：处理系统在无故障情况下的功能不足

3.2 ISO 21448的核心框架

我个人习惯把ISO 21448的流程分成三大块：

识别：找出所有可能的触发事件
评估：分析这些事件是否会导致危害
改进：通过设计或验证手段降低风险

嗯，这里要注意，ISO 21448不是要替代ISO 26262，而是互补。我见过不少团队把两者割裂开，结果项目后期发现大量遗漏场景，返工成本极高。

3.3 触发事件（Triggering Events）—— 一切问题的起点

触发事件，说白了就是“什么情况下系统会出问题”。我把它分为三类：

触发事件类型	举例	典型场景
环境因素	强光、暴雨、大雾、夜间	摄像头在逆光下无法识别交通标志
场景因素	复杂路口、施工区域、行人突然横穿	激光雷达在密集车流中无法区分相邻车辆
系统交互因素	多传感器融合冲突、通信延迟	摄像头和雷达对同一目标检测结果不一致

避坑指南：

我曾经在项目中犯过一个错误——只考虑了“典型”触发事件，忽略了“边界”情况。比如自动泊车系统，我们测试了标准车位，但没测试斜列式车位。结果量产前才发现，系统在斜列式车位前完全“懵了”。从那以后，我要求团队必须列出至少50个边界触发事件。

3.4 功能不足与性能局限

这两个概念容易混淆。我用自己的理解来解释：

功能不足：系统设计时就没考虑这个功能。比如你的ACC（自适应巡航）不支持识别静止车辆，这就是功能不足。
性能局限：系统有这个功能，但能力有限。比如摄像头能识别行人，但在夜间识别距离只有50米，白天能到100米。

你想想看，这两者处理方式完全不同。功能不足可能需要增加新的传感器或算法，而性能局限往往可以通过优化现有方案来改善。

3.5 如何系统性地识别触发事件？

我推荐一个方法，叫“场景-能力矩阵”。

// 场景-能力矩阵示例（伪代码）
struct Scenario {
    string weather;      // 晴天/雨天/雪天/雾天
    string lighting;     // 白天/黄昏/夜晚
    string roadType;     // 高速/城市/乡村
    string trafficDensity; // 稀疏/中等/密集
};

struct Capability {
    string sensor;       // 摄像头/雷达/激光雷达
    float range;         // 有效检测距离
    float accuracy;      // 检测精度
    string limitation;   // 已知局限
};

// 遍历所有场景组合
for each scenario in allScenarios:
    for each capability in systemCapabilities:
        if capability.limitation conflicts with scenario:
            addTriggeringEvent(scenario, capability);

嗯，这里要注意，组合数量可能爆炸。我建议先聚焦在“高风险场景”上，比如：

恶劣天气（雨、雪、雾）
低光照条件（黄昏、夜晚、隧道出入口）
复杂交通参与者（行人、自行车、动物）
特殊道路结构（急弯、坡道、施工区）

重要提醒：

触发事件识别不是一次性的工作。随着系统迭代、软件更新、甚至OTA升级，都可能引入新的触发事件。我建议每个开发迭代都重新审视一次触发事件清单。

3.6 从触发事件到安全目标

识别出触发事件后，下一步就是分析它是否会导致危害。举个例子：

触发事件：摄像头在隧道出口处因光线突变导致短暂“失明”

潜在危害：未能识别前方静止车辆，导致追尾

安全目标：在光线突变场景下，系统必须在200ms内恢复目标检测能力

这个安全目标，就是后续功能安全设计和验证的输入。你看，预期功能安全和功能安全在这里就衔接上了。

3.7 我的经验总结

做了这么多年预期功能安全，我总结了几条铁律：

别指望一次分析完所有触发事件。我见过最成功的项目，都是把触发事件识别做成持续迭代的过程。
重视实车测试数据。很多触发事件在仿真里根本发现不了，只有上路跑才能暴露。
团队里要有“悲观主义者”。做安全分析时，需要有人专门负责“找茬”，想象最坏的情况。

最后说一句，ISO 21448不是束缚，而是工具。它帮我们系统性地思考“系统在什么情况下会不够好”，而不是等到出事了才后悔。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录