Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

3.8 安全状态与降级——故障后的生存策略

你正在驾驶一辆配备EPB（电子驻车制动）的SUV，以时速120公里行驶在沪昆高速上。你的双手握着方向盘，右脚踩着油门，一切正常。

突然，EPB控制器的CAN接收中断了。仪表盘上，EPB故障警告灯亮起琥珀色。你对这个灯很熟悉：上一次看到它是三天前，在小区停车场车速3km/h时，EPB自动施加了驻车制动。那个场景很安全，车基本是静止的，驻车制动只是稳稳地把车固定在了停车位上。

但现在不一样。你现在车速120km/h。如果此时EPB按照它的“默认安全反应“：施加驻车制动，后轮会瞬间抱死，车辆失控甩尾。根据ISO 26262车辆层面的危害分析，这属于ASIL C/D级别的致命场景。

但是，如果EPB选择“什么都不做“，那也不行。你很可能在10分钟后到达目的地，需要在坡道上停车。如果EPB完全失效，你无法施加驻车制动，溜车同样会造成致命事故。

这是功能安全设计中最高级别的两难问题：安全状态：在故障发生后的每一个时间点，系统必须处于一个“不会造成不合理风险“的运行模式。但什么是“安全“不是绝对的：它是场景相关的、时间依赖的、条件约束的。

功能安全的设计不是寻找“不会坏的完美系统“，而是设计“坏了以后不会杀人的系统“。在功能安全的词汇表中，“Safe“从来不是一个形容词（描述系统本身的性质），而是一个动词（描述系统在故障后的行为）。

安全状态的形式化定义：它不是一个状态，是一个过程

ISO 26262对安全状态（Safe State）的定义

ISO 26262-1:2018 第3.131条将安全状态定义为：

Safe State: Operating mode, in case of a failure, of an item without an unreasonable level of risk.

翻译为中文：条目在发生故障时的运行模式，不存在不合理的风险。

这个定义读起来有点绕，需要拆开看。ISO 26262 术语中的“安全状态“特指故障发生后条目进入的运行模式，它的核心是“风险可接受“，不是“没有故障“。正常无故障运行在标准里就叫正常模式，不叫安全状态。因为安全状态是一个在故障触发后被主动进入的、被设计和验证过的运行模式。一个EPB系统正常工作（无故障）时处于“可用“模式，此时当然也是安全的，但标准不称它为“安全状态“。一个EPB系统在CAN通信故障后，进入“警告灯亮起、驻车制动锁止在当前位置“的模式，这才是标准定义的安全状态。它不健康（有故障），但它是安全的（不会在120km/h时锁死后轮）。

故障响应时间链

安全状态不是瞬达的：它是一个严格受时间约束的过程。ISO 26262定义了一系列时间参数来约束故障响应：

FDTI（Fault Detection Time Interval）— 故障检测时间间隔 从故障发生到故障被检测到的时间。FDTI包括：

  • 通信超时（例如CAN帧500ms未更新=超时）
  • CRC/E2E校验检测到腐败
  • 程序流监控检测到非法转移
  • 内存保护单元（MPU）触发访问违规异常

FRTI（Fault Reaction Time Interval）— 故障响应时间间隔 从故障被检测到到系统进入安全状态的时间。FRTI包括：

  • Safety SW-C收到故障通知并触发对应的安全响应
  • 执行器接收到指令并执行物理动作（如断开电机桥、施加制动）
  • 物理过程的时间常数（如电机转子惯性滑行时间）

FHTI（Fault Handling Time Interval）— 故障处理时间间隔 FHTI = FDTI + FRTI。即从故障发生到系统进入安全状态的整个时间跨度。

FTTI（Fault Tolerant Time Interval）— 容错时间间隔 这是安全概念中最关键的参数。FTTI是在不导致危害事件的前提下，系统能够容忍一个故障存在的最长时间。如果FHTI > FTTI，危害事件必然发生，无论安全机制设计得多好，响应太慢就等于没有响应。

数学约束：

FHTI = FDTI + FRTI < FTTI

这个不等式是整个安全架构设计的“第一约束“。所有故障检测机制（E2E的超时、CRC校验、程序流监控）和故障响应机制（降级、关断、告警）的设计，都必须以“满足所有危害场景的FTTI约束“为前提。

