【CP-08】AUTOSAR诊断体系深度剖析 - DEM/DCM/ECU State Manager实战指南

CP-08 AUTOSAR诊断体系深度剖析

CP-08 AUTOSAR诊断体系深度剖析

CP-08：AUTOSAR诊断体系深度剖析 – DEM/DCM/ECU State Manager实战指南

关键词：AUTOSAR CP、诊断体系、DEM、DCM、FIM、ECU State Manager、UDS、ISO 14229、故障管理、DaVinci Configurator

适用对象：汽车嵌入式软件开发工程师，具有AUTOSAR基础但诊断模块经验不足的读者

预计阅读时间：35分钟

AUTOSAR诊断体系思维导图

前言：为什么诊断是AUTOSAR中最复杂又最被低估的模块？

凌晨两点，某款车型售后店里，一辆SUV的发动机故障灯亮了。技师用诊断仪连上OBD接口，屏幕上跳出一串故障码：P0101（空气流量传感器信号不合理）、P0172（混合气过浓）、U0100（与ECM通信丢失）。他盯着故障码看了半天，清除后跑了三天，故障又复发了。

这不是故事，这是真实的诊断困境。

诊断的本质是什么？ 诊断不是简单地在代码里加几个错误码，而是一套完整的故障检测-状态管理-数据记录-功能抑制-通信交互体系。在这个体系里，ECU需要知道：

• 传感器是真的坏了，还是线束接触不良？
• 这个故障是什么时候发生的？发生时车速、转速、温度是多少？
• 故障持续了多久？有没有自动恢复？
• 下次启动时还需要报这个故障吗？
• 故障发生后，整车应该进入什么降级模式？

AUTOSAR Classic Platform用三个核心模块回答了以上所有问题：DEM（Diagnostic Event Manager）、DCM（Diagnostic Communication Manager）和FIM（Function Inhibition Manager），以及协调这一切的ECU State Manager。

本文将带你深入理解这套诊断体系，不仅是规范条文，更是实战中为什么这样设计、什么场景用什么策略、哪些坑最容易踩。

第一章：诊断体系全景 – 三层架构与标准脉络

1.1 UDS协议栈在AUTOSAR中的位置

要理解AUTOSAR诊断架构，先要理解它与UDS（Unified Diagnostic Services）的关系。

UDS是一套标准化的诊断服务协议，定义在ISO 14229-1中。你可以把UDS想象成医生手里的检查项目清单：读取故障码（0x19）、清除故障码（0x14）、读取数据（0x22）、写入数据（0x2E）……这些服务本身是标准化的，但谁来响应这些请求、谁来管理故障数据、谁来决定功能是否该被禁用，这正是AUTOSAR诊断模块要解决的核心问题。

AUTOSAR的诊断体系是一个三层架构：

┌─────────────────────────────────────────────────────────────────────┐
│ DCM (Diagnostic Communication Manager) │
│ ───────────────────────────────────────────────────────────────── │
│ 职责：诊断通信的"前台接待" │
│ • 接收外部诊断仪的请求（0x10会话切换、0x19读取DTC等） │
│ • 路由到对应的服务处理器 │
│ • 组装响应报文返回给诊断仪 │
│ • 管理诊断会话状态和安全访问等级 │
├─────────────────────────────────────────────────────────────────────┤
│ DEM (Diagnostic Event Manager) │
│ ───────────────────────────────────────────────────────────────── │
│ 职责：诊断数据的"数据中心" │
│ • 接收来自软件组件/BSW模块的故障事件上报 │
│ • 管理DTC（故障码）的状态、快照数据、扩展数据 │
│ • 决定故障何时确认、何时老化清除 │
│ • 与NVM交互实现数据持久化 │
├─────────────────────────────────────────────────────────────────────┤
│ FIM (Function Inhibition Manager) │
│ ───────────────────────────────────────────────────────────────── │
│ 职责：功能安全的"执行机构" │
│ • 订阅DEM的故障状态变化 │
│ • 根据故障状态决定哪些功能需要被禁用 │
│ • 向被禁用的软件组件发送 Inhibition 信号 │
└─────────────────────────────────────────────────────────────────────┘

这三者之间是松耦合但强协同的关系：

• DCM → DEM：DCM收到读取DTC请求时，向DEM查询故障数据
• DEM → FIM：DEM检测到故障后，通知FIM触发功能抑制
• FIM → SW-C：FIM向软件组件发送功能禁用信号，SW-C检查自身是否被抑制

1.2 与ISO 14229/ISO 15031的关系

很多初学者容易混淆这几个标准的关系，这里做一张对照表：

关键理解：ISO 14229定义了“服务长什么样”（请求格式、响应格式），而AUTOSAR定义了“谁来处理这些服务、怎么存储数据、怎么与其他模块交互”。

1.3 ECU State Manager的协调作用

很多人忽视了ECU State Manager在诊断体系中的地位。实际上，诊断的可用性完全取决于ECU所处的状态。

ECU State Manager（EcuM）负责管理ECU的启动序列、运行状态切换、关机流程。诊断服务并不是在所有状态下都可用的：

• STARTUP阶段：DEM正在初始化，DTC可能还未加载完成
• RUN阶段：诊断服务可用
• POST_RUN阶段：部分诊断仪可能仍能访问
• SHUTDOWN阶段：诊断服务不可用，但下电前的数据保存至关重要

EcuM通过唤醒源管理、状态通知和初始化时序控制，确保诊断体系在正确的时机做正确的事。

第二章：DEM（Diagnostic Event Manager）深度剖析

2.1 Event定义与生命周期

2.1.1 Event与DTC的关系

