UDS诊断随笔

This essay is just limited to personal learning，don’t judge somebody even you don’t know him/her.
We always judge a book by its cover or a person from the outside
Absolutely，just fight all your natural instincts, and you’ll be great.
工作细则：
1）当再次审查问题时应换一种角度去思考
2）讨论问题时应当有自己的思路而不是跟着别人的思路走，别人的思路不一定适合你
3) 遇到难题时喜欢走神，需要想办法改善
4) 做事情不要太想当然，从前到后都要自己捋一遍，也许事情没你想的那么简单
5) 问别人你不熟悉的东西时，根据实际情况你自己每个细节都要确认清楚
6) 删除一个整体内容，自己要是否都要删除，如果不清楚找清楚的人来确认
7) 理解问题前都要明确需求输入，不明确需求怎么输入输出
8) 做事无论是否有结论都要明确自己做到什么地步就可以了，有什么证据都贴出来
UDS诊断部分当遇到问题时要多参照ISO14229协议，有些重要的概念都有解释。

API，英文全称Application Programming Interface，翻译为“应用程序编程接口”。 是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。研发人员A开发了软件A，研发人员B正在研发软件B。 有一天，研发人员B想要调用软件A的部分功能来用，但是他又不想从头看一遍软件A的源码和功能实现过程，怎么办呢？ 研发人员A想了一个好主意：我把软件A里你需要的功能打包好，写成一个 函数 ；你按照 我说的流程 ，把这个函数放在软件B里，就能直接用我的功能了！ 其中，API就是研发人员A说的那个函数。 这就是API的诞生

can bus 要求是 两条通信线，两根线都是通信线，并且没有TX/RX之分。
只有两根线组合在一起，才是一条总线。既是TX线，也是RX线。
UDS和OBD的区分：
UDS和OBD的最大区别在于UDS是面向所有ECU，而OBD是面向排放系统ECU
SDS:Session Data Start
SA(Source Address) 源地址
TA(Target Address) 目标地址
源地址和目标地址：
地址和报文ID相关：诊断报文ID = 基地址 + 节点地址
例如：某个ECU为物理寻址，基地址为0x700，测试仪的地址为0x35,ECU的地址为0x65，则测试仪对此ECU的物理寻址为：0x735,ECU的响应则为0x765.
功能寻址则一般根据特定的ID.

S/R、C/S是什么？
S/R是sender receiver的缩写，C/S是client server的缩写，这是AUTOSAR在定义接口模板里比较常用的两种类型。当然我们还有用于多个软件组件之间标定变量共享的calibration port interface，通信应发生于组件之间、应用软件和基础软件之间。
主动请求或者发送数据的就是Client端/sender端；被动完成服务或被动提供数据接受数据的就是receiver或者server端。
C/S和S/R最大的不同就在于C/S通过operation prototye实现交互，而S/R通过Data Element Prototypes进行交互。
从生成代码来看：C/S采用的是函数的方式传递数据；S/R采用的是全局变量的方式传递数据。

Port interface C/S 中的operation Prototypes是什么,用来做什么？
在swc和swc之间 每一个operation都是一个函数，这个函数在Server端实现，在client端调用。
在swc和service之间每一个operation对应一个宏，指向runnable

Port interface S/R 中的Data Element Prototypes是什么,用来做什么？
Data Element是一个全局变量，通过Rte_Write_Name,Rte_Read_Name对全局变量进行读写
可以支持 1:n (i.e. one sender, multiple receivers) or n:1 (i.e. many senders, one receiver)
Interface在定data element需要指定类型 ，由data types完成。

data types 中的Application data types和implementation data types有什么区别呢？
Application data types 提供给应用层使用，是一种功能定义，并不会生成实质代码，需要配合Implementation data type使用。
Implementation data type 则引用了实际上的数据类型，这个数据类型为 base type，还可以设置相应的设计方法和限制条件。
Application data type 在autosar中是可选的，可以直接使用implementation data type。如果使用了application data type 需要增加application data type 和implementation data type之间的映射，这样应用层才有了确切的数据类型。Data type 还可以定义数据单位（unit），数据计算方法（compu method）、数据约束（data constraint），library其实是为了创建不同的package。

