一句话理解功能安全

功能安全 = 系统在遇到故障（硬件坏了/软件bug/感知异常）时，仍然能保证不发生不可接受的人身伤害

没有功能安全：激光雷达死机 → 感知丢失 → 车辆继续行驶 → 撞车

有功能安全：激光雷达死机 → 感知模块报错 → 安全监控介入 → 车辆安全靠边停车

功能安全不关心"系统能不能做好自动驾驶"——那是算法团队的职责。功能安全关心的是**“当系统出问题时，怎么保证不撞死人”**。

第一部分：ISO 26262基础

ISO 26262是道路车辆功能安全的国际标准，源自工业通用的IEC 61508。该标准覆盖了从概念设计到生产释放再到退役的整个安全周期。

核心概念体系

在学习ISO 26262之前，需要先建立它的概念体系。这些术语的精确含义与日常使用存在差异，需要仔细区分。

故障 (Fault)：系统的异常状态。可以是硬件故障（如电阻短路）、软件故障（如空指针异常）或系统故障（如设计缺陷）。故障是"因"。

失效 (Failure)：系统或组件丧失执行所需功能的能力。当故障被激活时，就会发生失效。例如，电阻短路（故障）导致供电电压异常（失效）。失效是"果"。

危险 (Hazard)：系统失效可能导致伤害的潜在状态。例如，刹车失效（失效）与车辆正在行驶（运行场景）结合，构成"无法制动"的危险。

风险 (Risk)：危险发生的概率与伤害严重程度的组合。ISO 26262的目标就是将风险降低到可接受的水平。

安全目标 (Safety Goal)：对系统在特定危险下必须满足的安全要求的顶层描述。例如：“在刹车指令发出后的500ms内，制动力必须达到需求的90%。”

安全状态 (Safe State)：系统失控后可以进入的一种不会对人员造成伤害的状态。最典型的安全状态就是"停止"——车辆刹车停稳，然后保持静止。

ASIL等级：风险的量化

ASIL (Automotive Safety Integrity Level) 是ISO 26262中最广为人知的概念。它将功能安全要求分为四个等级：ASIL A（最低）到ASIL D（最高）。还有一个QM (Quality Management) 级别，表示仅需标准质量管理，无需功能安全流程。

ASIL等级由三个参数决定：

$$ ASIL = f(Severity, Exposure, Controllability) $$

严重度 (Severity, S)：伤害的严重程度。

  • S0：无伤害
  • S1：轻伤（如擦伤）
  • S2：重伤（如骨折）
  • S3：致命伤

暴露率 (Exposure, E)：系统运行场景中危险出现的概率。

  • E0：几乎不会发生
  • E1：极少发生（<1%的驾驶时间）
  • E2：偶尔发生（1%-10%）
  • E3：经常发生（10%-50%）
  • E4：几乎持续发生（>50%）

可控性 (Controllability, C)：驾驶员或乘客能否通过适当反应避免伤害。

  • C0：完全可控
  • C1：简单可控
  • C2：一般可控
  • C3：难以控制或无法控制

三者的组合确定ASIL等级：S3 + E4 + C3 = ASIL D（最高安全等级）；S1 + E1 + C1 = QM（仅需质量管理）。

理解ASIL的工程意义：

ASIL等级直接决定了开发过程中需要投入的安全工程工作量。对于ASIL D级别的功能：

  • 硬件需要达到99%以上的诊断覆盖率
  • 软件需要双模冗余或更高级别的容错机制
  • 开发流程需要独立的安全评审和验证团队
  • 测试覆盖率要求远高于低ASIL级别

在自动驾驶中，转向、制动、动力等核心执行器相关的安全功能通常被归类为ASIL D。而某些非安全关键功能（如信息娱乐系统）可能仅需QM级别。

HARA分析

HARA (Hazard Analysis and Risk Assessment) 是ISO 26262概念阶段的核心活动，也是确定ASIL等级的方法论。

HARA的完整流程分为三步：

第一步：场景分析 (Situation Analysis)

识别系统在生命周期中可能处于的所有运行场景。对于自动驾驶来说，场景分析需要覆盖正常驾驶、泊车、充电/加油、维护、维修等全部阶段。

每个场景进一步细分为"运行模式"和"环境条件"。例如，“高速公路夜间小雨中行驶"就是一个具体的场景组合。

第二步：危险识别 (Hazard Identification)

对每个场景，分析系统失效可能导致的危险。以自动紧急制动(AEB)系统为例：

