五、诊断服务
1、UDS诊断服务分类
（1）ISO 14229-1中定义的26个服务标识符如下所示，其中蓝底标记的服务较常使用，部分较简单或不常使用的服务将不会详细介绍。
| SID | 服务 |
| 0x10 | 诊断会话控制（Diagnosis Session Control） |
| 0x11 | ECU复位（ECU Reset） |
| 0x14 | 清除诊断信息（Clear Diagnostic Information） |
| 0x19 | 读故障码（Read DTC Information） |
| 0x22 | 按标识符读取数据（Read DataByIdentifier） |
| 0x23 | 按地址读取内存（Read Memory By Address） |
| 0x24 | 按标识符读取数据（Read Scaling Data ByIdentifier） |
| 0x27 | 安全访问（Security Access） |
| 0x28 | 通信控制（Communication Control） |
| 0x2A | 按周期标识符读取数据（Read Data By Periodic Identifier） |
| 0x2C | 动态定义数据标识符（Dynamically Define Dataldentifier） |
| 0x2E | 按标识符写入数据（Write Data ByIdentifier） |
| 0x2F | 按标识符控制输入输出（Input Output Control Byldentifier） |
| 0x31 | 例程控制（Routine Control） |
| 0x34 | 请求下载（Request Download） |
| 0x35 | 请求上传（Request Upload） |
| 0x36 | 数据传输（Transfer Data） |
| 0x37 | 请求传输退出（Request Transfer Exit） |
| 0x38 | 请求文件传输（Request File Transfer） |
| 0x3D | 按地址写入内存（Write Memory ByAddress） |
| 0x3E | 待机握手（Tester Present） |
| 0x83 | 访问时序参数（Access Timing Parameter） |
| 0x84 | 安全数据传输（Secured Data Transmission） |
| 0x85 | 控制故障码设置（Control DTC Setting） |
| 0x86 | 事件响应（Response On Event） |
| 0x87 | 通信链路控制（Link Control） |
（2）UDS诊断服务可以分为六大类：
①诊断和通信管理功能单元。
0x10服务——Diagnosis Session Control
0x27服务——Security Access
0x28服务——Communication Control
0x3E服务——Tester Present
0x85服务——Control DTC Setting
0x11服务——ECUReset
0x83服务——AccessTimingParameter
0x84服务——SecureDataTransmission
0x86服务——ResponseOnEvent
0x87服务——LinkControl
②数据传输功能单元。
0x22服务——Read DataByIdentifier
0x23服务——Read Memory By Address
0x24服务——Read Scaling Data ByIdentifier
0x2A服务——Read Data By Periodic Identifier
0x2C服务——Dynamically Define Dataldentifier
0x2E服务——Write Data ByIdentifier
0x3D服务——Write Memory ByAddress
③存储数据传输功能单元。
0x19服务——Read DTC Information
0x14服务——Clear Diagnostic Information
④输入/输出控制功能单元。
0x2F服务——Input Output Control Byldentifier
⑤例程功能单元。
0x31服务——Routine Control
⑥上传/下载功能单元。
0x34服务——Request Download
0x35服务——Request Upload
0x36服务——Transfer Data
0x37服务——Request Transfer Exit
0x38服务——Request File Transfer
2、UDS诊断服务支持的消息格式
（1）某些UDS诊断服务，除了数据参数以外，A_Data只有SID。
（2）大多数UDS诊断服务支持子功能，A_Data中包含SF。
（3）一些UDS诊断服务支持数据标识符（Data Identifier，DID）。
（4）0x31服务同时包含SID、SF及例程标识符（Routine Identifier，RID）。
3、故障的记录
（1）故障通常可分为可观察到的故障和不可观察到的故障，诊断服务最初设计的目的就是方便定位和分析整车中各ECU的故障位置及故障类型。
（2）以下的“故障”多指ECU的故障位置和故障类型。
（3）如果系统检测到故障，则通过诊断故障代码DTC（DiagnosticIroubleCode，DTC）进行存储。
（4）DTC的格式：
①ISO 14229-1中定义的DTC长度为3字节，DTC信息除了DTC本身的定义以外，还包含一个DTC状态。
②ISO 15031-6/SAE J2012-DA中定义的DTC是5位标准故障码，第1位是字母，后面4位是数字，然后是故障子类型及DTC状态。
③DTC状态也占一个字节，ISO 14229-1中定义的DTC状态位如下所示。
| Bit# | statusOfDTC位字段名称 | 说明 |
| 0 | testFailed | DTC最近请求的测试结果为失败 |
| 1 | testFailedThisOperationCycle | DTC在当前操作循环中测试结果为失败 |
| 2 | pendingDTC | DTC在当前或上一个操作循环中测试失败 |
| 3 | confirmedDTC | DTC在请求时已确认 |
| 4 | testNotCompletedSinceLastClear | 自从上次DTC清除后测试尚未完成 |
| 5 | testFailedSinceLastClear | 自从上次DTC清除后测试结果为失败 |
| 6 | testNotCompletedThisOperationCycle | DTC在当前操作循环中测试未完成 |
| 7 | warningIndicatorRequest | 服务器请求激活与该DTC相关的报警指示灯 |
六、各类诊断服务介绍
1、诊断会话控制（0x10服务）
（1）诊断测试仪和ECU通过通信媒介建立连接，会在会话层形成诊断会话（下图所示为OSI体系结构，是一个七层协议的体系结构）。
（2）诊断会话模式的转换：
一共有三种会话模式——默认会话、编程会话、扩展诊断会话，不同的诊断会话具有不同的功能、不同的定时参数、受到不同的安全访问保护，其转换关系如下图所示
①默认会话模式：
通常来说，ECU上电、软件复位（0x11服务）会使会话层进入默认会话模式，也可认为这是个初始化的状态，此模式下ECU处于锁定状态，执行应用功能程序（APP）
诊断测试仪发送0x10 01服务请求，也会使ECU进入默认会话模式
诊断会话中的定时器S3Sever超时，也会使ECU进入默认会话模式
②编程会话模式：
编程会话模式专用于ECU软件刷写，此模式下ECU处于非锁定状态（通过安全访问解锁）
诊断测试仪通过安全访问将ECU解锁后，发送0x10 02服务请求，会使ECU进入编程会话模式
③扩展诊断会话模式：
部分诊断服务要求进入非默认会话模式，除了编程会话模式以外，就是扩展诊断会话模式，此模式下ECU处于非锁定状态（通过安全访问解锁）
只有诊断测试仪通过ECU的安全访问，ECU发送肯定响应报文之后，即会话层使用S_Data.confirm向应用层确认S_Result = S_OK，ECU才会进入诊断测试仪所请求的诊断会话模式，诊断仪才能解锁ECU，获得ECU内部数据信息的权限，否则当前诊断会话模式保持不变
比如软件刷写涉及向ECU的非易失存储器写入数据，所以在软件刷写前，需要ECU进入扩展诊断会话模式做准备，可认为这是软件刷写的“预编程”环节，该环节中诊断测试仪将请求禁止ECU记录DTC、禁止ECU发送应用程序报文及网络管理报文，甚至可能还有其它请求
诊断测试仪通过安全访问将ECU解锁后，发送0x10 03服务请求，会使ECU进入扩展诊断会话模式
（3）会话超时：
ECU处于不安全的编程会话状态时，诊断测试仪需要周期性地向ECU发送0x3E服务，用于告知ECU诊断测试仪在线，请求ECU不断开诊断会话，发送周期需要小于定时器S3Sever的超时阈值，否则软件刷写会被异常中断
（4）ISO 14229-1规定了不同诊断会话模式下允许的诊断服务。
（5）诊断会话控制请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | DiagnosticSessionControl Request SID | M | 0x10 |
| #2 | sub-function = [ diagnosticSession Type ] | M | 0x00-0xFF |
其中ISO 14229-1给出了diagnosticSession Type（诊断会话类型，也可将其认为是0x10服务的子功能）的4个选项定义，实际开发中可视情况继续增加可选选项
| Hex值 | Description | Cvt | Mnemoic |
| 00 | ISOSAEReserved（预留） | M | ISOSAERESRVD |
| 01 | defaultSession（请求进入默认会话） | M | DS |
| 02 | programmingSession（请求进入编程会话） | U | PRGS |
| 03 | extendedDiagnosticSession（请求进入扩展诊断会话） | U | EXTDS |
| …… | …… | …… | …… |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | DiagnosticSessionControl Response SID | M | 0x50 |
| #2 | sub-function = [ diagnosticSession Type ] | M | 0x00-0xFF |
| #3 …… #6 | sessionParameter Record[] = [data#1 …… data#4] | M …… M | 0x00-0xFF …… 0x00-0xFF |
其中ISO 14229-1给出了sessionParameter Record（会话参数记录）的内容定义
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 #2 #3 #4 | sessionParameter Record[] = [P2Server_max（高字节） P2Server_max（低字节） P2*Server_max（高字节） P2*Server_max（低字节）] | M M M M | 0x00-0xFF 0x00-0xFF 0x00-0xFF 0x00-0xFF |
P2Server_max与P2*Server_max的定义如下
| Parameter | Description | #of bytes | Resolution | minimum value | Maximum value |
| P2Server_max | Default P2Server_max timing supported by the server for the activated diagnostic session | 2 | 1ms | 0ms | 65535ms |
| P2*Server_max | Enhanced (NRC 0x78) P2Server_max supported by the server for the activated diagnostic session | 2 | 10ms | 0ms | 655350ms |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果不支持子功能参数，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 如果不满足请求诊断会话控制的条件，则应发送此NRC | CNC |
（6）在诊断描述文件（.cdd格式）中的依赖性（Dependencies）中可以查看定义的诊断会话转换。（具体查阅CANdelaStudio的使用手册）
（7）抑制肯定响应消息（SPRMIB）在0x10服务中的应用：
在UDS协议中，0x10服务既可以采用物理寻址，也可以采用功能寻址，这取决于具体的应用场景和要切换的会话类型
如果诊断测试仪使用功能寻址的0x10服务进行扩展会话模式切换，它往往不想所有ECU进行响应（为了降低总线负载率），便会发送0x10 83服务请求（SPRMIB位为1），ECU收到此请求后，响应逻辑如下：
①如果ECU可以给出肯定响应，则ECU不发送肯定响应
②如果ECU不接受诊断测试仪的请求，则ECU发送否定响应
2、安全访问（0x27服务）
（1）诊断测试仪可以通过诊断协议访问ECU数据，如果不加以任何安全措施，任意一个“诊断测试仪”都能按照同样的方法访问ECU数据，这显然是很危险的，所以在诊断测试仪访问ECU的数据前，需要进行安全访问。
（2）ECU在上电或复位后会处于锁定状态，诊断测试仪要想读取其中的数据，就需要使用密钥解锁ECU的安全模式，这个过程通过0x27服务实现。
（3）安全访问的步骤：
①诊断测试仪向ECU发出0x27服务请求（向ECU请求种子Seed，种子的长度由原始设备制造商制定）。
②ECU收到0x27服务请求后，向诊断测试仪发回种子Seed，这个种子一般为随机数。
③诊断测试仪收到ECU发回的种子Seed后，根据Seed&Key安全算法（每个项目的安全算法不一定一致）计算Tester端的密钥Key1，再将其发给ECU，Key1应为参数为Seed的种子函数值（即一个Seed不能对应两个Key1）。
④ECU收到密钥Key1后，结合其本地保存的种子Seed、密钥Key1及Seed&Key安全算法计算ECU端的密钥Key2，若Key1与Key2一致，则ECU解锁，否则进入延时。
下图所示为安全等级为m=2n-1时的安全访问流程
如果在收到RequestSeed消息时ECU已经解锁，则ECU应回复包含种子值为0的肯定响应消息（取逆否命题，如果ECU回复的种子值不为0，说明ECU仍未解锁）
（4）安全状态处理：
①ECU在任何时候都只能激活一个安全级别，如果需要切换安全级别，诊断测试仪需再走一遍安全访问流程。
②安全级别编号是任意的，并不意味着级别之间的任何关系。
（5）安全访问请求消息及响应消息的定义：
①请求种子Seed消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | SecurityAcces Request SID | M | 0x27 |
| #2 | sub-function = [ securityAcces Type = requestSeed ] | M | 0x01,0x03,0x05,0x07-0x7D （奇数） |
| #3 …… #n | securityAccesDataRecord[] = [parameter#1 …… parameter#m] 种子参数是服务器发送的数据值，在计算访问安全性所需的密钥时由客户端使用，如果请求消息是在子功能设置为请求服务器种子的值的情况下发送的，则securitySeed数据字节仅存在于响应消息中 | U …… U | 0x00-0xFF …… 0x00-0xFF |
②发送密钥Key消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | SecurityAcces Request SID | M | 0x27 |
| #2 | sub-function = [ securityAcces Type = sendKey ] | M | 0x02,0x04,0x06,0x08-0x7E （偶数） |
| #3 …… #n | securityKey[] = [Key#1（high byte） …… Key#m（low byte）] 请求消息中的“密钥”参数是由对应于特定“种子”值的安全算法生成的值 | M …… U | 0x00-0xFF …… 0x00-0xFF |
③肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | SecurityAcces Response SID | M | 0x67 |
| #2 | sub-function = [ securityAcces Type ] | M | 0x00-0x7F |
| #3 …… #n | securityAccesSeed[] = [seed#1（high byte） …… Seed#m（low byte）] 种子参数是服务器发送的数据值，在计算访问安全性所需的密钥时由客户端使用，如果请求消息是在子功能设置为请求服务器种子的值的情况下发送的，则securitySeed数据字节仅存在于响应消息中 | C …… C | 0x00-0xFF …… 0x00-0xFF |
| C：此参数的存在取决于securityAccessType参数，如果securityAccessType参数指示客户端想要从服务器检索种子，则必须存在 | |||
④否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果不支持子功能参数，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 如果不满足请求安全访问的条件，则应发送此NRC | CNC |
| 0x24 | requestSequenceError 如果在没有收到“requestSeed”请求消息的情况下接收到“sendKey”子功能，则应发送此NRC | RSE |
| 0x31 | requestOutOfRange 如果用户可选的securityAccesDataRecord包含无效数据，则应发送此NRC | ROOR |
| 0x35 | invalidKey 如果收到预期的“sendKey”子功能值并且密钥的值与ECU内部存储/计算的密钥不匹配，则应发送此NRC | IK |
| 0x36 | exceededNumberOfAttempts 如果延迟定时器由于超过允许的最大非法访问尝试次数而处于活动状态，则应发送此NRC | ENOA |
| 0x37 | requiredTimeDelayNOTExpired 如果延迟定时器处于活动状态并发送请求，则应发送此NRC | RTDNE |
（6）在诊断描述文件（.cdd格式）中的依赖性（Dependencies）中可以定义的安全等级转换。（具体查阅CANdelaStudio的使用手册）
3、通信控制（0x28服务）
（1）通信控制用于打开/关闭服务器的某些消息的发送和/或接收，例如应用程序通信消息、网络管理通信消息，在降低总线负载率时可考虑此服务。
（2）通信控制服务交互流程：
（3）通信控制请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | CommunicationControl Request SID | M | 0x28 |
| #2 | sub-function = [ control Type ] | M | 0x00-0xFF |
| #3 | communication Type 此参数用于引用要控制的通信类型，它是位代码值，允许同时控制多种通信类型（编码表请查阅ISO 14229-1） | M | 0x00-0xFF |
| #4 #5 | nodeIdentificationNumber（high byte） nodeIdentificationNumber（low byte） 此参数用于识别车辆某处的子网络上的节点，该节点不能使用较低OSI层1至6的寻值方法来寻值 如果子功能参数control Type设置为0x04或0x05，则此参数存在 | Ca Ca | 0x00-0xFF 0x00-0xFF |
请求消息子功能参数的定义如下所示
| Hex值 | Description | Cvt | Mnemoic |
| 00 | enableRxAndTx 该值表示应为指定的communication Type启用消息的接收和传输 | U | ERXTX |
| 01 | enableRxAndDisableTx 该值表示应启用消息接收，并且应禁用指定的communication Type传输 | U | ERXDTX |
| 02 | enableRxAndEnableTx 该值表示应禁用消息接收，并且应为指定的communication Type启用传输 | U | DRXETX |
| 03 | disableRxAndTx 该值表示应对指定的communication Type禁用消息的接收和发送 | U | DRXTX |
| 04 | enableRxAndDisableTxWithEnhancedAddressInformation 该值表示寻址的总线主控器应将相关的子总线段切换到仅诊断调度模式 | U | ERXDTXWEAI |
| 05 | enableRxAndTxWithEnhancedAddressInformation 该值表示寻址的总线主控器应将相关的子总线段切换到应用程序调度模式 | U | ERXTXWEAI |
| 06-3F | ISOSAReserved 保留值范围，用于将来定义 | M | ISOSAERESRVD |
| 40-5F | vehicleManufactureSpecific 该值范围保留，供车辆制造商特定用途 | U | VMS |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | CommunicationControl Response SID | M | 0x68 |
| #2 | sub-function = [ communication Type ] | M | 0x00-0x7F |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果不支持子功能参数，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 在服务器处于关键的正常模式（inacritical nomal mode）活动时使用，因此无法禁用/启用请求的通信类型 | CNC |
| 0x31 | requestOutOfRange 如果ECU检测到communication Type或nodeIdentificationNumber参数中有错误，则应发送此NRC | ROOR |
（4）应用举例：
①禁用网络管理消息的发送。
请求消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Request SID | 0x28 |
| #2 | control Type = enableRXAndDisableTx suppressPosRspMsgIndicationBit = FALSE | 0x01 |
| #3 | communication Type = network management | 0x02 |
响应消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Response SID | 0x68 |
| #2 | ControlType = enableRXAndDisableTx suppressPosRspMsgIndicationBit = FALSE | 0x01 |
②将远程网络切换到仅诊断调度模式，其中连接了地址为0x000A的节点。
请求消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Request SID | 0x28 |
| #2 | control Type = enableRxAndDisableTxWithEnhancedAddressInformation suppressPosRspMsgIndicationBit = FALSE | 0x04 |
| #3 | communication Type = normal messages | 0x01 |
| #4 | nodeIdentificationNumber（high byte） | 0x00 |
| #5 | nodeIdentificationNumber（low byte） | 0x0A |
响应消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Response SID | 0x68 |
| #2 | control Type = enableRxAndDisableTxWithEnhancedAddressInformation suppressPosRspMsgIndicationBit = FALSE | 0x04 |
③切换到具有增强的地址信息的应用程序调度模式，连接到子网络的节点0x000A。
请求消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Request SID | 0x28 |
| #2 | control Type = enableRxAndTxWithEnhancedAddressInformation suppressPosRspMsgIndicationBit = FALSE | 0x05 |
| #3 | communication Type = normal messages | 0x01 |
| #4 | nodeIdentificationNumber（high byte） | 0x00 |
| #5 | nodeIdentificationNumber（low byte） | 0x0A |
响应消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Response SID | 0x68 |
| #2 | control Type = enableRxAndTxWithEnhancedAddressInformation suppressPosRspMsgIndicationBit = FALSE | 0x05 |
④在进行ECU软件刷写前，首先请求ECU进入扩展诊断会话模式，为了尽可能地降低网络的通信负载率，需要禁止ECU向总线发送非诊断信息，包括网络管理通信消息和正常通信消息。
请求消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Request SID | 0x28 |
| #2 | control Type = enableRXAndDisableTx suppressPosRspMsgIndicationBit = FALSE | 0x01 |
| #3 | communication Type = network management and normal communication | 0x03 |
响应消息流：
| A_Data byte | Parameter Name | Byte Value |
| #1 | CommunicationControl Response SID | 0x68 |
| #2 | ControlType = enableRXAndDisableTx suppressPosRspMsgIndicationBit = FALSE | 0x01 |
4、待机握手（0x3E服务）
（1）0x3E服务用于周期性地向ECU（或多个ECU）指示诊断测试仪仍然连接到ECU，并且先前已激活的某些诊断服务和/或通信将保持活动。
（2）测试仪在线请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | TesterPresent Request SID | M | 0x3E |
| #2 | sub-function = [ zeroSubFunction ] | M | 0x00/0x80 |
请求消息子功能参数的定义如下所示
| Hex值 | Description | Cvt | Mnemoic |
| 00 | zeroSubFunction 该参数值用于指示此服务不支持suppressPosRspMsgIndicationBit旁边的子功能值 | M | ZSUBF |
| 01-7F | ISOSAEReserved 此值范围保留 | M | ISOSAERESRVD |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | TesterPresent Response SID | M | 0x7E |
| #2 | sub-function = [ zeroSubFunction ] | M | 0x00 |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果不支持子功能参数，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
5、控制故障码设置（0x85服务）
（1）0x85服务用于请求停止或恢复单个ECU或一组ECU中DTC状态位的更新。
（2）DTC控制服务交互流程：
（3）控制故障码设置请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | Control DTC Setting Request SID | M | 0x85 |
| #2 | sub-function = [ DTCSetting Type ] | M | 0x00-0xFF |
| #3 …… #n | DTCSettingControlOptionRecord[] = [parameter#1 …… parameter#m] 当控制DTC状态位的更新时，该参数记录是用户可选的，用于将数据发送到服务器，例如，它可以包含要打开或关闭的DTC列表 | U …… U | 0x00-0xFF …… 0x00-0xFF |
请求消息子功能参数的定义如下所示
| Hex值 | Description | Cvt | Mnemoic |
| 00 | ISOSAEReserved 此值保留 | M | ISOSAERESRVD |
| 01 | on ECU应根据正常操作条件恢复故障诊断代码状态位的更新 | M | ON |
| 02 | off ECU应停止更新诊断故障代码状态位 | M | OFF |
| 03-3F | ISOSAEReserved 此值范围保留 | M | ISOSAERESRVD |
| 40-5F | vehicleManufactureSpecific 此值范围供车辆制造商特定用途 | U | VMS |
| 60-7E | systemSupplierSpecific 此值范围保留给系统供应商特定用途 | U | SSS |
| 7F | ISOSAEReserved 此值保留 | M | ISOSAERESRVD |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | Control DTC Setting Response SID | M | 0xC5 |
| #2 | DTCSetting Type | M | 0x00-0x7F |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果不支持子功能参数，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect ECU无法执行请求的DTC控制功能，则应发送此NRC | CNC |
| 0x31 | requestOutOfRange 如果ECU检测到DTCSettingControlOptionRecord存在错误，则应发送此NRC | ROOR |
6、按标识符读取数据（0x22服务）
（1）0x22服务支持诊断测试仪根据DID读取ECU数据（例如ECU应用程序的内部量、系统状态信息、版本号等），也就是说，每一个DID（dataIdentifier，双字节参数，标识诊断测试仪请求的ECU数据）都会一一对应ECU中的一个数据，具体对应关系由系统供应商/车辆制造商定义。
（2）诊断测试仪读取ECU数据流程：
①一次0x22服务请求可请求多个DID，当然请求的个数是有上限的，ECU会根据每个DID一一将诊断测试仪请求的数据回复。
②读取数据前需完成安全访问，将ECU解锁。
（3）按标识符读取数据请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | ReadDataByIdentifier Request SID | M | 0x22 |
| #2 #3 | dataIdentifier[]#1 = [byte#1(MSB), byte#2] | M M | 0x00-0xFF 0x00-0xFF |
| …… | …… | …… | …… |
| #n-1 #n | dataIdentifier[]#(n-1)/2 = [byte#1(MSB), byte#2] | M M | 0x00-0xFF 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | ReadDataByIdentifier Response SID | M | 0x62 |
| #2 #3 | dataIdentifier[]#1 = [byte#1(MSB), byte#2] | M M | 0x00-0xFF 0x00-0xFF |
| #4 …… #(k-1)+4 | dataRecord[]#1 = [data#1 …… data#k] | M …… U | 0x00-0xFF …… 0x00-0xFF |
| …… | …… | …… | …… |
| #n-(o-1)-2 #n-(o-1)-1 | dataIdentifier[]#m = [byte#1(MSB), byte#2] | U U | 0x00-0xFF 0x00-0xFF |
| #n-(o-1) …… #n | dataRecord[]#m = [data#1 …… data#o] | U …… U | 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，或诊断测试仪超过允许一次请求的最大DID数，则应发送此NRC | IMLOIF |
| 0x14 | responseTooLong 如果响应消息的总长度超过基础传输协议的限制（例如在单个请求中请求过多DID），则应发送此NRC | TRL |
| 0x22 | conditionsNotCorrect 不满足ECU的操作条件，则应发送此NRC | CNC |
| 0x31 | requestOutOfRange 如果设备不支持所请求的DID，比如当前会话中不支持任何请求的DID，或者所请求的DID尚未分配，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果至少有一个DID受到保护，且ECU处于未解锁状态，则应发送此NRC | SAD |
7、按标识符写入数据（0x2E服务）
（1）0x2E服务支持诊断测试仪根据DID向ECU写入数据，同样的，每一个DID（dataIdentifier，双字节参数，标识诊断测试仪请求写入ECU的数据，如VIN编号）都会一一对应ECU中的一个数据，具体对应关系由系统供应商/车辆制造商定义，有时候ECU会限制或禁止对某些DID值的写访问。
（2）诊断测试仪向ECU写入数据流程：
①一次0x2E服务请求只可请求一个DID，ECU会根据DID将诊断测试仪请求的数据写入。
②写入数据前需完成安全访问，将ECU解锁。
（3）按标识符写入数据请求消息及响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | WriteDataByIdentifier Request SID | M | 0x2E |
| #2 #3 | dataIdentifier[]#1 = [byte#1(MSB), byte#2] | M M | 0x00-0xFF 0x00-0xFF |
| #4 #m+3 | dataRecord[]#1 = [data#1 …… data#m] | M …… U | 0x00-0xFF 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Cvt | Byte Value |
| #1 | WriteDataByIdentifier Response SID | M | 0x6E |
| #2 #3 | dataIdentifier[]#1 = [byte#1(MSB), byte#2] | M M | 0x00-0xFF 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 不满足ECU的操作条件，则应发送此NRC | CNC |
| 0x31 | requestOutOfRange 如果设备不支持所请求的DID，或者所请求的DID只可读不可写，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果引用特点地址的DID受到保护，且ECU处于未解锁状态，则应发送此NRC | SAD |
| 0x72 | generalProgrammingFailure 如果ECU在写入内存位置时检测到错误，则应发送此NRC | GPF |
8、读故障码（0x19服务）
（1）0x19服务支持诊断测试仪读取ECU记录的诊断故障代码DTC，该服务有28种子功能，常用的有如下4种。
①02号子功能：通过DTC状态掩码（DTCStatusMask）读取DTC。
②04号子功能：读取DTC快照数据（DTCSnapshotData）记录（故障发生时的环境数据）。
③06号子功能：读取DTC扩展数据（DTCExtendedData）记录（服务执行时的环境数据）。
④0A号子功能：读取ECU内支持的所有DTC和相应状态的列表。
（2）常用子功能介绍及其请求消息和响应消息的定义：
①通过DTC状态掩码（DTCStatusMask）读取DTC：
ECU内部往往存储了非常多DTC，但是诊断测试仪有时只需要分析处于特定状态的DTC，那么它就可以通过状态掩码筛选出特定状态的DTC，让ECU进行回复
通过DTC状态掩码（DTCStatusMask）读取DTC的流程如下：
[1]SM——StatusMask（状态掩码），SAM——StatusAvailabilityMask（状态可用掩码）
[2]ECU筛选DTC的原则为——满足（(statusOdDTC & DTCStatusMask) != 0）的所有DTC
[3]除了statusOfDTC的第7位“warningIndicatorRequested”以外，ECU支持所有状态位屏蔽
请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Request SID | 0x19 |
| #2 | sub-function = reportDTCByStatusMask suppressPosRspMsgIndicationBit = FALSE | 0x02 |
| #3 | DTCStatusMask | 0x00-0xFF |
肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Response SID | 0x59 |
| #2 | reportType = reportDTCByStatusMask | 0x02 |
| #3 | DTCStatusAvailabilityMask | 0x00-0x7F |
| #4 #5 #6 #7 | DTCAndStatusRecord#1[DTCHighByte] DTCAndStatusRecord#1[DTCMiddleByte] DTCAndStatusRecord#1[DTCLowByte] DTCAndStatusRecord#1[statusOfDTC] | 0x00-0xFF 0x00-0xFF 0x00-0xFF 0x00-0xFF |
| …… | …… | …… |
| #n*4 #1+n*4 #2+n*4 #3+n*4 | DTCAndStatusRecord#n[DTCHighByte] DTCAndStatusRecord#n[DTCMiddleByte] DTCAndStatusRecord#n[DTCLowByte] DTCAndStatusRecord#n[statusOfDTC] | 0x00-0xFF 0x00-0xFF 0x00-0xFF 0x00-0xFF |
②读取DTC快照数据（DTCSnapshotData）记录：
在分析故障原因时，往往需要获取故障发生时刻的一些数据，对此ECU会在记录DTC时将故障发生时的环境数据也一并记录，将这个称之为快照，诊断测试仪可以请求读取之，让ECU进行回复
一个DTC可能有多组快照数据，由于存储空间有限，ECU只能支持有限个数的快照数据，当快照 数据的数量溢出时，取舍策略由制造商定义，而诊断测试仪在请求快照数据时，也需指出请求哪一组快照，用DTCSnapshotRecordNumber标识，编号策略也由制造商定义
一组快照数据可能包含多个数据标识符（DID）及其对应的数据，ECU在回复快照数据时，需用DTCSnapshotRecordNumberOfIdentifiers标识回复的快照数据中包含了多少个数据标识符（DID）及对应数据
读取DTC快照数据（DTCSnapshotData）记录的流程如下：
请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Request SID | 0x19 |
| #2 | sub-function = reportDTCSnapshotRecordByDTCNumber suppressPosRspMsgIndicationBit = FALSE | 0x04 |
| #3 #4 #5 | DTCMaskRecord#[DTCHighByte] DTCMaskRecord#[DTCMiddleByte] DTCMaskRecord#[DTCLowByte] | 0x00-0xFF 0x00-0xFF 0x00-0xFF |
| #6 | DTCSnapshotRecordNumber | 0x00-0xFF |
肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Response SID | 0x59 |
| #2 | reportType = reportDTCSnapshotRecordByDTCNumber | 0x04 |
| #3 #4 #5 #6 | DTCAndStatusRecord#[DTCHighByte] DTCAndStatusRecord#[DTCMiddleByte] DTCAndStatusRecord#[DTCLowByte] DTCAndStatusRecord#[statusOfDTC] | 0x00-0x7F 0x00-0x7F 0x00-0x7F 0x00-0x7F |
| #7 | DTCSnapshotRecordNumber | 0x00-0xFF |
| #8 | DTCSnapshotRecordNumberOfIdentifiers | 0x00-0xFF |
| #9 #10 | dataIdentifier1 [byte#1](MSB) dataIdentifier1 [byte#2](LSB) | 0x00-0xFF 0x00-0xFF |
| #11 #12 #13 …… | DTCSnapshotRecord1[data#1] DTCSnapshotRecord1[data#2] DTCSnapshotRecord1[data#3] …… | 0x00-0xFF 0x00-0xFF 0x00-0xFF …… |
| …… | …… | …… |
③读取DTC扩展数据（DTCExtendedData）记录：
在分析故障原因时，可能还需要获取故障发生次数等数据，对此ECU可以为故障创建故障计数器，将其作为DTC扩展数据（DTCExtendedData）存储，诊断测试仪可以请求读取之，让ECU回复当前DTC扩展数据的存储内容
读取DTC扩展数据（DTCExtendedData）记录的流程如下：
请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Request SID | 0x19 |
| #2 | sub-function = reportDTCExtDataRecordByDTCNumber suppressPosRspMsgIndicationBit = FALSE | 0x06 |
| #3 #4 #5 | DTCMaskRecord#[DTCHighByte] DTCMaskRecord#[DTCMiddleByte] DTCMaskRecord#[DTCLowByte] | 0x00-0xFF 0x00-0xFF 0x00-0xFF |
| #6 | DTCExtendedDataNumber 【0xFF通常用于请求所有DTC扩展数据】 | 0x00-0xFF |
肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Response SID | 0x59 |
| #2 | reportType = reportDTCExtDataRecordByDTCNumber | 0x06 |
| #3 #4 #5 #6 | DTCAndStatusRecord#[DTCHighByte] DTCAndStatusRecord#[DTCMiddleByte] DTCAndStatusRecord#[DTCLowByte] DTCAndStatusRecord#[statusOfDTC] | 0x00-0x7F 0x00-0x7F 0x00-0x7F 0x00-0x7F |
| #7 #8 …… #7+n | DTCExtendedDataNumber1 DTCExtendedDataRecord1[byte#1] …… DTCExtendedDataRecord1[byte#n] | 0x00-0xFF 0x00-0xFF …… 0x00-0xFF |
| #8+n #9+n …… #8+n+m | DTCExtendedDataNumber2 DTCExtendedDataRecord2[byte#1] …… DTCExtendedDataRecord2[byte#m] | 0x00-0xFF 0x00-0xFF …… 0x00-0xFF |
| …… | …… | …… |
④读取ECU内支持的所有DTC和相应状态的列表：
读取ECU内支持的所有DTC和相应状态的列表的流程如下：
请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Request SID | 0x19 |
| #2 | sub-function = reportSupportedDTCs suppressPosRspMsgIndicationBit = FALSE | 0x0A |
肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Read DTC Information Response SID | 0x59 |
| #2 | reportType = reportSupportedDTCs | 0x06 |
| #3 | DTCStatusAvailabilityMask | 0x7F |
| #4 #5 #6 #7 | DTCAndStatusRecord#1[DTCHighByte] DTCAndStatusRecord#1[DTCMiddleByte] DTCAndStatusRecord#1[DTCLowByte] DTCAndStatusRecord#1[statusOfDTC] | 0x00-0x7F 0x00-0x7F 0x00-0x7F 0x00-0x7F |
| #8 #9 #10 #11 | DTCAndStatusRecord#2[DTCHighByte] DTCAndStatusRecord#2[DTCMiddleByte] DTCAndStatusRecord#2[DTCLowByte] DTCAndStatusRecord#2[statusOfDTC] | 0x00-0x7F 0x00-0x7F 0x00-0x7F 0x00-0x7F |
| …… | …… | …… |
9、清除诊断信息（0x14服务）
（1）当ECU的故障恢复后，DTC不会自动被清除，往往需要满足某些条件（如整车点火循环大于40次）才会清除，要想先把DTC清除，可以用诊断测试仪向ECU请求0x14服务。
（2）诊断测试仪清除ECU诊断信息流程：
（3）清除诊断信息请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Clear Diagnostic Information Request SID | 0x14 |
| #2 #3 #4 | groupOfDTC = [groupOfDTCHighByte groupOfDTCMiddleByte groupOfDTCLowByte] 表示DTC组（例如动力总成、车身、底盘等）或要清除的特定DTC | 0x00-0xFF 0x00-0xFF 0x00-0xFF |
groupOfDTC的定义和DTC号码的范围如下
| Byte Value | Description | Cvt |
| 0x000000-0x0000FF | 保留 | M |
| 0x000100-0x0xFFFEFF | 由车辆制造商决定 | U |
| 0xFFFF00-0xFFFFFE | 参照ISO 14229-1 | M |
| 0xFFFFFF | All Groups（all DTCs） | M |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Clear Diagnostic Information Response SID | 0x54 |
10、按标识符控制输入输出（0x2F服务）
（1）如果希望使用诊断测试仪控制ECU的输入输出（比如控制ECU的某个引脚输出一个指定频率、指定幅值和指定占空比的电流），则可使用0x2F服务，根据DID与ECU数据的对应关系请求控制ECU的输入输出，当然，该服务只能应用于一些简单的控制，不可能替代应用功能程序。
（2）按标识符的输入输出控制ECU的流程：
（3）按标识符的输入输出控制请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Input Output Control Byldentifier Request SID | 0x2F |
| #2 #3 | dataIdentifier[] = [byte#1(MSB) byte#2(LSB)] 该参数标识ECU本地输入信号/内部参数/输出信号 | 0x00-0xFF 0x00-0xFF |
| #4 …… #4+m-1 | controlOptionRecord[] = [inputOutputControlParameter controlState#1 …… controlState#m] 参照ISO 14229-1 | 0x00-0xFF 0x00-0xFF …… 0x00-0xFF |
| #4+m …… #4+m+r-1 | controlEnableMaskRecord#1[] = [controlMask#1 …… controlMask#r] 只有当要控制的DID包含多个参数，才支持该参数，controlEnableMaskRecord中应该有一位对应于DID中定义的每个单独参数 controlEnableMaskRecord中每个位的值应确定DID中的相应参数是否会受到请求的影响，controlEnableMaskRecord中的位值“0”表示相应的参数不受此请求的影响，位值“1”表示相应的参数受此请求的影响 ControlMask#1的最高有效位应对应于ControlState中的第一个参数，从ContralState#1的最高有效位开始，ControlMash#1的第二个最高有效位应对应于ControdState中的第二个参数，并继续以这种方式利用尽可能多的ControIMask字节来掩盖所有参数，例如，ControlMask#2的最低有效位将对应于controlState中的第16个参数。 对于位图DID，不支持的位也应在controlEnableMaskRecord中有相应的位，以便每个掩码位的位置 controlCnableMaskRecord中的参数应与controlState中相应参数的位置完全匹配 | 0x00-0xFF …… 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Input Output Control Byldentifier Response SID | 0x6F |
| #2 #3 | dataIdentifier[] = [byte#1(MSB) byte#2(LSB)] 该参数标识ECU本地输入信号/内部参数/输出信号 | 0x00-0xFF 0x00-0xFF |
| #4 #5 …… #5+m-1 | controlStatusRecord[] = [inputOutputControlParameter contorlState#1 …… contorlState#m] 参照ISO 14229-1 | 0x00-0xFF 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect ECU无法执行请求的输入输出控制功能，则应发送此NRC | CNC |
| 0x31 | requestOutOfRange 如果ECU检测到DID存在错误，或者inputOutputControlParameter中存在无效值，或者controlOptionRecord记录的一个或多个适用的controlState值无效，或者设备不支持在controlEnableMaskRecord中启用控制的位组合，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果诊断测试仪发送带有有效安全DID的请求，且ECU的安全功能当前处于活动状态，则应发送此NRC | SAD |
11、例程控制（0x31服务）
（1）如果希望使用诊断测试仪控制ECU执行指定的一系列动作并获得结果，比如擦除存储器、运行自检、ECU软件下载后的编程依赖性检查等，则可使用0x31服务，每“一系列动作”各自对应一个RID（Routine Identifier，例程标识符）。
（2）例程控制的步骤：
①诊断测试仪向ECU请求0x31 01服务，即请求开始例程。
②诊断测试仪向ECU请求0x31 03服务，即请求例程结果。
③诊断测试仪得到例程结果后，向ECU请求0x31 02服务，即请求结束例程。
（3）例程控制请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Routine Control Request SID | 0x31 |
| #2 | sub-function = [ routineControl Type ] | 0x00-0xFF |
| #3 #4 | routineIdentifier[] = [byte#1(MSB) byte#2(LSB)] | 0x00-0xFF 0x00-0xFF |
| #5 …… #n | routineControlOptionRecord[] = [routineControlOption#1 …… routineControlOption#m] 可选参数，用于子功能startRoutine和stopRoutine 可通过参数记录配置例程入口选项参数，选择指定例程的开始条件，或者配置例程退出选项参数，选择指定例程的停止条件 | 0x00-0xFF …… 0x00-0xFF |
请求消息子功能定义如下
| Hex值 | Description | Cvt | Mnemoic |
| 00 | ISOSAEReserved 此值范围保留 | M | ISOSAERESRVD |
| 01 | startRoutine 此参数指定ECU应启动RID指定的例程 | M | STR |
| 02 | stopRoutine 此参数指定ECU应停止RID指定的例程 | U | STPR |
| 03 | requestRoutineResults 此参数指定ECU应返回RID指定的例程的结果值 | U | RRR |
| 04-7F | ISOSAEReserved 此值范围保留 | M | ISOSAERESRVD |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Routine Control Response SID | 0x71 |
| #2 | routineControl Type | 0x00-0x7F |
| #3 #4 | routineIdentifier[] = [ byte#1(MSB) byte#2(LSB) ] | 0x00-0xFF 0x00-0xFF |
| #5 | routineInfo 该字节的定义留给车辆制造商（可选参数），并且为车辆制造商提供一种机制，以给予该返回值支持所有实现的例程的通用外部测试设备处理 | 0x00-0xFF |
| #6 …… #n | routineStatusRecord[] = [routineStatus#1 …… routineStatus#m] 用于返回例程执行后的状态或结果数据，其长度和内容完全由例程预先定义 | 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x12 | sub-functionNotSupported 如果所请求的子功能不受支持或者不被请求的RID支持，则应发送此NRC | SFNS |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 如果不满足请求例程控制的条件，则应发送此NRC | CNC |
| 0x24 | requestSequenceError 满足以下几种情况之一，则应发送此NRC A. 例程当前处于活动状态，并且在收到“startRoutine”子功能时无法重新启动（由车辆制造商决定是否可以在激活时重新启动给定的例程） B. 当收到“stopRoutine”子功能时，例程当前不活动 C. 当收到“requestRoutineResults”子功能时，例程结果不可用 | RSE |
| 0x31 | requestOutOfRange 如果ECU不支持所请求的RID，或者用户可选的routineControlOptionRecord包含无效数据，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果诊断测试仪发送带有有效安全RID的请求，且ECU的安全功能当前处于活动状态，则应发送此NRC | SAD |
| 0x72 | generalProgrammingFailure 如果ECU在执行访问ECU内部存储器的例程时检测到错误，则应发送此NRC | GPF |
（4）例程控制常用于请求ECU执行软件刷写操作，该操作需配合0x34服务、0x36服务和0x37服务，如下为请求软件刷写的流程示意。
（5）ISO 14229-1定义的RID：
①RID范围定义：
| RID范围 | 类型 | 描述 |
| 0x0000-0x00FF | ISO/SAE保留 | 为ISO/SAE未来标准化预留，通常不使用 |
| 0x0100-0x01FF | 行车记录仪测试ID | 分配给与行车记录仪相关的例程 |
| 0x0200-0xDFFF | 汽车制造商定义 | 由OEM根据车辆/系统特定需求自行定义 |
| 0xE000-0xE1FF | OBD测试ID | 预留用于OBD/EOBD相关的例程 |
| 0xE200-0xE2FF | 安全系统例程 | 通常用于报废车辆时引爆安全设备的例程 |
| 0xE300-0xEFFF | ISO/SAE保留 | 为ISO/SAE未来标准化预留，通常不使用 |
| 0xF000-0xFEFF | 系统供应商自定义 | 由系统供应商根据系统特定需求自行定义 |
| 0xFF00-0xFEFF | ISO/SAE定义&保留 | 见下表 |
②标准中预定义的特定RID：
| RID | ISO 14229-1定义 | 描述 |
| 0xFF00 | eraseMemory | 擦除内存，在ECU刷写前，擦除指定的Flash区域 |
| 0xFF01 | checkProgrammingDependencies | 检查编程依赖性关系，在刷写前或刷写后，验证所有条件是否满足 |
| 0xFF02-0xFFFF | ISO/SAE保留 | 为ISO/SAE未来标准化预留 |
12、请求下载（0x34服务）
（1）如果希望使用诊断测试仪对ECU执行软件刷写操作，则可使用0x34服务，请求ECU将程序下载到其Flash指定区域中。需要注意的是，0x34服务报文仅用于指定刷写的位置，需要写进Flash中的内容由0x36服务报文传输。
（2）请求下载请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Request Download Request SID | 0x34 |
| #2 | dataFormatIdentifier 该参数每个半字节分别编码，高半字节指定压缩方法，低半字节指定加密方法 | 0x00-0xFF |
| #3 | addressAndLengthFormatIdentifier 该参数每个半字节分别编码，高半字节指定memorySize的长度，低半字节指定memoryAddress的长度 | 0x00-0xFF |
| #4 …… #(m-1)+4 | memoryAddress[] = [byte#1(MSB) …… byte#m] 该参数指定要写入数据的ECU内存的起始地址 | 0x00-0xFF …… 0x00-0xFF |
| #n-(k-1) …… #n | memorySize[] = [byte#1(MSB) …… byte#m] 该参数指定传输的数据总量（或者说期望刷写的存储器空间大小），用于与ECU内存大小比较 | 0x00-0xFF …… 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Request Download Response SID | 0x74 |
| #2 | lengthFormatIdentifier 该参数每个半字节分别编码，高半字节指定maxNumberOfBlockLength的长度，低半字节预留，设置为“0” | 0x00-0x7F |
| #3 …… #n | maxNumberOfBlockLength = [byte#1(MSB) …… byte#m] 该参数用于通知诊断测试仪在每个0x36服务请求消息中应包含多少数据字节（也能理解为BootLoader的接收能力上限） | 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 如果ECU在接收软件或校准模块的下载过程中收到对此服务的请求（在下载期间ECU和Tester之间的数据大小不匹配，则可能发生这种情况），则应发送此NRC | CNC |
| 0x31 | requestOutOfRange 如果指定的dataFormatIdentifier无效，或者指定的addressAndLengthFormatIdentifier无效，或者指定的memoryAddress/memorySize无效，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果ECU的安全功能当前处于活动状态，则应发送此NRC | SAD |
| 0x70 | uploadDownloadNotAccepted 发生某些故障情况，导致无法完成软件下载到ECU内存的工作，应发送此NRC | UDNA |
13、数据传输（0x36服务）
（1）0x36服务通常配合0x34服务使用，用于向ECU传送二进制形式的软件。
（2）传输数据请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Transfer Data Request SID | 0x36 |
| #2 | blockSequenceCounter 参数值从0x01开始，对于每个后续的0x36服务请求，该参数值递增1，直到计数至0xFF后，参数翻转为0x00，下个0x36服务请求，该参数值继续递增1，用于ECU识别可能存在的“丢包”现象 | 0x00-0xFF |
| #3 …… #n | transferRequestParameterRecord[] = [transferRequestParameter#1 …… transferRequestParameter#m] 0x36服务请求传输的数据 | 0x00-0xFF …… 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Transfer Data Response SID | 0x76 |
| #2 | blockSequenceCounter | 0x00-0x7F |
| #3 …… #n | transferResponseParameterRecord[] = [transfeResponseParameter#1 …… transferResponseParameter#m] 具体由OEM定义，可以是ECU计算的校验和等 | 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x22 | conditionsNotCorrect 如果ECU不满足接收数据的条件，则应发送此NRC | CNC |
| 0x24 | requestSequenceError ECU识别到请求序列错误，比如0x34服务请求未响应就发出0x36服务请求，则应发送此NRC | RSE |
| 0x31 | requestOutOfRange 如果指定的blockSequenceCounter无效，或者指定的transferRequestParameterRecord无效，则应发送此NRC | ROOR |
| 0x33 | securityAccessDenied 如果ECU的安全功能当前处于活动状态，则应发送此NRC | SAD |
| 0x71 | transferDataSuspended 在将接收到的数据写入非易失性存储器（如Flash）时发生错误（如写入失败、校验错误），则应发送此NRC | TDS |
| 0x72 | blockSequenceCounterError 收到的blockSequenceCounter 值与ECU期望的下一个序列号不匹配，则应发送此NRC | BSCE |
14、请求传输退出（0x37服务）
（1）0x37服务通常配合0x34服务使用，用于终止传输流程。
（2）请求传输退出请求消息和响应消息的定义：
①请求消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Request Transfer Exit Request SID | 0x37 |
| #2 …… #n | transferRequestParameterRecord[] = [transferRequestParameter#1 …… transferRequestParameter#m] 传输终止的结束参数，如校验和，可根据实际情况选择是否需要 | 0x00-0xFF …… 0x00-0xFF |
②肯定响应消息定义：
| A_Data byte | Parameter Name | Byte Value |
| #1 | Request Transfer Exit Response SID | 0x77 |
| #2 …… #n | transferResponseParameterRecord[] = [transfeResponseParameter#1 …… transferResponseParameter#m] 传输终止的结束参数，如校验和，可根据实际情况选择是否需要 | 0x00-0xFF …… 0x00-0xFF |
③否定响应代码NRC定义：
| NRC Hex值 | Description | Mnemoic |
| 0x13 | incorrectMessageLengthOrInvalidFormat 如果消息的长度错误，则应发送此NRC | IMLOIF |
| 0x24 | requestSequenceError 如果收到此服务请求时，编程过程未完成，则应发送此NRC | RSE |
| 0x31 | requestOutOfRange 如果指定的transferRequestParameterRecord无效，则应发送此NRC | ROOR |
| 0x72 | blockSequenceCounterError 如果ECU在最终确定Tester和ECU之间的数据传输时检测到错误，则应发送此NRC | BSCE |
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