在DEM中，有两个核心概念需要先理清：Event和DTC。

• Event（事件）：软件组件或BSW模块向DEM报告的原始故障状态，通常是一个布尔量（FAILED/PASSED）
• DTC（Diagnostic Trouble Code）：对外暴露给诊断仪的标准化故障码，遵循SAE J2012或ISO 15031的编码规则

一个Event可以对应一个或多个DTC（通过Combined Event机制），但通常情况下是1:1的关系。

// 软件组件向DEM报告故障
void AirFlowSensor_MainFunction(void)
{
if (AirFlowSignal > MAX_VALID_VALUE) {
// 传感器信号超限，报告Event FAILED
Dem_ReportErrorStatus(DEM_EVENT_ID_AFS_SIGNAL_RANGE_HIGH);
}
}

2.1.2 Event状态机

Event在DEM内部有一个复杂的状态机，理解它是理解DEM一切的根基：

┌──────────────────────────────────────────────────────┐
│ Event States │
│ │
│ ┌─────────┐ ┌───────────┐ ┌──────────┐ │
Dem_SetEventStatus() │ qualified │──▶│ prefailed │──▶│ failed │ │
+ │ │ │ (FDC>0) │ │ (FDC=max)│ │
EnableCondition满足 └─────────┘ └───────────┘ └──────────┘ │
│ │
│ Debounce结果 │ Storage Condition满足
│ │ + Confirmation Status bit
▼ ▼ 置位
┌─────────────────┐ ┌──────────────────┐
│ passed │ ◀────────────────debounce到0────────────────│ confirmed DTC │
│ (计数器恢复到0) │ │ (状态位bit3=1) │
└─────────────────┘ └──────────────────┘

各状态详解：

重要：Event状态与DTC状态位是两个不同的概念。Event进入failed状态只是说明内部判定逻辑认为有故障，只有当Storage Condition满足且Confirmation完成后，才会在DTC层面设置TestFailed位。

2.1.3 UDS状态位

当DTC被存储到事件存储器后，其状态用8个bit表示（ISO 14229-1定义）：

实战理解：0x19服务（读取DTC信息）的很多子功能就是基于这些状态位的组合筛选：

• 0x02（reportDTCByStatusMask）：按状态掩码筛选DTC
• 0x0A（reportConfirmedDTC）：只读confirmedDTC=1的DTC
• 0x0E（reportDTCSnapshotIdentification）：读取快照记录标识

2.2 DTC结构：故障码、快照数据、扩展数据

2.2.1 DTC编码规则

DTC（Diagnostic Trouble Code）遵循SAE J2012 DA标准格式（针对乘用车）：

┌────────┬────────┬────────┐
│ Byte 1 │ Byte 2 │ Byte 3 │
├────────┴────────┴────────┤
│ Category │ Failure Type │
└─────────────────────────┘

• Byte 1（Category）：故障类别
  • P0xxx-P2xxx：动力系统（Powertrain）
  • C0xxx-C3xxx：底盘（Chassis）
  • B0xxx-B3xxx：车身（Body）
  • U0xxx-U3xxx：网络（Network）
• Byte 2-3（Failure Type）：具体的故障类型码

例如：P0101 → Category=P0（动力系统），Failure Type=101（MAF传感器信号不合理/卡滞）

2.2.2 Freeze Frame（冻结帧）

冻结帧是故障发生时的环境快照，类似于飞机黑匣子，在汽车行业叫“故障录制”。

冻结帧包含什么数据？ 这是完全可配置的，典型数据包括：

• 故障发生时的车速
• 发动机转速
• 冷却液温度
• 故障相关传感器的原始值
• 其他OEM关心的环境数据

冻结帧的存储策略（DaVinci配置参数DemFreezeFrameCapture）：

typedef enum {
DEM_TRIGGER_EVENT_MEMORY_STORAGE, // 触发条件：存入事件存储器时
DEM_TRIGGER_TESTFAILED // 触发条件：TestFailed位从0变1时
} DemFreezeFrameCaptureType;

OBD冻结帧的特殊要求：根据排放法规，OBD相关的DTC必须存储至少一组冻结帧，且格式必须符合ISO 15031规定的OBD Freeze Frame格式（通常是0号记录）。

2.2.3 Extended Data（扩展数据）

扩展数据是与DTC关联的统计和状态信息，包括：

配置示例（DaVinci Configurator中）：

DemConfigSet → DemDTCClass → DemExtendedDataClass
├── DemExtendedDataRecord[1]: ConfirmationCounter
├── DemExtendedDataRecord[2]: OccurrenceCounter
├── DemExtendedDataRecord[3]: FaultPendingCounter
├── DemExtendedDataRecord[4]: FaultRecoveryCounter
└── DemExtendedDataRecord[10]: OEMSpecificData

2.3 Debounce机制：计数法/时间法/频率法

防抖（Debounce）是诊断系统中最核心也最容易被误解的机制。为什么要防抖？

因为你不想把“偶发的瞬时干扰”当成“真实的硬件故障”来报。传感器线束受到一次电磁干扰就报故障，诊断仪上全是“幽灵故障”，车主会骂街，技师会崩溃。

AUTOSAR定义了三种防抖策略：

2.3.1 计数法（Counter-Based）

通过增减计数器来判断故障是否真正发生：

// 配置参数
DemCounterBasedDebounceThresholdFDC // 故障确认阈值（典型值：10）
DemCounterBasedDebounceFailedThreshold // 失败阈值（通常等于确认阈值）
DemCounterBasedDebouncePassedThreshold // 恢复阈值（典型值：0）
DemCounterBasedDebounceJumpUpValue // 跳跃值（快速进入failed状态）

