3. SBW系统级安全目标：转向功能安全目标定义、安全状态识别、故障容错时间间隔(FTTI)设定
好，我们进入第三章。这一章讲的是SBW系统级安全目标的落地。说白了，就是回答三个问题：转向系统到底要安全成什么样？出问题了怎么办？多久必须反应过来？
我个人习惯，做功能安全设计时，先不看具体电路，也不看软件架构。先盯着系统级的安全目标，把边界画清楚。边界画不清楚，后面所有工作都是白费。
3.1 转向功能安全目标定义
SBW和传统转向最大的区别是什么？机械解耦。方向盘和车轮之间没有物理连接了。这意味着一旦电子系统失效，驾驶员没有直接的机械备份可用。所以，安全目标的定义必须非常严格。
根据ISO 26262和实际项目经验，SBW系统通常需要定义以下几个核心安全目标：
| 安全目标编号 | 安全目标描述 | ASIL等级 | 关联危害场景 |
|---|---|---|---|
| SG-01 | 防止非预期的转向角度输入（误转向） | ASIL D | 高速行驶中方向盘突然自行转动 |
| SG-02 | 防止转向助力完全丧失（卡死） | ASIL D | 弯道中转向力矩突然消失 |
| SG-03 | 防止方向盘与车轮转角比例严重失调 | ASIL C | 变道时方向盘转30°，车轮只转5° |
| SG-04 | 防止路感反馈信号异常误导驾驶员 | ASIL B | 路面颠簸时方向盘反馈力矩突变 |
这里有个关键点：ASIL等级不是拍脑袋定的。它来源于危害分析和风险评估（HARA）。我在做第一个SBW项目时，团队差点把SG-03定成ASIL D，后来仔细分析了暴露概率和可控性，才调整为ASIL C。你想想看，如果所有目标都定成D级，开发成本和周期会翻倍，而且不一定有必要。
核心原则：安全目标必须可验证、可测试。不能写模糊的“系统要安全”，要写具体的“当检测到转角传感器信号偏差超过5°时，系统必须在100ms内进入安全状态”。
3.2 安全状态识别
安全目标定义好了，接下来要回答：出故障了，系统往哪儿跑？这就是安全状态识别。
SBW系统不像传统转向，坏了还能靠机械连杆硬拽。SBW的安全状态不是单一的，而是分级的。我把它归纳为三种典型安全状态：
- 完全功能状态（Normal）：所有功能正常，无故障。
- 降级功能状态（Degraded）：部分功能受限，但转向基本能力保留。比如：路感反馈减弱，但转向执行器仍可控。
- 安全停止状态（Safe Stop）：系统无法维持转向功能，必须请求驾驶员接管或触发紧急停车。
嗯，这里要注意。很多工程师容易犯一个错误：认为安全状态就是“停机”。但在高速公路上，突然让转向系统停机，那才是最大的危险。所以，安全状态的选择必须结合车辆动态。
我的经验：在降级功能状态下，建议保留至少50%的转向能力。我曾经在项目中遇到过，降级策略太激进，直接切到30%助力，结果驾驶员在紧急避让时打不动方向盘。后来我们改成了根据车速动态调整降级比例。
安全状态识别的流程，我习惯用状态机来管理。下面这张图展示了SBW系统典型的安全状态迁移逻辑：
3.3 故障容错时间间隔(FTTI)设定
FTTI，全称Fault Tolerant Time Interval。这个概念很多人理解得不够深。它不是一个固定的数字，而是从故障发生到系统进入安全状态的最大允许时间。
FTTI的设定，直接决定了你的硬件响应速度、软件执行周期、诊断覆盖率和冗余切换时间。说白了，FTTI就是整个安全机制的“deadline”。
我一般把FTTI分解成三个部分：
- 故障检测时间（FDT）：从故障发生到诊断模块报出故障的时间。这取决于诊断策略的采样周期和算法复杂度。
- 故障反应时间（FRT）：从故障报出到系统开始执行安全措施的时间。这包括软件中断响应、任务调度延迟等。
- 安全执行时间（SET）：从开始执行安全措施到系统完全进入安全状态的时间。比如电机切换到备份模式、输出扭矩归零等。
注意：FTTI不是FDT+FRT+SET的简单累加。实际工程中，这三部分可能有重叠，也可能有等待。我建议在计算时留出至少20%的余量。我曾经因为FTTI余量留少了，在实车测试时发现系统在极限工况下超时，后来不得不重新调整诊断周期。
下面是一个典型的SBW系统FTTI分配示例：
| 安全目标 | FTTI要求 | FDT分配 | FRT分配 | SET分配 |
|---|---|---|---|---|
| SG-01（误转向） | ≤ 100 ms | 40 ms | 20 ms | 40 ms |
| SG-02（助力丧失） | ≤ 200 ms | 80 ms | 40 ms | 80 ms |
| SG-03（比例失调） | ≤ 150 ms | 60 ms | 30 ms | 60 ms |
| SG-04（路感异常） | ≤ 300 ms | 120 ms | 60 ms | 120 ms |
你可能会问：为什么SG-01的FTTI只有100ms？因为误转向在高速工况下，100ms的延迟就可能导致车辆偏离车道。而路感异常相对不那么紧急，300ms以内驾驶员通常能感知并适应。
FTTI的验证，我建议在HIL（硬件在环）台架上做。实车测试成本高、风险大。在HIL上注入故障，测量从故障注入到安全状态确认的时间戳，反复跑，看最差情况是否满足要求。
一个小技巧：在代码中埋入时间戳标记点。故障检测点、反应决策点、执行完成点，每个点都打上时间戳。这样在分析FTTI超标问题时，能快速定位是哪个环节拖了后腿。
最后说一句。安全目标、安全状态、FTTI，这三者是SBW功能安全的基石。它们不是写文档用的，是指导整个开发过程的。后面我们讲硬件架构、软件实现、测试验证，都会反复回到这三个概念上。所以，这一章的内容，值得你多花点时间消化。