4、系统降级模式：降级模式分类与切换逻辑
各位，咱们接着聊。上一节我们把故障响应机制讲清楚了，这一节重点说说系统降级模式。说白了，就是当系统出了毛病，我们怎么让车还能「凑合着开」，而不是直接趴窝。
我参与过好几个量产项目，每次评审降级策略时，总有人问：「到底降到什么程度才算安全？」这个问题没有标准答案，但有一套成熟的方法论。今天我就把这套东西掰开揉碎了讲给你听。
4.1 降级模式分类
降级模式，我习惯分成三类：性能降级、功能降级、冗余切换。这三者不是互斥的，很多时候是组合使用。
4.1.1 性能降级
性能降级，就是功能还在，但跑得慢一点、精度低一点。举个例子，你想想看，一个雷达传感器被泥巴糊住了，它还能探测，但探测距离从200米缩到了50米。这时候ACC自适应巡航还能用，但只能低速跟车。
我在项目中遇到过一种情况：某个MCU的CAN控制器因为电磁干扰频繁报错。我们没直接关掉CAN通信，而是把通信速率从500kbps降到了125kbps。虽然数据更新慢了，但至少没丢帧。这就是典型的性能降级。
- 传感器采样率降低（比如摄像头从30fps降到15fps）
- 控制周期拉长（比如电机控制从1ms变成5ms）
- 通信带宽压缩（比如CAN FD降级为普通CAN）
- 计算精度折半（比如浮点运算改为定点运算）
4.1.2 功能降级
功能降级更狠一些——直接砍掉某些功能。但注意，砍功能要有优先级。我记得有一次做ADAS控制器，我们定了一个规则：如果系统算力不足，先关掉自动泊车，保留AEB自动紧急刹车。为什么？因为AEB是安全相关的，自动泊车只是舒适性功能。
功能降级通常分等级：
| 降级等级 | 保留功能 | 关闭功能 | 典型触发条件 |
|---|---|---|---|
| Level 0 | 全部功能 | 无 | 正常状态 |
| Level 1 | 安全功能 + 核心功能 | 舒适性功能 | 轻度故障 |
| Level 2 | 仅安全功能 | 所有非安全功能 | 中度故障 |
| Level 3 | 仅基础行驶功能 | 所有辅助功能 | 严重故障 |
4.1.3 冗余切换
冗余切换，说白了就是「备胎上场」。这是最高级别的降级策略，也是成本最高的。
我做过一个线控制动项目，主控制器是Infineon TC397，备份控制器是TC234。正常情况下TC397干活，TC234只做心跳检测。一旦TC397挂了，TC234在10ms内接管制动控制。嗯，这里要注意：冗余切换不是简单的「拔插头」，你得考虑状态同步问题。
冗余切换有三种常见模式：
- 冷备份：备机不通电，主机挂了才启动。切换时间最长，但功耗低。
- 温备份：备机通电但不参与控制，只同步关键状态。切换时间中等。
- 热备份：备机同步运行，随时准备接管。切换时间最短，但功耗和成本最高。
我个人建议，安全关键系统至少用温备份。冷备份的启动时间太长了，等备机初始化完，车可能已经撞了。
4.2 降级模式切换条件与触发逻辑
降级不是你想降就能降的，得有明确的触发条件。我习惯把触发条件分成三类：
- 硬件故障触发：比如传感器失效、执行器卡死、通信中断。这类触发最直接，通常由硬件BIST或监控狗检测。
- 软件异常触发：比如任务超时、堆栈溢出、数据校验失败。这类触发需要软件看门狗或E2E保护机制。
- 环境条件触发：比如温度过高、电压过低、振动过大。这类触发需要环境传感器配合。
触发逻辑怎么写？我给大家看一段伪代码，这是我实际项目中用过的逻辑：
// 降级模式触发逻辑示例
if (brake_pressure_sensor_status == FAILED) {
// 刹车压力传感器失效，触发功能降级
degrade_level = LEVEL_2; // 仅保留基础刹车
activate_backup_brake_algorithm();
} else if (ambient_temperature > 85) {
// 温度过高，触发性能降级
degrade_level = LEVEL_1;
reduce_control_frequency(50); // 控制频率减半
} else if (main_ecu_heartbeat_timeout > 3) {
// 主ECU失联，触发冗余切换
switch_to_backup_ecu();
degrade_level = LEVEL_3;
}4.3 降级模式退出与恢复策略
降级容易，恢复难。很多工程师只关心怎么降级，却忘了设计怎么恢复。结果就是车进了降级模式就再也出不来了。
恢复策略我总结为三种：
- 自动恢复：故障消失后，系统自动回到正常模式。适用于瞬态故障，比如电磁干扰导致的通信错误。
- 条件恢复：需要满足特定条件才能恢复。比如车速低于30km/h、档位在P档、或者系统自检通过。
- 手动恢复：需要驾驶员或维修人员手动操作。比如熄火重启、或者用诊断仪清除故障码。
我个人比较推荐「条件恢复 + 手动恢复」的组合。自动恢复虽然方便，但风险也高。你想想看，如果系统因为某个间歇性故障反复降级、恢复、降级、恢复，那体验得多糟糕。
恢复逻辑里还有一个关键点：恢复前的自检。不能因为故障码消失了就认为系统好了。我要求我的团队在恢复前必须做一次完整的BIST（内置自检），确认所有相关模块都正常，才能退出降级模式。
- 设置恢复延迟时间（比如故障消失后等待5秒再恢复）
- 恢复前执行自检（BIST或回环测试）
- 恢复后记录日志（故障时间、降级时长、恢复原因）
- 考虑恢复后的状态同步（特别是冗余切换后）
好了，降级模式这部分就讲到这里。下一节我们聊聊故障响应的时间约束——说白了就是「多快算快」。这个在功能安全里可是硬指标，ISO 26262里写得明明白白的。