工作原理： – Monitor报告FAILED → 计数器+1 – Monitor报告PASSED → 计数器-1 – 计数器达到阈值 → Event状态切换为failed – 计数器恢复到0 → Event状态切换为passed

适用场景： – 电气信号类故障（传感器短路/断路） – 需要快速响应但又要过滤偶发干扰的场景

2.3.2 时间法（Time-Based）

通过持续时间来判断故障是否真正发生：

// 配置参数
DemDebounceTimeBasedFailedTime // 故障确认所需持续时间（ms）
DemDebounceTimeBasedPassedTime // 恢复所需持续时间（ms）

工作原理： – Monitor报告FAILED → 启动计时器 – 持续FAILED状态达到配置时间 → Event状态切换为failed – Monitor变为PASSED → 计时器清零，状态切换为passed

适用场景： – 需要故障“稳定存在一段时间”才确认的场景 – 例如：总线通信超时故障（CAN/LIN通信消失10秒以上才报故障）

2.3.3 频率法（Frequency-Based）

通过失败次数/总检测次数的比例来判断故障：

// 配置参数
DemDebounceFrequencyBasedFailedThreshold // 确认阈值（0-100%）
DemDebounceFrequencyBasedFailedCycles // 统计周期内的检测次数

工作原理： – 在一个统计周期内，统计FAILED的次数 – 失败次数/总检测次数达到阈值 → Event状态切换为failed

适用场景： – 间歇性故障检测（如节气门开度信号偶尔跳变） – 需要评估故障发生频率而非单次持续时间的场景

2.3.4 实战选型建议

2.4 Operation Cycle与Aging

2.4.1 Operation Cycle的概念

Operation Cycle（操作循环）是AUTOSAR诊断中时间维度的基本单元。常见的Operation Cycle定义：

• PowerCycle（电源循环）：从KL15上电到下电为一个循环
• DrivingCycle（行驶循环）：从发动机启动到熄火为一个循环
• EngineRunCycle（发动机运行循环）：从发动机启动到停机

为什么需要Operation Cycle？

因为故障的确认和恢复往往需要跨越多个操作循环来判断。例如：

• OBD法规要求：催化器效率低于阈值，必须在两个行驶循环内确认故障
• 故障恢复验证：某些故障需要在下一次完整的行驶循环内不再出现，才能标记为“已恢复”

2.4.2 Aging（老化/自愈）机制

Aging是DEM中自动清除DTC的机制。当一个已确认的DTC在连续多个操作循环内都没有再次发生，DEM会将其从confirmed状态降级，最终清除。

Aging的工作流程：

Cycle 1: DTC confirmed (bit3=1, AgingCounter=0)
Cycle 2: DTC未发生 → AgingCounter++
Cycle 3: DTC未发生 → AgingCounter++
Cycle 4: DTC未发生 → AgingCounter++
…
Cycle N: AgingCounter达到阈值 → DTC进入"aged"状态
(bit3=0, DTC从confirmed列表移除，但仍可被0x19 0x0A查询)

关键配置参数：

DemAgingCycleCounterThreshold // Aging所需的连续无故障操作循环数
DemAgingCycleProcessing // Aging处理方式
// – DEM_AGING_CYCLE_PROCESSING_EXTERN: 外部提供Cycle状态
// – DEM_AGING_CYCLE_PROCESSING_INTERN: DEM内部计算

实战陷阱：

坑#1：Aging不生效？Operation Cycle理解偏差

很多工程师配置了Aging但发现DTC永远不会被老化清除，排查半天发现是Operation Cycle的定义有问题。

典型错误：将Operation Cycle配置为“PowerCycle”，但车辆在老化测试时是持续供电的（不关闭KL15），导致Cycle状态永远不会切换，Aging计数器永远不会增加。

解决方案：对于需要上电就老化的场景，应将Operation Cycle定义为DrivingCycle（基于车速或发动机转速判断Cycle切换），而不是简单的电源循环。

2.4.3 存储策略与Memory Allocation

DEM支持多种事件存储器：

Memory Overflow时的行为（DemEventDisplacementSupport）：

• 启用置换（Displacement）：当Memory满时，按优先级替换已存在的DTC
• 禁用置换：Memory满时，新DTC无法存储（可能导致故障丢失）

实战建议：对于安全相关的ECU，强烈建议启用Displacement，并配置合理的DTC优先级，确保关键DTC不会被非关键DTC挤出Memory。

2.5 DEM与NVM的交互

2.5.1 数据持久化架构

DEM本身不直接读写Flash/EEPROM，而是通过NVRAM Manager（NvM）来实现数据的持久化：

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ DEM │ ───▶ │ NvM │ ───▶ │ NVRAM │
│ │ API调用 │ │ │ (Flash/ │
│ • DTC状态 │ │ • 数据块管理 │ │ EEPROM) │
│ • 快照数据 │ │ • 写保护 │ │ │
│ • 扩展数据 │ │ • CRC校验 │ │ │
└──────────────┘ └──────────────┘ └──────────────┘

关键交互流程：

2.5.2 配置示例

DemConfigSet → DemNvBlockConfiguration
├── DemNvBlockLifetime: NORMAL // 普通数据块
├── DemNvRamBlockId: 0x01 // 对应NvM的Block ID
├── DemNvRamBlockCrc: ENABLE // 启用CRC校验
└── DemNvRamBlockWriting: ASYNC // 异步写入模式

2.5.3 常见配置问题

坑#2：DTC存不进去？NVM配置问题

症状：故障明明已经confirmed，但0x19读取不到