关于肯定响应抑制位（SPRMIB）：
Q:如果10 83没有响应怎么确认是否进入扩展会话？肯定响应抑制位的意义是什么？
A:如果ECU没有给出否定响应就表示诊断请求被成功执行了。
肯定响应抑制主要用于客户端（Client）通过功能寻址请求多个ECU同时执行诊断服务的场景。
比如你提到的Bootloader下载流程中诊断仪通过功能寻址请求所有ECU进入扩展会话。这时，所有收到功能寻址请求的ECU都会执行进入扩展会话的操作。成功执行的ECU不给出肯定响应。只有没成功进入扩展会话的ECU才会给出否定响应。
为什么要抑制肯定响应呢。因为同时执行10 83服务的ECU有多个，甚至十几个，如果这些ECU都发出肯定响应，短时间会对CAN总线造成很大的负担。这些ECU要竞争总线，发送肯定响应。在ECU成功发送肯定响应前，还不能再响应其他的诊断服务。关键是诊断仪并不关心这些肯定响应（收到这些肯定响应也不会做额外的处理），反而更关心哪些ECU没有成功进入扩展会话（给出否定响应）。这时采用肯定响应抑制就是一个比较合适的操作

Bootloader刷写

HASH 算法
通常也称散列算法，是一种将任意长度的消息变成固定长度的消息摘要算法，不可逆；

1 MD5
Message Digest Algorithm 5，流行度极高，但目前被发现存在碰撞冲突风险；
任意长度输出为128bit=16字节摘要

2 SHA1
SHA 指Security Hash Algorithm，由美国国家安全局NSA设计的安全散列算法系列；
SHA1 输出长度为160bit=20字节摘要

3 SHA256
继SHA1 出现的算法(属于SHA-2类)，安全性较SHA1更高；
SHA256 输出长度为256bit=32字节摘要。

**数字摘要（消息摘要）**是将任意长度的消息变成固定长度的短消息，它类似于一个自变量是消息的函数，也就是Hash函数。
数字摘要就是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。

