CAN诊断学习

汽车CAN总线有动力总成PCAN,底盘控制CCAN，整车控制BCAN，娱乐ECAN，诊断DCAN五种。

CAN诊断，即是对CAN网络中各节点，各CAN总线，网关的故障进行检查与修复。

统一诊断服务（UDS），即ISO-14229标准，是绝大多数汽车厂商使用的诊断服务。

10：诊断会话请求服务

    一般的诊断请求的输入格式为：710 02 10 01

    帧ID为710，帧数据长度为8，数据长度为02，数据内容为10 01，其中10代表诊断会话发起服务，01表示默认会话(其中10服务可以切换三种模式，01为默认模式，02为编程模式，03为扩展模式)

    必须先发起诊断会话，类似于先建立握手。

 

2E：写入配置请求服务

    对某个ECU写入配置项数据，也就是重新标定

    常用帧格式：710 07 2E C0 01 01 03 22 FF

    数据长度07，C0 01是一个DID数据标识符，代表某ECU节点的多个参数，01 03 22 FF代表ECU里的多个参数应该设定的值

 

11: 网关复位刷新请求服务

      一般如果用2E写入ECU配置值值后, 必须对网关刷新复位, 不然这个值可能不会立马生效.（其中01为硬件复位，02为KeyOfOn复位，03为软件复位）

      常用如: 710 02 11 01 (代表向所有的ECU发起硬复位请求)

 

27: 安全访问认证请求服务

      一般如果需要涉及2E写入ECU配置项等服务时, 必须通过网关的安全认证, 不然无权限修改, 你可以理解成, 没成功申请到27安全访问的话, 你的CAN网络权限是只读的, 不可写.

        常用如:710 02 27 03 (代表向网关发起安全认证的请求)

这个服务就是用来权限管理的，他的权限进入方式是：

    诊断仪                        电机控制器ECU 

1.     请求种子       -->           计算种子

2.     接收种子     <--             答复种子

3.     发送密钥       -->           计算密钥 对比密钥

4.     获取权限      <--             返回权限切换状态    

比如你要向ECU写入数据，一般人当然不能随便写，只有专门懂的人才能写入，因此需要权限来保证。

 

22: 读取配置请求服务

        简单点说: 读取某个ECU配置项信息

        常用如:710 03 22 C0 01 (代表读取C0 01 这个数据标识符里的多项参数值)

 

19: 读取故障码请求服务

       读取正常CAN网络的故障信息, 一般有ECU节点丢失(比如ECU节点松动脱落或者烧坏了等), 电压过高过低, CAN总线异常(即Bus Off)等...这些故障会记录在一串超长故障码(DTC)列表里.

        常用如:710 03 19 02 0C (代表读取整个CAN网络的当前已生效的故障码)

       01子服务：通过状态掩码的形式去，查找该状态掩码匹配的故障个数，其实意思就是查找故障个数。这里稍微解释一下状态掩码，在UDS规定里面，每个故障都对应8个状态，每个状态对应一个bit，比如状态0对应bit0，表示当前发生的故障，状态3对应bit3，表示已经确认的故障等等，那么状态掩码的意思就是用一个8bit的数去按位与，如果与的结果非0表示匹配到了，然后故障数就++。

        02子服务：通过状态掩码的形式去，查找匹配的故障，以及故障的状态。

        04子服务：请求指定故障码（DTC）的快照信息，意思就是说为了找到故障的原因，查找故障发生时刻的一些数据，来分析故障原因。

        06子服务：请求指定故障码（DTC）的扩展信息，就是想了解一些该故障的一些其他信息，比如发生的次数、自恢复的次数等，具体数据可自定义。

        0A子服务：通过该服务可获取所有支持的故障码和故障状态信息，注意是所有的故障及故障码。

 

14: 清除故障码请求服务

       清除所有ECU的诊断故障码, 包括故障码相关的快照等,

       如果CAN网络有故障, 其会源源不断的反馈以上故障, 

       即使清除后也会立马再发出. 

       常用如:710 04 14 FF FF FF (代表清除所有ECU上的诊断故障码(包括故障码相关的快照等.))

 

23/3D：

23是通过地址读数据

3D是通过地址写入数据，一般用的较少。

 

28服务：

通信控制，包括对发送和接收消息的开关控制。

31服务：

例程控制，比如一些复杂的操作需要用他来实现，目前比较通用的包括烧录时的数据完整性检查、擦除内存等等。

2F服务：

IO控制，主要用于对一些输入输出口的调试控制，目前这一块接触较少，比如一些传感器的开关控制。

34/35/36/37服务：

和数据传输有关的服务，包括请求传输、请求下载、数据传输、数据上传、退出传输等，这些服务和BootLoader相关。

85服务：

用于控制故障的更新，包括开启和关闭故障更新，比如关闭之后不允许故障、故障状态、故障记录等信息的更新。开启则反之。

诊断回应

肯定回应：718 06 50 01 00 32 01 F4 00

在ISO-14229中规定，ECU的诊断响应ID=ECU诊断请求ID+0x008；响应服务的ID＝请求服务的ID+0x40

 

否定服务：718 03 7F 10 22 00 00 00 00

其中7F为否定码  22表示为否定原因条件不符合

其他原因：11服务不支持，12子功能不支持，13报文长度错误，31请求超出范围

 

例子：

诊断读取故障码：

7E1 03 19 02 FF 00 00 00 00

回应：

7E9 07 59 02 FF C1 21 20 DB

 

读取故障码19服务有01，02，04，06，0A等子服务，在01子服务中，第四个数据字节代表需要读取哪种状态的DTC，其中FF表示读取所有Bit置1位的DTC

响应服务59中，C1 21 20为DTC的内容，分为高位字节C1，中位字节21，低位字节20，DB表示这个DTC的状态。

在高位字节的8Bit中，又分为三个编码集合，first编码集合：Bit7-Bit6；second：Bit5-Bit4；third：Bit3-Bit0

first编码集合有00动力系统P，01底盘系统C，10车身系统B，11网络系统U

 

分析DTC信息C1 21 20 DB：

分解为二进制：1100 0001    0010 0001    0010 0000    1101 1011

可知是网络出了问题，即通信故障，与ABS通信丢失。

DB表示的DTC状态可根据状态位描述得到：DTC出现错误，且在当前驾驶循环下被确认

 

Bit 0            Test Failed                                                        DTC最近的一次诊断结果为失败

Bit 1            Test Failed This Operation Cycle                       在当前驾驶循环中处于故障状态

Bit 2            pending DTC                                                 在当前或者前一个驾驶循环DTC处于故障状态

Bit 3            Confirmed DTC                                                  DTC已经被确认

Bit 4            Test Not Completed Since Last Clear                自上一次清除故障码后测试没有完成

Bit 5            Test Failed Since Last Clear                              自上一次清除故障码后测试结果为失败

Bit 6            Test Not Completed This Operation Cycle        在当前驾驶循环中测试没有完成

Bit 7            Warning Indicator requested                             与DTC相关的报警指示请求

 

 

 

转载于:https://www.cnblogs.com/shinedaisiki/p/9815992.html