汽车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：Bit
3-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相关的报警指⽰请求