VIN :车辆识别号，是主机厂对一辆车的唯一标识码，是在下线检测的时候写入到ECU当中
诊断的作用：读取软硬件版本号，故障检测，程序升级刷写，下线检测，IO控制（比如雨刮器的耐久测试）
UDS 定义了一种C/S架构的诊断响应机制
OBD: 与排放相关的，可支持CAN LIN K ，主要与法规相关
UDS是应用层协议，与底层的通讯介质不相关，所以可以在任何形式的通讯介质上实现
UDS 也是参考ISO 七层网络协议模型：每一层都有对应的标准，比如物理层是ISO11898-1/ISO11898-2；网络层和传输层中是不同通讯协议的标准，比如ISO15765-2是基于CAN的传输协议，ISO17987-2是基于LIN的协议
14229 一共有6个部分
ISO 14229-3 是基于CAN的UDS
UDS 与OBD的关系：
OBD是在15031-5中定义的排放相关的服务，UDS是14229-1中定义的通用服务两者都依赖15765-2中定义的网络层和14229-2中定义的会话层一个ECU中是可以共存OBD与UDS的，两者各司其职Unified: 可以实现任何通讯方式的诊断 原因：网络层，传输层和会话层之间的T_PDU（虚拟PDU）T_PDU 是A_PDU与任何通讯方式PDU之间连接的接口6种服务原语（了解即可，底层ECU开发不需要关心这部分的实现）
服务请求原语（开始发送给诊断请求）服务请求确认原语（诊断请求发送完成） 内部有A_Result数据：枚举类型，表示是否正确传输服务指示原语（ECU请求消息收到，开始处理诊断请求）服务响应原语（ECU处理结束，开始向tester发送，响应报文）服务响应确认原语（ECU发送响应报文结束）内部有A_Result数据：枚举类型，表示是否正确传输服务确认原语（tester 接收响应报文成功确认）原语格式：
A_MType：本地诊断还是远程诊断A_TA_type: 物理还是功能A_AE只是针对于远程诊断方式的A_SDU与A_PDU的关系
应用层服务A_SDU是通过服务原语进行传递到A_PDU的，原语将诊断应用程序中发出的诊断服务需求，转换成A_PDU对等实体间就是通过对应的PDU进行传递的A_PDU = A_PCI +A_SDUA_PCI （应用层协议控制信息）根据A_PCI参数的第一个字节是否为0x7F分
A_PCI (SID) ：请求服务和肯定响应，一个字节无符号整数A_PCI （NR_SI, SI）：否定响应SID(服务标识符)
0x00-0xFF 之间，但是其中部分保留了，可以让供应商或者主机厂自定义的字节14229-1的部分，目前定义了26个服务类型对于请求服务，第六个bit为0，相对应的返回的肯定响应标识符第6个bit为1，此为他们的对应关系，即肯定响应SID =请求的SID+0x40肯定响应NR_SID =0x7F 固定NRC :返回错误的原因，NRC 可以直接查询14229-1附录就是了诊断三要素：
请求肯定响应否定响应A_PDU
Cvt: convention; M： mandatory, C：conditional（基于某一些标准的），S: selectonal(可选的)，U: User optional(用户自定义)
子功能（SF）:带子功能（S）; 不带子功能（U）
SF ：一个字节；子功能参数范围0x00-0x7F： 0-127
第7位决定了是否需要发送肯定响应消息
A_PDU处理过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NUsTLbXy-1601947004780)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509072247357.png)]
UDS中定义的服务一共6类26个，下面定义一些常用的服务
三种诊断会话
默认诊断会话：ECU一般刚上电，冷启动，软件复位进入的状态，是比较安全的状态，通过0x10 01 让ECU进入此会话，安全锁定状态非默认诊断会话 编程会话：用于重新编程即软件刷写的状态，主编程环节 0x10 02扩展诊断会话：ECU刷写的预编程环节, 0x10 03注意：不同的诊断会话具有不同的功能和定时参数；一般来说非默认会话基本能够支持比较多的服务，默认会话能够支持的服务比较有限
注意：不能由默认会话直接跳转到编程会话的，只能有扩展会话跳转到编程会话，如果在默认会话中发送跳转到编程会话的请求是，ECU会回复NRC7E
会话超时-定时器S3
在非默认会话中保持的时间是可以设置，一般默认P2=50ms, P2* = 5000ms
问：P2和P2*是什么意思？
P2–从ECU收到请求消息到发送响应消息之间的时间
P2*–从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x54XtmD6-1601947004782)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200528102453424.png)]
S3server 的时间是确认从PDUR中接收到数据之后开始计时的
通过0x3E服务可以请求不要断开非默认会话
一般用于软件刷写中
0x10 服务
SF 0x00-0xFFNRC诊断描述文件（cdd）
在dependency中可以看到会话切换的转换图有时候在功能寻址过程中为了减少总线负载，如果不想所有的ECU都发送肯定响应，则需要应用SF中的一直肯定响应消息位 如 0x10 83
四个步骤
请求，2n-1表示安全等级，如果请求时已经解锁，则直接返回位为全0的肯定响应，表明已经处于解锁状态
ECU返回种子，随机数，种子的字节长度由OEM自定义
Tester通过种子,再根据种子安全等级与范围，计算一个密钥key1
ECU 通过key1 计算Key2, 如果Key1 =Key2 则解锁
ECU返回解锁消息
0x27 可以实现不同安全等级切换，但是在任意时刻只能有一个安全等级编写cdd文件时，种子字节、安全等级、密钥数据类型都可以自定义，创建好的安全等级可以在state groups中查看常见8个NRC不同安全等级之间的关系
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AaoBNnrz-1601947004785)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200529164400912.png)]
不同安全等级之家可以是相互独立的也可以是有依赖关系的，比如说要先解锁了安全等级1之后才能进入到安全等级3
从解锁状态跳转到锁定状态的几种方式：
接收了$11服务，ECU重新复位了ECU重新上电了
接收了$10会话切换功能[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BRd6QeKH-1601947004787)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200806163112407.png)]
用于停止或者恢复单个服务器或者一组服务器中DTC状态记录
0x85 01 正常记录
0x85 02 停止DTC更新
以下诊断服务用得相对于上面的少一些
问题：怎么编写CDD文件
读取ECU内的数值，如软件版本号，VIN, 车型配置等
读写数据的个数规定上限为4095
根据DID读取数据
模拟量输入输出内部数据系统状态信息DID规范见14229附录，一次请求可以发送多个DID，每一个DID都是双字节无符号数
比如读取VIN的DID就是0xF190，VIN号一共是17个字节比如DID=0x010A 返回发动机冷却液温度、节气门位置、发动机转速、歧管进气压力、怠速控制等等比如DID=0x0110 包含电池正电压ISO对于DID的取值范围做了划分，具体DID代表了什么/多少数据、格式就需要OEM/Supplier制定不同的DID需要不同的服务支持一共28种子功能，常用的有4种
0x02 最常用 SM（StatusMask）表示掩码; SAM（StatusAvailabilityMask）表示返回的可用掩码
注意:SAM是通过SM与ECU内部的现有的DTC的状态进行&计算，筛选出非0的所有的DTC
所以一般状态掩码与DTC的状态码的定义类似
0x04 快照数据，也就是故障发生时候的环境数据
ECU每发生一次故障，记录一次DTC，都会记录一次snapshotData，主要作用是帮助分析发生故障的主要原因
分为
全局快照（必须）
一般包括：
供电电压
里程数
电源模式
日期
时间
冷却液温度
局部快照（可选）：全局快照信息的补充
比如：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ugkblX6K-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103311366.png)]
0x06 扩展数据—服务执行时的环境数据
扩展数据信息是一组提供诊断故障代码相关扩展状态信息的数据组，一般包括 包括故障出现计数器-记录的次数故障待定计数器-记录的次数已老去计数器-记录的此时 老化计数器-记录的次数 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5bOTVFus-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103655505.png)]0x0A 读取所有的DTC，返回ECU内目前记录的所有DTC
3个字节的DTC组是用于选择DTC组的掩码，group对应着车身、动力总成、车身、地盘等
清除完成之后，返回肯定响应，即使没有DTC，同样发送肯定响应
清除所有DTC
清除某一个DTC: 后面直接跟DTC的具体数值就行了
远程控制，让ECU启动、停止或者执行一段特定的序列，并返回其结果
又同步和异步两种方式
例程：执行特定序列并或者相关的输出结果，比如，ECU上电的自检、ECU存储器擦除、调整电机的零位角度,可以把例程视为一段比较复杂的逻辑程序。
三个步骤
开始例程 0x31 01
请求例程结果 0x31 03
停止例程 0x31 02
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a5ezRdCS-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509105520277.png)]
上传用得比较少，多用下载功能（也就是软件刷写）
有关软件刷写需要注意的几点
烧录的时候，为了降低总线的负载率，需要控制车上各个ECU的收发信息开关烧写时不能开启故障存储[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0DrEsAOH-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110208006.png)]
肯定响应
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k8quQRAU-1601947004793)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110335965.png)]
请求停止程序/数据的传送
对0x36 数据传输的数据校验，常见的校验和是CRC8 ，CRC16
UDS诊断服务的几种形式
只有SID 如0x3E带SF ，SID+SF带数据标识符DID ，SID+DID, 如0x22 和0x21其他 SID+SF+RID(历程标识符) 如 0x3ECAN总线的UDS实现，ISO15765-2
三种寻址方式：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-egjrUo4r-1601947004794)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509111945059.png)]
正常寻址扩展寻址混合寻址CAN总线一次最多只能发送8个字节
请求超出范围
比如NRC31在三个会话中都是支持的，但是不是所有的DID在所有的会话中都是支持的，当读取某一个DID信息时，如果该DID在当前会话下不支持就会返回NRC31
DCM模块主要是实现UDS和OBD诊断服务的实现，但是DCM跟其他模块的交互比较频繁，需要了解诊断服务的机制需要其他模块配合，比如BswM、DEM、EcuM以及SWC等。
DSL用于处理诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序。
当收到诊断请求时，PDUR调用Dcm_StartOfReception()和Dcm_CopyRxData()函数将收到的诊断请求数据放置在DCM模块的Buffer中，然后PDUR调用Dcm_TpTxConfirmation()函数通知Dcm模块接收到了新的诊断请求。
当需要响应诊断请求时，DSL模块通过调用PduR_DcmTransimit()和Dcm_CopyTxData()将数据传递至PDUR模块，其中PduR_DcmTransimit()函数只是传递长度信息、地址信息，数据是通过Dcm_CopyTxData()函数传递至PDUR模块，当数据传输成功后，PDUR模块通过Dcm_TpTxConfirmation()函数告知DCM数据接收成功。
DSL提供Dcm_GetSecurityLevel()、DslInternal_SetSecurityLevel()两个函数分别用于获取当前的安全等级和设置安全等级。
对于配置层面而言，DSL菜单主要是：
配置诊断帧，包括物理寻址和功能寻址，单次通信的最大Buffer，以及时间参数，包括回复0x78的时间为了防止诊断服务异常，允许0x78的最大次数等。DSD模块负责检查诊断请求的有效性（诊断会话、安全访问级别、应用程序权限的验证），并跟踪服务请求执行的进度。
当DSL接收到新的诊断请求，DSL通过内部接口通知DSD，如图3所示。DSD调用Dcm_GetSesCtrlType()、Dcm_GetSecurityLevel()获取当前的Session和安全等级，DSD模块会在当前Session的“Service Identifier Table”检查诊断请求SID是否在其中，如果不在table中，DSD会发送NRC 0x7F，如果诊断服务支持，但当前Session不支持该子服务，DSD会发送NRC 0x7E；然后检查当前安全等级是否满足条件，如果当前安全等级不支持该诊断请求，DSD会发送NRC 0x33。最后检查数据的长度。
图3 DSL与DSD的交互
当DSP模块完成诊断请求处理后，DSD负责将整理响应数据。并发送至DSL。
DSD模块将服务标识符(SID)(如果是负反馈，则为0x7F)和响应的数据流添加至“Dcm_MsgContextType”。然后DSD将其传送至缓冲区，并在缓冲区的第一个字节添加SID。
对于配置而言，DSD主要是配置：
所需要实现的服务服务所支持的session服务执行的安全等级DSP用于实现不同服务的处理，当接收到DSD请求处理诊断服务，DSP的处理过程如下：
比如0x22和0x2E服务需要调用SWC的数据接口进行读写；0x28需要调用BswM的逻辑实现关闭不同的CAN报文；0x19服务需要调用DEM模块获取快照数据和扩展数据。
对于配置而言，DSP模块配置项比较杂，比如：
DID的实现，包括DcmDspData用于配置DID的数据类型，数据长度，以及接口类型；DcmDspDidInfo用于配置DID的读写功能；DcmDspDids用于汇总DcmDspDidInfo和DcmDspData，并且添加DID value。
安全等级的实现，包括种子和秘钥的位数、最大的错误访问次数，以及时间参数。
Session的配置，包括Session的等级，Session是否支持跳转至Boot，以及时间参数P2 ServeMax和P2* ServeMax。
用于处理诊断事件的信息和相关的数据，DCM模块通过服务请求可以获得这些数据。
DEM模块主要是处理的DTC相关的数据。
DCM模块遵循的标准与DCM相同，负责直接处理与DTC相关的服务，如UDS中的0x19服务(响应报文由DCM发送出去)。当软件构件中的Monitor Function检测到故障或BSW模块检测到故障时，将通知DEM模块处理和储存“诊断事件”(由Event ID进行标识)。如果故障确诊，呼叫NVRAM Manager(非挥发性内存管理器)提供的接口将其存取到非挥发性内存中，同时通知应用层进行故障指示。DEM的状态图如下图所示：
DTC信息= DTC（高3bytes）+DTC状态(低1byte)
5位SAE标准故障码
UDS
详情可看14229-D附录
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ij9xuYra-1601947004797)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509100644731.png)]
BIT0 : testFailed。表示发生了TestFailedBIT1:testFailedThisOperationCycle。表示当前Cycle发生了TestFailed
BIT2:pendingDTC。表示当前发生了testFailed
BIT3: confirmedDTC,表示已经检测到多次testfailed，并且能确认故障发生，需要去存储相关的数据。
BIT4:testNotCompletedSinceLastClear, 表示自执行14服务起，还没有完成完成测试，也就是没有testPass或者testFailed。BIT5:testFailedSinceLastClear，表示自执行14服务起，发生了testFailed事件。
BIT 6:testNotCompletedThisOperationCycle,表示当前OperationCycle还未完成测试
BIT7: warningIndicationRequested,表示特定的DTC需要置告警，车身故障灯亮起
DEM提供接口函数Dem_SetEventStatus设置DTC的Status
Debounce方式也就定义了DTC状态变化的形式
连续测试中：
如果一直测试通过，达到Pass界限，BIT4由1置位0，BIT6由1置位0如果侦测到testFiled，那么TripCounter就直接从大于0开始计数当TripCounter连续计数累计超过Failed时，BIT2与BIT3置位AgingCounter&Agecounter
当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1，同时DTC Status的BIT就会清0当AgingCounter计数达到一定的阈值后，此故障已经完成了老化，可以自愈。同时DTC Status的BIT3清014229-1附录D提供了关于AgingCounter的演示SnapShot
SnapShot是一群DID数据的集合每个DTC在Confirm时可以生成快照，将当时的一些关键数据存储在NVM中通过19服务读取SnapShot的具体数据cess=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70)
Debounce方式也就定义了DTC状态变化的形式
连续测试中：
如果一直测试通过，达到Pass界限，BIT4由1置位0，BIT6由1置位0如果侦测到testFiled，那么TripCounter就直接从大于0开始计数当TripCounter连续计数累计超过Failed时，BIT2与BIT3置位AgingCounter&Agecounter
当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1，同时DTC Status的BIT就会清0当AgingCounter计数达到一定的阈值后，此故障已经完成了老化，可以自愈。同时DTC Status的BIT3清014229-1附录D提供了关于AgingCounter的演示SnapShot
SnapShot是一群DID数据的集合每个DTC在Confirm时可以生成快照，将当时的一些关键数据存储在NVM中通过19服务读取SnapShot的具体数据