2. ADAS系统故障模型：典型故障类型、影响与ISO 26262要求
大家好，我是你们的老朋友。今天我们来聊聊ADAS系统的故障模型。说实话，这部分内容我每次讲课时都觉得特别重要——你想想看，如果连故障长什么样都不知道，你怎么去设计看门狗和恢复机制？
我在做ADAS项目的头两年，就吃过这个亏。当时觉得故障嘛，无非就是程序跑飞了。结果呢？项目测试时各种稀奇古怪的问题冒出来，搞得我们焦头烂额。嗯，从那以后，我养成了一个习惯：先建故障模型，再谈恢复策略。
2.1 ADAS系统典型故障类型
ADAS系统的故障，说白了可以分为两大类：硬件故障和软件故障。我个人习惯把它们再细分一下，这样设计恢复机制时更有针对性。
2.1.1 硬件故障
硬件故障是ADAS系统最头疼的问题之一。我在项目中遇到过摄像头被泥巴糊住的情况，结果车道保持功能直接罢工了。
- 传感器故障：摄像头、雷达、激光雷达等感知器件失效。比如摄像头镜头污染、雷达天线损坏、激光雷达扫描机构卡死。
- 处理器故障：CPU/GPU/FPGA等计算单元异常。包括时钟漂移、内存位翻转、电源纹波过大导致逻辑错误。
- 通信故障：CAN总线、以太网、FlexRay等通信链路中断或数据损坏。我曾经遇到过CAN总线终端电阻虚焊，导致间歇性丢帧。
- 执行器故障：制动、转向、油门等执行机构响应异常。比如制动踏板位置传感器卡滞在某个值。
2.1.2 软件故障
软件故障嘛，说白了就是代码里的坑。我见过最离谱的一次，是某个工程师把数组下标写成了1而不是0，结果在特定工况下才触发。
- 时序故障：任务超时、死锁、优先级反转。比如某个控制算法计算时间超过了调度周期。
- 数据故障：数据损坏、溢出、精度丢失。我记得有个项目，浮点数精度问题导致车辆在弯道中偏离了车道。
- 逻辑故障：状态机跳转错误、条件判断遗漏。比如某个安全状态没有覆盖到所有可能的输入组合。
- 资源故障：内存泄漏、堆栈溢出、文件句柄耗尽。我曾经调试过一个内存泄漏问题，跑了8小时后系统才崩溃。
2.2 故障对系统安全的影响
不同类型的故障，对系统安全的影响天差地别。我习惯用ASIL等级来评估影响程度。你想想看，一个故障如果导致车辆突然加速，那肯定是ASIL D级别。
| 故障类型 | 典型影响 | ASIL等级 | 实际案例 |
|---|---|---|---|
| 传感器完全失效 | 感知功能丧失，系统降级 | ASIL B/C | 摄像头被遮挡，ACC自动退出 |
| 传感器数据偏差 | 错误的目标检测，可能导致误制动 | ASIL C/D | 雷达测距偏差导致AEB误触发 |
| 处理器死锁 | 控制输出冻结，车辆失控 | ASIL D | 转向控制任务死锁，方向盘卡死 |
| 通信超时 | 控制指令丢失，系统进入安全状态 | ASIL B/C | CAN总线负载过高导致丢帧 |
| 软件逻辑错误 | 错误的安全决策，可能引发事故 | ASIL C/D | 状态机跳转到错误状态 |
这里我要特别强调一下：故障的传播路径比故障本身更可怕。比如一个传感器的小偏差，经过控制算法的放大，最终可能导致灾难性的后果。我在项目中就遇到过这种情况——一个温度漂移导致传感器输出偏了0.5%，结果融合算法把目标位置算偏了2米。
2.3 ISO 26262对故障恢复的要求
ISO 26262对故障恢复的要求，说白了就是一句话：故障发生后，系统必须进入安全状态。但具体怎么实现，标准里写得可细了。
2.3.1 故障检测时间间隔（FTTI）
ISO 26262要求每个安全目标都有对应的故障检测时间间隔。比如对于制动系统，FTTI可能要求小于100ms。我习惯这样设计：看门狗的喂狗周期要小于FTTI的一半，这样才有余量。
关键点：FTTI不是随便定的。它取决于故障的严重程度和车辆动力学特性。比如高速行驶时，FTTI要比低速时严格得多。
2.3.2 故障响应时间（FRTI）
从检测到故障到进入安全状态，这个时间叫FRTI。ISO 26262要求FRTI必须小于FTTI。嗯，这里要注意：FRTI包括故障确认时间、决策时间和执行时间。
我曾经在项目中踩过一个坑：看门狗检测到任务超时后，系统花了200ms才切换到安全模式。但FTTI只有150ms。结果呢？安全评审没通过，只能重新设计恢复流程。
2.3.3 安全状态定义
ISO 26262要求每个安全目标都要定义明确的安全状态。比如：
- 降级模式：关闭部分功能，保留基本安全功能。比如ACC失效后，保留AEB功能。
- 安全停止：车辆减速并停在安全位置。比如检测到制动系统故障时，自动靠边停车。
- 故障静默：系统停止输出，由驾驶员接管。比如转向系统故障时，方向盘变重但不断开。
2.3.4 故障恢复的冗余要求
ISO 26262对故障恢复的冗余有明确要求。对于ASIL D的系统，通常需要硬件冗余和软件冗余双重保障。
举个例子：对于转向系统，ISO 26262要求：
- 主控制器故障时，备份控制器必须在10ms内接管
- 两个控制器的软件必须独立开发，避免共因失效
- 看门狗必须独立于主控制器，不能共享时钟源
我记得有个项目，为了满足ASIL D要求，我们用了三个独立的看门狗：一个在MCU内部，一个在外部专用芯片上，还有一个在电源管理芯片里。虽然成本高了点，但安全冗余确实到位。
2.4 故障恢复的实战要点
说了这么多理论，最后分享几个实战中的要点：
- 故障分级处理：不是所有故障都需要立即恢复。我习惯把故障分为三级：轻微故障（记录日志）、中等故障（降级运行）、严重故障（立即安全停止）。
- 故障确认机制：不要一检测到异常就触发恢复。我建议至少连续检测3次异常才确认故障，避免误触发。
- 恢复后的自检：故障恢复后，系统必须进行自检，确认故障已消除才能恢复正常运行。我曾经遇到过恢复后故障还在，结果系统反复进入安全状态。
- 故障记录：每次故障都要记录详细信息，包括故障类型、时间、系统状态等。这些数据对后续的故障分析和系统优化非常重要。
好了，关于ADAS系统的故障模型，今天就聊到这里。记住一句话：没有完美的系统，只有完善的故障恢复机制。下一章我们聊聊看门狗的具体实现方案，到时候见。