|
诊断和通信控制功能 |
SID10 |
诊断会话控制服务 |
|
SID11 |
控制器重启服务 |
|
|
SID27 |
身份认证服务 |
|
|
SID28 |
通信控制服务 |
|
|
SID3E |
握手服务 |
|
|
SID85 |
DTC设置控制服务 |
|
|
故障码传输功能 |
SID19 |
读取故障码信息服务 |
|
SID14 |
清除故障码服务 |
|
|
数据传输功能 |
SID22 |
根据标识符读取数据服务 |
|
SID23 |
根据地址读取数据服务 |
|
|
SID2C |
静态定义标识符服务 |
|
|
SID2E |
根据标识符写入数据服务 |
|
|
SID3D |
根据地址写入数据服务 |
|
|
IO控制功能 |
SID2F |
输入输出控制 |
|
例程控制功能 |
SID31 |
例程控制 |
|
上传和下载功能 |
SID34 |
请求下载数据 |
|
SID35 |
请求上传数据 |
|
|
SID36 |
请求上传或下载数据 |
|
|
SID37 |
数据传输完成，请求退出 |
|
|
SID38 |
文件传输请求 |
10 服务
- 01 Default默认会话；
- 02 Programming编程会话（用于解锁bootloader相关的诊断服务，即程序烧录）；
-
03 Extended扩展会话；
ECU上电时，进入默认会话（Default）。如果进入非默认会话，超过一段时间无请求，那么诊断将退回到默认会话01。值得一提的是，通过3E服务，可以使诊断保持在非默认状态。
11 服务
- 00：硬件复位（等同于ECU断蓄电池电再上电）；
- 01：KeyOffOn复位（等同于将点火钥匙旋至OFF后再回到ON位置）；
- 02：软件复位；
27 服务
27服务是Security Access安全访问。加上子服务，再加上种子（seed），可以请求解锁。
服务的格式：
+ + SID是27。
Sub-function，表征安全访问类型。
-
00：ISOSAEReserved -
01：request Seed -
02：send Key -
03,05,07-5F: request Seed（不同安全等级） -
04,06,08-60: send Key（不同安全等级） -
61-7E：留给OEM自行发挥 -
7F：ISOSAEReserved
完成安全访问的步骤：
-
诊断仪向ECU请求“种子”（通常是与时间相关的伪随机数）, -
ECU向诊断仪发送“种子”, -
诊断仪向ECU发送“密钥” (根据请求得到的种子和一个本地的密码进行计算得来) -
ECU判断诊断仪发来的“密钥”是否有效
举个例子：
Rx：02 27 05 00 00 00 00 00 安全访问，05子功能Tx：07 67 05 08 27 11 F0 77 肯定响应，回复了对应安全级别的种子Rx：06 27 06 FF FF FF FF 00 发送密钥，4个FF。注意06与05成对使用。Tx：03 7F 27 78 00 00 00 00 否定响应，7F+27+NRCTx：02 67 06 00 00 00 00 00 肯定响应，通过安全校验
28服务是Communication Control通讯控制。用于打开/关闭某些类别的报文的发送/接收，通常在软件刷写时使用。
在刷写软件时，需要下载大量数据，此阶段的总线负载较高，可以在刷写前发送28服务，将通信关闭，使其他节点保持静默，把所有通信资源都留给软件下载，当下载完成后再利用28服务将通信恢复。
28服务的格式：
+ + + SID即0x28。
Sub-function，表明要对ECU的通信进行哪种控制，具体包括 ：
-
00 enableRxAndTx （激活接收和发送） -
01 enableRxAndDisableTx（激活接收和关闭发送） -
02 disableRxAndEnableTx（激活发送和关闭接收） -
03 disableRxAndTx（关闭接收和发送） -
04-3F ISOSAEReserved（预留） -
40-5F vehicleManufacturerSpecific(OEM自行发挥) -
60-7E systemSupplierSpecific（供应商自行发挥） -
7F：ISOSAEReserved（预留）
communication Type，即诊断请求对哪种报文进行控制，长度为1 byte。最常用的就是低2 位，0代表预留，1代表应用报文，2代表网络管理报文，3代表普通应用报文和网络管理报文。
Node ID num是可选项，只有当sub-functional等于0x04或0x05时才需要使用。
比如：
28 01 01 表示激活应用报文的接收并关闭应用报文的发送（网络管理报文不受影响）。
28 00 01 表示激活应用报文的接收和发送（网络管理报文不受影响）。
3E 服务
3E服务是Tester Present待机握手
用于向ECU指示诊断仪仍然连接在网络上，先前激活的特定诊断服务和通信功能仍然保持激活状态，周期性发送。
在前面我们介绍了通过10服务使切换ECU的当前会话状态；当我们通过10 02/03请求ECU进入编程/扩展会话后；则需要周期性地发送TesterPresent (3E 服务) 服务，用于ECU非默认会话模式的保持，防止其自动返回到默认会话状态。关于3E服务的请求格式如下：
这里对sub-function的Bit7进行介绍，该位suppressPosRspMsgIndicationBit表示抑制肯定响应消息指示位；如果该位为0，那么报文的响应正常发送；但如果该位是1，那么注意此时的肯定响应是不需要进行回复发送的。所以，关于周期性的3E服务，我们常用的是80这个sub-function；这样ECU不需进行肯定响应的回复。
如果请求的是3E 00 ，那么ECU在收到该服务后，返回的肯定响应格式如下：
85服务是Control DTC Setting控制DTC设置，开启或关闭ECU内部的诊断故障码设置功能
通常与28服务一起使用。在开始刷新前，为了提升传输速率，通过28服务将所有ECU的通信服务关闭，这种情况下，ECU收到不到其他节点的报文，没有必要存储DTC，可以使用85服务将ECU存储DTC的功能禁止。
85服务的格式：
SID> + Sub-function> + DTCSettingControlOptionalRecord>SID：0x85
sub-function，表明是打开还是关闭ECU的DTC存储，具体包括 ：
0x01 on；0x02 off。
DTCSettingControlOptionalRecord：可选项，OEM自行定义。
22和2E服务
22服务是Read Data By Identifier读DID；2E服务是Write Data By Identifier写DID。两个服务成对出现，所以一起介绍。
Request（请求）：
22+DID（Data Identifier，通常是两个字节）Response（响应）：
62+DID+DataDID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。
Request（请求）：
2E+DID+DataResponse（响应）：
6E+DID注意，比如0xF186这个DID不支持直接写入数据，需要用10服务来进行会话转换。也就是说，对于写数据的请求，一般需要在非默认会话，或解锁的状态下才能进行。
19 服务
19服务是Read DTC Information 读取故障码信息，19 拥有28种子服务（Sub-Function）。
常用的子服务：
01（通过DTC掩码读取DTC数量）02（通过DTC状态掩码读取DTC）06（读取扩展信息）0A（读ECU支持的所有DTC数据）0E（读取最近确认的DTC）
0x01 （reportNumberOfDTCByStatusMask）
sub-function = 0x01用于读取符合特定条件的DTC数量，此时parameter为一个byte的Mask，用于与DTC的Status进行“按位取与”运算，而ECU返回的则是取"与"运算之后不为0的DTC的数量。DTC的Status用一个byte表示，其中的8个bit分别代表DTC的不同状态，比如，bit 0 表示这个DTC是active的还是passive的，bit 4表示这个DTC是否已经被confirm了，如果DTC的状态是confirm，则说明该DTC已经被ECU存储下来了。
像19 01 08这个命令，就是读取所有状态为confirm的DTC的数量。
0x02 （reportDTCByStatusMask）
sub-function = 0x02用于读取符合特定条件的DTC列表，parameter仍为一个byte的Mask，用于与DTC的Status进行“按位与”运算，而ECU返回的则是取"与"运算之后不为0的DTC。
19 02 01这个命令，就是读取所有状态为active的DTC的数量。
此时ECU返回的格式应该是59 02 01 XX XX XX 01 YY YY YY 09。
返回的DTC列表中的每个条目为4个字节，前三个字节用于标识DTC，比如 XX XX XX，最后一个字节用于标识DTC状态，比如01，表示DTC是active的，09表示DTC是active且confirm的。
0x06 （reportDTCExtDataRecordByDTCNumber）
sub-function = 0x06用于读取某个DTC及其相关的环境数据，此时parameter为4个byte，前三个byte用于标识我们要读取的DTC，第四个byte用于标识要读取的环境数据的范围，UDS规定使用FF来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。
比如 19 06 XX XX XX FF就表示读取 XX XX XX这个DTC的所有环境数据，ECU的返回值应该是59 06 XX XX XX AA BB CC DD.....，其中AA BB CC DD...代表的就是XX XX XX这个DTC产生时所一起存储的环境数据。
0x0E（reportMostRecentConfirmedDTC）
sub-function = 0x0E时，不需要parameter。
0x0E表示，要求ECU上报最近的一条被置为confirm的DTC。0x0E的19服务通常被作为参数传递给86指令，要求ECU在发生DTC存储的时候进行自动上报，即19 0E这两个字节的指令被嵌入到86服务的命令中。这条命令在开发阶段会用到，比如验证某个故障路径是否生效。
清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。
Request：14+FF+FF+FF；Response：54 。
14 服务
14服务是Clear Diagnostic Information清除诊断信息
清除ECU中存储的DTC。第一个字节是SID，后三个字节用来标识将要被删除的DTC种类，UDS规定用FF FF FF表示所有种类的DTC，OEM自定义代表动力总成，底盘，车身，网络通信等种类DTC的值。
举个例子：
14 FF FF FF 表示删除ECU中所有DTC。
ECU响应0x54，表示成功执行。
2F 服务
2F服务是Input Output Control By Identifier通过ID控制输入输出
输入输出功能主要是ECU的输入信号（如传感器）和输出信号（如执行器）进行控制。该服务在产线上用的非常多。比如，生产线车辆装配完成后，要看看冷却风扇的工作是否正常，就可以通过2F服务的诊断命令来控制风扇动作，直观且高效。
31 服务
SID> + Sub-function> + Routine ID> + RoutineControlRptionRecord>-
SID即0x31 -
sub-function，用于标识要执行什么动作：01开启，02停止，03请求结果 -
routineIdentifier，用于标识要执行的routine -
routineControlOptionRecord，可选参数，用于标识routine执行时所需要的参数，由各家自定义它的内容
作者简介：
Demu，传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年，有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流，共同进步.
