4. 危害分析与风险评估

各位好,欢迎来到第4章。前面我们聊了危害分析与风险评估,得出了ASIL等级。但光有等级还不够,你得把「到底要保证什么」写清楚。这就是安全目标定义要做的事。

我个人习惯把安全目标比作「系统的底线承诺」。它不能含糊,不能有歧义。你想想看,如果连目标都写不清楚,后续的验证和确认工作根本没法开展。今天我们就来拆解安全目标的三个核心要素:语法结构、安全状态描述、容错时间间隔。

4.1 安全目标的语法结构

安全目标不是写作文,它有固定的句式。ISO 26262虽然没有强制规定语法模板,但行业里已经形成了共识。我建议你按照这个结构来写:

标准语法模板:

[系统/功能] 应避免 [危害事件],在 [运行场景] 下,通过 [安全机制] 实现,ASIL [等级]。

举个例子,这样写就对了:

SG-01: 电动助力转向系统(EPS)应避免非预期的转向扭矩输出,
       在车辆行驶速度 > 10 km/h 时,
       通过扭矩传感器监控与控制器自检实现,
       ASIL D。

这里有几个关键点,我踩过坑,跟大家说说:

  • 主语要明确:别写「系统应避免...」,要写「某某系统」或「某某功能」。我在一个项目里见过「系统应避免非预期加速」,结果后来发现这个「系统」指的是整车还是动力域?扯皮了两个月。
  • 危害事件要具体:用HARA阶段定义的那个危害事件,别自己重新发明一个。
  • 运行场景要可观测:比如「车速>10 km/h」就比「车辆正常行驶」好得多。后者没法验证。
  • ASIL等级必须写:这是后续分解和分配的依据。

我的小技巧: 每个安全目标都配一个唯一的ID,比如SG-01、SG-02。这样在追溯矩阵里一目了然。我曾经吃过没有ID的亏,评审时大家指着同一句话说是不同的目标,场面一度很尴尬。

4.2 安全状态的描述

安全目标定义了「要避免什么」,安全状态则定义了「出了事怎么办」。说白了,就是当系统检测到故障时,它应该进入一个什么样的状态,才能保证不违反安全目标。

安全状态描述要回答三个问题:

  1. 系统做什么? 比如切断动力、输出零扭矩、进入降级模式。
  2. 系统不做什么? 比如不响应驾驶员请求、不执行自动功能。
  3. 这个状态持续多久? 是永久保持,还是等待复位?

我给大家看一个实际项目中的例子:

安全目标 SG-02: 制动系统应避免非预期的制动力施加。
安全状态描述:
  - 当检测到主控制器故障时,系统应在 50ms 内切换至冗余控制器。
  - 冗余控制器输出零制动力请求,并点亮制动系统故障灯。
  - 该状态保持至车辆完全停止且点火开关关闭。

注意: 安全状态不是「系统关机」。很多新手工程师喜欢写「系统进入安全状态」,但没定义这个状态到底是什么。我曾经在一个项目里看到安全状态写的是「系统停止工作」,结果测试时发现系统停了,但方向盘锁死了——这比不停还危险。

安全状态可以分为几类,我整理了一个表格:

类型 描述 示例
被动安全状态 系统停止输出,进入休眠或关闭 EPS 输出零扭矩
降级安全状态 系统以受限功能继续运行 ACC 降级为普通巡航
冗余安全状态 切换至备份通道或冗余控制器 制动主控切换至冗余控制器
紧急操作状态 系统执行紧急动作后停止 安全气囊点爆后断电

4.3 容错时间间隔(FTTI)

容错时间间隔,英文叫 Fault Tolerant Time Interval,简称 FTTI。这个概念很多人理解偏了。它不是「系统能撑多久」,而是「从故障发生到违反安全目标的最长时间」。

我换个说法:你有一个安全目标「转向不能非预期输出」。如果转向控制器坏了,从坏掉的那一刻开始,到车轮真的开始乱转、导致车辆失控,中间有多长时间?这个时间就是 FTTI。

FTTI 的确定要考虑三个因素:

  • 物理系统的惯性:机械系统有响应延迟,比如转向管柱的扭转刚度、电机的响应时间。
  • 人的反应时间:驾驶员需要时间介入。一般取 0.5s 到 2s。
  • 车辆动力学边界:车辆在什么时间内还能保持可控。

FTTI 的典型值(来自实际项目经验):

  • 制动系统:100ms - 500ms
  • 转向系统:200ms - 1s
  • 动力系统:500ms - 2s
  • ADAS 感知系统:100ms - 400ms

这里有个容易混淆的概念:FTTI 和 FDTI(故障检测时间间隔)不是一回事。FDTI 是系统检测到故障需要的时间,它必须小于 FTTI。你想想看,如果检测就要 1 秒,但 FTTI 只有 500ms,那系统还没检测到故障,危害就已经发生了。

我画了一张图,帮大家理清这几个时间参数的关系:

安全时间参数关系图 故障 检测 响应 危害 FDTI FRTI FTTI(容错时间间隔) FTTI = FDTI + FRTI + 安全裕度 FDTI: 故障检测时间 | FRTI: 故障响应时间 | 安全裕度: 通常取 20%-30%

从图上可以看得很清楚:故障发生后,系统需要先检测(FDTI),再响应(FRTI),这两段时间加起来必须小于 FTTI。我建议你在定义 FTTI 时,留出至少 20% 的安全裕度。别卡着极限值设计,否则测试时稍微有点偏差就过不了。

避坑指南: 我曾经在一个 EPS 项目里,FTTI 定了 400ms,但 FDTI 就占了 350ms,留给响应的时间只有 50ms。结果硬件团队说「50ms 不够电机响应」,最后只能改 FTTI。所以我的建议是:先定 FTTI,然后反推 FDTI 和 FRTI 的分配,别拍脑袋。

4.4 三者如何协同工作

安全目标、安全状态、FTTI 不是三个独立的东西。它们是一个整体。我习惯这样描述它们的关系:

  • 安全目标:定义「不能发生什么」。
  • 安全状态:定义「如果出事了,系统应该变成什么样」。
  • FTTI:定义「从出事到变成安全状态,最多能花多长时间」。

举个例子,把它们串起来:

安全目标 SG-03: 动力电池系统应避免热失控。
安全状态描述:
  - 当检测到单体电压异常或温度超过 60°C 时,
  - BMS 应在 100ms 内断开主继电器,
  - 并激活主动冷却系统,
  - 该状态保持至维修人员手动复位。
FTTI: 500ms(从单体温度异常到热失控发生的时间窗口)

你看,这样写出来,整个安全概念就清晰了。后续做安全架构设计、安全机制分配,都有了明确的输入。

最后提醒一句: 安全目标定义阶段最容易犯的错误是「过度设计」。我见过有人把安全目标写得像安全机制一样详细,比如「系统应通过三路冗余比较来避免...」。别这样。安全目标只关心「要保证什么」,不关心「怎么保证」。怎么保证是后面安全架构设计的事。你现在写死了,后面设计空间就没了。