排查步骤： 1. 检查DemNvRamBlockId是否与NvM中配置的Block ID一致 2. 检查NVRAM的NvmJobResult是否正确（可能是上次写入失败） 3. 检查CRC校验是否通过（数据损坏会导致DEM拒绝加载） 4. 确认NVRAM的初始化顺序在DEM之前（EcuM的BSW Init Sequence）

第三章：DCM（Diagnostic Communication Manager）深度剖析

3.1 诊断会话管理

3.1.1 会话类型

DCM通过会话（Session）来区分不同的诊断访问权限。UDS定义的三个标准会话：

会话切换的时序：

Tester: 10 03 // 请求切换到Extended Session
ECU: 50 03 XX XX // 响应，P2Server=50ms, P2*Server=5000ms

Tester: 10 01 // 请求返回Default Session
ECU: 50 01 XX XX // 响应

会话超时机制：

// 配置参数
DcmDspSessionP2ServerMax // P2*时间（extended/Programming session）
DcmDspSessionP2StarServerMax // P2**时间（会话恢复时间）
DcmDspSessionTimeouterP2Server // 诊断仪等待响应超时时间

3.1.2 会话与安全等级的组合

会话和安全等级（Security Level）是两道独立的门：

Session 0x01 (Default) → Security Level 0 (Lock状态) → 基础权限
Session 0x03 (Extended) → Security Level 1 → 中等权限
Session 0x03 (Extended) → Security Level 2 → 最高权限
Session 0x02 (Programming)→ Security Level 3 (通常) → 刷写权限

3.2 安全等级：Seed&Key机制

3.2.1 安全访问流程

安全等级通过Seed & Key机制来实现访问控制：

┌─────────┐ ┌─────────┐ ┌─────────┐
│ Tester │ │ DCM │ │ App/BSW │
└────┬────┘ └────┬────┘ └────┬────┘
│ 27 01 (Request Seed) │ │
│─────────────────────────────▶│ │
│ │──── 27 01 ─────────────────▶│
│ │ 请求安全算法模块计算Seed │
│ │◀─── Seed_Value ─────────────│
│◀─────────────────────────────│ │
│ 67 01 XX XX XX XX (Seed) │ │
│ │ │
│ 27 02 (Send Key) │ │
│ 计算 Key = f(Seed) │ │
│─────────────────────────────▶│ │
│ │──── 27 02 Key ────────────▶│
│ │ 验证Key，正确则解锁 │
│ │◀─── SecurityResult ─────────│
│◀─────────────────────────────│ │
│ 67 02 XX (Key Valid) │ │
│ │ │
│ ✅ 现在可以访问受保护的服务 │ │

3.2.2 Seed&Key的实现

Seed&Key的算法由应用层或BSW模块实现，DCM只是转发：

// 典型的Seed&Key实现（简化示例）
Std_ReturnType GetSeed_SecurityLevel1(uint8* Seed)
{
// 生成随机Seed（实际需要加密伪随机数）
Seed[0] = 0x12;
Seed[1] = 0x34;
Seed[2] = 0x56;
Seed[3] = 0x78;
return E_OK;
}

Std_ReturnType CompareKey_SecurityLevel1(uint8* Key)
{
// 简单的Key验证算法（实际需要复杂加密）
uint32 expectedKey = (uint32)(Key[0]<<24 | Key[1]<<16 | Key[2]<<8 | Key[3]);
uint32 actualKey = ~expectedKey + 1; // 取反+1只是示例

if (expectedKey == actualKey) {
Dcm_SecuritySetLevel(1); // 解锁安全等级
return E_OK;
}
return E_NOT_OK;
}

3.2.3 安全等级配置

DcmConfigSet → DcmDspSecurity
├── DcmDspSecurityRowId: 1 // 安全等级ID
├── DcmDspSecuritySeedSize: 4 // Seed字节数
├── DcmDspSecurityKeySize: 4 // Key字节数
├── DcmDspSecurityAttemptCounterMax: 3 // 最大尝试次数
├── DcmDspSecurityDelayTime: 10000 // 锁定等待时间(ms)
└── DcmDspSecurityLocked: TRUE // 初始状态：锁定

实战提示：实际项目中Seed&Key算法通常由OEM或安全团队提供，并严格保密。常见的混淆算法包括： – XOR/移位混淆 – AES加密（硬件支持） – 查表法

3.3 UDS服务路由：核心服务详解

DCM的内部架构分为三个子模块：

┌─────────────────────────────────────────────────────────────────┐
│ DCM Architecture │
├─────────────────────────────────────────────────────────────────┤
│ DSL (Diagnostic Session Layer) │
│ • 诊断请求/响应的数据流 │
│ • 会话状态管理 │
│ • P2/P2*定时器管理 │
├─────────────────────────────────────────────────────────────────┤
│ DSD (Diagnostic Service Dispatcher) │
│ • 请求分发：路由到对应的DSP │
│ • 子功能验证 │
│ • 权限检查（会话+安全等级） │
├─────────────────────────────────────────────────────────────────┤
│ DSP (Diagnostic Service Processor) │
│ • 执行具体的UDS服务逻辑 │
│ • 与DEM/App交互获取数据 │
│ • 组装响应报文 │
└─────────────────────────────────────────────────────────────────┘

3.3.1 0x10 – 诊断会话控制（DiagnosticSessionControl）

// 请求格式
0x10 SS
// SS: subfunction = 01(Default) / 02(Programming) / 03(Extended)

// 响应格式
0x50 SS P2Server P2StarServer [optional: sessionParameterRecord]

会话切换时的行为：

3.3.2 0x19 – 读取DTC信息（ReadDTCInformation）

0x19是最复杂的UDS服务之一，有多个子功能：

