uds28服务实战案例：如何安全启用刷写模式-平芜编程栈

如何用 uds28 服务安全进入刷写模式？一个老司机的实战手记

最近刚搞定一个棘手的 OTA 刷写项目，客户反馈某款车型在远程升级时偶发“节点失联”，复现后发现竟是因为通信没管好——明明在写 Flash，ECU 却还在拼命往外发周期报文，导致总线拥堵、数据丢帧。最后定位下来，问题就出在uds28 服务没用对。

今天我就结合这次踩坑经历，聊聊如何真正把uds28（Communication Control）这个看似简单的服务，用到刀刃上。别看它只是两条 CAN 帧的事儿，搞不好就是“刷砖”的前兆。

为什么刷写前必须动 uds28？

先说结论：不关通信就刷写，等于边开车边换轮胎。

现在的车少则十几个 ECU，多则三四十个，全部挂在 CAN 或 CAN FD 总线上。当你准备给某个 ECU（比如 BCM）刷固件时，如果它还在持续发送车身状态、灯光信号等应用报文，甚至网络管理（NM）心跳包也没停，那会发生什么？

刷写数据流 + 原有报文 → 总线负载飙升
高优先级诊断帧被挤占 → 超时重传 → 整体效率下降
更严重的是，某些关键响应可能丢失，触发 ECU 自保复位，Flash 写一半断电，直接变“砖”

所以，在进入编程会话之前，我们必须做一件事：让目标 ECU “闭嘴”——准确地说，是让它停止对外发送非必要的通信流量。

这时候，uds28就该登场了。

📌 提示：uds28 不是让你拔网线，而是通过标准协议让 ECU 主动进入“静默模式”。

uds28 到底控制了啥？别再只背命令了

很多人记住了28 01 03这条指令，但不知道它背后到底干了啥。我们来拆开看看。

它有两个参数，缺一不可

请求格式：[SID] [SubFunction] [CommunicationType] 0x28 0x01 0x03

SubFunction：你想让它干嘛？

值	操作含义
0x00	Enable communication（恢复通信）
0x01	Disable transmission（禁止发送）
0x02	Disable reception（禁止接收，极少用）

最常用的就是0x01，也就是“别再发东西了”。

CommunicationType：你要禁哪一类？

这是个 bit mask 字段，ISO 14229-1 表 270 规定了每一位的意义：

Bit	含义
0	Application Communication Messages
1	Network Management Messages
2	Reserved (must be 0)
3	I/O Debug Messages
4~6	Direction: 0 = Rx, 1 = Tx
7	Reserved

举个例子：
-0x03= Bit0 和 Bit1 置 1 → 对应“应用通信 + NM 通信”
- 结合 SubFunction0x01（Disable Tx），整体意思就是：

“从现在起，禁止你发送任何应用层和网络管理层的报文。”

这就是为什么我们在刷写脚本里常看到这条命令：

Send: 28 01 03 Expect: 68 01 03 # 正响应，表示执行成功

✅ 实战经验：如果你只禁了应用通信（0x01），但 NM 报文还在发，照样会影响总线；反之亦然。务必根据实际通信结构选择掩码。

它是怎么工作的？底层逻辑揭秘

你以为uds28是简单地调个 API 关掉 CAN 发送？错。它的实现涉及多个软件模块协同，尤其在 AUTOSAR 架构下，链条很长。

大致流程如下：

诊断仪发起请求
发送28 01 03，走的是 UDS 协议栈；
DCM 模块接收到请求
Dcm_DspCommControl() 被触发，解析 subfunction 和 comm type；
转交给 ComM 和 PduR 处理
- ComM：通知通信管理模块切换网络状态；
- PduR：路由层关闭指定通道的发送使能；
- CanIf / CanDrv：最终由 CAN 驱动设置控制器为“无发送模式”或“静默监听模式”；
返回正响应68 xx xx

整个过程不需要重启 CAN 控制器，也不影响内部任务运行，仅屏蔽输出行为。

⚠️ 注意：uds28 只控制逻辑行为，不会关闭物理收发器。ECU 依然能“听”总线，只是不能“说”。

这也意味着你可以一边刷写，一边监控该节点是否误发报文——这对调试非常有用。

