总目录：（单击下方链接皆可跳转至专栏总目录）
《UDS/OBD诊断&诊断描述文件CDD》总目录
https://blog.csdn.net/qfmzhu/article/details/120425660
目录
4 ISO 15765-4中“P2CAN和P2*CAN”应用时序参数定义
6.1 ISO 15765-4 - 在P2时序内不可用的数据或无法在P2时序内执行服务
6.2 数据不可用—协议的测试条件：ISO 15765-4通过CAN的诊断通信
0 前言
ISO 15031（OBD诊断协议）由以下Part组成，总称为“Road vehicles - Communication between vehicle and external equipment for emissions-related diagnostics道路车辆-车辆与外部设备之间的排放相关诊断通信”：
- Part 1: General information and use case definition一般信息和用例定义
- Part 2: Guidance on terms, definitions, abbreviations and acronyms术语，定义，缩写和首字母缩写的指南
- Part 3: Diagnostic connector and related electrical circuits, specification and use诊断连接器和相关电路，规范和用途
- Part 4: External test equipment外部测试设备
- Part 5: Emissions-related diagnostic services与排放相关的诊断服务
- Part 6: Diagnostic trouble code definitions故障诊断代码定义
- Part 7: Data link security数据链路安全
这些Part加在一起提供了一套连贯一致的规范，以促进与排放相关的诊断。ISO 15031-1介绍了该系列国际标准。
ISO 15031-2到ISO 15031-7基于SAE J1979推荐的作法（其中ISO 15031-5基于SAE J1979）。
为此，它基于符合ISO/IEC 7498-1和ISO/IEC 10731的开放系统互连(OSI：Open Systems Interconnection)基本参考模型，该模型将通信系统分为七层。
当映射到这个模型上时，本国际标准规定的服务按照下表分为以下层次。
| Applicability 适用性 | OSI 7 layers | Emissions-related OBD communication requirements 与排放相关的OBD通信需求 | Emissions-related WWH-OBD communication requirements 与排放相关的WWH-OBD通信需求 | ||||||
| Seven layers according to ISO/IEC 7498-1 and ISO/IEC 10731 | Application (layer 7) | ISO 15031-5/SAE J1979 | ISO 27145-3 | ||||||
| Presentation (layer 6) | ISO 15031-2, ISO 15031-5, ISO 15031-6 | ISO 27145-2 | |||||||
| SAE J1930-DA, SAE J1979-DA, SAE J2012-DA | SAE J1930-DA, SAE J1979-DA, SAE J2012-DA | ||||||||
| Session (layer 5) | Not applicable | ISO 14229-2 | |||||||
| Transport (layer 4) | ISO 15031-5 | ISO 14230-4 | ISO 15765-2 | ISO 15765-4 | ISO 15765-2 | ISO 15765-4 | ISO 13400-2 | ||
| Network (layer 3) | |||||||||
| Data link (layer 2) | SAE J1850 | ISO 9141-2 | ISO 14230-2 | ISO 11898-1, ISO 11898-2 | ISO 11898-1, ISO 11898-2 | ISO 13400-3 | |||
| Physical (layer 1) | ISO 14230-1 | ||||||||
| a World-Wide Harmonized. | |||||||||
OBD法规要求乘用车和轻型、中型和重型卡车为外部（非车载）“通用”测试设备提供一个最少的诊断信息集。
1 OBD诊断中“术语”的定义
absolute throttle position sensor节气门绝对位置传感器
用于表示节气门开度的值。
注：对于输出与输入电压成比例的系统，此值为最大输入信号的百分比。对于输出与输入电压成反比的系统，该值为100％减去最大输入信号的百分比。空转/怠速时的节气门位置通常指示大于0%，而节气门全开时的节气门位置通常指示小于100%。
bank气缸
共用一个控制传感器的特定气缸组。
注1：气缸组1始终包含气缸#1，气缸#2始终包含相反的气缸组。
注2：如果只有一个气缸组，则使用气缸组＃1 DTC，并可省略“气缸组”一词。对于使用多个传感器的单个“气缸组”系统，气缸组1的DTC用于识别传感器为#1、#2和#3，以便它们远离气缸。
base fuel schedule基本燃油表
燃油标定计划在制造时或由车外源更新时编入动力总成控制模块或PROM中，在任何学习的车载校正之前。
CALID：calibration identifier标定标识符
服务器/电子控制单元（ECU）中包含的用于特定软件/标定的识别码。
注：如果法规要求排放相关软件的标定标识，则应以SAE J1979-DA中规定的标准化格式报告这些标识。
CVN：calibration verification number标定验证码
服务器/ECU计算的标定标识号的验证号，以验证服务器/ECU中包含的软件/标定的完整性。
注：如果法规要求有关排放的软件的标定标识，则应以ISO 15031-2中规定的标准格式进行报告。
calculated load value计算的负载值
“火花点火式车辆”通常表示当前气流除以全开节气门时的峰值气流作为rpm的函数，其中气流根据海拔和环境温度进行校正。
注1：火花点火和压缩点火车辆都可以使用替代定义，在计算中用发动机扭矩代替气流。
注2：该定义提供了一个数字（不带单位），并为维修技术人员提供了正在使用的发动机容量百分比的指示。
client客户端
该功能是测试仪的一部分，并利用诊断服务。
注：测试人员通常会使用其他功能，例如数据库管理、特定解释和人机界面。
continuous monitoring连续监视
每秒不少于两个样本的采样率。
注：如果出于控制目的，对计算机输入的采样频率较低，则可以在每次采样发生时评估组件的信号。
Cvt：convention惯例
列集成在每个消息表中，标记包含的每个参数。
注：使用以下约定：
C = Conditional有条件的：请求/响应消息中标记为“C”的参数仅在消息表底行指定的条件下出现；
M = Mandatory强制性：请求/响应消息表中标记为“M”的参数始终存在；
U = User(optional)用户（可选）：请求/响应消息表中标记为“U”的参数是根据制造商的动态使用情况提供的。
公约推荐了一个可用于实施的助记符。在任何情况下，指定的助记符都不是任何实现的强制性要求。
DT：delay time延迟时间
在访问尝试之间插入的时间段。
diagnostic service诊断服务
由客户端（外部测试设备）发起的信息交换，以便从服务器(ECU)获取诊断信息或修改其行为以进行诊断。
注：这也等同于测试模式或模式。
emissions-related DTC排放相关诊断故障码
在故障导致车辆排放超过法定排放阈值时设置的DTC，或者要求按照车载诊断法规的规定设置DTC（例如，禁用诊断系统的另一部分）。
注：通常，在设置与排放有关的DTC，会同时点亮故障指示灯（MI）。根据车载诊断法规的规定，由车辆制造商确定与排放相关的DTC。
ECU：electronic control unit电子控制单元
任何电子控制单元的通用术语。
FAA：false access attempt错误的访问尝试
车载控制器接收到错误的密钥。
FT：fuel trim燃油修正
对基本燃料计划的反馈调整。
注：短期燃油调整是指动态或瞬时调整。长期燃油调整是指对燃油校准计划的调整比短期调整调整要缓慢得多。这些长期调整补偿了随着时间的推移发生的车辆差异和逐渐变化。
I/M：I/M station
检查和维修站，以测试车辆排放相关系统的适航性。
key密钥
数据值，用于访问从外部测试设备发送到车载控制器的安全功能，以响应种子。
MI：malfunction indicator故障指示
在发生故障时能够清楚地通知驾驶员的指示灯。
OBD：on-board diagnostics车载诊断
监视部分或全部计算机输入和控制信号的系统。
注：超出预定限制的信号意味着系统或相关系统中的故障。
negative numbers负数
有符号二进制，二进制数的最高有效位（MSB），用于表示正数（0）/负数（1）。
注：2的补码：负数表示为二进制数的补码，然后加1。
示例：–0,99 = 800116 = 1000 0000 0000 00012
0 = 000016 = 0000 0000 0000 00002
+0,99 = 7FFF16 = 0111 1111 1111 11112
注：（–0,99）+（+0,99）= 0。
＃：number编号
用这个符号“＃”表示。
P2,P3 timing parameter（P2，P3时序参数）
ECU和外部测试设备的应用时序参数。
P2CAN_min timing parameter（P2CAN_min时序参数）
具有最小值的CAN应用时序参数，用于ECU和外部测试设备启动响应消息。
P2CAN_max timing parameter（P2CAN_max时序参数）
具有最小值的CAN应用时序参数，用于ECU和外部测试设备启动响应消息。
P2reload timing parameter（P2reload时序参数）
具有最大值(P2CAN_max)的CAN应用时序参数仅用于外部测试设备。
secured functions安全功能
受限制的功能，需要对其进行访问才能解锁板载控制器。
示例：车辆排放系统的编程，例如燃料/点火图，防盗系统和里程表。
seed种子
从机载控制器发送到外部测试设备的伪随机数据值，并由安全算法处理以生成密钥。
server服务器
功能是提供诊断服务的电子控制单元的一部分。
注：ISO 15031的这一部分区分了服务器（即功能）和电子控制单元，因此ISO 15031的这一部分与实施无关。
service服务
由客户端（外部测试设备）发起的信息交换，以便从服务器(ECU)获取诊断信息和/或修改其行为以进行诊断。
注：这也相当于测试模式或模式。
unsecured functions不安全的功能
车辆制造商提供的标准诊断功能，并由车载控制器进行控制和保护。
示例：对选定项目进行重新编程，例如清除故障代码。
VIN：vehicle identification number车辆识别码
遵循每个国家/地区当局的适用法律规定，每辆车特有的唯一识别号。
2 OBD诊断中“缩写”的描述
Addr：address地址
B1S1：Bank 1 Sensor 1气缸组1传感器1
B1S2：Bank 1 Sensor 2气缸组1传感器2
B1S3：Bank 1 Sensor 3气缸组1传感器3
B2S1：Bank 2 Sensor 1气缸组2传感器1
B2S2：Bank 2 Sensor 2气缸组2传感器2
B2S3：Bank 2 Sensor 3气缸组2传感器3
BARO：barometric atmospheric pressure大气压
CALID：calibration identifier标定标识符
CAN：controller area network控制器区域网络
CARB：California Air Resources Board加州空气资源委员会
CVN：calibration verification number标定验证码
DoCAN：Diagnostic communication over CAN通过CAN进行诊断通信
DoK-Line：Diagnostic communication over K-Line通过K-Line进行诊断通信
DTC：diagnostic trouble code诊断故障码
DTC FRZF：DTC Freeze Frame
ECU：electronic control unit电子控制单元
ECM：engine control module发动机控制模块
ECT：Engine Coolant Temperature发动机冷却液温度
FF：Flexible Fuel弹性燃油
FRZF：Freeze Frame冻结帧
FUEL PRES：Fuel Pressure燃油压力
FUEL SYS 1：Fuel System 1 Status燃油系统1状态
IPT：in-use performance tracking使用性能跟踪
ITID：infotype identifier信息类型标识符
I/M：inspection and maintenance检查和维护
ISO：International Organization for Standardization国际标准化组织
ISR：interrupt service routine 中断服务程序
LONG FT 2：Long Term Fuel Trim Bank 2气缸组2的长期燃油调整
K-Line：UART-based communication data link基于UART的通信数据链路
MI：malfunction indicator故障指示
MIL：malfunction indicator lamp故障指示灯
MAF：mass air flow 空气质量流量
MAP：manifold absolute pressure歧管绝对压力
NRC：negative response code否定响应码
OBD：on-board diagnostic车载诊断
OBDMID：on-board monitor identifier车载监视标识符
OSI：open systems interconnection开放系统互连
O2SLOC11：Oxygen Sensor Location Bank 1 Position 1氧传感器位置气缸组1位置1
PCM：powertrain control module动力总成控制模块
PID：parameter identifier参数标识符
PWM：pulse width modulated脉冲宽度调制
RPM：rounds per minute每分钟转数
SAE：Society of Automotive Engineers美国汽车工程师学会
SI：international system of units国际单位制
TID：test identifier测试标识符
TCM：transmission control module变速箱控制模块
UDS：unified diagnostic services统一诊断服务
VIN：vehicle identification number车辆识别号码
VPM：variable pulse width可变脉冲宽度
ACL：additional communication line附加通信线路
RHD：right-hand-driven右手驱动
.con：confirmation确认
.ind：indication指示
.req：request请求
CRC：cyclic redundancy check循环冗余校验
DT：delay time延迟时间
ERR：error detection byte错误检测字节
EWMA：exponential weighted moving average指数加权移动平均
FF：first frame首帧
FAA：false access attempt错误的访问尝试
ISR：interrupt service routine中断服务程序
LSB：least significant bit最低有效位
MSB：most significant bit最高有效位
N_PDU：network protocol data unit网络协议数据单元
N/A：not applicable不适用
NVRAM：non-volatile memory非易失性存储器
PCI：protocol control information协议控制信息
RSP in-frame response帧内响应
SF：single frame单帧
SOM：start of message消息开始
T_AE：virtual transport interface address extension虚拟传输接口地址扩展
T_Data[ ]：virtual transport interface data field虚拟传输接口数据字段
T_Mtype：virtual transport interface message type虚拟传输接口消息类型
T_Length：virtual transport interface length information虚拟传输接口长度信息
T_PDU：virtual transport interface protocol data unit虚拟传输接口协议数据单元
T_Result：virtual transport interface result虚拟传输接口结果
T_SA：virtual transport interface source address虚拟传输接口源地址
T_TA：virtual transport interface target address虚拟传输接口目标地址
T_TAtype：virtual transport interface target address type虚拟传输接口目标地址类型
UASID：unit and scaling identifier单位和缩放标识符
3 ISO 15031-5的适用范围
ISO 15031-5旨在满足美国和欧洲以及将来可能会采用类似要求的任何其他地区的车载诊断（OBD）法规的数据报告需求。ISO 15031-5规定
a）请求和响应消息的消息格式，
b）外部测试设备的请求消息与车辆的响应消息之间以及这些消息与后续请求消息之间的时序需求，
c）如果数据不可用，车辆和外部测试设备的行为，以及
d）一组具有相应请求和响应消息内容的诊断服务，以满足OBD法规。
ISO 15031-5规定了机动车和外部试验设备所需支持的诊断服务和功能寻址请求/响应信息，用于与汽车排放相关的数据相关的诊断目的。符合ISO 15031-4需求的任何外部测试设备都使用这些消息从车辆中检索与排放相关的信息。
ISO 15031-5参考了SAE J1979-DA（Digital Annex数字附件），其中包括PID，OBDMID，TID和INFOTYPE的所有定义。
4 ISO 15765-4中“P2CAN和P2*CAN”应用时序参数定义
对于基于ISO 15765-4的CAN总线系统，车载系统的（所有）响应ECU应启动对P2CAN内的请求消息的响应消息。下表指定了P2的应用时序参数值。
| 参数 | 最小值P2CAN_min ms | 最大值P2CAN_max ms | 描述 |
| P2CAN | 0 | 50 | 这是与诊断响应时间相关的系统范围参数。每个服务器(ECU)都需要响应P2CAN_min和P2CAN_max之间的请求。 对于响应的single-frame单帧(SF)或first-frame首帧(FF)，客户端（tester）应至少等待P2CAN_max。 P2CAN是多帧响应消息（FirstFrame）的第一个指示之前的时间。在收到完整的消息（最后一个ConsecutiveFrame连续帧）之前，客户端不应处理响应。 对于还支持UDsonCAN以进行增强诊断的客户端（tester），需要P2reload机制。收到SF或FF后，客户端（tester）应重新加载其P2CAN计时器，其值至少为P2CAN_max，并重新启动计时器。 一旦客户端（tester）的P2CAN计时器到期而没有收到SF或FF，客户端（tester）可能会假设没有更多的响应即将到来。 |
| P2*CAN | 0 | 5 000 | 成功接收NRC 7816否定响应消息和下一个响应消息（肯定或否定信息）之间的时间。 |
注意：multiple-frame响应的网络层时序参数未显示。ISO 15765-4中规定了法规诊断消息的网络层时序要求。
5 ISO 15765-4协议的实施指南示例
5.1 默认会话期间的功能OBD通信
下图以图形方式描述了客户端和三个服务器中默认会话期间功能寻址请求消息的时序处理。图后面的描述引用了图中标记的点。
图 - 功能OBD通信-默认响应时序
Key
1 客户端T_Data.req：诊断应用程序问题功能解决请求消息到网络层。
2 所有服务器T_Data.ind：网络层向诊断应用程序发出请求消息的接收。所有服务器使用P2CAN = P2CAN_max的值启动P2CAN计时器。
客户端T_Data.con：网络层向诊断应用发出请求消息完成的确认。客户端使用默认重载值P2CAN = P2CAN_max启动其P2CAN_Client定时器。
3 服务器#1 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。响应消息可以是多帧或单帧响应消息。
4 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。使用P2CAN_max值重新加载P2CAN。
5 服务器#2T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。响应消息可以是多帧或单帧响应消息
6 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。使用P2 CAN_max值重新加载P2CAN。
7 服务器#1 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。
8 服务器#2 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。
9 服务器#3 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。响应消息可以是多帧或单帧响应消息。
10 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。使用P2CAN_max值重新加载P2CAN。
11 服务器#2 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。
5.2 具有增强响应时间的功能OBD通信
下图说明了在默认会话期间客户端和三个服务器中针对功能寻址请求消息的时序处理，其中一个服务器通过包含NRC 7816的否定响应消息请求增强的响应时序。图之后的描述引用了图中标记的点。
图 - 功能性OBD通信-增强的响应时间
Key
1 客户端T_Data.req：诊断应用程序问题功能解决请求消息到网络层。
2 所有服务器T_Data.ind：网络层向诊断应用程序发出请求消息的接收。所有服务器使用P2CAN = P2CAN_max的值启动P2CAN计时器。
客户端T_Data.con：网络层向诊断应用发出请求消息完成的确认。客户端使用默认重载值P2CAN = P2CAN_max启动其P2CAN计时器。所有NRCPendingCounter = 0。
3 服务器#1 T_Data.req：诊断应用程序没有准备好肯定响应消息，并通过T_Data.req向P2CAN内的网络层发出NRC = 7816的否定响应消息。
4 服务器#1 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用程序发出消息的接收。由于接收到的响应消息是NRC = 7816的否定响应消息，因此NRCPendingCounter服务器#1递增1（0+1 = 1）。使用P2*CAN_max值重新加载P2CAN。服务器#1使用P2*CAN_max值重新加载P2CAN。
5 服务器#3 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。
6 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。使用P2*CAN_max重新加载P2CAN。
7 服务器#3 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。
8 服务器#2 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。
9 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。客户端使用P2*CAN_max值重新加载P2CAN。
10 服务器#1 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req
11 客户端T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。由于接收到的响应消息是肯定响应消息，NRCPendingCounter服务器#1递减1（1-1 = 0）。客户端使用P2CAN_max值重新加载P2CAN。
12 服务器#2 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。
13 服务器#1 T_Data.con：网络层向诊断应用发出响应消息的完成
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成
6 ISO 15765-4数据不可用
有五种情况的数据被视为不可用：
a)不支持请求消息：不支持功能请求消息的ECU不应发送任何响应消息；
b)支持请求消息但不支持数据：支持功能请求消息但不支持请求数据（例如PID、OBD监视器ID、TID或INFOTYPE）的ECU不允许发送否定响应消息因为另一个ECU会发送一个肯定的响应消息。如果外部测试设备发送包含多个PID的消息，并且每个与排放相关的ECU不支持所有请求的PID，则每个ECU应发送包含支持的PID和数据值的肯定响应消息，并且不应发送否定响应信息。如果ECU不支持任何请求的PID，则不允许发送否定响应消息；
c)支持请求消息，但目前没有数据：确实（确实）支持功能请求消息但当前没有可用请求数据的ECU应使用NRC 2216 - ConditionNotCorrect以否定响应消息进行响应（否定响应消息格式在6.3.3中规定）。对于服务0116、0216、0316、0616、0716和0A16，不允许使用包含NRC 2216的否定响应消息。对于服务0416、0816和0916，允许使用NRC 2216。将2216用于服务0916 CVN请求可能会受到OBD法规的限制；
d)支持请求消息，但在P2时序内数据不可用：ECU和外部测试设备的行为在6.1中规定；
e)支持请求消息，但不能在P2时间内进行服务：ECU和外部测试设备的行为在6.1中规定。对于服务0416和0916，允许使用NRC 7816。
6.1 ISO 15765-4 - 在P2时序内不可用的数据或无法在P2时序内执行服务
支持功能请求消息但在P2时间内没有可用请求数据或无法在P2时间内执行请求服务的ECU应执行以下处理：
a）ECU(s)应使用NRC 7816 - RequestCorrectlyReceived-ResponsePending在P2时间内以否定响应消息进行响应（不允许服务0116、0216、0316、0616、0716和0A16请求）；
b)在正确接收到NRC 7816的否定响应消息后，外部测试设备和发送否定响应消息的ECU应将P2CAN_max参数定时值设置为P2*CAN_max(5 000 ms)；
c)如果另一个ECU也用NRC 7816发送否定响应消息，则P2CAN_max时序参数值应重新加载到P2*CAN_max；
d)需要超过P2*CAN_max来执行请求的动作的ECU应在P2*CAN_max到期之前用NRC 7816重复否定响应消息，直到正确接收到肯定响应消息；
e)在收到所有肯定响应消息或超时后，发生了P2*CAN_max，P2CAN_max计时参数应重置为表7中指定的值。
车辆制造商负责确保车辆的网络架构在响应服务0116、0216、0316、0616、0716、0816和0A16请求时不会导致超过P2CAN_max时序的时序延迟，因为带有NRC 7816的否定响应消息将不被允许。
图15说明了使用NRC 7816处理ISO 15765-4接口的否定响应消息。
图 - ISO 15765-4：-否定响应代码NRC = 7816处理概述
Key
1 客户端T_Data.req：诊断应用程序问题功能解决请求消息到网络层。
2 所有服务器T_Data.ind：网络层向诊断应用程序发出请求消息的接收。所有服务器使用P2CAN = P2CAN_max的值启动P2CAN计时器。
客户端T_Data.con：网络层向诊断应用发出请求消息完成的确认。所有NRCPendingCounter = 0。客户端使用默认重载值P2CAN = P2CAN_max启动其P2CAN计时器。
3 服务器#1 T_Data.req：诊断应用程序没有准备好肯定响应消息，并通过T_Data.req向P2CAN内的网络层发出NRC = 7816的否定响应消息。
4 客户端T_Data.ind：网络层向诊断应用程序发出消息的接收。由于收到的响应消息是NRC = 7816的否定响应消息，服务器#1的NRCPendingCounter增加1(0+1 = 1)。客户端使用P2*CAN_max值重新加载P2CAN。
服务器#1 T_Data.con：网络层向诊断应用发出响应消息的完成。
5 服务器#2 T_Data.req：诊断应用程序没有准备好肯定响应消息，并通过T_Data.req向P2CAN内的网络层发出NRC = 7816的否定响应消息
6 客户端 T_Data.ind：网络层向诊断应用程序发出消息的接收。由于接收到的响应消息是NRC = 7816的否定响应消息，因此NRCPendingCounter服务器#2递增1（0+1 = 1）。客户端使用P2*CAN_max值重新加载P2CAN。
服务器#2 T_Data.con：网络层向诊断应用发出响应消息的完成。
7 服务器#3 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。
8 客户端 T_DataSOM.ind：网络层向诊断应用程序发出StartOfMessage的接收，该消息由CAN上的FirstFrame指示的接收发起（参见ISO 15765-2）。客户端使用P2*CAN_max值重新加载P2CAN。
9 服务器#3 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端 T_Data.ind：网络层向诊断应用发出响应消息的完成。
10 服务器#2 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。响应消息是单帧消息。
11 服务器 #2 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端T_Data.ind：网络层向诊断应用发出响应消息的完成。由于接收到的响应消息是肯定响应消息，NRCPendingCounter服务器#2递减1（1-1 = 0）。客户端使用P2*CAN_max值重新加载P2CAN。
12 服务器#1 T_Data.req：诊断应用程序已准备好响应消息并向P2CAN内的网络层发出T_Data.req。响应消息是单帧消息。
13 服务器#1 T_Data.con：网络层向诊断应用发出响应消息的完成。
客户端 T_Data.ind：网络层向诊断应用程序发出响应消息的完成。由于接收到的响应消息是肯定响应消息，NRCPendingCounter服务器#1递减1(1-1 = 0)。客户端使用P2CAN_max值重新加载P2CAN。
6.2 数据不可用—协议的测试条件：ISO 15765-4通过CAN的诊断通信
以下是认为没有数据的五个条件：
—不支持服务；
—支持服务，但不支持数据；
—支持服务，但在发出请求时数据不可用；
—支持服务，但在P2时序内数据不可用；
—支持服务，但不能在P2定时内执行。表11列出了正确的服务器/ECU响应，如6.1所述。
表11 - 服务器/ECU对ISO 15765-4协议的肯定响应
| 服务 (16进制） | 条件 | ISO 15765-4 | NRC |
| 01 | 不支持 | 如果支持服务0116，所有ECU应响应服务0116 PID 0016。如果不支持服务0116，则不允许响应。 | N/A |
| 请求的PID不受支持 | ECU不响应。 | N/A | |
| 请求支持的PID | 需要肯定响应（不允许带有NRC7816的否定响应消息）。 | N/A | |
| 支持初始化期间请求的PID 0016 | 需要肯定响应或否定响应，最多5次。 | 2116 | |
| 02 | 不支持 | ECU不应响应。 | N/A |
| 支持的PID，请求帧XX16，未存储冻结帧 | 1)ECU应响应PID 0216 帧XX16；PID 0216帧XX16应指示000016。 2)ECU应响应帧XX16(0016,2016,...)的支持PID。 3)如果请求支持PID或PID 0216以外的PID，则ECU不应响应。 | N/A | |
| 不支持的PID，请求帧XX16，未存储冻结帧 | PID 0216帧XX16指示000016，但如果请求任何其他PID，ECU不应响应。 | N/A | |
| 支持的PID，帧XX16请求，冻结帧存储 | 1)ECU应在P2时间内响应PID 0216帧XX16。 2)ECU应在P2时序内响应帧XX16（0016、2016...）的支持PID，并应响应P2时序内指示为支持的PID帧XX16。 | N/A | |
| 不支持的PID，请求的帧XX16，已存储冻结帧 | ECU不应响应。 | N/A | |
| 03/ 07/ 0A | 不支持 | ECU不应响应。 | N/A |
| 支持，不存储DTC | 表示不需要DTC的肯定响应。 | N/A | |
| 支持，已存储DTC | 需要包含存储的DTC的肯定响应。 | N/A | |
| 04 | 不支持 | ECU不应响应。 | N/A |
| 支持，条件不正确 | 需要否定响应。 | 2216 | |
| 支持，条件正确 | 需要肯定响应消息。请求后最多5000毫秒内允许多个否定响应消息，直到需要肯定响应。 | 78 | |
| 06 | 不支持 | ECU不应响应。 | N/A |
| 请求支持的OBDMID，没有可用的存储数据 | 需要肯定响应；测试值，最小和最大限制应设置为0016。 | N/A | |
| 请求的OBDMID不受支持，没有可用的存储数据 | ECU不应响应。 | N/A | |
| 支持OBDMID请求，存储数据可用 | 需要肯定响应。 | N/A | |
| 请求的OBDMID不受支持，存储的数据可用 | ECU不应响应。 | N/A | |
| 08 | 不支持 | ECU不应响应。 | N/A |
| 请求支持的TID，条件正确 | 需要肯定响应。 | N/A | |
| 请求支持的TID，条件不正确 | 需要否定回应。 | 2216 | |
| 请求的TID不受支持 | ECU不应响应。 | N/A | |
| 09 | 不支持 | ECU不应响应。 | N/A |
| 请求支持的信息类型，数据可用（VIN、CVN、CALID） | 需要肯定响应。 | N/A | |
| 请求支持的INFOTYPE，数据不可用，条件正确(CVN) | 在P2max(50 ms)内需要初始否定响应消息，在P2max(5.0s)内需要连续否定响应消息，直到发送肯定响应。 | 7816 | |
| 请求支持的INFOTYPE，数据不可用，条件不正确(CVN)，仅在2005年之前MY | 需要负面回应。（使用NRC 2216可能受到OBD法规的限制。） | 2216 | |
| 请求的信息类型不受支持 | ECU不应响应。 | N/A | |
| 00,05 or 0B – 0F | 不允许 | ECU不应响应。 | N/A |
7 NRC否定响应代码参数定义
响应代码应在支持服务的ECU中实现，该服务在请求时没有可用的有效数据，或者无法使用P2K-Line和P2CAN时序内可用的有效数据进行响应。
表16定义了否定响应代码。
表16 -否定响应代码（NRC）的定义
| 支持的ISO协议 | 字节值 (16进制） | 响应代码定义 | 助记符 |
| 14230–4 | 10 | generalReject一般拒绝 此响应代码表示服务被拒绝，但服务器(ECU)未指定拒绝原因。 | GR |
| 14230–4 | 11 | serviceNotSupported不支持的服务 此响应代码表示将不会执行请求的操作，因为服务器(ECU)不支持请求的服务。 | SNS |
| 14230–4 | 12 | subFunctionNotSupported-InvalidFormat(subFunction不支持-格式无效) 此响应代码表示将不会采取请求的操作，因为服务器(ECU)不支持请求消息的参数或参数字节的格式与指定服务的规定格式不匹配。 | SFNSIF |
| 14230–4 15765–4 | 21 | busy-RepeatRequest忙-重复请求 此响应代码表示服务器(ECU)暂时太忙而无法执行请求的操作。对于ISO 15765-4协议，客户端（外部测试设备）的行为应符合ISO 15765-4中的定义。在多客户端（多个外部测试设备，例如远程信息处理客户端）环境中，一个客户端的诊断请求消息可能会被响应代码为2116的否定响应消息暂时阻止，而另一客户端完成诊断任务。因此，此否定响应代码(NRC)仅允许在协议的初始化序列期间使用。 注：如果服务器(ECU)能够执行诊断任务，但需要额外的时间来完成任务并准备响应消息，则使用响应代码为7816的否定响应消息而不是2116。 | BRR |
| 14230–4 15765–4 | 22 | conditionsNotCorrectOrRequestSequenceError条件不正确或请求顺序错误 此响应代码表示将不会执行请求的操作，因为服务器(ECU)先决条件不满足。当顺序敏感的请求以错误的顺序发出时，也可能发生此请求 | CNCORSE |
| 14230–4 15765–4 | 78 | requestCorrectlyReceived-ResponsePending请求正确接收-响应待定 此响应代码表明请求消息已正确接收，请求消息中的任何参数均有效，但可能尚未完成要执行的操作。此响应码可用于指示请求消息已正确接收，不需要重新传输，但服务器（ECU） 尚未准备好接收另一个请求。带有此响应代码的否定响应消息可以由ECU在 P2K-Line = P2CAN = P2*max内重复，直到带有请求数据的肯定响应消息可用。 | RCR-RP |
8 Byte order字节顺序约定
当报告大于一个字节的数据时，最高有效字节（或高字节）被报告为第一个数据字节，然后是下一个最高有效字节。
最低有效字节（或低字节）被报告为最后一个数据字节。在ISO 15031的这一部分中的许多示例中都显示了该约定。
9要显示的数据格式
表19指出了数据类型和显示格式的最低要求。
表19 - 要显示的数据格式
| Data | Services (16进制） | 显示格式 |
| Device ID – source address of response | All | ISO 9141-2:Hexadecimal(0016 to FF16) ISO 14230-4:Hexadecimal(0016 to FF16) SAE J1850:Hexadecimal(0016 to FF16) ISO 15765-4:Hexadecimal(11 bit or 29 bit CAN Identifier) |
| Parameter ID(PID) | 01 and 02 | Hexadecimal(0016 to FF16) description(see SAE J1979-DA) |
| Frame number | 02 | Decimal(0 to 255) |
| Data values | 01 and 02 | See SAE J1979-DA |
| Diagnostic trouble codes | 03,07,and 0A | “P”,“B”,“C”,or“U”,plus 4 hexadecimal characters and/or DTC definition (see SAE J2012-DA) |
| Test ID | 05, 06,and 08 | Hexadecimal(0016 to FF16) |
| Test value and test limits | 05 | Engineering units for Test IDs less than 8016(see SAE J1979-DA) –decimal(0 to 255) for Test IDs greater than 8016 |
| Test value and test limits | 06 | Decimal (0 to 65 535) |
| Component ID | 06 | Hexadecimal(0016 to 7F16) |
| Optional data bytes | 08 | 4 bytes,each decimal(0 to 255)(see SAE J1979-DA) |
| Vehicle information type | 09 | Hexadecimal(0016 to 7F16)(see SAE J1979-DA) |
| Vehicle information data | 09 | See SAE J1979-DA |
注意：ISO 15031-4/SAE J1978详细说明了显示服务0116到0916数据的指南和示例。
10 用于ISO 15765-4的OBD诊断服务概述
| 服务 （16进制） | 描述 |
| 01 | Request current powertrain diagnostic data 请求当前动力总成诊断数据 |
| 02 | Request powertrain freeze frame data 请求动力系统冻结帧数据 |
| 03 | Request emission-related diagnostic trouble codes 请求与排放相关的诊断故障代码 |
| 04 | Clear/Reset emission-related diagnostic information 清除/重置排放相关诊断信息 |
| 05 | Request oxygen sensor monitoring test results 请求氧气传感器监测测试结果 |
| 06 | Request on-board monitoring test results for specific monitored systems 请求特定监控系统的车载监控测试结果 |
| 07 | Request emission-related diagnostic trouble codes detected during current or last completed driving cycle 请求在当前或上次完成的驾驶循环中检测到的与排放相关的诊断故障代码 |
| 08 | Request control of on-board system, test, or component 请求控制车载系统、测试或组件 |
| 09 | Request vehicle information 请求车辆信息 |
| 0A | Request emission-related diagnostic trouble codes with permanent status 请求具有永久状态的与排放相关的诊断故障代码 |
以上摘自《ISO 15031-5:2015》。
11 结尾
扫一扫
964
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
