目录
一、诊断常见的协议：
二、OEM诊断规范
ISO14229
UDS定义的相关服务：
SID的格式
ISO-14229常用服务
10服务（诊断会话的控制）
在UDS当中非常常用的表格：
CAN总线示例
Recommended Session(s) for Service
三、 安全访问
安全解锁步骤
Supported NRC:基于27服务所支持的NRC
通过DID读数据：
通过DID写数据：
四、DTC
DTC的结构
DTC ISO 15031-6:
读取DTC的19服务
02服务
DTC读取：
DTC擦写：
五、诊断通讯模式
物理寻址
功能寻址
一、诊断常见的协议：
ISO14230针对K线的诊断协议,15765针对CAN线的协议，15031针对排放相关的定义，ISO14229。
二、OEM诊断规范
ISO14229
UDS可以基于不同的总线网络来实现，诊断服务，发送SID给ECU如果ECU认可，就发送SID+40（肯定响应），如果没有认可，会回一个7F，7F是否定响应的标识符。用7F+SID+NRC，NRC就是否定响应的代码。（否定响应），在14229里面NRC有定义（从10到93），这个可以去14229-1里面找到，有全部的定义。
UDS定义的相关服务：
在UDS里面定义的服务有26种，每一个服务发出请求的格式是不一样的。但是每一个服务都带有格式标识符（SID）。
SID的格式
SID主要有四种不同的格式：
SID，只发出一个服务的请求，ECU就可以认可,
SID+SF，服务后面加上子服务Subfunction，这样ECU才会认可,
SID+DID，由我们的服务再加上我们的数据标识符Data Identifier,
SID+SF+DID，既要加上子服务，又要加上我们的DID
ISO-14229常用服务
在14229的26种服务中，有几个常用服务：
首先是10服务，10服务是诊断会话的控制，是诊断最基本的服务，所对应的是27的服务，是诊断的管理控制的服务，27是安全访问的服务。22和2E，是通过我们的DID来读写我们数据的服务。还有就是跟DTC相关的两个服务，19和14，19是读DTC，14是清除DTC。
10服务（诊断会话的控制）
当ECU上电的时候，进入的是默认会话Default Session（10 01），如果想跳转到非默认会话，也就是02或者03，就需要用10+子服务（SF），里面有一个S3计时器，如果在S3的时间没有任何请求发出来的话，我们会自动的回到默认会话，相当于保护机制。还有一个重要的服务，3E服务，就是保持在当前会话的服务，因为我们在非默认会话的时候，不可能一直发出请求。当我们停下来做数据分析或者其它动作的时候ECU没有发出有效命令的时候，我们可以用到3E，3E就是在S3计时时间到之前，我们发出一个3E服务，这样就会一直保持在非默认会话的情况。
在UDS当中非常常用的表格：
在Cvt列，M代表强制，强制使用10和子服务。在UDS SF当中定义了00到03，其中00是不会被使用的。01到03代表不同的含义。Response对应的相应，对应的肯定响应是在SID上加上40，10+40=50，S也代表强制使用，在这里面代表如果我们的肯定相应没有被抑制的话，这个字节就是要被强制使用的。后面我们的服务也是被强制使用的。后面C是有条件使用的。由客户决定。
不同的NRC，对于10来说主要用到的就是12 13还有22三种否定响应。
CAN总线示例
在CAN总线当中每一个帧的报文每一条请求都只支持8个字节。第一个02代表TP层的一个单帧，2代表后面有两个有效字节。在Request里面，后面5个字节对我们来说是没有意义的。肯定响应也一样，三个字节加5个填充位。最后否定响应，有四个字节7F+SID+否定响应的代码NRC。22表示当前的状态。
Recommended Session(s) for Service
在默认会话服务当中，有一些不支持，但是在非默认会话当中，这些都是支持的。
三、 安全访问
平常读写只需要用到22服务+DID，有一些数据需要加密，在ECU上电以后，是一个锁定的状态，我们通过27+子服务+密钥，通过这样的服务请求来进行一个解锁状态。解锁之后ECU状态就变成了Unlocked状态，Unlocked状态整车厂可以设置不同的级别。各个级别之间没有制约关系。是可以互相转换的。
安全解锁步骤
在解锁之前，先向我们的ECU请求一个种子，所以用27服务和2n-1(相当于是奇数)，让n=1,这时候27 01对ECU进行了请求解锁，这时候ECU给我们一个肯定的响应，就回了一个67服务和2n-1，就是67 01后面再跟一段字符，就是我们的种子。当我们的测试端拿到种子的时候，进行运算（由整车厂进行规定），利用这个算法，生成钥匙K1，然后再通过27 2n K1,就是 27 02 K1，把这条请求发送给ECU，ECU拿到K1进行运算，计算出K2，当K1和K2匹配的时候，ECU就可以解锁了。解锁以后ECU向测试端发出肯定响应67 02。
Supported NRC:基于27服务所支持的NRC
通过DID读数据：
22服务通过DID来读数据，后面加上DID标识位，如果DID肯定响应的话就会回62加上DID后面的
根据distapu的数据长度来确定。示例：如果去读当前诊断会话，F1 86代表着当前会话的诊断标识。22 F1 86作为请求。请求的意思是先读取数据，读的数据标识符是当前激活的诊断会话。肯定响应22+40=62 F1 86 最后一个字节是02，02代表编程会话。
DID有一部分已经被UDS规定了，可以在14229-1里面找到。这是5个相关DID,可以使用可以不使用
通过DID写数据：
2E DID Data，F186这个DID不能强制写入诊断会话。需要用10来进行会话的转换。写的请求一般来讲是在非默认会话和解锁状态下面来进行的。
四、DTC
诊断故障代码，通过诊断服务来读取故障。
DTC的结构
在UDS种规定以3个字节的长度作为一个DTC，一般来说都会使用15031-6里面的规范来规定3个字节所代表的不同的含义。前两个字节可以代表一个根DTC，最后一个字节是一个DTC状态的位。FTB就是错误类型的Bit，fault tape bit, 在H-OBD和OBD II中都有不同的DTC的格式。在商用车J1939当中也不太一样。
DTC ISO 15031-6:
最高的两个位，代表的是故障系统的分类。00是动力系统，01是底盘系统，10代表的是车身系统 11代表网络系统。这样就把所有DTC分为四大类，就是P C B U,第五位和第四位这两位分别代表0123，00 01 10 11，01是车厂控制的，其他的由ISO协议规范来控制。对于一个根DTC来说是由一个字母和四个数字来组成的。
读取DTC的19服务
19服务也是配合子服务来使用的，有28种子服务，02是读取DTC，通过DTC的状态掩码来读取，04是读取一个快照信息，06是读扩展信息，0A是读ECU当中支持的所有DTC的数据。
02服务
02服务，通过DTC的状态掩码来读，DTC状态掩码：这里面有8个字节，每一位都代表着不同的状态。从0到7，具体定义看14229附录4中的具体定义。DTC的状态有专门的一个字节来表示。
对于02服务，字节的用法，有不同的3种类型。在请求的时候可以随意设置，在响应当中也会响应一个DTC状态，和请求不同，响应的时候就是1502+ECU可以支持的所有的DTC状态掩码，假如都置1，那响应的时候就是FF，第三种形态对于每个DTC来说，都会有一个相应的故障的状态。这个也会表现在肯定响应当中。
DTC读取：
当我们请求DTC的时候，我们就用19 02 故障状态掩码（SM），肯定响应的时候也是要有一个状态掩码SAM，在每一个DTC当中，不光只有三个字节的本身DTC代表的一个CODE， 最后一个位还会有一个DTC的状态。这个是当产生和记录的时候这个位就已经被创建好了。19 0A也一样，响应的时候响应59 0A。
DTC擦写：
当故障被清除以后，系统是不会把DTC清除掉的，这时候用14服务进行擦写，14服务后面会加3个字节代表我们的DTC的分组，如果拿到了肯定响应54的时候，就代表所有的DTC都已经被清除掉了。
五、诊断通讯模式
因为诊断是应用层面的，所以UDS服务前面要加上地址的寻址SA代表原地址，TA代表目标地址，TA的类型代表着目标地址的类型。
物理寻址
物理寻址模式，原地址T会向所有ECU发出一个E2的请求，就是点对点的通讯只能对一个ECU来进行通讯，这种就是物理寻址。
功能寻址
功能寻址是广播式的寻址，T向多个ECU发送功能寻址的地址，这个功能被多个ECU都认可，所有寻址的信息都可以叫做CAN-ID，对我们一个ECU来说，它请求的时候可以认可两种请求的CAN-ID。对一个ECU，它响应的时候只有一个物理寻址的ID。能接受的请求有两种，可能是物理请求，也可能是功能请求。
