前言
刚进入汽车行业的时候。
我一直以为故障码很简单。
无非就是：
传感器坏了
报码
结束
后来真正参与量产项目。
发现事情完全不是这样。
一个DTC从产生到最终出现在诊断仪上。
中间可能会经过：
Monitor
DEM
FiM
NvM
DCM
UDS
DoIP
多个模块。
甚至一个简单的故障码。
从检测到存储再到上报。
可能跨越几十个函数。
今天我们就扒开AUTOSAR诊断系统。
看看：
一个DTC到底是怎么诞生的？
先说结论
如果把故障管理比作医院。
那么：
Monitor = 医生
DEM = 病历系统
NvM = 档案室
DCM = 前台护士
UDS = 医院窗口
诊断仪 = 患者
医生发现病人发烧。
记录病历。
存档。
患者来查询。
前台再把病历拿出来。
AUTOSAR诊断系统本质上也是这个逻辑。
什么是DTC？
DTC：
Diagnostic Trouble Code
诊断故障码。
例如：
P0101
P0300
U1000
在AUTOSAR里面。
真正保存的通常不是这些显示码。
而是：
0x123456
这种内部DTC编号。
每个DTC对应一个故障事件。
例如：
摄像头失联
毫米波雷达超时
CAN BusOff
Flash校验失败
这些都可以成为一个DTC。
故障从哪里来？
很多新人有个误区：
DEM负责检测故障。
其实错了。
DEM不检测故障。
真正检测故障的是：
Monitor。
例如：
if(CameraTimeout > 100ms)
{
Dem_SetEventStatus(
Camera_Comm_Event,
DEM_EVENT_STATUS_FAILED
);
}
看到没有。
故障已经被业务逻辑检测出来了。
DEM只是接收结果。
看图。
图1：故障产生流程
DEM真正干什么？
DEM：
Diagnostic Event Manager
诊断事件管理器。
名字里面最关键的词：
Event
事件。
DEM的核心职责：
事件管理
DTC管理
冻结帧管理
故障存储
故障恢复
简单理解：
DEM就是整个故障系统的大脑。
一次故障上报全过程
假设：
摄像头通信超时。
Monitor发现异常：
Dem_SetEventStatus(
Camera_Comm_Event,
FAILED
);
DEM收到后。
首先更新故障状态。
例如：
TestFailed
置位。
随后更新：
PendingDTC
继续满足条件：
ConfirmedDTC
最终形成正式故障码。
为什么故障不会立刻报码？
因为汽车环境太复杂。
例如：
某次CAN报文丢失。
可能只是：
瞬时干扰
如果立刻报码。
用户每天都会看到故障灯。
因此AUTOSAR引入：
Debounce
去抖机制。
例如：
连续失败3次。
才认为故障成立。
配置可能类似：
FAILED_THRESHOLD = 3
PASSED_THRESHOLD = -3
这样可以过滤误报码。
冻结帧到底是什么？
很多人去4S店读故障码时。
经常看到：
VehicleSpeed
BatteryVoltage
Mileage
这些信息来自：
Freeze Frame。
冻结帧。
当故障第一次出现时。
DEM会记录现场信息。
例如：
车速
电压
时间戳
环境温度
这就像：
事故现场照片。
后续工程师分析问题时。
可以知道：
故障发生那一刻。
车辆到底是什么状态。
看图
图2：冻结帧示意图
故障如何掉电保存？
如果故障存在RAM。
熄火就没了。
因此DEM会调用：
NvM
进行存储。
路径通常是：
DEM
↓
NvM
↓
Fee
↓
Fls
↓
Flash
最终保存到Flash。
即使车辆断电。
故障依然存在。
诊断仪为什么能读到故障码？
因为还有一个模块：
DCM
Diagnostic Communication Manager
诊断仪发送：
UDS 0x19
读取DTC请求。
DCM收到请求后。
向DEM查询：
当前有哪些DTC？
DEM返回：
DTC列表
状态位
冻结帧
DCM再封装UDS响应。
返回给诊断仪。
看图。
图3：诊断读取流程
在智驾域控制器里DEM更重要
传统ECU：
可能几十个DTC。
而智驾域控制器：
可能有：
Camera
Radar
Lidar
Fusion
Planning
Ethernet
SOME/IP
OTA
上千个故障事件。
每一个故障：
都需要：
检测
确认
存储
上报
恢复
复杂度远超传统ECU。
一张图看完整生命周期
Monitor
↓
Dem_SetEventStatus()
↓
DEM
↓
DTC生成
↓
FreezeFrame
↓
NvM存储
↓
DCM查询
↓
UDS响应
↓
诊断仪显示
写在最后
很多新人认为：
DEM只是存故障码。
实际上。
DEM是整个AUTOSAR诊断体系的核心。
它连接着：
Monitor
FiM
NvM
DCM
UDS
几乎所有诊断相关模块。
🚗 一句话总结：
Monitor负责发现问题，DEM负责记住问题，DCM负责告诉别人问题。
下期预告：
《UDS服务0x19到底做了什么？为什么一个ReadDTCInformation请求能把DEM全部串起来？》