失效模式运行场景危险事件
意外触发制动高速行驶后车追尾
制动不足障碍物前与前车碰撞
制动力不平衡湿滑路面车辆失控
制动响应延迟行人横穿行人碰撞

第三步：风险评估 (Risk Assessment)

对每个危险事件，评估S、E、C三个参数，确定ASIL等级。上例中，“制动不足 → 与前车碰撞"在高速场景下的S通常为S3（致命伤），E为E3（经常遇到），C为C2（一般可控），综合得到ASIL C或D。

HARA实践中的典型经验数据：

  • 一个中等复杂度的自动驾驶系统（覆盖L2+功能）通常会产生50-150个危险事件
  • 每个危险事件对应1-2个安全目标
  • ASIL D级别的安全目标通常占总量10-20%，ASIL B/C占30-40%，QM占30-50%

第二部分：ISO 21448 (SOTIF)

ISO 26262主要针对的是"系统故障导致的安全问题”（比如传感器坏了、软件算错了）。但自动驾驶面临一个更根本的挑战：即使所有硬件和软件都没有故障，仅仅因为算法能力不足（看不准、预测错），也可能导致危险。

这就是SOTIF (Safety Of The Intended Functionality)——预期功能安全——要解决的问题。

从26262到21448

ISO 21448标准的核心洞察是将场景分为四个象限：

已知场景未知场景
安全场景已知且模型处理正确（Quadrant I）场景未知但无害（Quadrant IV）
不安全场景已知但模型处理不好（Quadrant II）场景未知且模型处理不好（Quadrant III）

ISO 26262负责的是Quadrant I到II的边界——已知场景中，如果系统因为故障导致不安全，那是26262的范畴。

SOTIF负责的是Quadrant II和Quadrant III——系统没有故障，但算法能力不足以安全处理场景。

工程解读：

  • Quadrant II（已知不安全）：我们明确知道哪些场景当前模型处理不好（如强逆光、大雨天雾、无保护左转）。对这些场景，需要量化感知不确定性、设计降级策略、或者在ODD中排除。
  • Quadrant III（未知不安全）：我们不知道模型在哪些场景中会失败——这就是最难处理的部分。SOTIF要求通过大量的路测和仿真暴露这些未知场景，将其转化为已知场景（迁移到Quadrant II），然后解决或排除。

SOTIF的核心流程

SOTIF的整体开发流程包括以下环节：

1. 功能规范分析与系统定义

明确系统的预期功能和非预期功能。例如：自适应巡航(ACC)的预期功能是"保持设定车速和跟车间距”，非预期功能包括"在施工区域错误识别限速标志"。

2. 安全场景识别与评估

通过以下手段识别不确定性来源：

  • 传感器局限性（雨、雾、逆光、低对比度等）
  • 算法局限性（感知模型在特定场景的精度退化）
  • 系统局限性（计算延迟导致的不确定性）

3. 功能改进 —— 减少不安全场景

通过算法改进降低Quadrant II和Quadrant III的规模：

  • 提升感知模型在长尾场景的精度
  • 引入感知不确定性量化模块
  • 设计冗余传感器方案覆盖感知盲区

4. 安全机制验证 —— 证明残余风险可接受

对于改进后仍然存在的残余风险，通过以下方式论证：

  • 定量分析：用统计数据证明风险低于可接受阈值
  • 降级策略：证明在已知不安全场景中，系统能及时降级到安全状态
  • 运行设计域(ODD)限制：在无法解决的场景中排除使用（如大雨天暂停运行）

5. 全生命周期安全评估

SOTIF不是一次性工作。随着路测数据的积累、ODD的扩展、新场景的暴露，需要持续更新安全分析和安全机制。

第三部分：VLA模型的安全工程实践

现在我们把功能安全和SOTIF的语言落地到VLA (Vision-Language-Action) 模型的具体实践中。VLA模型用大语言模型作为推理后端，直接输出驾驶决策，这在安全工程上带来了全新的挑战。

感知不确定性量化

VLA模型需要环境感知作为输入。无论是直接处理视觉token还是接收BEV特征，感知模块的不确定性都会传递到决策模块。对不确定性的量化和处理是SOTIF在VLA模型中最直接的落地。

三类不确定性：

1. 偶然不确定性 (Aleatoric Uncertainty)

源于传感器或环境的固有噪声。比如雨天LiDAR点云的稀疏性、摄像头在弱光下的信噪比降低。

量化方法：对于每个感知输出，模型同时输出一个不确定性估计。例如，检测头的输出不仅包含边界框 $(x, y, w, h)$，还包含方差 $\sigma^2$：

