车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议。
常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有我们熟悉的ISO 14229就是UDS协议，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。
UDS全称Unified diagnostic services，即统一诊断服务。
UDS主要对车载电子控制单元提供统一的诊断功能，如：自动变速箱、防抱死制动系统等。
UDS包含了对传输、数据处理、以及具体的诊断应用服务等各方面的要求，不单指某一方面的诊断服务而是包含了对传输方式、数据格式要求、具体诊断服务等一系列的标准和交互架构。
在国际标准ISO 14229-1中定义，UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据，而到OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。
下图就描述了UDS在OSI七层模型中的应用，OSI七层模型，第一层第二层分别定义了物理层和数据链路层，第三层第四层定义了网络层和传输层，第七层是应用层。
应用层：诊断服务的具体实现，用于tester/client发出诊断请求，server（MCU）根据请求做出不同响应
网络层：中间层，是数据转换的桥梁，包括多帧数据传输，进行数据的打包、拆包，协调上下层工作；还包括对等实体间的通信，数据同步，时间管理，错误管理。
数据链路层：CAN 总线（ISO 11898-1）最初指定的链路层协议仅包括对物理层的抽象需求，ISO11898-1-2015指定了经典CAN帧格式和新引入CAN-FD帧格式。 高速物理层关于电气方面的（电压，电流，数量导体）规定来自于 ISO 11898-2，该协议目前被广泛接受；低速则在 ISO 11898-3 中。但是，物理层关于机械方面的（接头种类和数量、颜色、标签、标准输出）并没有标准文档来正式指定。
物理层：传输所需要的硬件条件，包括收发器，终端电阻，双绞线，距离限制，尺寸；哪些传感器的CANH和CANL连接到网络上，不同速率网络通信需要网关等。
比如说我们熟悉CAN总线，物理层和数据链路层遵循的是ISO 11898，而它的传输层遵循的是ISO 15765-2，在ISO 14229-3中定义了UDS基于CAN总线的应用，而现在比较火的以太网，它的物理层和数据链路层遵循的是ISO 13400-3，它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5
关于诊断流程的描述：
客户端(client)/诊断仪(tester)：发送诊断请求者（读写数据，启动例程）
服务器（server/ECU）：诊断响应的提供者-ECU发送诊断响应（正响应、负响应）
远程诊断（Remote diagnosis）：客户端和服务器不在同一个网段
服务函数：
请求 request：诊断仪对ECU发送请求;
请求确认 req_confirm:当请求被成功收到之后，诊断仪会调用req_confirm表示“请求已经正确的发送成功”;
指示 indication：ECU收到请求后会有一个指示（回调）告诉ECU上层“收到一个诊断请求”;
响应 response：ECU对请求处理完之后，会有返回一个响应;
响应确认 rsp_confirm:诊断仪收到响应之后，ECU会触发rsp_confirm,表示响应发送成功;
确认confirm：当响应发到网络被诊断仪接收到之后，诊断仪会有一个确认confirm（回调），表示已经处理完请求;
服务分为两类有确认服务和无确认服务：
- 有确认服务：
- 无确认服务：
诊断的流程：
诊断学习记录 (二) - UDS 服务
UDS 寻址方式有两种：
功能寻址（1：N）：
客户端（Tester）与服务器（ECU）之间采用一对多的诊断通信方式，客户端向多个服务器发出同一功能寻址的诊断请求。
物理寻址（1：1）：
客户端（Tester）与服务器（ECU）之间采用一对一的诊断通信方式。
UDS应用层服务
服务原语：
服务请求原语：由诊断测试仪诊断应用程序的客户端使用，以启动请求服务并将关于所请求的诊断服务的数据传递给ECU。
服务请求确认原语：用来指示请求服务是否正确传输。
服务指示原语：应用层使用指示原语将关于请求的诊断服务数据传递给ECU的诊断应用程序，并且启动对应的服务功能。
服务响应原语：由ECU诊断应用程序中的服务器使用，以启动响应服务并诊断服务提供的响应数据传递给诊断测试仪。
服务响应确认原语：用来指示响应服务是否正确传输。
服务确认原语：应用层使用确定原语将先前服务请求的结果传递给诊断测试仪。
服务请求原语的消息格式如下：
A_MType（应用层消息类型）：
类型：枚举
范围：diagnostic，remote diagnostic
说明：
如果为diagnostic，则原语不包含A_AE参数。
如果为remote diagnostic，则原语包含A_AE参数。
A_SA（应用层源地址）：
类型：2字节无符号整数
范围：0x0000 ~ 0xFFFF
说明：用于编码客户端与服务器标识符。
A_TA（应用层目标地址）：
类型：2字节无符号整数
范围：0x0000 ~ 0xFFFF
说明：用于编码客户端与服务器标识符。
A_TA_type（应用层目标地址类型）：
类型：枚举
范围：physical，function
说明：用于描述消息的寻址方式。
A_AE（应用层远程地址）：
类型：2字节无符号整数
范围：0x0000 ~ 0xFFFF
说明：用于扩展可用的地址范围以编码（远程）客户端和（远程服务器）标识符。
A_Length：
类型：4字节无符号整数
范围：0 ~ 232-1
说明：需要发送/接收的数据长度。
A_Data：
类型：字符串
范围：0 ~ 232-1
说明：需要发送/接收的数据。
UDS应用层服务的数据格式：
请求服务标识符（SID）：
类型：1字节无符号整数
范围：0x00 ~ 0xFF
请求服务的SID：(X0XXXXXX)b SID的第6位为1
肯定响应服务标识符（SID）：
类型：1字节无符号整数
范围：0x00 ~ 0xFF
肯定响应服务标识符：(X1XXXXXX)b SID第6位为1
肯定响应服务的SID = 请求服务标识符 + 0x40
否定响应服务标识符（NR_SID）：
类型：1字节无符号整数
固定值：0x7F
首先来看服务请求和响应格式，“请求”由Tester端发送给ECU，请求报文里带有SID，根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”。
看两个名词，一个叫做Subfunction，一个叫做ID，UDS服务支持Subfunction的请求和响应格式，“请求”为“SID+一个字节Subfunction+具体的数据”，
肯定响应为“SID+40+Subfunction+具体的数据”，而有的UDS服务里面是不支持Subfunction，是支持DID的，DID是“数据ID”的意思，那么它的请求格式为“SID+具体的DID+数据内容”，肯定响应“SID+40+DID+具体的数据”，这里举出两个例子，一个是 “31例程控制服务”，还有一个是“2F IO控制服务”，31就是它的请求报文里面，带一个字节的Subfunction和两个字节的Routine ID，后面的这个数据是跟具体的数据内容，也可以没有具体的数据。2F是它的SID+两个字节的DID+一个字节的输入输出控制参数（这里注意这一个字节的数据类似于Subfunction，但是他不是Subfunction）+后面加具体的数据内容。
上图有一个概念，为肯定响应抑制位。肯定响应抑制位是在Subfunction里的这个字节的最高位，我们把它叫做肯定响应抑制位。只有这个服务支持Subfunction的时候，才有可能支持肯定响应抑制位，当肯定响应抑制位置1的时候，要求所有的肯定响应的抑制将不再发送。当肯定响应抑制位为0的时候，肯定响应是不被抑制的。这里要注意的是它只是抑制肯定响应，而否定响应是不被抑制的。
Tester发送的请求报文格式错误，或者请求发送的条件处于错误，ECU将发送否定响应，否定响应的格式是“7F+SID+NRC”，常用到的NRC在这里罗列了。
11 表示服务不支持；
12 subfunction不支持；
13 请求的长度不正确，或者格式不正确
31 是请求超出范围；
7E 是在当前会话下subfunction不支持
7F 是在当前会话下服务不支持
下面是与时间有关的参数：
当Tester给ECU发送请求过后，ECU需要在P2Sever时间内给出相应的响应，如果ECU当前正在处理别的任务，处理别的事情，而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78的Pending报文，告诉Tester“ECU正在忙”，之后会在P2Sever*的时间内给出其它的响应报文，如果P2Sever*的时间内还是不能给出相应的肯定响应和否定响应，将继续给出Pending报文，直到能够正确处理请求报文之后，会给出正确的响应报文。
P2 Server：
当ECU（Server端）接收到请求后需要在P2时间内给出响应，如果超时，则会报Timeout，返回否定响应（0x7F+SID+0x78），说明响应超时。
在实际项目中会区分P2 Server与P2 Client，其中Server对应ECU，Client端对应Tester
P2* Server：
当ECU收到请求后，在P2时间内没有给出响应，这时候ECU会发送否定响应（0x7F+SID+0x78），并且开启P2*计时器。在P2*计时器到达时，若还未发送响应，则再次发送否定响应（0x7F+SID+0x78），重新启动P2*计时器。
在实际项目中，不会一直发送NRC 0x78，启动P2*计时器的次数由OEM定义。
ISO-14229-2内P2 Server的推荐值为50ms，P2* Server的推荐值为5000ms。
另外，还有一个跟UDS会话模式相关的时间参数S3 Server。
UDS会话模式：
UDS有三种会话模式：默认会话、扩展会话、编程会话
0x10（Session Control）与0x11（ECU reset）服务能够改变ECU的会话模式
S3 Server：
S3 Server保持在非默认会话的最长时间，即在ECU处于非默认会话模式时，如果在S3时间内没有收到诊断请求，则会自动退回到默认会话模式。
周期性发送0x3E（Test Present）服务来使得ECU维持在非默认会话模式。
如下是UDS会话模式的转换图：
S3 Server 时间的示意图如下：