0x19 0x02的典型交互：

Tester: 19 02 FF // 读取所有DTC (statusMask=0xFF)
ECU响应: 59 02 XX (DTCCount) [(DTC1)(Status1) (DTC2)(Status2) …]

3.3.3 0x22/0x2E – 读写数据标识符（DataByIdentifier）

0x22: ReadDataByIdentifier // 读取
0x2E: WriteDataByIdentifier // 写入

典型应用：

// 0x22读取DID示例（读取车辆VIN码 F190）
Tester: 22 F1 90
ECU: 62 F1 90 "LSVXX45678SA123456"

// 0x2E写入DID示例（写入VIN码）
Tester: 2E F1 90 "LSVXX45678SA123456"
ECU: 7E F1 90 // Positive Response

DID配置要点：

DcmConfigSet → DcmDspData → DcmDspDidClass
├── DcmDspDidIdentifier: 0xF190 // DID号
├── DcmDspDidDataSize: 17 // 数据长度
├── DcmDspDidSecurityLevelRead: 0 // 读取所需安全等级
├── DcmDspDidSecurityLevelWrite: 2 // 写入所需安全等级
├── DcmDspDidSessionLevelRead: 1 // 读取所需会话
└── DcmDspDidSessionLevelWrite: 3 // 写入所需会话

3.3.4 0x31 – 例程控制（RoutineControl）

用于执行特定的操作序列：

典型应用场景：

• 雨刮自学习（位置初始化）
• 电动车窗防夹功能参数学习
• 胎压传感器位置匹配
• ECU复位后的配置加载

3.3.5 0x34-0x36 – 文件传输（RequestDownload/TransferData/RequestTransferExit）

用于大块数据的传输，通常用于：

• Flash Programming（Bootloader更新）
• 远程OTA升级包下载
• 配置参数批量写入

传输流程：

1. 34: RequestDownload (请求开始传输，指定地址和长度)
└─ 收到74 + lengthFormatId + maxBlockLength

2. 36: TransferData (逐块传输数据)
└─ 每次传输后收到76 + blockSequenceCounter

3. 37: RequestTransferExit (结束传输)
└─ 收到77，确认传输完成

3.3.6 0x28 – 通信控制（CommunicationControl）

用于控制ECU的通信行为：

0x28 00 01 // 关闭网络管理报文，保留应用报文
0x28 03 01 // 关闭扩展诊断会话的应用报文

典型应用：

• Bootloader刷写时关闭应用报文
• 某些测试场景下禁用部分报文
• 降低功耗时减少总线负载

3.3.7 0x14 – 清除DTC（ClearDiagnosticInformation）

// 请求格式
0x14 XX XX XX
// └── DTC Format Identifier + Group of DTC

// 常见用法
14 FF FF FF // 清除所有DTC（组=0xFFFFFF）
14 00 00 00 // 清除排放相关DTC（OBD组）

清除时的数据清除顺序：

1. 清除Primary Memory中的DTC + 快照 + 扩展数据
2. 清除Secondary Memory中的DTC（如果配置）
3. 清除Mirror Memory中的DTC（如果配置）
4. 清除Permanent Memory（通常需要特殊权限）

坑#3：0x19返回不正确？DEM-DCM映射遗漏

症状：诊断仪请求0x19 0x02读取DTC，但返回空列表或DTC状态不对

排查步骤： 1. 确认DTC的DemDtcOrigin是否正确映射到DCM可访问的Memory 2. 确认DTC的DemDtcObdGuest配置（OBD相关DTC的特殊处理） 3. 检查DcmDcmGenericDtcFilter的DTC状态掩码过滤配置 4. 确认DEM初始化完成（EcuM_BSW_Init Sequence中DEM在DCM之前）

3.4 DCM-DEM接口：谁管理DTC的读写？

DTC的读写是DCM和DEM协作完成的，但谁主导这个问题需要厘清：

读DTC时：

诊断仪 ──0x19请求──▶ DCM ──Dem_GetDTCByStatusMask()──▶ DEM
◀───DTC列表+状态──────────────────
◀──响应报文─────────────────────────────── DCM

关键API：

// DCM调用这些API获取DTC信息
Dem_ReturnGetDTCByStatus Type Dem_GetDTCByStatusMask(
uint8 StatusMask,
Dcm_DTCListType* DTCList
);

Dem_ReturnGetNumberOfFilteredDTCType Dem_GetNumberOfFilteredDTC(
uint8 StatusMask,
uint16* NumberOfDTC
);

清除DTC时：

诊断仪 ──0x14请求──▶ DCM ──Dem_ClearDTC()──▶ DEM
◀───清除结果─────────────────
◀──响应报文─────────────────────────── DCM

关键API：

Dem_ReturnClearDTCType Dem_ClearDTC(
uint32 DTC, // DTC码（0xFFFFFF表示全部）
Dem_DTCFormatType DTCFormat,
Dem_DTCOriginType DTCOrigin // Primary/Secondary/Permanent/Mirror
);

第四章：FIM（Function Inhibition Manager）

4.1 功能禁用的触发机制

FIM是AUTOSAR诊断体系中连接故障与功能的桥梁。它的核心逻辑是：当某些关键故障发生时，禁用相关的软件功能以保护人身安全或防止故障扩大。

FIM的工作原理：

┌────────────┐ ┌────────────┐ ┌────────────┐
│ DEM │ ──────▶ │ FIM │ ──────▶ │ SW-C │
│ │ Event │ │ FID │ │
│ 检测到故障 │ Status │ 查找FID │ Inhibit │ 检查FID │
│ │ Changed │ 映射表 │ Signal │ 是否被抑制 │
└────────────┘ └────────────┘ └────────────┘