$$ \hat{y} = f_\theta(x), \quad \hat{\sigma}^2 = g_\theta(x) $$

训练时使用不确定性加权的损失函数：

$$ \mathcal{L} = \frac{\lVert y - \hat{y} \rVert^2}{2\hat{\sigma}^2} + \frac{1}{2}\log\hat{\sigma}^2 $$

2. 认知不确定性 (Epistemic Uncertainty)

源于模型的"知识盲区"——模型训练数据中没有覆盖的场景。比如在训练数据中从未出现过的工程车辆。

量化方法：使用Monte Carlo Dropout、Deep Ensemble或直接学习"不知道"的阈值。在VLA模型中，一个实用方案是用模型对备选轨迹的logit值的方差来衡量认知不确定性。

3. 分布外检测 (OOD Detection)

当输入与训练数据分布显著不同时，模型应该"承认自己不知道"而不是强行输出一个错误的结果。

常用方法包括基于特征距离的方法（Mahalanobis距离到训练集特征中心的距离）：

$$ D_{Mahalanobis}(x) = (z - \mu_{train})^T \Sigma_{train}^{-1} (z - \mu_{train}) $$

其中 $z$ 是模型的中间层特征，$\mu_{train}$ 和 $\Sigma_{train}$ 是训练集特征的均值和协方差矩阵。

当 $D_{Mahalanobis}$ 超过某个阈值时，模型判定当前输入为OOD，触发降级策略。

工程落地经验：感知不确定性量化的核心挑战不是"能不能算"，而是"阈值怎么设"。阈值太宽松会频繁触发不必要的降级（影响可用性），阈值太严格则漏掉真正危险的不确定性。实践中通常通过收集大量路测数据，分析不确定性分数与实际驾驶风险的对数关系来确定阈值。

降级策略 (Degradation Strategy)

降级策略是功能安全中的"最后一道防线"——当系统检测到自身无法安全处理当前场景时，自动降低功能级别。

三级降级体系：

级别检测到的问题行为对用户体验的影响
Level 1感知不确定性轻微升高降低车速上限(如从80降到60km/h); 增加跟车距离基本不可感知
Level 2感知不确定性显著升高; 单传感器失效; VLA模型置信度过低通知驾驶员准备接管; 限速到40km/h; 切换到冗余传感器方案驾驶员需要关注路况
Level 3多传感器失效; 系统严重异常; 严重OOD最小风险策略(MRM, Minimal Risk Maneuver): 安全靠边停车立即接管或系统自动执行MRM

MRM的设计：最小风险策略是降级的终极状态。MRM需要设计为在安全冗余系统上执行，不能依赖于引发降级的那套感知系统。典型的MRM流程：

  1. 减速到安全速度（通常10-15km/h，保证在检测到障碍物时有足够刹车距离）
  2. 打双闪灯
  3. 缓慢靠向右侧路肩或紧急停车带
  4. 停车后挂入P挡，拉起电子手刹
  5. 通过车联网上传故障日志和降级原因

整个MRM过程需要设计为在单传感器失效、单计算单元失效的情况下仍然可执行。这意味着MRM的执行路径必须经过冗余设计和独立供电。

安全监控器 (Safety Monitor)

安全监控器是一个独立于主算法模型的安全监控系统。它的核心原则是：不依赖于被监控对象来判断自身的可靠性。

安全监控器的设计原则：

  1. 独立性：监控器使用与主模型不同的传感器、不同的计算平台、不同的算法原理。例如，主模型使用基于神经网络的视觉感知，监控器可以使用基于传统计算机视觉的校验算法。
  2. 简单性：监控器应该足够简单，使得它的行为可以被正式验证。这通常意味着使用确定性算法而不是深度学习模型。
  3. 实时性：监控器的延迟必须低于主模型的决策周期，通常要求在30-50ms以内输出安全评估结果。

监控器的典型工作模式：

主安模全型监输步输控入骤出器::123::...主{模独→→→一输轨型立致出迹输验制轨占性::出证动迹用检：距曲预查{[+用离率测：安w独是是是当全a独立否否否前标y立感符超冲输志p传知合限突出:o感数物??与i器据理前Pn数校约((NAt据验束曲自帧Ss主?率车输S]模半规出/,型径划是W的轨否A速推^>迹一R度理2是致N:/根否？/2据与加V1a当独速I2前立度Om<车检/L/速测转Ass的的向T,到最其变I最小他化O转近转物是N向障弯体否,角碍半重合:物径叠理推)))？荐0动.作0:3rNaOdN}E/DEGRADE/MRM}

