4. 安全目标与安全状态：从危害到设计的桥梁
各位好，欢迎来到第四章。前面我们聊了危害分析与风险评估（HARA），搞清楚了系统在什么场景下会出危险。但光知道危险还不够，我们得把它转化成工程团队能执行的设计输入。这个转化的关键，就是安全目标和安全状态。
我个人习惯把这一章叫做“从危害到设计的桥梁”。你想想看，HARA 的输出是一堆 ASIL 等级和危害事件，但硬件工程师、软件工程师拿到这些，怎么开始干活？他们需要一个明确的、可量化的设计目标。安全目标就是这个目标，安全状态就是系统出问题后该往哪跑。
核心逻辑链：
危害事件 → 安全目标（顶层安全要求） → 安全状态（期望的系统行为） → 安全机制（具体实现） → FTTI（时间约束）
4.1 安全目标的定义与导出
安全目标（Safety Goal, SG）是干什么的？说白了，它就是针对每个危害事件，定义一条顶层的安全要求。ISO 26262 第 3 部分明确要求：每个危害事件都要对应至少一个安全目标。
我见过不少新手工程师，上来就写“系统不能失效”。这种目标太笼统了，没法验证。安全目标必须满足三个条件：具体、可验证、有时间约束。
举个例子。假设我们做电动助力转向（EPS）系统，HARA 分析发现一个危害事件：“车辆高速行驶时，转向系统非预期输出大角度转向力矩，导致车辆偏离车道”。对应的安全目标怎么写？
安全目标示例（EPS 系统）：
SG-01：在车辆速度 > 30 km/h 时，转向系统不得输出超过 ±5 Nm 的非预期转向力矩，ASIL D，FTTI ≤ 100 ms。
你看，这个目标包含了：
- 条件：车速 > 30 km/h
- 行为：非预期转向力矩 ≤ ±5 Nm
- ASIL 等级：D（最高等级）
- 时间约束：FTTI ≤ 100 ms
安全目标的导出过程，我建议遵循以下步骤：
- 从 HARA 表格中提取每个危害事件
- 定义“不发生什么”——即系统必须避免的危险行为
- 量化阈值——比如力矩、电压、温度的具体数值
- 分配 ASIL——继承自对应的危害事件
- 定义 FTTI——从危害发生到系统进入安全状态的最大允许时间
我的经验：安全目标不要写太多。一个中等复杂的 ECU，安全目标通常在 5~15 个之间。写多了，后面安全机制的验证工作量会爆炸。我曾经在一个项目中看到 40 多个安全目标，最后有一半是重复的，白白浪费了评审时间。
4.2 安全状态设计
安全状态（Safe State）是什么？就是系统在检测到故障后，要进入的一个不会导致危害事件发生的系统状态。
安全状态不是只有一个。我个人习惯把安全状态分为三类：
| 安全状态类型 | 描述 | 典型场景 |
|---|---|---|
| 完全关闭 | 系统停止所有功能，进入休眠或断电 | 安全气囊控制器检测到传感器故障 |
| 降级模式 | 系统部分功能受限，但维持基本安全操作 | 制动系统 ESP 故障，保留基础制动 |
| 跛行回家 | 系统以受限能力运行，允许车辆开到维修点 | 电机控制器过温，限制输出功率 |
设计安全状态时，有几个关键点要注意：
- 安全状态必须可验证——你能通过测试确认系统确实进入了该状态
- 安全状态必须可退出——通常需要钥匙电循环或故障消除后才能退出
- 安全状态本身不能引入新危害——比如突然断电可能导致转向锁死，那就不是安全状态
我曾经踩过的坑：在一个线控制动项目中，我们设计的安全状态是“切断制动助力”。结果发现，切断助力后驾驶员需要踩 3 倍的力才能制动，在紧急情况下根本刹不住。这就是安全状态本身引入了新危害。后来我们改成“保留基础助力，但限制助力幅度”。
4.3 安全机制概念
安全机制（Safety Mechanism）是实现安全目标、达到安全状态的具体技术手段。ISO 26262 第 5 部分和第 6 部分对安全机制有详细要求。
安全机制可以按功能分为三类：
- 故障检测机制——发现故障的存在
- 例如：CRC 校验、看门狗、自检程序、信号合理性检查
- 故障响应机制——在检测到故障后采取行动
- 例如：切换到冗余通道、触发安全状态、记录故障码
- 故障避免机制——从设计上防止故障发生
- 例如：物理隔离、冗余设计、降额设计
你想想看，一个安全目标通常需要多个安全机制共同实现。比如前面 EPS 的例子：
- 安全目标：非预期转向力矩 ≤ ±5 Nm
- 安全机制 1：扭矩传感器信号合理性检查（检测）
- 安全机制 2：双通道扭矩计算对比（检测）
- 安全机制 3：检测到不一致时，切断助力电机供电（响应）
- 安全机制 4：进入降级模式，保留基础机械转向（安全状态）
关键原则：安全机制本身也可能失效！所以对于 ASIL C/D 的系统，安全机制通常需要具备“诊断覆盖率”和“安全机制自身的独立性”。说白了，你不能用一个可能坏掉的东西去保护另一个东西。
4.4 容错时间间隔（FTTI）
FTTI（Fault Tolerant Time Interval）是 ISO 26262 里一个非常重要的时间参数。它的定义是：从故障发生到可能引发危害事件之间的最大时间间隔。
换句话说，FTTI 就是你的“救命时间”。系统必须在这个时间内完成故障检测、故障响应、进入安全状态这一整套动作。
FTTI 的组成可以分解为：
| 阶段 | 描述 | 典型时间占比 |
|---|---|---|
| 故障潜伏时间 | 故障发生到被检测到的时间 | 30%~50% |
| 故障响应时间 | 检测到故障后，执行安全机制的时间 | 20%~30% |
| 安全状态建立时间 | 系统从故障响应到完全进入安全状态的时间 | 20%~30% |
FTTI 怎么确定？我建议从两个方向入手：
- 自上而下：从危害事件分析，确定系统级 FTTI。比如制动系统，从制动失效到车辆失控可能只有 200 ms，那 FTTI 就不能超过 200 ms。
- 自下而上：从组件的响应时间出发，累加得到系统级 FTTI，然后看是否满足要求。
我的习惯：在项目初期，我会先定一个“保守的 FTTI”。比如系统分析下来 FTTI 需要 100 ms，我可能会先按 80 ms 去设计安全机制。为什么？因为后面集成测试时，各种延迟叠加，实际 FTTI 往往会比理论值大。留点余量，心里踏实。
FTTI 的分配是一个系统工程。举个例子，一个 EPS 系统的 FTTI 分配：
系统级 FTTI（安全目标要求）：100 ms
├── 故障检测时间（扭矩传感器自检）：30 ms
├── 故障确认时间（软件滤波 + 一致性检查）：20 ms
├── 故障响应时间（切断助力继电器）：15 ms
├── 安全状态建立时间（电机放电 + 状态确认）：25 ms
└── 设计余量：10 ms
注意：FTTI 不是越短越好。过短的 FTTI 会导致系统频繁进入安全状态，影响可用性。比如一个传感器偶尔出现毛刺，如果 FTTI 太短，系统可能还没确认故障就切断了功能，造成不必要的降级。所以 FTTI 的设计要在安全性和可用性之间找平衡。