我们是怎么一步步配置成功的

下面是我所在项目中实际采用的流程设计，已在量产车型中验证超过 5 万台次。

第一步：会话切换 + 安全解锁

# 进入扩展会话（必须！否则 uds28 可能被拒绝） Send: 10 03 Recv: 50 03 ... # 安全访问解锁（防止非法操作） Send: 27 01 → Recv: 67 01 [seed] Send: 27 02 [key] → Recv: 67 02

🔐 强烈建议：uds28 必须配合 uds27 使用。否则任何设备都能让你的 ECU “闭嘴”，这本身就是安全隐患。

第二步：精准执行通信屏蔽

# 禁止应用通信 & NM 通信 的发送行为 Send: 28 01 03 Recv: 68 01 03

这里有个细节：我们的 BCM 把 NM 报文走的是独立 PDU Route，所以在 PduR 层需要分别处理两个 channel：

if (commTypeMask & 0x01) { PduR_DisableTx(APP_PDU_CHANNEL); // 应用报文 } if (commTypeMask & 0x02) { PduR_DisableTx(NM_PDU_CHANNEL); // NM 报文 }

否则你以为禁了，其实 NM 包还在偷偷发。

第三步：跳转 Bootloader 开始刷写

# 请求编程会话 Send: 10 02 Recv: 50 02 ... # 执行跳转例程（常见于 non-unified bootloader） Send: 31 01 02 FF // RoutineControl: Start Erase App Area Recv: 71 01 02 FF

此时应用层已停止运行，Bootloader 接管通信，开始接收刷写数据。

第四步：刷完一定要恢复通信！

这是最容易翻车的地方。

很多脚本只记得“开始前禁用”，却忘了“结束后恢复”。结果 ECU 重启后虽然程序跑了，但 NM 报文没发，网关认为它“死了”，迟迟不分配地址，用户反映“灯控失效”。

正确的做法是在复位前补一句：

# 恢复所有通信 Send: 28 00 03 Recv: 68 00 03 # 然后再复位 Send: 11 01

哪怕你觉得“反正重启会自动恢复”，也要显式执行一次 enable。因为有些 Bootloader 不会主动恢复应用层通信策略。

那些年我们一起踩过的坑

❌ 坑点1：用了 uds28，但总线还是爆了？

现象：明明执行了28 01 03，刷写过程中总线负载仍达 85%+。

排查发现：邻近 ECU 没停！

uds28 是点对点操作，只能控制单个节点。如果你要刷 A 节点，B/C/D 节点还在狂发报文，总线照样堵。

✅ 解决方案：
- 在网关侧广播一条全局控制指令（若支持）；
- 或者提前协调其他节点进入低功耗通信模式；
- 更高级的做法是使用DCM 的 Routing Control（0x3E）配合网关做流量调度。

❌ 坑点2：uds28 没响应，卡住了？

可能原因：
- 当前处于 Default Session，权限不足；
- Security Access 未通过；
- ECU 正忙于高优先级任务（如高压下电流程）；
- 参数错误，如 CommunicationType 设置了保留位（Bit2/Bit7 为 1）；

✅ 秘籍：
- 加超时重试机制（最多 3 次）；
- 失败后记录 DTC（如DTC_Uds28_Failed）；
- 提供 fallback 方案：降级为短时间暂停刷写，而非硬性阻塞。

❌ 坑点3：恢复后 NM 不上线？

根因：Bootloader 中没有正确继承或恢复 ComM 状态。

✅ 改进措施：
- 在 application 中保存当前通信状态标志位到 RAM 或 BSR（Backup Shadow Register）；
- Bootloader 启动新 APP 前，还原该状态；
- 或者强制要求每次启动都由应用层重新激活通信。

工程师必备 checklist

为了确保 uds28 不出问题，我在团队内推行了一套检查清单：

项目	是否满足
✅ 是否已在 Extended Session 下执行？	□
✅ 是否已完成 Security Access？	□
✅ CommunicationType 掩码是否覆盖所有待禁类型？	□
✅ 是否验证了正响应？	□
✅ 是否在刷写结束前显式恢复通信？	□
✅ 是否记录了 uds28 操作日志（时间戳、参数、结果）？	□
✅ 多节点场景是否有协调机制？	□