关键概念：

• FID（Function Inhibition Identifier）：功能抑制ID，标识需要被抑制的功能
• Event-to-FID映射：一个Event可以触发多个FID，一个FID也可以被多个Event触发

4.2 配置示例

// DemConfigSet中定义Event到FID的映射
FimConfigSet → FimFunctionId
├── FimFunctionId: 0x01 // 功能ID：发动机扭矩限制
├── FimFunctionAvailable: TRUE // 功能可用
└── FimEventIdRef: [Event_EngineOverTemp, Event_ThrottleSensorFail]
// 触发条件：水温过高 或 节气门传感器故障

FimConfigSet → FimFunctionId
├── FimFunctionId: 0x02 // 功能ID：巡航控制
└── FimEventIdRef: [Event_CruiseControlFail]

软件组件中的FID检查：

void CruiseControl_MainFunction(void)
{
// 检查巡航控制是否被抑制
if (Fim_GetFunctionAvailable(FIM_FUNCTION_ID_CRUISE_CONTROL) == FALSE) {
// 功能被抑制，退出
return;
}

// 正常执行巡航控制逻辑
// …
}

4.3 ASIL相关功能的降级策略

在功能安全领域，FIM常用于实现ASIL（Automotive Safety Integrity Level）降级策略：

降级策略的设计原则：

第五章：ECU State Manager与诊断的联动

5.1 EcuM状态机

ECU State Manager管理ECU的完整生命周期：

┌─────────┐ Wakeup ┌─────────┐
│ OFF │◀────────────│ STARTUP │
└─────────┘ └────┬────┘
│ │
│ 下电 │ EcuM_Init
▼ ▼
┌─────────┐ ┌─────────┐
│ SHUTDOWN│─────────────▶│ RUN │
└─────────┘ Sleep/Reset└────┬────┘
│
│ 预热完成/驾驶员离开
▼
┌───────────┐
│ POST_RUN │
└─────┬─────┘
│
│ 超时/下电请求
▼
┌───────────┐
│ SHUTDOWN │
└───────────┘

5.2 诊断在哪个状态可用？

诊断服务的可用性取决于ECU状态：

配置示例（EcuM_GetSessionInfo）：

// 定义诊断会话与ECU状态的关联
typedef enum {
ECU_STATE_OFF = 0,
ECU_STATE_STARTUP,
ECU_STATE_RUN,
ECU_STATE_POST_RUN,
ECU_STATE_SHUTDOWN
} EcuM_StateType;

5.3 Initialization Timing

DEM初始化的时序要求：

EcuM_Init
│
├─▶ NvM_Init // 1. NVRAM Manager先初始化
│
├─▶ Dem_PreInit // 2. DEM预初始化（配置检查）
│
├─▶ Dem_Init // 3. DEM正式初始化
│ │
│ ├─▶ Dem_SetEventStatus() // Monitor开始报告故障
│ │
│ └─▶ NvM_ReadBlock() // 从NVRAM恢复DTC数据
│
└─▶ Dcm_Init // 4. DCM最后初始化，开始响应诊断请求

为什么要这样排序？

• NvM必须最先，因为它提供存储服务
• DEM必须在DCM之前初始化，否则DCM收到诊断请求时DEM还没准备好
• DCM最后初始化，确保所有下游服务都已就绪

**坑#4：诊断响应超时？P2/P2*时序配置**

症状：诊断仪请求超时，P2 Server Error

常见原因： 1. DcmDspSessionP2ServerMax配置过小（典型值：50ms） 2. DcmDspSessionP2StarServerMax配置过小（典型值：5000ms） 3. 诊断服务处理时间过长（NVRAM读写、复杂计算） 4. 总线通信延迟

解决方案：

DcmDspSessionRow[0] → DefaultSession
├── P2ServerMax: 50ms // 标准响应时间
└── P2StarServerMax: 5000ms // 扩展响应时间（等待处理）

DcmDspSessionRow[2] → ExtendedSession
├── P2ServerMax: 50ms
└── P2StarServerMax: 15000ms // 复杂操作需要更长时间

5.4 快速启动场景下的诊断就绪策略

对于安全相关ECU（如安全气囊ECU），快速启动是一个关键需求。OBD法规要求：

排放相关ECU必须在行驶循环开始后15秒内完成所有DTC的就绪状态更新。

快速启动策略：

第六章：实战案例 – 空气流量传感器故障的完整诊断流程

6.1 场景描述

一辆车的空气流量传感器（MAF）信号在高速行驶时出现异常跳变，导致混合气过浓，发动机亮灯。

6.2 完整诊断流程

Step 1: 传感器故障检测

// AirFlowSensor.c – 软件组件的Monitor函数
void AirFlowSensor_Monitor(void)
{
uint16 rawValue = MAF_GetRawValue();
boolean faultDetected = FALSE;

// 信号范围检查
if (rawValue > MAF_MAX_VALID_VALUE || rawValue < MAF_MIN_VALID_VALUE) {
faultDetected = TRUE;
}

// 信号跳变率检查
uint16 delta = ABS(rawValue – lastValidValue);
if (delta > MAF_MAX_DELTA_PER_CYCLE) {
faultDetected = TRUE;
}

// 向DEM报告Event状态
if (faultDetected) {
Dem_ReportErrorStatus(DEM_EVENT_ID_MAF_OUT_OF_RANGE);
} else {
Dem_ReportErrorStatus(DEM_EVENT_ID_MAF_NORMAL);
}
}

Step 2: DEM Event处理

