什么是诊断服务？
在还没有诊断服务的时候，如果车辆故障，需要有经验的师傅长时间的摸排查找，费时费力。而车辆的ECU节点有了诊断模块后，就具有了诊断功能，这样车辆如果有了故障，就会自动生成故障代码储存在诊断模块中，然后利用诊断仪就可以读取故障代码，车辆哪个节点出现的哪个故障就一目了然
当然除了通过诊断服务读取故障代码外，还可以通过诊断服务做：
车载网络分为四层，物理层、数据链路层、网络层和应用层，诊断服务位于应用层
Unified Diagnostic Services，统一诊断服务，ISO14229标准规范，是诊断服务的其中一种协议规范，是目前普遍使用的诊断协议
UDS基于CAN通讯诊断，也就是说它的网络层采用CAN网络协议
UDS服务结构为：服务标识符（Service ID） + 子功能（SubFunction）/数据位（DataIdentifier） + 数据(Data)
表明了服务类型，由1字节无符号整数表示，从请求和响应的角度看，有三种类型的Service ID
格式：x0xx xxxx
UDS请求服务标识符的bit6要为0，比如请求读取DTC故障信息的服务标识符是0x19，二进制是0001 1001，bit6就是0
既然有请求，ECU肯定要有响应，而响应又有正负之分
格式：x1xx xxxx
肯定响应标识符是把请求服务标识符的bit6置为1，其他位不变，比如诊断仪向ECU发送请求读取DTC故障信息的服务0x19，ECU回复肯定响应，就需要把0x19的bit6设为1，就是0101 1001，也就是0x59，从中可以看出，bit6置为1对应成16进制就是加上0x40，所以肯定响应服务标识符就是把请求服务标识符加上0x40
当请求的服务ECU不支持，或者请求服务的参数不正确，或者。。。时，ECU需要回复否定响应告知
格式：0111 1111
可以看出，否定响应服务标识符是一个固定值，0x7F
如果UDS诊断服务支持子功能，子功能参数的第一个字节的bit7是禁止肯定响应指示位，bit7 = 1表示ECU禁止肯定响应，bit7 = 0表示ECU可以肯定响应，比如请求ECU reset服务11 02，02的bit7为0，表示ECU执行复位时回复肯定响应
前言
""诊断服务作为应用层的服务功能，实现逻辑很简单，请求-响应，一来一回之间，需要对每个间断进行时间设置""
之前在介绍UDS服务时，UDS由物理层、链路层、网络层和应用层组成，其中并没有传输层
然而不管是ISO官方文档还是CANoe工具，把应用层的定时参数看作是传输层功能，其中有以下几种：
•P2Client
客户端在成功发送请求消息到收到响应消息的超时时间
•P2Server
服务器在收到请求消息后到发出响应消息时的性能要求
•P2*Client
客户端在接收到78 hex的否定响应后等待服务器发送响应时的增强型超时设置
78否定响应码表示服务器暂时繁忙，用来提示客户端继续等待，而P2*Client就是继续等待的超时时间
•P2*Server
服务器在发送78 hex的否定响应后，到服务器发出响应消息时间的性能要求
•S3Client
客户端为保持非默认会话而连续发送的Tester Present请求消息的时间间隔
Tester Present会话保持服务SID是3E hex
•S3Server
服务器在未收到任何诊断请求消息的情况下使诊断会话保持在非默认会话的时间
我们知道如果ECU在一定时间内未收到诊断消息，就会从其他会话返回默认会话，这个时间就是S3Server
所以只要在S3Server内一直有诊断通信，ECU就会维持在活动状态（非默认会话），那为什么还要定义一个3E服务来维持会话呢？
因为有的时候通信可能暂停，等到下次想使用诊断服务时，又需要重新切会话，比较麻烦，所以就定义了一个专门用来维持通信的服务，其实就是定时发送3E请求消息，ECU收到后回复7E响应的过程
•P3ClientPhys
客户端在成功发送无需 响应的 物理寻址的请求消息后，再次发送下一条物理寻址请求消息的 最小时间间隔
什么意思？就是客户端如果发送需要响应的请求消息时，需要等收到响应后才能继续发送，然而如果发送那些不需要响应的消息时，也需要有一个最小时间间隔，不能像下饺子一样，这样服务器会无法及时响应
•P3ClientFunc
客户端在成功发送 所有服务器无需响应或仅需 部分服务器响应的 功能寻址的请求消息后，再次发送下一条功能寻址请求消息的 最小时间间隔
DiagnosticSessionControl(0x10)
ECU的某些诊断服务必须在指定的诊断会话下才能进行，所以在请求某些服务前，必须用10服务请求ECU切到指定的诊断会话下，不同的子功能代表不同的诊断会话，比如说：
10 01 默认模式
10 02 编程模式
10 03 扩展诊断模式
这里有两个点需要注意：
ECU如果确认10请求成功，就会切换诊断模式，同时回复肯定响应，比如10 03就会回复50 03
那如果请求失败，ECU回复否定响应，否定响应服务标识符是7F，但是失败的原因可能有多种，所以7F后面还需要有否定响应码NRC，用它来表明失败的具体原因
10服务支持的否定响应码
否定响应码NRC
常用的否定响应码
最后一个78，并不代表请求失败，只是说明ECU现在正忙，无法处理此诊断请求，待ECU空闲时，就会处理此请求
TesterPresent(0x3E)
比如说发10 03让ECU切到扩展模式，正常过几秒后ECU就会切回默认会话，而你需要让ECU一直保持在扩展模式，你就可以先周期性地发送3E 00，告诉ECU我是一直在线的，这样ECU就会一直维持在扩展模式
3E服务支持的否定响应码
SecurityAccess(0x27)
ECU如果支持27服务的安全保护，就可以用27服务解锁，受保护的ECU是无法执行某些诊断请求的
解锁的过程
诊断仪向ECU请求种子，然后用ECU回复的种子，代入到特定的算法中，计算得到秘钥，然后把这个秘钥再发给ECU，ECU拿到秘钥验证正确后，解锁即成功。所以，诊断仪这边必须要有ECU的算法
27服务支持的否定响应码
CommunicationControl(0x28)
28服务是用来打开/关闭对非诊断消息的发送/接收
28服务支持的否定响应码
ECUReset(0x11)
11服务可以让ECU重启复位，包括断电重启（模拟断电上电）和软重启（模拟长按power键）
有的请求服务会规定ECU必须重启才能生效，这时候就可以用11服务重启ECU
WriteDataByIdentifier(0x2E)
什么意思？通过诊断刷写的方式对ECU功能配置做相关的设置
比如说某厂商的语音导航系统可以通过诊断刷写的方式支持/不支持WLAN功能，那么WLAN功能会定义一个DID值，比如0x035F，然后用00代表不支持，用01代表支持，那么完整的诊断请求就是：
2E 03 5F 00 -> 通过诊断方式让ECU不支持WLAN功能
2E 03 5F 01 -> 通过诊断方式让ECU支持WLAN功能
还有的功能包含了很多小的功能，比如说蓝牙功能，它的DID是0x055F，它里面有很多配置功能，比如说显示/不显示，支持/不支持A2DP功能，支持/不支持HFP功能等等，你可以在DID的后面用一个字节来表示子功能，再用一个byte表示动作，比如
虽然可以这样定义，但是这样会不会很麻烦，你需要写三次，才能配置好整个的蓝牙功能，有没有一次就搞定的方式？当然是有的，可以这样定义
用一个byte的不同bit位表示不同的子功能，0和1的值表示动作，这样只要刷写一次2E 05 5F 05就表示配置蓝牙功能：显示，不支持A2DP，支持HFP
当然如何定义这些参数具体还是要看厂商的需求是什么
ReadDataByIdentifier(0x22)
上面的2E是写入配置，这个22是读取配置，2E是把配置的值写进去，22就是读取ECU回复的值，然后根据值可以判断ECU配置的功能是如何
比如22 05 5F，ECU回复62 05 5F 05，就可以根据最后的05值在需求定义中查看功能配置的情况
ReadDTCInformation(0x19)
DTC， Diagnostic Trouble Code，当ECU的某些功能发生了错误，比如说连接的音频线路短路、开路，ECU所接的电压过高过低，ECU有些消息未收到等等等等，都会产生相应地DTC code，通过19 + 子功能，就可以读取当前DTC或者历史DTC
什么是当前DTC，历史DTC？
当前DTC就是故障当前还是存在的，历史DTC就是故障之前发生过，现在你读取的时候已经消失了
当前DTC和历史DTC都是同一个DTC code的两种状态而已，而且同一时刻是互斥的，一个DTC不可能既是当前DTC又是历史DTC
ClearDiagnoticInformation(0x14)
会把储存当前DTC和历史DTC的内存空间清除，如果清除完了再读，读取的就是当前DTC，历史DTC就没有了
DTC生成的条件各有不同，有的是需要重新上电才会生成，有的是实时生成
InputOutputControlByIdentifier(0x2F)
可以简单的理解成模拟某些功能，比如说可以让喇叭发出声音，可以模拟按键的操作，可以连接蓝牙设备等等
2F服务支持的否定响应码
RoutineControl(0x31)
比如清空蓝牙配对列表，恢复某些默认值，通过诊断刷写软件版本等
31服务支持的否定响应码
