引言:
从之前的课程我们了解到, 车上的智能硬件设备太多, 即ECU节点太多, 这些节点通过CAN总线外加汽车网关, 组成了整车CAN网络. 当车辆某个节点, 或者某条CAN总线出故障甚至网关出故障了, 会有什么现象呢?
某ECU节点故障: 也就是你的车上的某个智能硬件不work或者不好用, 比如空调这个设备无法调节温度了.
某条CAN总线故障:比如BCAN整条CAN总线都不work了, 那整条CAN总线上的智能硬件(ECU节点)会功能不好用, 比如语音控制打开天窗, 没效果了, 必须要手动用硬件打开天窗.
CAN网关除故障了: 嘴哥还没碰见过...., 但肯定是更加严重的, 比如到处都发出报警提示音, 因为很多ECU节点都丢失了.
但以上一般是不会有生命危险的,动力系统一般还可用, 车窗啥的单独的硬件按钮调节.
这时候你把车开去4s店维修:
如果是4s店的维修工人, 一般是会帮您读取下诊断故障码,然后发现某项ECU的参数不对, 然后跟您说重新刷了下软件或更换了整个智能硬件. 这就是CAN诊断最通俗的解释了.
什么是ECU自检与诊断故障码
ECU自检:每个ECU都有自己故障检测功能, 基本上每个ECU都有一块EEPROM(可读性可编程存储器),可存储自身故障信息,但是以上故障信息一般会上传至网关的EEPROM,并以诊断故障码(DTC:Diagnose Trouble Code)的形式存储.
什么是CAN诊断
CAN诊断, 即对CAN网络各节点, 各CAN总线, 网关的故障查验与修复.
查验包括: 诊断故障码查询
修复包括: 重新对ECU写入新的配置值
CAN诊断的发起条件
需要通过Diag CAN才能进行诊断.
一般是将直接将CAN硬件工具(诊断仪, PCAN-USB, Vehicle SPY3, CANoe...)的CAN-High, CAN-Low直接接到Diag 诊断CAN上, 然后通过诊断仪, PCAN-Explorer, Vehicle SPY3, CANoe等软件发送CAN诊断输入!
也有通过Tbox进行本地诊断或远程诊断的, 因为Tbox是诊断CAN总线上的唯一节点.
一般 什么人会用到诊断
① 4s店的维修人员, 他们一般只需要做读取故障码(19服务), ECU参数写入服务(2E服务), ECU参数读取服务(22服务)
② Tbox开发测试, 网关开发测试人员, 由于Tbox可发起本地诊断与远程诊断, 网关负责诊断信号转发, 所以都需要测试诊断.
③ 车厂的电子电气研发部门研发人员.....
CAN诊断标准介绍
统一诊断服务(UDS:Unified Diagnostic Services), 即IOS-14229标准, 绝大大部分汽车厂商用的诊断服务,诊断命令都大同小异, 唯一可能不同的是各厂商某些数据标识符(DID)及程序标识符不一致.
统一诊断服务(UDS)规定了以下诊断发起的服务, 诊断回应规范等:
诊断请求(发起)服务_Request
注: 以下都是16进制数字,本应该加上0x前缀.
一般诊断请求(发起, 就是我们常说的Request)的输入格式: 710 02 10 01
常用的诊断请求(发起)服务列表:
10: 诊断会话请求服务
必须先发起诊断会话, 不然无法进行其他诊断服务发起服务.
也就是说只要诊断, 必须先用10服务, 发起诊断会话session,
类似于先建立握手,
常用如:710 02 10 01 (10代表诊断会话发起服务, 01代表默认会话功能)
2E: 写入配置请求服务
简单点说: 对某个ECU写入配置项数据, 就是常听说的重新标定.
常用如:710 07 2E C0 01 01 03 22 FF (C0 01是一个DID数据标识符, 代表某ECU节点的多个参数, 01 03 22 FF代表ECU里的以上多个参数应该设定的值),
11: 网关复位刷新请求服务
一般如果用2E写入ECU配置值值后, 必须对网关刷新复位, 不然这个值可能不会立马生效.
常用如: 710 02 11 01 (代表向所有的ECU发起硬复位请求)
27: 安全访问认证请求服务
一般如果需要涉及2E写入ECU配置项等服务时, 必须通过网关的安全认证, 不然无权限修改, 你可以理解成, 没成功申请到27安全访问的话, 你的CAN网络权限是只读的, 不可写.
常用如:710 02 27 03 (代表向网关发起安全认证的请求)
22: 读取配置请求服务
简单点说: 读取某个ECU配置项信息
常用如:710 03 22 C0 01 (代表读取C0 01 这个数据标识符里的多项参数值)
19: 读取故障码请求服务
读取正常CAN网络的故障信息, 一般有ECU节点丢失(比如ECU节点松动脱落或者烧坏了等), 电压过高过低, CAN总线异常(即Bus Off)等...这些故障会记录在一串超长故障码(DTC)列表里.
常用如:710 03 19 02 0C (代表读取整个CAN网络的当前已生效的故障码)
14: 清除故障码请求服务
清除所有ECU的诊断故障码, 包括故障码相关的快照等,
如果CAN网络有故障, 其会源源不断的反馈以上故障,
即使清除后也会立马再发出.
常用如:710 04 14 FF FF FF (代表清除所有ECU上的诊断故障码(包括故障码相关的快照等.))
诊断回应_Responding
任何一轮诊断输入后, 都会有诊断回应帧, 一般是帧ID是:718
但是分为肯定回应及否定回应.
肯定回应:
即您刚才输入的诊断命令,目标对方(网关或某节点)已经收到并做了处理返回.
比如以下是: 10 诊断会话服务发起后, 收到的肯定回应,
如下示例:
否定回应:
即您刚刚输入的诊断命令, 目标对方(网关或某节点)因为某些原因,未成功收到或者未做处理就被打回了, 可以理解成吃了闭门羹.
看到7f否定回应码就知道吃闭门羹了, 所有吃闭门羹的都是7f否定回应码.
比如以下是: 10 诊断会话服务发起后, 收到的否定回应:
以上的吃闭门羹的原因是: 22条件不符合.
其实还有很多其他的原因会导致吃闭门羹, 常用的有:
11 服务不支持
12 子功能不支持
13 报文长度错误
31 请求超出范围.....
实例
用PCAN-USB 读取诊断故障码(19服务)
1. 发起诊断会话10服务01默认会话功能并成功收到肯定回应
710 02 10 01
2. 发起诊断故障码查询服务19服务02按故障掩码查询方式功能0C已经确认的诊断故障代码
710 03 19 02 0C
3. PCAN-Explorer端的输入如下:
即每10ms一轮的故障码查询服务.
点击ok后, 就到以下页面,
诊断请求, 请看Transmit消息发送去的710帧,
诊断回应结果, 请看Receive消息接收区的718帧.
具体数据比较长, PCAN-Explorer这里只显示了:
10 73 59 02 FF C1 40 87 这8个字节, 其实不止的,
通过其他的CAN工具(支持超过8个的多字节显示)读取出:
10 73 59 02 FF C1 40 87 2F C1 64 87 2F D0 01 87 2F D1 40 87 2F C1 55 87 2F C1 98 87 2F C2 45 87 2F C1 51 87 2F D2 64 87 2F C1 21 87 2F C1 26 87 2F C1 28 87 2F C1 00 87 2F C1 01 87 2F C1 02 87 2F D0 08 87 2F C2 93 87 2F 91 65 17 2F 91 67 17 2F 40 42 54 2F 05 64 1C 2F 05 89 1C 2F 08 26 1C 2F D0 03 87 2F C2 36 87 2F D0 09 87 2F 91 6A 17 2F C1 27 87
10代表超长字节
73代表数据长度, 共73个字节
59代表发起的19服务+40的偏移量
FF代表之前故障(之前有问题, 但是现在故障已经不存在了)
2F是当前故障(现在还没好,故障还存在)
以上FF和2F共28次出现, 代表了28个故障信息,
比如FF C1 40 87就是一条"之前故障".
具体是什么故障, 要看C1 40 87的文档定义了,个人认为每个厂商的定义可能不一样.
以上只是嘴哥的浅谈CAN诊断.
有需要详细了解CAN诊断的朋友可以看看下面这批文章, 这偏文章写的超级赞, 算是CAN诊断里写的最通俗易懂的一篇文章了.
https://wenku.baidu.com/view/f2c2cc6afd0a79563c1e72d7.html?from=search
这是网友分享的众泰公司的诊断需求说明书.
学好了诊断, 您应该就可以进行tbox测试了, 及部分的网关测试, 也会模拟发送各种信号了. 诊断算是CAN教程里边最简单的课程了, 嘴哥不骗人, 因为嘴哥已经实现了诊断的自动化测试
.
而且CAN诊断是统一标准, 各个公司都用UDS统一诊断服务, 大同小异的!
祝您成功!