DEM接收到Event: MAF_OUT_OF_RANGE
│
├─▶ 检查EnableCondition: 是否满足监控条件？
│ └─▶ 发动机转速>500rpm？温度>-40°C？→ 满足
│
├─▶ 执行Debounce（计数法）
│ └─▶ 连续10次检测到FAIL → Event状态变为failed
│
├─▶ 检查StorageCondition
│ └─▶ 车速>30km/h？→ 满足
│
└─▶ 存储DTC: P0101 (MAF Signal Range/Performance)
├─▶ 设置DTC状态位: TestFailed=1, PendingDTC=1
├─▶ 捕获FreezeFrame（当前车速、转速、温度）
└─▶ 通知FIM: Fim_EventStatusChanged(MAF_FAULT, FAILED)

Step 3: FIM功能禁用

FIM收到通知: MAF故障已确认
│
├─▶ 查找FID映射表
│ └─▶ FID_ENGINE_TORQUE_LIMIT ← Event MAF_FAULT
│
└─▶ 发送Inhibition信号
└─▶ EngineControl_SWC收到: TorqueLimit = 50%

Step 4: 诊断仪读取故障

诊断仪: 10 03 // 切换到Extended Session
ECU: 50 03 XX XX

诊断仪: 27 01 // 请求安全访问Seed
ECU: 67 01 XX XX XX XX

诊断仪: 27 02 XX XX XX XX // 发送Key
ECU: 67 02 // 安全等级解锁

诊断仪: 19 02 FF // 读取所有DTC
ECU: 59 02 03 // 3个DTC
(P0101)(12) // MAF故障，状态=0x12
(P0172)(12) // 混合气过浓继发故障
(P0420)(02) // 催化器效率（需进一步确认）

诊断仪: 19 06 P0101 01 // 读取P0101的快照记录1
ECU: 59 06 P0101 01
[车速=80km/h][转速=3500rpm][温度=85°C][MAF=520g/s]

Step 5: 维修后清除故障

诊断仪: 14 FF FF FF // 清除所有DTC
ECU: 54 // 清除成功

诊断仪: 19 02 FF // 再次读取验证
ECU: 59 02 00 // 0个DTC

6.3 DaVinci Configurator关键配置

6.3.1 DEM配置

DemConfigSet → DemDTCClass[0]
├── DemDtcClassId: 0
├── DemDtcClassName: "MAF_P0101"
├── DemDtcValue: 0x0101
├── DemDtcSeverity: DEM_DTC_SEVERITY_C
└── DemDtcKind: DEM_DTC_KIND_EMISSION

DemConfigSet → DemEventParameter[MAF_OUT_OF_RANGE]
├── DemEventId: 100
├── DemDTCClassRef: → DemDTCClass[0]
├── DemDebounceAlgorithm: DEM_DEBOUNCE_COUNTER_BASED
├── DemCounterBasedDebounceThresholdFDC: 10
├── DemCounterBasedDebounceJumpUpValue: 5
└── DemFreezeFrameClass: → DemFreezeFrameClass[0]

DemConfigSet → DemFreezeFrameClass[0]
├── DemFreezeFrameRecordNumber: 1
├── DemFreezeFrameDataClass:
│ ├── FF_VehicleSpeed: 0x01
│ ├── FF_EngineSpeed: 0x02
│ ├── FF_CoolantTemp: 0x03
│ └── FF_MAF_Value: 0x04
└── DemFreezeFrameCapture: DEM_TRIGGER_TESTFAILED

6.3.2 DCM配置

DcmConfigSet → DcmDspServiceTable[0]
├── DcmDspServiceId: 0x19
├── DcmDspServiceUsedInSession: [Default, Extended, Programming]
├── DcmDspServiceUsedInSecurity: [0, 1, 2]
└── DcmDspSubService:
├── SubFunction: 0x02 (reportDTCByStatusMask)
└── SubFunction: 0x06 (reportDTCSnapshotRecordByDTCNumber)

DcmConfigSet → DcmDspDid[0xF195]
├── DcmDspDidIdentifier: 0xF195
├── DcmDspDidDataSize: 4
├── DcmDspDidSecurityLevelRead: 0
└── DcmDspDidData: → DcmDspData[MAF_RawValue]

6.3.3 FIM配置

FimConfigSet → FimFunctionId[0]
├── FimFunctionId: 0x01
├── FimFunctionName: "EngineTorqueLimit"
├── FimFunctionAvailable: TRUE
└── FimEventIdRef:
├── Event: MAF_OUT_OF_RANGE
└── Event: THROTTLE_FAIL

FimConfigSet → FimFunctionId[1]
├── FimFunctionId: 0x02
├── FimFunctionName: "CruiseControl"
└── FimEventIdRef:
└── Event: MAF_OUT_OF_RANGE

第七章：常见坑与调试技巧

坑#1：DTC存不进去？NVM配置问题

症状：故障已confirmed，但0x19读取不到

排查清单：

□ 1. 检查NVRAM Block的读写权限
□ 2. 确认DemNvRamBlockId与NvM Block ID一致
□ 3. 检查NvM_BlockCrc配置是否启用
□ 4. 查看NVRAM初始化是否在DEM之前完成
□ 5. 确认DEM初始化前NVRAM数据完整性（CRC校验）
□ 6. 检查Storage Condition是否满足

典型配置问题：

// ❌ 错误：Block ID不匹配
DemConfigSet → DemNvRamBlockConfiguration
└── DemNvRamBlockId: 0x10 // DEM配置为0x10

NvMConfig → NvMBlockDescriptor[0]
└── NvMBlockId: 0x11 // NvM配置为0x11