VLA模型特有的安全监控挑战：

VLA模型使用大语言模型的token generation作为推理过程。这种"非结构化推理"给安全监控带来了新问题：

  1. 推理过程不可观测：传统规划模型输出明确的轨迹点，可以直接校验。VLA模型输出的是自然语言/action token，防御性校验的输入维度完全变了。
  2. 幻觉问题：大模型可能在输出中生成合理但事实错误的推理。例如，“前方没有障碍物”（但实际有施工区域），模型仍然生成了一个合理的加速轨迹。
  3. 延迟波动：大模型推理的延迟可能随输入长度和复杂度显著变化，这与功能安全要求的确定性延迟时间存在冲突。

应对方案：在实践中，VLA模型通常采用"混合架构"——用大模型做高层意图推理（如"前方车流密集，准备跟车"），但最终的动作执行仍然通过一个固定的、可验证的规划器来生成。安全监控器监控的是最终输出的轨迹，而不是大模型的推理过程。

第四部分：功能安全的工程现实

安全文化 vs 安全程序

功能安全标准最重要的贡献不是那些条条框框，而是建立了一种"安全的思考习惯"。ISO 26262让整个开发团队养成一种条件反射：每做一个决策，都要问"如果这里出问题了会怎么样？"

但在工程现实中，很容易陷入"为了过审而走流程"的形式主义——HARA分析成了填表格，安全评审成了走过场。

一个好的功能安全实践，至少要做到三件事：

  1. 安全工程师嵌入开发团队：安全不是独立于开发的"监管活动"，安全工程师需要实际参与设计评审
  2. 安全工件与实际代码关联：每个安全目标和安全机制都需要通过git commit或者具体的代码变更来追溯
  3. 安全测试与功能测试融合：功能安全验证不是独立于功能测试的额外工作，而是测试计划的一部分

安全冗余的工程成本

每增加一级安全冗余，都意味着硬件成本、开发工程量、系统复杂度的显著上升。以ASIL D的转向系统为例：

  • 单一控制器方案：硬件成本X，功能安全等级无法达ASIL D
  • 双控制器热备方案：硬件成本约2.3X，工具链成本增加约1.5倍，可以实现ASIL D
  • 三模冗余方案：硬件成本约3.5X，同步机制复杂度指数级上升，开发周期增加2倍以上

在实际量产中，OEM会根据ASIL等级的精确定义来决定冗余的具体实现方式——不是"越冗余越好"，而是"刚好达到安全目标即可"。

SOTIF验证的数据量估算

SOTIF的验证要求是：残余风险必须低于可接受水平。但"可接受水平"是多少？业界还没有一个完全统一的标准，但一个常见的参考是：L4系统要求每百万公里发生致命事故的频率低于1次。

要达到这个置信水平，需要多少路测数据？假设真实世界中致命事故的发生率为每百万公里0.5次（这是人类驾驶的平均水平），要在95%置信水平下验证系统致命事故率不超过1次/百万公里，需要大约300万公里的路测数据。

300万公里对应一个50辆车的测试车队，每辆车每天跑300公里，连续运行200天。这还不包括在罕见场景中需要的大量仿真数据。这就是SOTIF验证令人望而生畏的地方——安全不是一个技术问题，在更大程度上是一个数据规模问题。

关键论文与延伸阅读

  1. ISO 26262:2018: “Road vehicles — Functional safety” — 功能安全主标准，共12个部分
  2. ISO 21448:2022: “Road vehicles — Safety of the intended functionality” — SOTIF标准正文
  3. HARA分析实践: R. Palin et al., “HARA: A Practical Guide for Automotive Systems”, SAE 2020. — HARA分析的方法论和工程案例
  4. 感知不确定性量化: A. Kendall et al., “What Uncertainties Do We Need in Bayesian Deep Learning for Computer Vision?”, NeurIPS 2017. — 偶然不确定性和认知不确定性的经典区分
  5. 自动驾驶安全框架: P. Koopman et al., “Safety First: A Safety-First Approach to Autonomous Vehicle Development”, 2019. — 基于SOTIF理念的自动驾驶安全框架白皮书
  6. MRM设计: S. Shalev-Shwartz et al., “On a Formal Model of Safe and Scalable Self-driving Cars”, arXiv 2017. — 最小风险策略(MRM)的理论基础

功能安全不生产自动驾驶的能力，但它定义了这个能力的"底线"。一个好的安全系统应该让用户感觉不到它的存在——直到真的出问题的那一刻，它才是所有人最感激的那个默默工作的组件。