【UDS】ISO14229之0x28服务

---

->返回总目录<-

前言

简称： “CommunicationControl”，通信控制
功能： 通讯控制服务用于开启/关闭电控单元对某些报文的发送或接收。

---

一、理论描述

诊断工具通过请求该服务可以实现对指定类型的报文收发进行控制。如：
一般通信报文
(如节点功能的报文，所开发的产品是控制灯光模块的，那么这个节点功能报文就负责检测灯光的信号并且发送至整车其他节点。)
网络报文
（基本上车内大多数节点都需要网络报文，负责管理节点的睡眠唤醒功能，来实现节能的效果）
关于网络管理的分析，可参考CAN网络管理Autosar(入门））

那么问题来了，为什么需要这个服务，要它何用？
我们ECU节点的软件需要不定期更新（如：整车厂改了需求），一般通过诊断工具更新ECU软件的方式如:FBL(Flash BootLoad)，此时为了使程序更新时不受其他报文收发干扰，就会在之前请求28服务来，禁止收发报文。待ECU程序更新完毕，在请求28服务打开报文收发功能。

二、使用步骤

1.请求

ControlType：控制类型
请看下图，简单明了。总共有四种控制类型。图中的约定列中：M代表强制，U代表可选。
倘若下图是整车厂发来的诊断规范，那么在开发的时候就必须支持00和03。

CommunicationType:通信的报文类型
所要控制通信的报文类型，如下图强制要求支持01（一般通信报文）

请求报文组合如下：
28 00 01：使能APP报文的收发
28 00 02：使能NM报文的收发
28 00 03：使能APP和NM报文的收发
28 03 01：禁止APP报文的收发
28 03 02：禁止NM报文的收发
28 03 03：禁止APP和NM报文的收发

举个实栗子：
28 03 01禁止发送和接收一般通信报文(除了网络报文和诊断报文，都统称一般通信报文，即APP报文)
当诊断工具收到ECU回复的正响应68 03。该节点就不会收发一般通信报文。只收发网络报文和诊断报文。

2.响应

1）正响应

见上面CANoe报文数据图可知，正响应的报文是02 68 03 AA AA AA AA AA。
02：正响应数据长度2字节，0x68 0x03
68：回复ID 0x28 + 0x40 = 0x68 （统一规范规则）
AA：未使用的字节填充0xAA（一般整车厂会告知你未使用的位应该用什么数字来填充）

2）否定响应
支持的否定响应如下，一般工作上根据整车厂给的诊断输入文档来选择要支持的NRC码。

博主平日项目中，上图的NRC都需要支持。

NRC12： 子服务不支持（ControlType中根本没有FF 服务，简直瞎搞）

NRC13： 请求报文数据长度有误（正确请求数据28 00 01 有三个字节。而下图中请求的是28 00两个字节）

NRC22： 请求条件不满足
（一般整车厂会告诉你NRC22的满足条件，例如：车速>3km/h，电源过欠压时候，请求服务，ECU便回复该NRC）

NRC31： 请求超出范围（不按套路出牌，CommunicationType有04?）

NRC7F： 当前会话下服务不支持
（整车厂要求该服务，需要在Extend session会话或者Promgramming会话下支持。倘若其他会话，回复7F 28 7F ）

总结

0x28服务还是比较简单的，下一章0x2F IO控制服务见！

->返回总目录<-