// ✅ 正确：ID必须一致
DemConfigSet → DemNvRamBlockConfiguration
└── DemNvRamBlockId: 0x10

NvMConfig → NvMBlockDescriptor[0]
└── NvMBlockId: 0x10

坑#2：0x19返回不正确？DEM-DCM映射遗漏

症状：请求0x19 0x02返回空列表，但实际有DTC

排查清单：

□ 1. 确认DTC的DemDtcOrigin配置（Primary/Secondary）
□ 2. 检查DcmDcmGenericDtcFilter的StatusMask配置
□ 3. 确认DTC未配置为"Suppressed"
□ 4. 检查DTC的EnableCondition是否满足
□ 5. 确认DEM初始化完成（检查Dem_Init返回值）
□ 6. 查看DEM是否报告了DEM_E_NO_INIT错误

坑#3：Aging不生效？Operation Cycle理解偏差

症状：DTC确认后长时间未自动老化

排查清单：

□ 1. 确认Operation Cycle定义是否正确
– PowerCycle: 基于KL15上下电
– DrivingCycle: 基于车速/发动机状态

□ 2. 检查DemAgingCycleCounterThreshold配置
– 典型值: 40-80个循环（法规要求）

□ 3. 确认Operation Cycle切换检测逻辑
– 是否有传感器/硬件问题导致Cycle无法切换？

□ 4. 检查连续无故障循环计数
– 调试器中观察AgingCounter变量的变化

□ 5. 确认Aging的触发条件
– DEM_AGING_CYCLE_PROCESSING_INTERN vs _EXTERN

坑#4：诊断响应超时？P2/P2*时序配置

症状：诊断仪报“Request Timeout”或“P2 Server Error”

排查清单：

□ 1. 检查P2ServerMax和P2StarServerMax配置
□ 2. 确认会话类型对应的时序参数
□ 3. 测量实际服务处理时间（示波器/调试器）
□ 4. 检查NVRAM读写是否阻塞
□ 5. 确认中断优先级是否合理（诊断中断被阻塞？）
□ 6. 检查总线通信延迟

典型配置值：

// 常规ECU配置
DcmDspSessionRow → DefaultSession
├── P2ServerMax: 50ms
└── P2StarServerMax: 5000ms

// 复杂ECU（需要更长处理时间）
DcmDspSessionRow → ExtendedSession
├── P2ServerMax: 100ms
└── P2StarServerMax: 15000ms

// Bootloader（快速响应优先）
DcmDspSessionRow → ProgrammingSession
├── P2ServerMax: 25ms
└── P2StarServerMax: 3000ms

坑#5：安全等级反复锁定？Seed&Key实现问题

症状：输入正确的Key仍然无法解锁

排查清单：

□ 1. 检查Seed&Key算法的一致性（ECU端 vs 诊断仪端）
□ 2. 确认Seed是否每次请求都不同（防止重放攻击）
□ 3. 检查Key比较逻辑（大小端问题？）
□ 4. 确认AttemptCounter是否溢出
□ 5. 检查DelayTime配置（锁定等待时间是否合理）
□ 6. 查看安全模块的Debug输出

第八章：总结与思维导图

核心知识点回顾

调试建议

进阶学习路径

基础: UDS协议 (ISO 14229-1) → AUTOSAR CP架构 → DEM/DCM/FIM规范
实践: DaVinci Configurator配置 → 实车测试 → 问题排查
高级: 功能安全 (ISO 26262) → ASIL降级策略 → 故障注入测试
专家: OBD法规 (ISO 15031) → 排放认证 → 全球统一法规(GTR)

附录：诊断体系思维导图

mindmap
root((AUTOSAR诊断体系))
)诊断通信层(DCM)
诊断会话管理
Default Session (0x01)
Extended Session (0x03)
Programming Session (0x02)
安全访问控制
Seed & Key机制
Access Level层级
UDS服务路由
0x10 会话控制
0x11 ECU复位
0x14 清除DTC
0x19 读取DTC
reportDTCByStatusMask
reportDTCSnapshotRecord
reportDTCExtendedData
0x22/0x2E 读写DID
0x27/0x28 安全/通信控制
0x31 例程控制
0x34-0x36 文件传输
内部子模块
DSL 诊断会话层
DSD 服务分发器
DSP 服务处理器
)诊断事件管理(DEM)
Event生命周期
qualified 预确认
prefailed/failed 故障确认
prepassed/passed 恢复
DTC数据结构
DTC故障码
Freeze Frame快照
Extended Data扩展
防抖机制
计数法 快速响应
时间法 稳定检测
频率法 间歇故障
存储与老化
Primary/Secondary Memory
Operation Cycle
Aging Counter
Mirror Memory
NVM持久化
下电保存
上电恢复
CRC校验
)功能抑制管理(FIM)
FID功能标识
Event-to-FID映射
功能降级策略
ASIL分级降级
Fail-Safe
Fail-Operational
)ECU状态管理(EcuM)
状态机
STARTUP
RUN
POST_RUN
SHUTDOWN
诊断就绪时序
快速启动策略

参考资料

声明：本文基于AUTOSAR CP R24-11规范及行业实践经验编写，部分示例代码和配置参数仅供参考，实际项目请以具体OEM规范和供应商文档为准。

相关文章： – CP-01：AUTOSAR CP架构详解 – 从入门到精通 – CP-03：AUTOSAR BSW层架构与MCAL详解 – CP-05：RTE运行时环境 – SW-C与BSW的桥梁

作者：汽车嵌入式软件老兵 | 专注AUTOSAR架构设计与诊断开发 标签：#AUTOSAR #汽车诊断 #嵌入式开发 #DEM #DCM #UDS #车载软件