FTTI的实际案例

回到EPB的场景。危害事件是“在高速行驶时后轮意外抱死导致车辆失控“。

危害分析显示：后轮从开始抱死到车辆完全失控的物理时间约为 120ms（取决于轮胎与地面的侧向附着力和车辆横摆惯性）。这个120ms就是FTTI的最大值，安全机制必须在120ms内检测到故障并防止后轮抱死。

FTTI不是由软件工程师决定的，它由物理决定。FTTI取决于车辆动力学、轮胎摩擦学、人体反应时间等物理常数。软件工程师能决定的只有：如何将FDTI和FRTI压缩到FTTI之内。当FTTI太短（如赛车中的10ms量级），软件检测已经不够快，必须使用硬件级的安全路径（如比较器直接关断MOSFET门极驱动，绕过软件栈）。

安全状态的层级谱系：不是关机，是降级

在实际的车辆功能安全设计中，“安全状态“不是一个单一的状态，而是一个降级层级谱系。以EPB为例：

层级0：完全功能（Full Function）

  • CAN通信正常，所有传感器和执行器正常。
  • EPB提供全部功能：动态驻车制动辅助、自动驻车（AutoHold）、坡道起步辅助（HSA）、紧急制动。

层级1：功能降级（Reduced Performance）

  • 触发条件：某个传感器失效（如卡钳温度传感器），但核心执行器正常。
  • 降级反应：关闭依赖温度补偿的高级功能（如制动力自适应调节），保留基本驻车功能和紧急制动功能。
  • 对驾驶员的影响：几乎不可感知。仅仪表盘记录一条隐藏的故障码（DTC），在下次保养时由维修设备读取。
  • 安全状态类型：功能受限安全状态，仍然在运行，但功能子集被削减。

层级2：紧急操作（Emergency Operation, EOT）

  • 触发条件：核心通信故障（如CAN帧丢失超过超时阈值），或核心传感器故障（如卡钳位置传感器故障），但执行器（电机）仍可受控。
  • 降级反应：EPB进入紧急操作模式。系统能够在驾驶员明确请求下执行驻车制动（例如长拉EPB开关超过3秒），但自动功能（如AutoHold）全部禁用。
  • 安全参数：
    • EOTTI（Emergency Operation Tolerance Time Interval）：系统允许在紧急操作模式下运行的最长时间。例如300秒（5分钟）。超过EOTTI后，系统必须进入最终安全状态（关断）。
  • 对驾驶员的影响：仪表盘亮起琥珀色/红色警告灯，可能有音频提示。驾驶员必须在EOTTI内采取行动（如驶入紧急停车带）。如果驾驶员不采取行动，系统在EOTTI到期后强制执行最终安全状态。

层级3：最终安全状态（Safe State）

  • 触发条件：FHTI超时，或EOTTI超时，或核心执行器本身故障（如电机驱动桥短路）。
  • 降级反应：
    • 如果车速 < 3km/h（车辆静止或极低速）：EPB施加驻车制动，卡钳锁死，车辆停止。
    • 如果车速 ≥ 3km/h（车辆在行驶中）：EPB不得施加驻车制动。替代安全状态：驱动桥进入空挡（或降低驱动扭矩至零），制动灯点亮，危险警告灯闪烁，依靠传统液压制动系统减速，直到车辆停止。停止后，EPB施加驻车制动。
  • 这是最后的防线：安全状态不是“系统做了什么“，而是“系统刻意不做什么“。EPB在高速时的安全状态是“禁止执行“，一个制动系统的最安全状态是不制动。

安全状态的最高智慧是克制的智慧。工程直觉会说“制动系统故障时立即施加制动“，但物理学告诉你120km/h时后轮锁死的后果比无制动严重得多。安全状态不是单一的动作，而是一个依赖运行条件的决策树，必须在设计阶段通过危害分析穷举，而非在故障发生后由软件临时判断。

降级策略的架构实现：安全路径的物理分离

在ISO 26262 Part 4中，降级策略的实现通常涉及两条控制路径的物理分离：

功能路径（Functional Path）

  • 正常的控制环路。经过完整的软件栈（应用层→RTE→基础软件层→MCAL→硬件）。
  • 具有最高的性能、最全的功能，但也最长的时间延迟（完整软件栈的延迟可能在微秒到毫秒级）。

