诊断服务实现（上）：0x10、0x11、0x14、0x19 的配置与实现
好，咱们今天来啃几块硬骨头。
0x10（诊断会话控制）、0x11（ECU复位）、0x14（清除诊断信息）、0x19（读取DTC信息）。这四个服务，是UDS诊断里最基础、也最常用的。你想想看，一个诊断工具连上ECU，第一件事就是切会话，然后读故障码，清故障码，搞不定就复位。所以这部分实现，必须稳。
0x10 诊断会话控制：一切诊断的起点
0x10服务，说白了就是告诉ECU：「我要开始干活了，你准备好。」
我个人习惯，在配置这个服务时，会先画一张会话状态机图。默认会话（Default Session）是上电后的初始状态。编程会话（Programming Session）和扩展会话（Extended Session）需要主动请求切换。
核心配置要点：
- 会话超时时间（S3 Server）：默认会话通常设为5000ms，扩展会话可以设长一点，比如10000ms。我遇到过客户要求编程会话永不超时，但说实话，这不太安全，建议还是设一个合理的值。
- 会话间转换规则：从非默认会话切回默认会话，只能通过超时或显式请求0x10 01。不能直接从编程会话跳到扩展会话，必须经过默认会话。
- 安全等级绑定：某些诊断服务只能在特定会话下执行。比如0x31（例程控制）通常只能在扩展会话下用。
代码实现上，我一般会在BswM（基础软件管理器）里注册会话状态回调。当会话切换时，BswM会通知各个模块更新自己的行为模式。
/* 伪代码示例：会话控制处理 */
void Dcm_HandleSessionControl(uint8 sessionType) {
switch(sessionType) {
case 0x01: // Default Session
Dcm_SetSessionState(DCM_SESSION_DEFAULT);
BswM_RequestMode(BSWM_SESSION_DEFAULT);
break;
case 0x02: // Programming Session
Dcm_SetSessionState(DCM_SESSION_PROGRAMMING);
BswM_RequestMode(BSWM_SESSION_PROGRAMMING);
break;
case 0x03: // Extended Session
Dcm_SetSessionState(DCM_SESSION_EXTENDED);
BswM_RequestMode(BSWM_SESSION_EXTENDED);
break;
default:
Dcm_SendNegativeResponse(NRC_SUBFUNCTION_NOT_SUPPORTED);
break;
}
}避坑指南：我曾经在一个项目里，把会话超时时间设得太短，结果诊断仪刚切到扩展会话，还没来得及发下一个请求，ECU就自动切回默认会话了。排查了半天，才发现是S3 Server设成了2000ms。嗯，这个坑你们别踩。
0x11 ECU复位：让ECU「重启一下」
0x11服务，就是让ECU执行复位操作。有三种复位类型：硬复位（Hard Reset）、钥匙下电复位（Key Off/On Reset）、软复位（Soft Reset）。
我个人建议，在实现时要注意以下几点：
- 复位前的准备：ECU收到复位请求后，不能立刻复位。得先保存NVM数据，关闭通信，通知所有应用模块准备关机。我见过一个项目，复位时没保存DTC快照数据，结果复位后故障码全丢了，客户投诉说「你们这诊断功能是假的吧」。
- 复位响应时序：ECU必须在发送正响应（0x51 + 复位类型）之后，才能执行复位操作。而且响应发送后，要留出至少50ms的延迟，确保诊断仪收到了响应。
- 复位后行为：复位完成后，ECU自动进入默认会话。如果诊断仪想继续诊断，得重新发0x10切会话。
特别注意：0x11服务不能用于「热启动」或「应用层重启」。它必须是完整的ECU复位流程。我曾经看到有人把0x11实现成只重启OS，结果NVM数据没保存，下次上电直接进异常。这属于严重的设计缺陷。
0x14 清除诊断信息：清故障码的学问
0x14服务，用来清除DTC及其相关的快照数据、扩展数据。看似简单，其实坑不少。
配置时，你需要关注：
- 清除范围：0x14可以清除所有DTC，也可以清除特定组的DTC（比如动力总成组、底盘组）。我建议在配置时，把DTC分组做好，这样诊断仪可以精准清除，避免误删。
- 清除条件：有些DTC是「永久故障码」，不能通过0x14清除。只有满足特定条件（比如故障不再存在、经过一定驾驶循环）后，才能被清除。这个逻辑要在Dcm模块里实现。
- 清除后的状态：清除成功后，ECU应该把DTC状态位全部清零，包括testFailed、confirmed、pending等。但注意，有些客户要求保留「已测试」位，这个得看具体需求。
实现建议：我习惯在Dem（诊断事件管理器）里维护一个DTC状态表。当收到0x14请求时，遍历这个表，把符合条件的DTC状态清零。同时，要触发NVM写操作，确保掉电后数据不丢失。
/* 伪代码示例：清除DTC */
void Dem_ClearDTC(uint32 dtcGroup) {
for (int i = 0; i < Dem_GetDtcCount(); i++) {
if (Dem_IsDtcInGroup(i, dtcGroup)) {
Dem_ClearDtcStatus(i);
Dem_SaveDtcToNvm(i);
}
}
Dcm_SendPositiveResponse(0x54);
}避坑指南：我曾经遇到一个bug，0x14清除后，DTC状态确实清零了，但快照数据没清。结果诊断仪读快照时，还能读到旧的冻结帧数据。后来发现是Dem模块的清除函数只清了状态位，没清数据记录。所以，实现时一定要把「清除DTC」和「清除相关数据」绑定在一起。
0x19 读取DTC信息：诊断的核心输出
0x19服务，是UDS里最复杂的服务之一。它有很多子功能，比如读已确认的DTC、读待定的DTC、读快照数据、读扩展数据等。
配置时，我建议重点关注：
- 子功能选择：0x19有28个子功能，但实际项目中常用的就几个：0x01（按状态掩码读DTC）、0x02（按DTC严重程度读）、0x04（读快照数据）、0x06（读扩展数据）。别贪多，够用就行。
- 状态掩码设计：状态掩码是0x19 01的核心。它用8位二进制表示DTC的各个状态位。比如掩码0x2F表示读取所有已确认的DTC。我建议在文档里把掩码定义写清楚，方便诊断仪开发人员理解。
- 快照数据配置：每个DTC可以关联多个快照记录（Snapshot Record）。快照里包含环境数据，比如车速、发动机转速、冷却液温度等。配置时，要定义好每个DTC需要记录哪些数据，以及记录多少个快照。
性能优化：0x19的响应数据可能很大，尤其是读所有DTC的快照时。我建议在实现时，使用分段传输（如ISO-TP的连续帧）。同时，在Dem模块里做好数据缓存，避免每次读请求都去NVM里翻数据。
/* 伪代码示例：读取DTC信息 */
void Dcm_ReadDtcInformation(uint8 subFunction, uint8* data) {
switch(subFunction) {
case 0x01: // Report DTC By Status Mask
uint8 statusMask = data[0];
Dem_GetDtcByStatusMask(statusMask, &dtcList);
Dcm_SendDtcList(dtcList);
break;
case 0x04: // Report Snapshot Record
uint32 dtc = (data[0] << 16) | (data[1] << 8) | data[2];
uint8 recordNum = data[3];
Dem_GetSnapshotRecord(dtc, recordNum, &snapshot);
Dcm_SendSnapshot(snapshot);
break;
default:
Dcm_SendNegativeResponse(NRC_SUBFUNCTION_NOT_SUPPORTED);
break;
}
}特别注意：0x19的响应格式必须严格遵循ISO 14229-1标准。比如，读DTC列表时，响应数据的第一字节是DTC数量，后面跟着DTC及其状态字节。我曾经见过一个项目，把DTC数量字节放错了位置，结果诊断仪解析出来的数据全是乱的。这种低级错误，千万别犯。
小结
这四个服务，是诊断栈的基石。0x10管会话，0x11管复位，0x14管清除，0x19管读取。配置时，多想想实际场景：诊断仪怎么用？ECU怎么响应？数据怎么存？
我个人经验是，先把标准读透，再结合实际项目需求做裁剪。别一上来就想搞个大而全的实现，容易翻车。
下一章，咱们继续聊剩下的诊断服务实现。到时候，我会重点讲0x22（读取数据）、0x2E（写入数据）和0x31（例程控制）。这些服务，才是真正和业务逻辑打交道的。