【车载开发系列】UDS诊断—通信控制($0x28)
UDS诊断---通信控制($0x28)
- 【车载开发系列】UDS诊断---通信控制($0x28)
- 一.概念定义
- 二.实现原理
- 三.应用场景
- 四.子功能
- 五.报文格式
- 1)请求报文
- 2)肯定响应
- 3)否定响应
- 六.前提条件
一.概念定义
- 根据ISO14119-1标准中所述,诊断服务28服务主要用于网络中的报文发送与接受,比如控制应用报文的发送与接收,又或是控制网络管理报文的发送与接收,以便满足一定场景下的应用需求。
- 简单来说28是对CAN报文收发的控制。
二.实现原理
- 针对28服务的通信控制过程会经过AUTOSAR BSW模块进行处理,然后完成最终的通信控制。
- Server会将该诊断报文请求传递至DCM模块;DCM模块调用28服务对应的上层应用函数首先进行输入参数的基本校验,校验无误之后然后传递相关控制模式请求至BswM模块;
BswM模块根据静态配置的规则来实现对应请求中的通道通信状态控制;(常见的模式控制为3X4 = 12种) - 28诊断服务经过DCM,BswM,Com,NM完成整个12种通信模式的控制。
三.应用场景
- 一般而言,对于28诊断服务,主要应用场景为:
- 存在某些特殊的测试场景,比如只希望接收或者发送对应的网络管理与应用报文;
- 绝大多数情况下应用在刷写ECU的过程中,在预编程条件下执行28服务功能寻址便可以抑制总线应用报文与网络管理报文的发送与接收,以便减少网络总线负载,提高ECU下载效率,同时刷写结束后也要执行28服务使能对应控制报文的发送与接收,在此过程中往往会配合85服务一起使用。
- 某种特殊情况下,我们在排查问题的时候,需要停止某部分的报文收发,从而去分析解决问题,28服务也会在这个时候体现它的作用。
四.子功能
ControlType控制该类通讯的接收和发送是开启还是关闭
Hex(bit6~0) | Description | 描述 |
---|---|---|
0x00 | enableRxAndTx | 使能接收和发送 |
0x01 | enableRxAndDisableTx | 使能接收和关闭发送 |
0x02 | disableRxAndEnableTx | 使能发送和关闭接收 |
0x03 | disableRxAndTx | 关闭接收和发送 |
0x04 | enableRxAndDisableTxWithEnhancedAddressInformation | 使能接收和关闭发送,针对特定的地址 |
0x05 | enableRxAndTxWithEnhancedAddressInformation | 使能接收和发送,针对特定的地址 |
0x06-0x7F | - | 都是保留或者留给厂商自定义的 |
五.报文格式
1)请求报文
- 第一部分:第一字节为SID 0x28
- 第二部分:第二字节为sub function,具体可以参照上面ControlType
- 第三部分:communicationType:控制哪种类型通讯。具体参照见下。
Hex | 描述 | Description | 备考 |
---|---|---|---|
0x01 | 常规应用报文 | normalCommunicationMessages | 内部应用信号在整车多ECU间交换 |
0x02 | 网络管理报文 | networkManagementCommunicationMessage | 值定义了所有网络管理相关通信,需要ECU支持 |
0x03 | 常规应用报文和网络管理报文 | networkManagementCommunicationMessages and normalCommunicationMessages | 定义了所有网络管理相关和应用相关通信 |
2)肯定响应
3)否定响应
否定响应没有什么特殊的地方。
六.前提条件
- 一般执行28服务的前提条件需要车速是有效且低速的状态下
- 系统不执行任何紧急操作的情况才可以实施28服务,至于哪些是紧急操作,可以参考各个车厂的定义
- 对于网关 ECU,正常诊断报文的路由不受此服务影响。
- 对于连接多个信道的 ECU(如网关),此服务会影响所有信道(不仅是接收到诊断请求的信道)。
- “控制类型”(ControlType)的默认是0x00使能接收和发送,在实施了11服务或者ECU切换到默认会话模式的话,ControlType也要恢复到默认。