安全路径（Safety Path / Hardware Safety Path）

  • 旁路路径，直接连接故障检测硬件到安全执行器。
  • 跳过大部分软件栈，仅依赖于硬件比较器、逻辑门和专用安全状态机（如Infineon AURIX的SMU（Safety Management Unit））。
  • 延迟极低（通常在纳秒到微秒级），但功能极其有限，通常只能执行“关断“或“保持在当前位置“。

案例：EPS电机的安全关断路径

正常路径：应用层计算扭矩 → RTE → PWM驱动 → 电机桥 → 电机
安全路径：母线电流传感器 → 硬件比较器 → 直接关断MOSFET预驱动器 → 电机桥断开

当EPS软件计算出一个异常高的扭矩指令（例如由于前述的栈溢出跳过了限幅函数），功能路径会忠实地输出这个指令。但安全路径上的硬件比较器独立监测母线电流。一旦电流超过预设的硬件阈值（例如150A），比较器直接触发MOSFET预驱动器的关断引脚，在200纳秒内断开电机桥，完全绕过了可能故障的软件栈。

这就像免疫系统的补体途径（Complement System）。它不依赖于T细胞或B细胞的“识别-激活-攻击“三层级联，而是直接在细菌表面激活攻膜复合体（MAC），瞬间在细菌膜上打出孔洞。补体途径就是一种“硬件安全路径“，低延迟、高鲁棒性、功能单一（只攻击细菌，不做抗原呈递或免疫记忆）。

恢复策略：从安全状态返回到正常运行

系统进入安全状态后，什么时候可以恢复？

ISO 26262-4中定义了恢复的条件：

  1. 故障已经消失（例如CAN通信恢复）。
  2. 故障消失的原因被确认（不是瞬态侥幸，而是系统性的恢复）。
  3. 系统已通过自检（上电自检POST或周期自检的重新执行）。
  4. 恢复操作本身不会引入新的风险（在某些场景下（如高速行驶中），永远不允许自动恢复）。

恢复策略的四种模式

模式A：自动恢复（Auto-Recovery）

  • 条件：故障原因已清除，且当前运行场景允许恢复。
  • 典型场景：CAN通信短时电磁干扰导致超时，通信恢复后自动恢复正常功能。
  • 约束：必须设定最大自动恢复次数。连续恢复3次后锁死，因为反复恢复意味着根源问题并未解决。

模式B：驾驶员确认恢复（Driver-Confirmed Recovery）

  • 条件：故障已清除，但系统要求驾驶员通过特定操作（如按下EPB开关、重启车辆）来确认恢复。
  • 典型场景：EPB在低速下进入了安全状态，即使故障已消失，也要求驾驶员主动操作来释放驻车制动，以防意外释放。

模式C：维修后恢复（Service Recovery）

  • 条件：故障需要维修设备（诊断仪）通过UDS服务清除DTC后才能恢复。
  • 典型场景：核心传感器永久性故障（如卡钳位置传感器烧毁），即使更换传感器后也必须通过诊断仪清除DTC，防止非授权维修导致的二次故障。

模式D：不可恢复（Non-Recoverable）

  • 条件：故障是永久性的且无法修复（如ASIC烧毁、Flash存储器不可擦除）。
  • 典型场景：安全MCU的锁步核（Lockstep Core）诊断检测到处理器核心永久性故障，固件将MCU锁定在故障状态，只能通过更换整个ECU恢复。

驾驶员警告策略：人机交互安全

安全状态不仅仅是MCU内部的状态机，它必须在恰当的时机、以恰当的方式告知驾驶员。ISO 26262和ISO 21434（网络安全）都对警告策略有明确要求：

警告的层级

层次1：提示（Information）— 对焦/听觉

  • 触发条件：功能降级，不影响安全。
  • 显示方式：仪表盘琥珀色指示灯，短促音频提示（1声）。
  • 时间要求：故障检测后500ms内显示。

层次2：警告（Warning）— 对焦/听觉/触觉

  • 触发条件：安全功能受限，驾驶员需要采取行动，但无紧迫威胁。
  • 显示方式：红色警告灯/弹出文字，持续性音频警告（间隔1秒的蜂鸣），可选方向盘振动。
  • 时间要求：故障检测后200ms内激活。

