UDS 28服务诊断会话控制的Davinci实战配置：从协议到落地的完整路径
你有没有遇到过这样的场景？在做OTA升级时，ECU明明已经进入编程会话，但总线上的周期性报文还在“狂发”，不仅占用带宽，还可能干扰刷写流程。或者你在调试安全访问流程时，发现某些通信无法真正关闭——问题很可能就出在UDS 28服务的配置上。
作为AUTOSAR诊断系统中极为关键的一环，Communication Control（SID: 0x28）看似简单，实则牵一发动全身。它不仅是实现“通信静默”的技术手段，更是保障软件刷新、安全调试和低功耗诊断顺利进行的基础能力。而使用DaVinci Developer + DaVinci Configurator Pro工具链进行配置时，稍有疏忽就会导致请求无响应、控制失效或状态混乱。
本文将带你穿透工具表象，直击底层机制，通过真实开发视角还原UDS 28服务在AUTOSAR架构下的完整配置逻辑与典型问题应对策略，助你构建稳定可靠的诊断通信控制系统。
为什么是28服务？不只是“关发送”那么简单
我们先来打破一个常见误解：很多人以为28h服务就是“让ECU别发消息了”。但实际上，它的作用远比这精细得多。
根据 ISO 14229-1 标准定义，UDS Service 28（Communication Control）是一种基于子功能（Sub-function）和通信类型（CommunicationType）双重控制的动态通信管理机制。它可以精确地：
- 启用/禁用正常通信（Normal Communication）
- 控制网络管理报文收发（NM Communication）
- 区分发送与接收通道
- 组合多种模式以适应不同工况
比如：
- 在 Flash 编程阶段，仅禁用周期性信号发送，保留诊断响应能力；
- 在安全调试模式下，完全屏蔽外部非必要通信，防止信息泄露；
- 进入休眠前，主动关闭所有应用层发送，降低总线负载。
这种“细粒度控制”正是其价值所在。而在 AUTOSAR 架构中，要实现这一功能，必须依赖 Dcm、ComM、CanSM 等多个模块协同工作。
28服务是如何工作的？一张图看懂数据流
当诊断仪发出一条28 02 03请求时，背后发生了什么？
[Diagnostic Tool] ↓ (CAN FD) [CanTp] ← [Dcm] ↔ [Dem] ↓ ↑ [PduR] ← [ComM] ↔ [CanSM] ↓ [CanIf] ↓ [Can Driver]整个流程可以分解为以下几个关键步骤：
- 请求到达 CanTp 层：原始 CAN 帧被重组为完整的 UDS 请求。
- Dcm 模块识别 SID=0x28：调度至对应的处理函数。
- 权限校验：检查当前是否处于允许执行该操作的诊断会话（如 DefaultSession 或 ProgrammingSession）。
- 解析参数：
- SubFunction =0x02→ Disable Transmission
- CommunicationType =0x03→ Normal Tx + NM Tx - 调用 ComM 接口：
ComM_CommunicationControl(channel, disable) - 状态迁移触发：ComM 通知 CanSM 进入 No Communication 状态
- 底层阻断：CanIf 停止调度相关 PDU，物理层不再发送
- 返回响应：成功则回
78 02 03；失败则返回 NRC（Negative Response Code）
✅ 正响应示例：
78 02 03
❌ 负响应示例：7F 28 12（NRC 12: sub-function not supported）
可以看到，这条短短的命令背后，涉及至少五个 AUTOSAR 模块的联动。任何一个环节配置错误，都会导致控制失败。
关键字段详解：别再搞混 CommunicationType 和 SubFunction
很多工程师踩坑的第一个地方，就是没搞清楚这两个字节到底代表什么。
SubFunction：你要做什么？
| 值 | 动作 | 说明 |
|---|---|---|
0x01 | Enable transmission | 开启发送 |
0x02 | Disable transmission | 关闭发送 |
0x03 | Enable reception | 开启接收（可选） |
0x04 | Disable reception | 关闭接收（可选） |
0x05 | Disable both tx/rx | 同时关闭收发 |
0x06 | Enable both tx/rx | 恢复全部通信 |
注意：并非所有子功能都必须支持。通常我们只启用
0x01,0x02,0x05,0x06。
CommunicationType：你对哪种通信下手？
这是一个位编码字段，每个 bit 控制一类通信行为：
| Bit | 含义 | 典型用途 |
|---|---|---|
| 0 | Normal Message Transmission | 周期性信号、事件报文 |
| 1 | Normal Message Reception | 应用层接收处理 |
| 2 | Network Management Transmission | CAN NM 报文发送 |
| 3 | Network Management Reception | CAN NM 报文接收 |
所以：
-0x01= 只控制 Normal Tx
-0x03= 控制 Normal Tx + NM Tx
-0x0F= 所有四类通信全控
📌 实战建议：在刷写场景中，推荐使用0x03来同时关闭应用和NM报文发送，避免唤醒源残留。
Davinci 中如何配置？一步步带你走通全流程
虽然 Davinci 是图形化工具，但理解其背后的结构逻辑至关重要。下面我们以DaVinci Configurator Pro为例，展示核心配置项。
Step 1：启用 DCM 中的 28 服务支持
打开 Dcm 模块 → Dsp → Service 28 配置页：
- ✅ 勾选
Support for Communication Control - 设置最大子功能数：一般设为 6
- 添加所需子功能条目
<DCM-DSP-SERVICE-28> <SHORT-NAME>DcmDspService28</SHORT-NAME> <DCM-DSP-SERVICE-28-SUBFUNCTION-TABLE> <DCM-DSP-SERVICE-28-SUBFUNCTION> <SHORT-NAME>EnableTx</SHORT-NAME> <DCM-SUBFUNCTION>0x01</DCM-SUBFUNCTION> <DCM-CONTROL-ENABLE-TX>true</DCM-CONTROL-ENABLE-TX> </DCM-DSP-SERVICE-28-SUBFUNCTION> <DCM-DSP-SERVICE-28-SUBFUNCTION> <SHORT-NAME>DisableTxRx</SHORT-NAME> <DCM-SUBFUNCTION>0x05</DCM-SUBFUNCTION> <DCM-CONTROL-DISABLE-TX>true</DCM-CONTROL-DISABLE-TX> <DCM-CONTROL-DISABLE-RX>true</DCM-CONTROL-DISABLE-RX> </DCM-DSP-SERVICE-28-SUBFUNCTION> </DCM-DSP-SERVICE-28-SUBFUNCTION-TABLE> <!-- 允许的操作会话 --> <DCM-DSP-SERVICE-28-SESSION-ALLOWED> <DCM-DIAGNOSTIC-SERVICE-ID>DefaultSession</DCM-DIAGNOSTIC-SERVICE-ID> <DCM-DIAGNOSTIC-SERVICE-ID>ProgrammingSession</DCM-DIAGNOSTIC-SERVICE-ID> </DCM-DSP-SERVICE-28-SESSION-ALLOWED> </DCM-DSP-SERVICE-28>生成的代码中会包含类似宏定义：
#define DCM_CFG_DSP_COMMCTRL_SUPPORT_ENABLED STD_ON #define DCM_CFG_DSP_COMMCTRL_SUBFUNC_MAX 6U这些决定了编译时是否包含该功能。
Step 2：配置 ComM 模块，打通控制链路
这是最容易出错的地方！即使 Dcm 收到了请求，如果 ComM 没配好，照样无效。
必须完成以下绑定：
| 配置项 | 说明 |
|---|---|
ComMChannel | 定义一个通信通道，例如ComMChannel_CAN1 |
ComMUser | 将 Dcm 注册为用户：ComMUser_Dcm |
ComMControlledBuses | 关联 CanNm 或 BusNm 实例 |
ComMMinimumDelayTime | 防止频繁切换造成震荡，建议 ≥ 50ms |
⚠️ 特别注意：
在ComMUser的属性中，必须勾选 “Allow Wakeup from Communication Control” 并设置正确的 Channel 映射，否则ComM_CommunicationControl()调用不会生效！
Step 3：CanSM 与 CanIf 协同配合
- CanSM负责状态机迁移：
- 当收到
No Communication请求时，进入CANSM_BSS_S_NO_COMMUNICATION 自动通知 CanIf 停止调度 PDU
CanIf需启用通信门控（Communication Gate Control）：
- 支持通过
CanIf_SetEcuPassive()实现静默 - 确保 PduR 遵循 ComM 状态过滤规则
常见问题排查手册：这些问题你一定见过
🔴 问题一：发送28 02 03返回7F 28 12（NRC 12）
含义：Sub-function not supported
排查方向：
- 是否在 Dcm 中启用了 Service 28？
- 子功能0x02是否已添加到 SubFunctionTable？
- 当前诊断会话是否在DcmDspService28SessionAllowed列表中？
🔧 解决方案：
在 Davinci 中检查 DcmDspService28 配置页 → 添加缺失的 SubFunction 条目 → 确保会话白名单正确。
🟡 问题二：命令执行成功，但仍有报文发出
现象：返回了78正响应，但 CAN 上仍能看到周期性信号
根本原因分析：
1.ComM Channel 未正确关联 Dcm User
- 导致ComM_CommunicationControl()调用未传递下去
2.应用层绕过 ComM 主动调用 Send
- 如任务线程中硬编码Can_Write()
3.PduRouter 未启用 Gateway 控制
- 不受 ComM 状态影响的 PDU 依然转发
🔧 最佳实践：
- 使用 Davinci 的Cross-Core Reference Checker检查模块连接完整性
- 在应用层加入ComM_GetStatus()查询，判断是否允许发送
- 启用 PduR 的 Communication Gateway 功能，统一受控
🟢 设计优化建议：让你的系统更健壮
| 项目 | 推荐做法 |
|---|---|
| 控制粒度 | 按通信类型细分，避免一刀切禁用所有通信 |
| 响应策略 | 生产环境返回正响应；调试期可设为静默模式 |
| 安全机制 | 结合 Security Access Level 控制敏感操作（如禁止NM） |
| 日志跟踪 | 启用 DcmState Trace 和 ComMMode Change Log |
| 回退机制 | 设置 Watchdog 定时恢复通信，防止单点死锁 |
💡 小技巧：可在 Dcm 中设置Suppression of Response标志位，在特定子功能下不回响应，减少总线干扰。
总结：掌握28服务，你就掌握了诊断系统的“开关”
UDS 28服务看似只是一个简单的控制指令，但它实际上是整个诊断通信体系的“闸门”。能否精准控制这个闸门，直接决定了 OTA 升级成功率、诊断效率以及系统安全性。
借助 Davinci 工具链，我们可以摆脱繁琐的手动编码，通过图形化建模快速完成 Dcm、ComM、CanSM 的联动配置。但工具越智能，越需要开发者理解其背后的工作原理——否则一旦出问题，连日志都不知道往哪看。
记住：
配置不是点几下鼠标就行，而是对 AUTOSAR 分层架构的深刻理解和工程经验的体现。
当你下次面对“为什么禁用了通信还在发报文”的问题时，不妨从这四个层面逐级排查：
1. Dcm 是否正确解析并响应了请求？
2. ComM 是否收到了控制命令？
3. CanSM 是否进入了 No Communication 状态？
4. CanIf 是否停止了 PDU 调度？
层层深入，才能真正掌控诊断系统的命脉。
如果你正在搭建诊断系统或优化现有配置，欢迎在评论区分享你的挑战与解决方案，我们一起探讨最佳实践。