基本原理：
（1） 被发送文件用SHA编码加密产生160bit的数字摘要(以SHA-1为例）
（2） 发送方用自己的私用密钥对摘要再加密，这就形成了数字签名。
（3） 将原文和数字签名同时传给对方。
（4） 对方用发送方的公共密钥对数字签名解密，同时对收到的文件用SHA编码加密产生又一摘要。
（5） 将解密后的摘要和收到的文件在接收方重新加密产生的摘要相互对比。如两者一致，则说明传送过程中信息没有被破坏或篡改过，否则不然。

XOR（异或）加密演算：
明文 XOR 密钥 = 密文
密文 XOR 密钥 = 明文
所以，明文 XOR 密钥 XOR 密钥
= 明文 XOR （密钥 XOR 密钥）
= 明文 XOR 0
= 明文

关于诊断中断：
诊断里的中断发生就是有故障发生，MCU去读取相应的寄存器查看到，然后记录DTC
中断是个定义，就是有问题才会响应，而本次开发的中断功能，是通过硬线连接到主机，把PIN脚配置成中断功能，如果在这一链路的电路上，发生了电源或对地短路，就会产生个中断信号通知给到MCU，MCU此时接收到信号，到对应的中断函数里编写代码，编写查看对应的寄存器进行判断。
中断服务是在代码开发时就要写好的，系统运行起来就会创建，有中断信号，就运行应用的中断信号函数，函数里就是要运行读寄存器的代码，如果判断到是DTC故障，就记录DTC故障码。
【注】：一般汽车诊断的算法都是甲方提供的，若没有特殊说明就是网上开源算法拿来用

关于DBC导入配置
CANID信号的导入和Autosar架构紧密相关，具体的模块涉及有：com/pdur/canif/can/rte模块,先修改这些can1/can2的收发配置等，导入前要全部生成对应的配置文件和Rte接口

关于bcm诊断应用
bcm <=> meter的交互之间的单独的诊断收发诊断命令信息的逻辑是要放在诊断应用层，不是放在底层的配置逻辑里它不调用自己的诊断服务来读写信息，所以can信号也不是走的底层can，而是走的应用can信号，这些需要dbc单独导入才能使用。
诊断报文: CANIF之上是CANTP,(CAN->CANIF->CANTP->PDUR->DCM)
普通报文:CANIF之上是PDUR, (CAN->CANIF->PDUR->COM)
NM报文:CANIF之上是CANNM,(CAN->CANIF->CANNM)
XCP报文:CANIF之上是XCP,(CAN->CANIF->XCP)

验证发送接收节点的超时：
1）MCU发送给can工具(诊断仪），在上电后can出现周期性发送的节点ID,然后在超时函数里打上断点，把can线断掉，超过设定时间会跑到断点处停止。
2）MCU接收can工具（诊断仪），can工具模拟发出信号给MCU后，在超时函数内打断点，停止can送信，在断点处会停。

关于要把某个CANID信号根据特殊需求主动从MCU外发而非周期发送需要在配置该信号时将其修改为事件触发类型
验证方法：调用rte外发接口装入实参放置在某个task函数里运行工程后查看canoe Rx信号出现在接收界面即为成功。
特别强调：如果CANID是扩展CANID，可以通过普通canoe验证，只需要三点一致（严格来说所有CANID都应和DBC属性一致）
1.canid名字后加小写x让其被识别为扩展帧ID
2.信号传输周期和DBC设定一致（DBC设定可以通过canoe界面Edit查看其属性）
3.CANID长度和DBC设定一致（DBC设定可以通过canoe界面Edit查看其属性）
因为在底层模块里面会有ID长度检查，如果不对是不能发送正确数据给MCU的；

可根据节点信号文档来确认接口类型：
Read Access -> MCU接收、PERIODIC
Write Access -> MCU外发、PERIODIC
Send Access ->Event触发类型，需修改节点触发类型：DIRECT/MIXED
Mixed 事件+周期
Direct 事件型
Periodic 周期型

SWC（上层逻辑）
👆
RTE（连接上层和存储区域的接口，读写接口：写接口写进去，读接口读取写接口写入的数据，写入的数据是写在NVM）
👆
NVM(ROM区域，划分不同的block给不同的功能来使用，只读区域(例如DEM 19服务的DTC只读），可读可写的区域(DCM 22/2E服务数据操作））
👆
FEE(Flash EEPROM Emulation 动态调整）
👆
FLS(Flash Driver 底层驱动）

2E写服务分三种：
下电写：写入NVM里的时候，掉电再上电，读取数据则为掉电前写入的值；
直接写：诊断请求消息中包括2E服务标识（0x2E）、标识符（Identifier）以及要写入的数据。诊断工具发送的2E请求消息将直接覆盖目标ECU指定标识符位置的数据，更新为新提供的数据。
循环写：循环写可以定义写入数据的循环周期和规则，可以是固定的时间间隔或特定事件触发的条件。通过循环写，可以周期性地更新数据，以确保目标 ECU 上的数据保持最新状态

2E服务的写接口：NVM可划分出Block给2E和22服务，这个block可再划分出不同的接口来对应2E服务的每个DID，
关于Mirror Ram是底层ROM区域的映射，在不能改写ROM的基础上你可以操作 Mirror Ram来作为22服务的读数据；
Const 保护的数据是在2E和22服务异常时提供的写死的数据；

canoe信号高低位的确认：
图中的信号是大端motorola的字节顺序来读取数据的：lsb 最低有效位，msb 最高有效位
所以是第40字节->第47字节->第32字节->第39字节的顺序（从低位到高位）
0x1234 -> 40至47字节存储:0x34,32至39字节存储0x12;
byte 0->byte 7低地址到高地址，大端低地址存高位字节，高地址存低位字节；

10服务
默认会话：01 Default Session，支持信息的读取和查询操作，权限最小。

编程会话：02 Programming Session 顾名思义是用来程序烧录的

扩展会话：03 Extended Session，主要用来数据读写，如写入VIN，序列号，读写诊断码

默认会话：子服务代码是01。就是ECU在刚启动时保持的状态，当ECU复位的时候也是会返回默认会话，不需要超时处理。
编程会话：子服务代码是02。刷写程序时解锁bootloader相关服务，超时或者刷写失败时会跳转回默认会话，即ECU从底层软件跳转到应用软件。
扩展会话：子服务代码是03。通常诊断用的大部分功能以及特殊功能都在这个会话模式下进行，例如写入数据/参数、读写诊断码。

S3定时器：

1）S3client：客户端的定时参数，通常取4000ms，客户端为保持非默认会话自动化连接，两个连续的待机握手服务请求的间隔时间（诊断仪发送3E服务保持会话最小的间隔时间）
2）S3server：服务器的定时参数，通常取5000ms，仅用于非默认会话模式。在S3Server 时间内，如果服务端没有收到任何诊断请求服务，则退出非默认会话，返回默认会话。 （保持非默认会话的时间）
协议交互双方是客户端和服务端，客户端是车主或者诊断仪，客户使用程序发出指令或请求。服务端是整车上的ECU，该ECU对客户的指令或请求做出反馈

ECU内部应始终且仅有一个激活的诊断会话。当上电时，ECU应总是首先启动默认会话。如果没有启动其它的诊断会话，那么ECU上电后应一直处于默认会话模式。

每个诊断会话支持的服务集合功能，扩展会话可以看做是默认会话的超级功能，即默认会话支持的功能在任一非默认会话模式下都是支持的，反过来不一定。

由于不同会话支持的服务集合功能不一样（比如通常默认会话不支持2E写服务），因此会话之间的跳转也是有限制的。编程会话并不能直接跳转到扩展会话。具体的会话跳转关系视项目要求而定

BootLoader启动顺序：boot程序 <=> app程序的切换
1.ECU上电或复位后，先进入Boot段。从Flash/EEPROM中读取 App有效标志，运行Boot标志位。判断Boot标志位若为1，则进入Boot段的编程会话（10 02）（安全等级为上锁），之后写Flash/EEPROM（不安全操作）， Boot标志位清零。若S3定时器超时则退回Boot段默认会话。
经过安全访问进入Level2解锁状态，开始执行App内存擦除，擦除后 App有效标志清零（不安全操作）。

开始烧写。烧写成功后运行boot标志写0，App有效标志写1。
2.判断运行boot标志 ，若为0，则进入Boot段的默认会话。

3.50ms后判断 App有效标志 ，若为1，则 跳转到 App段默认会话。实现时使用汇编指令执行APP段程序；若为0，退回Boot段默认会话，且不再判断 App有效标志，不会再尝试进入App段。

4.App段程序若收到了编程会话请求，运行boot标志写1，随即执行ECU复位，这样会重新进入boot段程序。

注：从BOOT跳入APP前需要判断APP的数据完整性，例如进行CRC校验

默认会话和非默认会话服务支持对比ISO-14229-2020

11服务
01 硬重启(hardReset)：模拟了服务器断开电池供电之后重新上电的操作
易失存储器和非易失存储器的数据都会被初始化
02 上下电(keyOffOnReset)：驾驶员断开并重新点火的操作
非易失存储器的数据将保留，易失存储器的数据会重新初始化
03 软重启(softReset)：重启应用程序application
易失存储器和非易失存储器的数据都不会被重新初始化。

计算机易失存储器和非易失存储器的典型代表分别是内存和硬盘

14服务
没有子服务，可以清除具体哪一个DTC或者04 14 FF FF FF表示清除所有的DTC,诊断规范中有定义不能被14服务清除的DTC除外

19服务
01 子服务：利用状态掩码筛选符合条件的DTC个数
DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配
02 子服务
按照定义的状态掩码的形式去查找匹配的故障，将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回。

01子服务只统计与状态掩码相匹配的DTC个数，02子服务则会将这些匹配的DTC信息返回
19服务常用的子功能Sub-function：
01 读取符合掩码条件的DTC数量
02 读取符合掩码条件的DTC列表和状态
举例说明：状态掩码是09，根据状态掩码相关知识（以下有说），是bit0和bit3置1，即当前故障和历史故障，查找符合此掩码的DTC故障以及状态
请求（单帧）：03 19 02 09 xx xx xx xx（请求查阅的状态位09）
响应（首帧）：10 1F 59 02 09 31 41 59（有效位是6字节，共0x1F=31字节有效位）
请求（流控帧）：30 00 00 xx xx xx xx xx（发送诊断仪发送首帧 = byte0 = 30, byte1 = Block Size = 0 诊断仪客户端接收的连续帧数量不限制，byte2 = STmin = 0 诊断仪客户端接收的连续帧间隔为0ms）
响应（连续帧）：21 08 26 53 58 08 97 93（有效位是7字节）
响应（连续帧）：22 23 08 84 62 64 08 33（有效位是7字节）
响应（连续帧）：23 83 27 08 98 90 13 08（有效位是7字节）
响应（连续帧）：24 95 06 A8 08 xx xx xx（有效位是4字节）
根据以上的反馈的DTC状态位说明均是历史故障
04 DTCSnapshotRecordNumber (Hex)
读取快照信息（冻结帧）-- 就像车道监控拍照，会记录故障在何时何地发生的
为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；
而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因
主要是记录参数：时间，车速，里程，电源电压，车辆点火状态，根据诊断调查表确认。
请求：字节长度+服务ID19+子服务snapshot 04+DTC 故障码+快照编号
正反馈：字节长度+59+04+DTC故障码+快照编号+快照数据个数
举例说明：
请求单
06 DTCExtDataRecordNumber（Hex）
用于记录故障的一些扩展信息，比如故障发生的次数、老化次数、已老化次数、故障持续时间、故障后行驶里程相关的数据
DTC信息。06服务就是用于请求指定故障码（DTC）的扩展信息，一般老化都是需要14服务来清除已存储的DTC
0A 读取ECU支持的所有DTC列表及其状态
02 19 0A xx xx xx xx xx（all in）

DTC 状态掩码：
bit 0 : testFailed
指示最近执行test的结果，testFailed置1，但是它不一定被ECU存储到EEprom中，只有当bit2或bit3被置1时DTC才会被存储。
test通过则置0，如果调用了14服务清除DTC的话，也需要重新置0。

bit1：testFailedThisMonitoringCycle
该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时，这个位需要置0，在调用了14服务后也需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。

bit2：pendingDTC –DTC的成熟
根据ISO 14229的定义，当一个test结束时，若某个DTC满足故障触发条件，则bit2置1。bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，称为待定DTC。因为DTC并不是一达到触发位就会被报出来的，而是故障出现一段时间后才会被确认，而中间的这个状态就用bit2位来表示，因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候，bit2被置1，若一段时间后故障条件不满足了，则bit2置0，若一段时间后故障仍然存在，那么bit3就要置1了

bit3：confirmedDTC
当bit3置1时，说明故障已经发生了一段时间，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，所以可以理解为历史故障。在调用14服务清除DTC后需要置0。

bit4：testNotCompletedSinceLastClear
因为并不是所有的DTC测试都是从上电就开始的，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。调用完14服务后就是置0的。

bit5：testFailedSinceLastClear
该位表示在上次调用14服务清除后DTC后，若test DTC未进行测试或者测试了但结果是pass时置0，如果test运行完成并且返回结果为fails，那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。

bit6：testNotCompletedThisMonitoringCycle
该位表示在当前检测循环周期过程中DTC test是否完成，若完成了置0，未完成置1。在调用ClearDiagnosticDTC后需要置1。

bit7：warningIndicatorRequested
该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0

DTC的老化：
如果没有特殊说明，40个IGN循环就是DTC的老化周期，排放相关 （OBD）ECU 的操作循环按照法规的定义，对于非排放相关 ECU，从 IGN ON到 IGN OFF 记为 1 次操作循环
一个operation cycle就是开始检测到结束检测的时间段，但实际上项目开发具体的开始检测和停止检测的条件还是要看具体项目需求。
AgingCounter也就是处于老化中DTC的计数。当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1，同时DTC Status的BIT3就会清0。
当AgingCounter计数达到阈值后，此故障已经完成了老化，可以自愈–清除历史DTC。同时DTC Status的BIT3清0。
AgingCounter就是一个故障发生了，他就处于老化中的故障，然后下个循环没有检测到故障，AgingCounter这个老化中的故障就加1，一直达到阈值，这个故障都没发生过，就表示这个故障消失了
AgedCounter这个加1，表示故障已经老化完毕，表示故障消失了
AgedCounter表示完成老化的DTC的数量

在存储快照信息时，如无法获取某快照信息的有效数值，则应使用其最近的有效数值
NRC37: 延迟时间未到，如果延迟定时器处于激活时间内收到请求，发送此否定响应码。

Primary Memory：主内存，对主机厂以及ECU供应商可见的DTC信息空间，如DTC Status、Snapshot Data、Extended Data等；
Second Memory：辅助内存，仅ECU供应商内部可见的信息，如event ID、ITC等信息
Mirror Memory ：镜像内存，作为可选的错误内存，且不能被14服务清除，它镜像的是正常的DTC内存，如果正常的错误内存被擦除那么镜像内存可以作为备份参考被使用，这里镜像的内存是主内存（正常的内存错误是之后就使用，镜像的是作为备份存储）

两个时间参数：一个是P2Sever，另一个是P2Sever*
P2Server_max指的是ECU在收到请求和给出响应之间的这个时间间隔，它描述了ECU的反应速度
P2Server_max这个时间参数是在ECU给出NRC 0X78之后生效的，ECU返回NRC 0X78，说明ECU当前处理能量不足，所以需要更长的反应时间，即P2Server_max

当Tester给ECU发送请求过后，ECU需要在P2Sever时间内给出相应的响应，如果ECU当前正在处理别的任务而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78的Pending报文，告诉Tester“ECU正在忙”，之后会在P2Sever *的时间内给出其它的响应报文，如果P2Sever *的时间内还是不能给出相应的肯定响应和否定响应，将继续给出Pending报文，直到能够正确处理请求报文之后，会给出正确的响应报文

NRC78等待回复的响应可以发送多少次在UDS中并没有限制，OEM和诊断工具制造商可能会有限制。

27服务

上位机（诊断仪）作为客户端请求种子；
ECU作为服务端发送种子，并根据安全算法计算密钥；
诊断仪根据接收到的种子也进行密钥计算，并进行发送；
ECU接收到密钥，与自身计算的密钥进行比较；
ECU根据比较结果决定自身是否解锁，并返回响应（肯定/否定响应）信息

诊断仪如果请求种子得到的反馈是全0的种子可以判定当前的安全等级已经解锁，此时服务端应该返回NRC，推荐NRC24（请求顺序错误，报出NRC24）

同一时刻只能有一个安全等级处于解锁状态，

具体安全等级的划分、密钥算法、种子、密钥的长度等信息会由车产规定好释放的。
NRC33 请求的服务需要安全访问，但是没有进行27安全等级解锁，服务器回复此NRC
NRC35 请求回复的密钥key is invalid.
NRC36 回复的密钥key invalid的次数已经超过所允许的尝试限制
NRC37 基于NRC36后尝试多次无效而进入锁定状态，此时需要重新开始安全认证申请seed
如果此时发送正确或错误的解锁方式会不会导致解锁时间缩短或延长这在UDS里面并没有解释，看需求怎么定义。

28服务
28服务主要用于网络中的报文发送与接收，比如控制应用报文和网管报文的收发。

28服务子功能（第2个字节为收发功能）：
00：enableRxAndTx（使能收发）能收发(0000)
01：enableRxAndDisableTx （使能接收并禁止发送）收，能收不能发(0001,bit0 = 1)
02：disableRxAndEnableTx （禁止接收并使能发送）发，能发不能收(0010,bit1 = 1)
03：disableRxAndTx（禁止收发）不能收发(0011,bit0 = 1,bit1 = 1)

控制类型 （communicationType）：
第3个字节为控制类型
01：所有应用报文（0001, bit0 = 1）
02：所有网管报文（0010，bit1 = 1）
03：应用+网管报文(0011，即bit0和bit1均为1）
03 28 03 03 总线上所有报文停止通讯
03 28 03 02 总线上停止收发网管报文
03 28 03 01 总线上停止收发应用报文

2F服务

0x00 returnControlToECU （将控制权还给ECU，即结束控制）
0x01 resetToDefault （将dataIdentifier所引用的输入信号、内部参数、输出信号等设为默认值）
0x02 freezeCurrentState（将dataIdentifier所引用的输入信号、内部参数、输出信号等冻结住）
0x03 shortTermAdjustment （将dataIdentifier所引用的输入信号、内部参数、输出信号进行设置，对ECU夺取控制权，即开始控制）

IO简单输入输出控制服务，InputOutControlByIdentifier（通过标识符控制输入输出）
该服务是用于client主动请求server去对相关输入输出信号进行控制。所谓的输入输出控制简而言之就是屏蔽实际的输入输出信号值，取而代之的是client主动以某种特定的控制方式去设置这些信号值。
验证2F有效：22服务读取DID里面的信号值可验证2F是否有效设置了DID的信号值。

2F这个服务就是对ECU的输入和输出进行控制。这个服务在生产线上会需要使用，比如，在总装阶段，工人需要验证车上的各种功能是否正常，例如四个车窗的升降是否正常，如果挨个开关去按，那效率很低，如果通过一个诊断命令就能够观察到车窗升降的情况，效率则高得多。

2F服务主要针对输入输出控制，列举常见的使用场景如下：
车窗的升降控制；（OutputControl）
直连执行器的启动与停止；（OutputControl）
车灯的开启与关闭；（OutputControl）
ADAS相关功能的配置开启与关闭；（InputControl）
（功能的配置开启可以理解为：烧录时确认的Configuration = 0/1/2/3来开启对应的功能）
LED报警灯的驱动与关闭；（OutputControl）

31服务
Routine Control Sub-function

0x01 表示 startRoutine（启动程序）
0x02 表示 stopRoutine（停止程序）
0x03 表示 requestRoutineResults（请求程序的运行结果）

Service31的典型用途可以包括擦除内存、重置定义的数据、覆盖正常服务控制策略以及控制ECU值随时间变化的功能。
相比0x2F服务，具有较大的灵活性，可用于较为复杂类型的控制。一般应用包括清除内存（多数用在更新ECU软件），重置或学习自适应数据，运行自检，方向盘角度零点标定等

3E服务
3E 00/80 可以保持当前的诊断服务或通信在激活状态，一般周期发送请求帧，使非默认会话不返回默认会话

85服务
监控DTC的开关服务
该服务要求ECU停止／恢复DTC的设置。将此服务与车载通信切换（服务$28通讯控制）相结合，可增加用于Flash Bootloader编程的速度
85 01 开启DTC监控
85 02 关闭DTC监控

此处是一般性例子，拿出来以便辅助记忆
Test Procedure :

1. Enable the NM and verify the VCU wakes-up.

2. Connect Hardware to run command for diagnostic channel

3. Set the Power mode = ON.

    02 10 01（Request diagnostic Session Request）
    02 50 01（ECU responded positively）
    02 3E 80（Request Tester Present per 2.5sec）
    02 7E 80（ECU responded positively）
    02 10 03（Request Diag Extended Session Request）
    06 50 03 00 32 00 C8（ECU responded positively）
   

   P2server_max (00 32): 由主机厂定义，解析度为1毫秒，00 32既是50毫秒（ms）最大65535ms
   P*2server_max (00 C8): 由主机厂定义，解析度为10毫秒，00 C8既是2000毫秒（ms）最大655350ms

4. Set the Power mode = OFF.

    02 85 02（Request Control DTC's Setting OFF）
    02 C5 02
    03 28 03 01（Request Disable Communication request）
    03 68 03 01（停止收发常规应用报文）
   
    02 10 02（Request Programing session）
    02 50 02（进入编程会话）
    02 27 01（Request Security Seed Level 01）
    22 67 01 XX XX(32 bytes of seed)
    02 27 02（Request Security Key）
    02 67 02
    02 2E XX XX(写入诊断仪序列号及ECU软件刷新日期)
   
    （下面这部分因为自己学习有限，没有具体报文）
    通过34、36、37服务下载Secondary Bootloader，即FlashDriver文件
    通过31服务检查SBL（Secondary Bootloader）程序的数据一致性和完整性，
    Bootloader会计算所有下载数据的校验和，此校验和将于31服务发送的Data进行比较。如果相同则认为数据可用
    通过31服务请求目标ECU清除部分内存
    通过34、36、37服务下载APP程序，即最终的mcu程序
    通过31服务检查APP程序的数据一致性和完整性
    通过31服务请求目标ECU运行一个例程，检查所有下载的软件部分的依赖关系
   
    02 11 01 （hardreset and wait for 2 sec)
    02 51 01
    02 10 03	(扩展会话）
    06 50 03 00 32 00 C8（ECU responded positively）
    03 28 00 01（收发常规应用报文）
    03 68 00 01
    02 85 01 （DTC监控开启）
    02 C5 01
    04 14 FF FF FF（清除所有记录的DTC）
    01 54
   

至此，已经通过Bootloader完整地刷新了一遍ECU软件

---

重点：不是资料的基础知识，而是诊断服务整体开发思路，每个服务手打代码的应用逻辑和接口交互，开发过程中替代重复性代码或者需求转化为代码的开发脚本，开发结束后的测试脚本，以及怎么验证代码的正确性
诊断服务模块的功能交互，例如从10服务开始，我可以进入哪些服务，
诊断应用模块的功能交互，例如2E服务拿到接口怎么用，内部逻辑的实现，输出数据的应用

OBD和UDS的读值区分：
UDS它是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU。
UDS可以满足OBD的功能，OBD可以被市面通用的诊断仪读取，而UDS基本只有主机厂的诊断仪才能读取

c.tom 是source insight的软件特色：个性化的属性或者说是代码风格

（自己只是作为学习日志来编辑的，仅作私用）