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 安全状态的描述
安全目标定义了「要避免什么」,安全状态则定义了「出了事怎么办」。说白了,就是当系统检测到故障时,它应该进入一个什么样的状态,才能保证不违反安全目标。
安全状态描述要回答三个问题:
- 系统做什么? 比如切断动力、输出零扭矩、进入降级模式。
- 系统不做什么? 比如不响应驾驶员请求、不执行自动功能。
- 这个状态持续多久? 是永久保持,还是等待复位?
我给大家看一个实际项目中的例子:
安全目标 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 时,留出至少 20% 的安全裕度。别卡着极限值设计,否则测试时稍微有点偏差就过不了。
避坑指南: 我曾经在一个 EPS 项目里,FTTI 定了 400ms,但 FDTI 就占了 350ms,留给响应的时间只有 50ms。结果硬件团队说「50ms 不够电机响应」,最后只能改 FTTI。所以我的建议是:先定 FTTI,然后反推 FDTI 和 FRTI 的分配,别拍脑袋。
4.4 三者如何协同工作
安全目标、安全状态、FTTI 不是三个独立的东西。它们是一个整体。我习惯这样描述它们的关系:
- 安全目标:定义「不能发生什么」。
- 安全状态:定义「如果出事了,系统应该变成什么样」。
- FTTI:定义「从出事到变成安全状态,最多能花多长时间」。
举个例子,把它们串起来:
安全目标 SG-03: 动力电池系统应避免热失控。
安全状态描述:
- 当检测到单体电压异常或温度超过 60°C 时,
- BMS 应在 100ms 内断开主继电器,
- 并激活主动冷却系统,
- 该状态保持至维修人员手动复位。
FTTI: 500ms(从单体温度异常到热失控发生的时间窗口)
你看,这样写出来,整个安全概念就清晰了。后续做安全架构设计、安全机制分配,都有了明确的输入。
最后提醒一句: 安全目标定义阶段最容易犯的错误是「过度设计」。我见过有人把安全目标写得像安全机制一样详细,比如「系统应通过三路冗余比较来避免...」。别这样。安全目标只关心「要保证什么」,不关心「怎么保证」。怎么保证是后面安全架构设计的事。你现在写死了,后面设计空间就没了。