OBD协议数据流说明

OBD远程车况诊断协议1.1.OBD远程车况诊断1.1.1.说明车载终端上报需要增加重传机制，上报不成功，需要重新传输。

1.1.2.CAN静态数据OBD模块根据终端设置规则，响应CAN静态数据；终端根据默认频率主动上报CAN 静态数据，当平台需要跟踪CAN静态数据时，采用跟踪命令修改上报频率。

1.1.2.1.终端上报CAN静态数据信息消息ID：0x0B21终端上报CAN静态数据消息体数据格式详见下表，平台采用通用应答。

说明：1、数据流掩码4字节DS MASK，表示30个数据流支持与否，字节位次序高位在先，低位在后。

比如：掩码第1个字节的BIT7决定第1个数据流（电瓶电压）支持与否掩码第1个字节的BIT0决定第8个数据流(车辆速度)支持与否掩码第2个字节的BIT7决定第9个数据流（进气温度）支持与否2、每个上传的静态数据包为固定的长度94字节，不支持的数据流，仍占用固定位置字节。

3、根据设置时间间隔上报（设置参数一定可以设置时间间隔）1.1.2.2.平台主动跟踪CAN 静态数据消息ID：0x8B21当平台发送主动跟踪CAN数据时，终端采用通用应答。

响应数据示例：1.1.3.车辆故障数据OBD模块采集到车辆故障时，将故障码主动传送给终端，终端通过上报故障数据将故障数据传送给平台。

1.1.3.1.终端主动上报车辆故障数据消息ID：0x0B22消息体见故障数据报，平台采用通用应答。

说明：1.1个故障码编号由4字节组成，分别为系统ID、故障字节1、故障字节2、故障字节3。

对于OBD故障码，SYS_ID为0x00，故障字节3无意义(为0)。

2.关机报一次1.1.3.2.平台查询车辆故障数据消息ID：0x8B22消息体为空，终端应答车辆故障数据。

1.1.4.驾驶行为数据当ACC OFF时，OBD模块主动产生驾驶行为数据发送给终端，终端上报驾驶行为数据给平台；当用户需要在平台查看驾驶行为数据时，可下发查询驾驶行为数据，终端从OBD 模块获取驾驶行为数据，并上报给平台进行展示。

OBD-II通讯协议OBD-II Network Standards» J1850 PW–Adopted by GM; also known as Class 2.–Adopted by Chrysler (known as J1850).–Some references to PW mode heard about in regards to Toyota (and Honda ?). –10.4 kbps, single wire.» J1850 PWM–Adopted by Ford; also known as Standard Corporate Protocol (SCP).–Also seen in some Mazda products.–Some references to PWM mode heard about in regards to Mitsubishi.–41.6 kbps, two wire balanced signal.» ISO 9141 and ISO 9141-2 (also known as ISO 9141 CARB)–Seen in some Chrysler and Mazda products.–Seems to be more common in Europe.–10.4 kbps, single wire.OBDII 通讯协议obdii generic communication protocols by manufacturerRecently I tried to install my product on Peuzeot(406 or somethingsimilar). There wasKWP 2000 bus. I tried to get the speed alue from the bus by sendingthe following string0xc2 0x33 0xf1 0x01 0x0d 0xf4.On responce I receied two answers from 2 different ECUs:1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x161) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66The first ECU sent me NACK(This response code indicates that the requested action will not betaken because the serer (ECU) does not support the arguments of therequest message or the format of the argument bytes do not match the prescribed format for the specified serice.)My question is: if there was something wrong with the arguments of the request message, the second ECU also should not understand therequest, bit it did !And the second question is: why the first ECU did send the negatieanswer. If you look at the j1979 PDF you will find there that "If anECU does not support any of the PIDs requested it is not allowed tosend a negatie response message".OBD 信息：我理解的OBD-II标准诊断插座列表我理解的obd-ii标准诊断插座列表端子号称端子接线---------------------------------------------------------------------4 搭铁16 蓄电池正极，9-127，15 资料数据传输线（iso 9141-2）5 信号反馈线搭铁2 sae j1850数据输送线10 sae制造厂数据输送线举一实例；捷达前卫诊断座t16中；就有16 4 7三个端子按以上要求接线。