层次3：紧急警告（Critical Alert）— 全感官动员

  • 触发条件：即将进入安全状态，驾驶员必须在极短时间内响应。
  • 显示方式：红色闪烁灯+全屏警告文字，高频蜂鸣，方向盘剧烈振动，制动踏板脉动。
  • 时间要求：故障检测后100ms内激活。

警告本身可能成为危害。如果每条CAN故障都触发全感官紧急警告，驾驶员会在第3次误报后选择无视（警告疲劳效应）。警告策略的设计必须平衡敏感性（不漏报）和特异性（不误报）。

免疫系统隐喻：发烧与昏迷——生物学的降级模式

人体的免疫应答策略与车辆的降级策略几乎惊人地同构：

发烧 = 功能降级（Reduced Performance）

当体温调节中枢检测到感染（通过IL-1、IL-6、TNF-α等炎性因子），它将体温设定点上调，人体开始“发烧“。发烧时：

  • 骨骼肌不自主收缩产热（寒战）→ 消耗大量能量
  • 肝脏加速合成急性期蛋白 → 资源从正常功能（消化、生长）转向防御功能
  • 大脑认知功能下降（“脑雾”）→ 将计算资源从高级认知转向免疫调控

这就是生物体的“层级2降级“：取消了“正常功能“（消化、运动、思考），集中资源用于“核心安全功能“（免疫防御）。我们的EPB在层级2中取消自动功能、保留紧急制动，完全一致的策略。

昏迷 = 最终安全状态（Safe State）

当损伤过于严重（大面积脑外伤、严重代谢中毒），大脑将身体转入昏迷状态，对外界刺激无反应，但维持心跳、呼吸、血压。这对应车辆的最终安全状态：

  • 停止一切主动功能（昏过去，不耦合外界世界）
  • 仅维持最低生命功能（心跳/呼吸 = 最小电气系统供电/通信）
  • 允许外部干预唤醒（医疗急救 = 诊断仪+维修设备）

但是：人体有一个车辆不具备的精妙功能：伤口的自愈能力。生物体可以在安全状态（昏迷）期间主动修复损伤（神经再生、组织修复）。而目前的汽车系统几乎不具备自愈能力，一旦进入安全状态，只能等待外部维修。

这指向了功能安全的下一个前沿领域：自主修复（Self-Healing Systems）。但这已经超出了ISO 26262 Part 3的范围。

安全状态的设计是功能安全的“第二类工程“，第一类是“如何让系统不出故障“，第二类是“故障后如何不死人“。安全状态不是静态度量，它是场景感知的（车速3km/h以上/以下完全不同）、时间约束的（FHTI < FTTI是铁律）、层级递进的（功能降级→紧急操作→最终安全状态）、条件分支的（驾驶员行为影响状态转移）四维决策矩阵。

本篇小结

  1. 安全状态是场景相关的条件决策：EPB在120km/h时的安全状态是“禁止施加驻车制动“，而在3km/h时是“施加驻车制动“——克制的智慧比执行的勇气更重要。
  2. 安全架构的第一约束是FHTI < FTTI：FTTI由车辆动力学和物理学决定（如后轮抱死到失控约120ms），FDTI和FRTI必须压缩在此窗口内。
  3. 降级策略分为四个层级：完全功能→功能降级（隐藏DTC）→紧急操作（EOTTI限时，驾驶员需在5分钟内行动）→最终安全状态（车速决定动作）。
  4. 硬件安全路径（200ns级，比较器直接关断MOSFET）与功能路径（毫秒级，经过完整软件栈）物理分离，确保软件故障时仍能强制执行安全动作。
  5. 恢复策略分为自动恢复（需限制连续次数）、驾驶员确认恢复、维修后恢复和不可恢复四种模式，警告策略也按严重程度分为提示/警告/紧急警告三级。

【下集预告】： 第3章一个一个过了看门狗、锁步核、ECC、MPU、E2E、CRC、程序流监控、降级策略——八个安全机制，每个都有独立的物理原理和适用范围。第4章打开它们在实际量产代码中长什么样：Arctic Core 的 WdgM、E2E、RamTst 源码逐行走读。看概念如何落地为 const 配置结构体、有限状态机和 CRC 查表。