[UDS] --- CommunicationControl 0x28

1 0x28功能描述

根据ISO14119-1标准中所述，诊断服务28服务主要用于网络中的报文发送与接受，比如控制应用报文的发送与接收，又或是控制网络管理报文的发送与接收，以便满足一定场景下的应用需求。

2 0x28应用场景

一般而言，对于28诊断服务，主要应用场景为以下场合：

存在某些特殊的测试场景，比如只希望接收或者发送对应的网络管理与应用报文；绝大多数情况下应用在刷写ECU的过程中，即在预编程条件下执行28服务功能寻址便可以抑制总线应用报文与网络管理报文的发送与接收，以便减少网络总线负载，提高ECU下载效率，同时刷写结束后也要执行28服务使能对应控制报文的发送与接收，在此过程中一般会配合85服务一起使用，后期会给大家介绍，敬请关注。

上述这些应用场景较为常见，这里就不一一列举。

3 0x28服务请求

3.1 0x28 request格式

按照ISO14229-1标准所述，下图所示为28通信控制原理中诊断服务请求格式：

- #1参数为service ID 28

• #2参数为子功能码
• #3参数为通信类型
• #4 #5 参数nodeIdentificationNumber仅在subFunction等于4或者5才有效，否则#4，#5参数可以不存在

3.2 子功能码

子功能码各个数字含义如下：

3.3 communication type

• Bit0-1:
  0x1：正常应用报文
  0x2：网络管理报文
  0x3：应用与网络报文
  
• Bit4-7:
  0x0：表示使能或者抑制所有的Dcm控制的comM通道；
  0x1:使能或者抑制特定的comM通道；
  0xF:仅能接受请求的comM通道
  

4 0x28请求和响应

4.1 正响应及示例

以抑制网络管理报文发送为例

28服务诊断请求实例如下图所示：

正响应格式

如下图所示，为28诊断服务的正响应格式：

从上图中可以看出，28诊断服务的正响应由以下2个部分组成：

• Response ID：该参数固定为SID+0x40 = 0x68；
• SubFunction：该参数为上述诊断请求格式中controlType;

其中，0x01就是跟诊断请求中的controlType保持一致即可

4.2 负响应NRC

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于28服务而言支持的NRC如下表：