单帧：请求报文：第一字节：4-7位=0 3-0位= SF-DL 单一框架数据长度第二字节：sid第三字节：0-6位diagnosticsessiontype：defauleSession =01ECUProgrammingSession= 02ExtendedDiagnosticSession =037位：0 不镇压响应报文1 镇压响应报文多帧：首帧：第一字节4-7位=1 3-0位+第二字节=FF-DL FF-DL 第一框架数据长度范围8-fff 第三字节：sid流控制帧：第一字节4-7位=30-3位=FS 流动状态0：继续发送1：等待2：超出流控制范围3-F保留第二字节=BS 块大小00-无FC01-FF除流控制帧外最多的连续帧第三字节= STmin 两个数据包之间最小等待时间连续帧：第一字节：4-7位=2 0-3位=SN 序列号范围0-F第二字节数据1DiagnosticSessionControl（sid=10）Sid 后的数据请求报文：第一字节：0-6位diagnosticsessiontype：defauleSession =01ECUProgrammingSession= 02ExtendedDiagnosticSession =037位：0 不镇压响应报文1 镇压响应报文主要完成：确定相应的模式，对时间参数进行相应的设定正确响应报文：sid=50第一字节：0-6位diagnosticsessiontype：defauleSession =01ECUProgrammingSession= 02ExtendedDiagnosticSession =03第二字节：sessionparameterRecord[][SessionParameterRecord[]#1=[P2CAN-SERVER-MAX高字节P2CAN-SERVER-MAX低字节P2*CAN-SERVER-MAX高字节P2*CAN-SERVER-MAX高字节错误响应报文：pci之后的数据：第一字节：NR-SI=7f第二字节:ID=50第三字节同上面的第二字节第五字节是错误响应代码：12-subfunctionnotsupported13-incorrectmessagelengthorinvalidformat22-conditionsnotcorrect主要完成：确定相应的模式，对时间参数进行相应的设定2. ECUReset sid=11单帧：请求报文：第一字节：0-6位resettype：hardreset =01keyoffonreset = 02softreset =03enablerapidpowershutdown =04disablerapidpowershutdown =057位：0 不镇压响应报文1 镇压响应报文正确响应报文：sid=51第一字节：0-6位resettype：hardreset =01keyoffonreset = 02softreset =03enablerapidpowershutdown =04disablerapidpowershutdown =05第二字节：powerdowntime错误响应报文：第一字节：NR-SI=7f第二字节:ID=51第三字节同上面的第二字节第四字节是错误响应代码：12-subfunctionnotsupported13-incorrectmessagelengthorinvalidformat22-conditionsnotcorrect33-securityaccessdenied（拒绝安全进入）主要完成：进行相应的复位模式3.SecurityAccess sid=27单帧：请求报文：第一字节：0-6位SecurityAccessType：requestSeed=01 ,03,05,07-5F s endkey=02,04,06,08-607位：0 不镇压响应报文1 镇压响应报文第二字节：securityAccessDataRecord[] / securitykey[]正确响应报文：sid=67第三字节：0-6位SecurityAccessType第四字节：SecuritySeed[]错误响应报文：第一字节：NR-SI=7f第二字节:ID=67第三字节同上面的第二字节第五字节是错误响应代码：12-subfunctionnotsupported13-incorrectmessagelengthorinvalidformat22-conditionsnotcorrect24-requestSequenceEerror //请求序列错误31-requestOutOfRange35-invalidKey//密码无效36-exceededNumberOfAttempts//超出所允许的输入密码次数37-requiredTimerDelayNotExoired//要求的时间延时已到municationControl sid=28单帧：请求报文：第一字节：0-6位Controltype：Enablerxandtx=00Enablerxanddisabletx=01Disablerxandenabletx=02Disablerxandtx=037位：0 不镇压响应报文1 镇压响应报文第二字节：Communicationtype Application=01bNetworkmanagement=10b正确响应报文：sid=68第一字节：0-6位Controltype：Enablerxandtx=00Enablerxanddisabletx=01Disablerxandenabletx=02Disablerxandtx=03第二字节：Communicationtype Application=01bNetworkmanagement=10b错误响应报文：第一字节：NR-SI=7f第二字节:ID=68第三字节同上面的第二字节第四字节同上第三字节第五字节是错误响应代码：12-subfunctionnotsupported13-incorrectmessagelengthorinvalidformat22-conditionsnotcorrect31-requestOutOfRange主要完成：确定相应的模式，对时间参数进行相应的设定5.testerPresent sid=3E单帧：请求报文：第三字节：0-6位Zerosubfunction=007位：0 不镇压响应报文1 镇压响应报文正确响应报文：sid=7E第一字节：0-6位Zerosubfunction=00错误响应报文：第一字节：NR-SI=7f第二字节:ID=7E第三字节同上面的第二字节第四字节是错误响应代码：12-subfunctionnotsupported13-incorrectmessagelengthorinvalidformat主要完成：确定相应的模式，对时间参数进行相应的设定6.Secureddatatrasmission sid=84单帧：请求报文：第一字节：0-6位securityDataRequestRecord[]7位：0 不镇压响应报文1 镇压响应报文正确响应报文：sid= C4第一字节：0-6位0-6位securityDataRequestRecord[]7位：0 不镇压响应报文1 镇压响应报文错误响应报文：第一字节：NR-SI=7f第二字节:ID= C4第三字节同上面的第二字节securityDataRequestRecord[]第四字节是错误响应代码：13-incorrectmessagelengthorinvalidformat 7.controlDTCsetting sid=85单帧：请求报文：第一字节：7位：0 不镇压响应报文1 镇压响应报文0-6位DTCsettingtype on=01 off=02第二字节：DTCsettingcontroloptionrecord[]正确响应报文：sid=c5第一字节：DTCsettingtype on=01 off=02错误响应报文：第一字节：NR-SI=7f第二字节:ID=c5第三字节同上面的第二字节第四字节同上第三字节8. ResponseOnEvent sid=86单帧：请求报文：第一字节：7位：0 不镇压响应报文1 镇压响应报文6位donotstoreevent=0Storeevent=10-5位stopresponse on event=00On dtc status change=01On timer interrupt=02On change of data identifier=03Report activate events=04Startresponse on event =05Clear response on event=06On comparision of values=07第二字节：event window time第三字节; eventTypeRecord[]….字节：service to respond to record[]=[sesvice idService parameter..]Service to resond to record [read data by identifier req sid=22 res sid=62Read dtc information 19 59Routine control 31 71Input outout control by identifier 2F 6F正确响应报文：sid=c6第一字节：7位：0 不镇压响应报文1 镇压响应报文6位donotstoreevent=0Storeevent=10-5位stopresponse on event=00On dtc status change=01On timer interrupt=02On change of data identifier=03Report activate events=04Startresponse on event =05Clear response on event=06On comparision of values=07第二字节; number of identified events第三字节：event window time第四即以后：event type record[]….字节：service to respond to record[]=[sesvice idService parameter..]错误响应报文：第一字节：NR-SI=7f第二字节:ID=c6第三字节同上面的第二字节第四字节同上第三字节。

Obd协议文档消息格式消息长度请求/响应消息的最大长度不超过256 字节。

消息结构请求/响应消息的结构完全一致。

消息头长度指令标识数据校验55 AA LEN CMD PID D1…Dn CRC2 字节 1 字节 1 字节 1 字节0~n 字节 1 字节消息头：55 AA。

长度：为CRC 之前所有字节的个数。

指令：消息类别。

标识：参数类别。

数据：与标识相关的数据。

校验：为CRC 之前所有字节的CRC-8。

主动上传消息设备到主机消息头长度指令标识数据个数校验55 AA LEN 01 01:低电压报警2:电压阈值,单位:mV CRC此消息无需主机响应。

为确保主机能正确收到行程结束消息，特要求主机对03 标识的消息做出响应。

响应消息为55 AA 05 01 03 98。

设备最多向主机尝试3次，间隔为5秒。

收到主机响应后立即结束。

读取设备参数主机下发指令消息头长度指令标识数据个数校验55 AA 05 02 01:设备序号0 7602:硬件版本5103:软件版本4C04:汽车型号1F05:汽车排量0206:速度阈值2507:报警开关3808:电压阈值8309:汽车VIN 9E0A:怠速时长阈值B90B:急加速阈值A40C:急减速阈值F70D:冷却液温度阈值EA设备回复pc主机消息头长度指令标识数据个数校验55 AA LEN 02 01:设备序号12:产品唯一识别序列CRC 02:硬件版本20:ASCII 字符串,以00 补足20位03:软件版本20:ASCII 字符串,以00 补足20位04:汽车型号2:保留，暂未启用，返回值无意义05:汽车排量2:单位:ml06:速度阈值1:单位:km/h07:报警开关1:算法:0-关闭;1-打开bit7 超速报警控制bit6 低电压报警控制bit5怠速超时报警控制bit4急加速报警控制bit3急减速报警控制bit2 冷却液高温报警控制bit1 保留bit0 保留08:低电压阈值2:单位:mV09:汽车VIN 17:ASCII 字符,0A:怠速时长阈值2:单位:s0B:急加速阈值1:单位:0.1m/s20C:急减速阈值1:单位:0.1m/s20D:冷却液温度阈值1:单位:℃说明：一次可读取多项设备参数。

ISO和SAE标准组织制定的OBD协议，ISO协议和SAE协议对应关系ISO和SAE标准组织制定的OBD协议，ISO协议和SAE协议对应关系如下：SAE文件 ISO文件描述无15031-1通用信息J1930 15031-2术语、定义、缩略语J1962 15031-3诊断接头J1978 15031-4OBDII解码器J1979 15031-5排放有关的诊断J2012 15031-6故障码定义J2186 15031-7数据链路安全SAE诊断标准SAE标准几乎覆盖维修技师每天接触的每一个元件和工具。

SAE 的J标准是专家委员会针对特定领域内起草的文件。

专家委员会完成项目的研究后，推荐报送到标准委员会，然后表决采用标准或将文件返回专家委员会进一步修改。

SAE的J标准特别适用于驾驶性能或排放诊断。

以下是最常使用的诊断标准：J1850 - Class B数据通讯网络接口。

建立适用于所有陆地行驶的公路或越野车辆的Class B数据通讯网络接口技术规范。

规范设定各个PCM和解码器的串行数据传输标准。

文件最初设定两个标准：可变脉冲宽度（VPW）信号控制在10.4kBaud（千波特），脉冲宽度调节（PWM）信号控制在41.6kBaud。

J1930 - 电气/电子系统的各种诊断术语、定义、缩略语和简称。

标准化汽车术语、名称、定义、缩略语和简称。

重点在电气/电子的诊断术语，同时也包括相关的机械术语、定义、缩略语和简称。

这个文件的特别应用包括诊断、服务和维修手册、技术通报及其更新、培训手册、维修数据库、发动机罩下排放标签和排放认证的使用。

J1962 - 诊断接头。

标准化诊断接头（DLC）的形状和针脚数量。

同时也标准化了16个针脚中的7个针脚功能。

制造厂按照他们的愿望可以使用剩余的针脚。

稍后，J2201的章节包括在了J1962中，并做出修改，允许ISO 9141-2针脚也可用于ISO 14230-4（口令协议2000）。

国际标准组织（ISO）预留针脚6用于高速控制器局域网（CAN Hi），预留针脚14用于低速控制器局域网（CAN Lo）。

OBD使用说明•OBD基本概念与原理•OBD设备选择与安装目录•数据读取与解析方法•故障诊断与排除流程•软件更新与升级策略•总结回顾与展望未来01OBD基本概念与原理OBD 能够对车辆的各种运行状态进行监测，及时发现潜在的故障并提醒驾驶员。

OBD系统还可以对车辆的排放进行监控，确保其符合环保法规要求。

OBD是英文On-Board Diagnostics的缩写，意思是指车载自动诊断系统。

OBD定义及作用OBD系统通过各种传感器和控制单元来监测车辆的运行状态。

当发现异常或故障时，OBD系统会通过故障代码（DTC）来指示具体问题。

驾驶员或维修人员可以通过专门的诊断工具来读取故障代码，并进行相应的维修。

工作原理简述在车辆年检时，检测人员会通过OBD 系统来检查车辆是否存在故障或排放超标等问题。

车辆年检故障排查二手车评估当车辆出现故障时，维修人员可以通过OBD 系统来快速定位并解决问题。

在购买二手车时，可以通过OBD 系统来检查车辆的历史故障记录和维修情况，为购买决策提供参考。

030201常见应用场景相关法规与标准各国针对OBD系统都制定了相应的法规和标准，以确保其能够有效地监控车辆的运行状态和排放情况。

在我国，环保部门也制定了严格的OBD法规和标准，要求所有新生产的轻型汽车和重型柴油车都必须配备OBD系统。

随着环保要求的不断提高，未来OBD系统将会更加普及和重要。

02OBD设备选择与安装03多功能集成式OBD 设备除了基本的OBD 功能外，还集成了GPS 定位、行车记录仪、胎压监测等多种功能。

01独立式OBD 设备可独立工作，无需连接手机或电脑，具有实时故障诊断、数据存储等功能。

02蓝牙/WIFI 连接式OBD 设备通过蓝牙或WIFI 与手机或电脑连接，实现远程监控、数据传输、实时故障诊断等功能。

设备类型及功能对比选购注意事项与建议选择与您的车型及OBD 接口兼容的设备。

选择知名品牌、质量可靠的产品，避免购买劣质设备。

obdii 的通讯协议OBDII通讯协议模板1. 协议概述•OBDII（On-Board Diagnostics II）是一种用于车辆诊断的标准通讯协议。

•本协议旨在规范OBDII通讯协议的相关规则和约定。

2. 协议版本•协议版本：3. 协议内容通讯协议介绍•OBDII通讯协议用于车辆与诊断设备之间的数据通讯。

•通过该协议，诊断设备可以获取车辆的故障码、传感器数据等诊断信息。

•OBDII通讯协议使用标准的诊断指令和响应格式进行数据交换。

通讯协议规则•通讯协议使用基于串行通信的方式进行数据传输。

•协议采用ASCII码表示通讯数据。

•通讯数据包由起始字符、命令、参数和校验位等字段组成。

数据包格式•起始字符：协议起始标识字符，一般为大写字母‘O’。

•命令：表示具体的诊断指令，由字母和数字组成。

•参数：可选字段，表示命令的附加参数。

•校验位：用于校验数据包的完整性和正确性。

通讯流程•诊断设备发送诊断命令包给车辆的OBDII系统。

•车辆OBDII系统接收并处理诊断命令，返回相应的诊断数据包。

•诊断设备解析收到的数据包，并进行相应的处理。

4. 协议约定•通讯协议遵循国家相关标准和法律法规。

•通讯协议的具体实现细节应与OBDII相关标准相匹配。

•本模板提供了协议的基本结构和规范，并可根据实际需求进行修改。

5. 协议修订•修订记录：–版本（起草）：2022年10月01日–版本（修订）：待定本协议模板仅供参考，具体实现应根据实际需求进行具体规定和约定。

6. 诊断指令列表以下是常用的诊断指令及其功能：1.01 - 读取实时数据–读取车辆实时的传感器数据和状态信息。

–参数：传感器标识符。

–响应：当前传感器的实时数值。

2.02 - 读取故障码–读取车辆故障码和故障信息。

–参数：无。

–响应：当前存储的故障码及相关信息。

3.03 - 清除故障码–清除车辆中存储的故障码。

–参数：无。

–响应：清除故障码的结果。

4.04 - 读取VIN码–读取车辆的VIN码（车辆识别号码）。