小知识点
10 02、10 03模式切换，S3 client开始诊断报文超时计时（3E80保持会话）
CANTP层 client 发36首帧10，server回流控30 08，client发8帧连续帧20-2f（500K，1ms发4帧）。
FlowControl第一字节的高4bit为0011，低4bit为FS，即FlowStatus，第二个字节为BS(BlockSize)，第三个字节为STmin（SeperateTime）
cs时间仲裁（ID小优先级高）
常用诊断ID介绍
1、诊断会话控制0x10服务
2、会话访问0x27服务
3、用于读/写的DID的0x22/0x2E服务
4、 故障存储相关的0x19和0x14服务
ISO分层
会话模式切换
这个是会话状态的一个状态机，状态机之间可以互相跳转，状态机自身也能跳转，我们把除了默认会话之外的会话状态，都叫做非默认会话状态。当ECU一上电的时候是处于默认会话的，我们通过10，比如说10 03,10 02来将会话状态由默认会话跳转到非默认会话。由非默认会话执行10 01跳转至默认会话。当ECU处于非默认会话的时候，S3 time这个时间超时，ECU也会从非默认会话跳转到默认会话。为了防止ECU从非默认会话跳转至默认会话，我们要求Tester端周期发送3E服务Tester present，让ECU一直维持在非默认会话。
Tester端会利用S3Client周期发送Tester present给ECU，ECU收到Tester present比如说3E 00，3E 80的服务请求，会让ECU维持在非默认会话，如果Tester端S3server这个时间内，比如说5000毫秒时间内，都没有给ECU发送任何诊断请求报文，那么ECU就会从非默认会话跳转到默认会话；如果ECU处于解锁状态，也会从解锁状态跳转到锁定状态。通常S3cleint时间小于S3server的时间，比如说网关延时的一些情况。
故障存储相关的0x19和0x14服务
在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。那么我们常用的UDS服务里面DTC格式用的是哪一种呢？有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式。
ISO 15031-6定义的DTC格式什么样的呢？两个字节的根字节来定义DTC，
左边前两位能反应DTC到底是哪一个系统：00表示Powertrain;01表示底盘；10表示车身；11是网络相关的。
左边第3~4位反应的是，DTC到底是由ISO，SAE，这些标准组织所定义的故障，还是由整车厂来定义命名的故障；
左边第5~8反应的是车辆系统的区域；
右边8位，这个字节具体的编码，就是DTC的编码。
在14229-1中定义的19服务读取DTC信息里，定义28个Subfunction，根据不同的Subfunction来获取不同的诊断信息，在这里我们介绍4个不同的Subfunction，这4个Subfunction也是在规范中常用的，他们分别是02；04；06；0A。
- 19 02由DTC的状态码获取DTC；
- 19 04读取DTC的快照数据。在14229里定义的数据叫做快照数据；在Autosar里定义的数据叫做冻结帧，其实他们指的是一类数据。快照数据是指当这个错误发生，或者当这个DTC存储的时候，记录的一些环境数据，比如说车速，水温，发动机转数等这些数据，从而我们读取这些数据之后，能够更好的判断DTC产生的原因以及发生故障原因。
- 19 06是来获取DTC存储的时候一些扩展数据，这个数据常用的比如说有一些计数器，比如说老化计数器，这样的数据。
- 19 0A是来读取这个ECU所支持的全部的DTC，ECU支持的哪些DTC是在ECU诊断规范的时候已经定义好的，所以我们通过19 0A读取的DTC是这个ECU应该支持的所有的DTC，即使这个DTC没有产生，也能够被读取的
刚才我们提到了DTC状态字节，这个DTC状态由8个位组成的一个字节。这8个位分别代表不同的含义，具体这8个位代表的含义，包括这8个位初始值是什么，它什么时候被置1，什么时候又被清0，它在什么情况下用，怎样用，在14229-1 2013版附录D有详细的定义。大家如果想具体了解这8个位的定义，可以参看附录D。
这里要提醒大家的是除了Bit4和Bit6以外，其它所有位的初始值都应该为0，而Bit4和Bit6的初始值位1。常用的有比如说Bit0和Bit3.Bit0当检测到这个故障，发生错误的时候被置1；
Bit3 ConfirmedDTC根据具体DTC的应用逻辑，这个DTC被检测到了多次，这个次数由具体的ECU规范定义，那么这一位也应该被置1。
我们通过19 02读取DTC的时候，会用到3个不同类型的DTC Status，那么这3个不同的DTC有什么区别呢：
- 在请求报文里有一个字节的DTC Status Mask，这个是被Test用来读取DTC数据的，这个值可以是00到FF之间的任意值，根据所要读取的DTC内容决定。如果你想读取这个ECU产生的所有DTC，你可以用 0xFF.
- 在肯定响应中，也有一个字节DTC Status Availability Mask，这个字节的DTC Status，是ECU诊断规范里定义的
- 在肯定响应中，读取的DTC后面还有一个字节，是反应的这个DTC，所产生时，对应的状态信息。
我们来看具体的请求和响应格式，首先看19 02。19 02后面跟一个字节的Status Mask，第0位和第3位被置1，而这一个字节Mask，是在ECU诊断规范定义的，所以 59 02 +一个字节的Mask+具体的DTC+DTC后面的跟的DTC Status。
如果有多个DTC，后面会重复DTC的格式：3个字节的DTC+DTC Status。
通过19 0A读取ECU支持的所有DTC，请求格式是两个字节“19 + 0A”；肯定响应格式“59 + 0A+一个字节的Mask+后面跟ECU支持的所有DTC”
当诊断故障信息被存储了以后，我还需要，问题我们已经通过维修的方式解决了，我们用什么样的方法将这个DTC清除呢？
用到14服务清除诊断信息，14服务格式很简单，请求格式是“14 + 3个字节数值”，这3个字节的数值可以是针对单个DTC清除，也可以是按组来清除DTC，也可以是清除全部DTC。当3个字节都为FF时，表示将ECU里产生的所有DTC清除。
那我能不能按照组来清除DTC，比如说清除和车身有关的DTC，就按照车身这个组的数值，将它添加到请求报文格式里；
那我能不能单独清除，只针对某一个DTC，清除这个DTC，也是可以的。只需将这个DTC的具体数值放在请求报文，那么的肯定响应格式是一个字节54。
这个表格在14229中也有描述，大家可以具体参看。
