OBD通讯协议
OBD通讯协议
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 manufacturer
Recently I tried to install my product on Peuzeot(406 or something
similar). There was
KWP 2000 bus. I tried to get the speed alue from the bus by sending
the following string
0xc2 0x33 0xf1 0x01 0x0d 0xf4.
On responce I receied two answers from 2 different ECUs:
1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16
1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66
The first ECU sent me NACK
(This response code indicates that the requested action will not be
taken because the serer (ECU) does not support the arguments of the
request 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 the
request, bit it did !
And the second question is: why the first ECU did send the negatie
answer. If you look at the j1979 PDF you will find there that "If an
ECU does not support any of the PIDs requested it is not allowed to
send a negatie response message".
OBD 信息：我理解的OBD-II标准诊断插座列表
我理解的obd-ii标准诊断插座列表
端子号称端子接线
---------------------------------------------------------------------
4 搭铁
16 蓄电池正极，9-12
7，15 资料数据传输线（iso 9141-2）
5 信号反馈线搭铁
2 sae j1850数据输送线
10 sae制造厂数据输送线
举一实例；捷达前卫诊断座t16中；就有16 4 7三个端子按以上要求接线。
EOBD 欧洲标准
新的european obd 诊断坐连接标准dlc-j1962
=============================================================================== =
pin 1 ......sae j2411, gm single wire can;通用公司单线can-bus
pin 2 ......iso 11519-4 (bus+)(sae j1850), 和10号脚同时使用, 41.6 kbps pwm脉宽调制
单线用法:只用2号脚1根线通讯10.4 kbps pw可变脉宽调制byte header + crc,
no "checksum" or "inter-byte separation" (in frame response byte ?)
pin 3 ...... chrysler, ccd+ (not obd) ;克莱斯勒ccd-bus网线h 线
pin 4 ...... 底盘地chassis ground
pin 5 ...... 逻辑地signal ground
pin 6 ...... iso 15765-4;can-bus 高速诊断线(h 线) ,250/500 kbit/s
pin 7 ....... kwp1281或kwp2000 协议诊断线(k线), 波特率10400/多数厂家默认kpw2000诊断线
pin8 ........ 点火开关打开有电ig+;点火开关on/off 状态识别用途
pin9 ........ 7号脚不方便用时,启用*kwp1281或kwp2000 协议诊断线(k线), 波特率10400 pin10 ....... iso 11519-4 (bus-)(sae j1850), 和2号脚同时使用, 41.6 kbps pwm脉宽调制
pin 11 ...... chrysler, ccd- (not obd) ;克莱斯勒ccd-bus网线l 线
pin 12 ...... * k 线制造厂保留用
pin 13 ...... * k 线制造厂保留用
pin 14 ...... iso 15765-4;can-bus 高速诊断线(l 线) ,250/500 kbit/s
pin 15 ...... kwp1281或kwp2000 协议诊断线(k线);7p不够用或控制单元过多时启用
pin 16 ...... 长火线bat+
obdii和eobd的基本区别
-------------------------------------------------------------------------------- 功能obdii eobd
--------------------------------------------------------------------------------
进行燃油箱及燃油系统的泻漏试验是不
探测发动机不（发）点火的转速到最大4500r/min
故障发生经历多少个驾驶周期故障指示灯才闪亮2 2-10
用故障指示灯显示汽车行驶距离不是
使用的通讯协议sae j1850 iso 9141-2
OBDII协议
Connected ISO9141 protocol to ECU Address 0x33 (protocol key bytes 0x08, 0x08)
Direction Header bytes Payload bytes Checksum Byte Meaning
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Serice 1, Parameter 0)
Car -> Tester 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Serice 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Serice 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Serice 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x02 0x00 0x00 0xC5 Request (Serice 2, Parameter 0)
Car -> Tester 0x00 0x00 0x00 0x00 0x00 0x00 Garbage!!
It successfully negotiated the initialization of an ISO9141 protocol session
(by responding key bytes "0x08, 0x08"), and then went berserk on me... eery time I tried this,
it has behaed the same way - useless. After a successful initialization,
it just responds "zeros" back to eery request,
******************************************************************************* **************************
标准OBD-II 有3种
1. ISO 使用ISO-9141 (借用BOSH)使用J1962-7 单线通讯电平高低表示逻辑"1" 和"0"
2. SAE J1850 (借用GM)使用J1962-2 单线通讯脉冲宽度表示逻辑"1" 和"0"
3. SAE J1850 (借用FORD)使用J1962-2/J1962-10 2线通讯可变脉宽.脉冲宽度表示逻辑"1" 和"0"
******************************************************************************* **************************
标准OBD-II 诊断之ISO标准部分使用ISO9141物理连接定义在J1962 的7号脚就是我们常说的K 线
标准OBD-II 协议ISO-9141 特点PCM动力系统5波特率地址码33H 协议字KB1:08H;协议字KB2:08H;
解码器用KB2取反$F7H确认收到$08 $08
protocol to ECU Address 0x33 (protocol key bytes 0x08, 0x08) 解码器地址码$F1
说话对象首字节工作字节校验和字节含意
============ ======== ================= ===== ========================
解码器-> 车68 6a f1 01 00 C4 请求(命令1, 参数0)
车-> 解码器00 00 无意义
解码器-> 车68 6a f1 01 00 C4 请求(命令1, 参数0)
车-> 解码器00 00 00 无意义
解码器-> 车68 6a f1 01 00 C4 请求(命令1, 参数0)
车-> 解码器00 00 00 00 无意义
解码器-> 车68 6a f1 01 00 C4 请求(命令1, 参数0)
车-> 解码器00 00 00 00 00 无意义
解码器-> 车68 6a f1 02 00 00 C5 请求(命令2, 参数0)
Car -> 解码器00 00 00 00 00 00 无意义
三个基本通讯协议：
1 iso 9141通讯协议电路。
基本型chrysler（克莱斯勒）汽车和所有欧洲生产的汽车以及大多数亚洲进口的汽车都使用国际标准化组织sio 9141通讯协议电路。
2 ase j1850 pw（可变的脉冲宽度调节）通讯协议电路。
美国通用（gm）汽车公司生产的轿车及轻型载货车汽车使用ase j1850pw通讯协议电路。
3 ase j1850 pwm（脉冲宽度调节）通讯协议电路。
福特（ford）汽车公司汽车使用该种通讯协议电路。
根据iso 15031-5标准，can（控制器局域网）采用iso 15765-4标准。
obdii和eobd都使用三个基本的通讯协议。然而有的制造商在通讯协议上做了一些修改。但是克莱斯勒和大多数亚洲进口的汽车和所有欧洲生产的汽车都使用国际标准化组织iso 9141通讯协议电路。
美国车载诊断技术（obdii）
欧洲车载诊断技术(eobd)
从欧i到欧ii，虽然说排放限值有所趋严，相对来说还比较容易实现。欧iii的难点不仅在于排放限值收紧，应该说，从欧ii到欧iii是一个飞跃，两者的主要差别在于：* 取消发动机起动後不采样的40秒钟怠速：欧i和欧ii排放法规的测试循环中，发动机起动後有一段40秒怠速阶段，在此期间排出的废气不予采集；欧iii则取消了这怠速，从发动机开始起动就采集废气样本；
* 氮氧化物的排放单独考核：在欧i和欧ii排放法规中，将碳氢化合物和氮氧化物的排放量合在一起算总账，只对两者之和制订一个限值标准，但是欧iii分别规定碳氢化合物和氮氧化物的限值；
* 增添-7℃以下的冷起动试验：欧iii增添了一项在-7℃以下的环境进行的冷起动试验；
* 对排放控制装置的耐久性要求更加严格：欧iii要求排放控制装置在行驶5年或8万公里之後，仍能满足型式认证的排放要求；
* 引入eobd：从欧iii开始要求引入欧洲车载诊断技术eobd，分阶段执行相关的法规。
用於排放控制的系统eobd（european on-board diagnostics），简称obd（on-board diagnostics），即“车载诊断技术”或简称“车载诊断”。欧i和欧ii排放法规阶段的发动机管理系统都带有车载故障诊断功能，但是在欧iii排放法规中，obd隐含着专门用於排放控制的意思，根据定义，它是“用於排放控制的车载诊断系统”，而且必须能够通过储存在计算机存储器中的失效代码来识别故障的可能範围。
美国加利福尼亚州率先于1994年以立法的形式提出了利用车载诊断技术对排放控制装置实行故障监测的要求，称为obdⅱ。後来，欧洲也制订了从2000年跟欧iii同时生效的指令70/220/eec（98/69/ec）附件xi。该指令适用于欧iii和欧i排放法规，内容包括：（1）所有车辆必须装备obd系统，其设计、制造和安装应能确保车辆在整个生命期内识别劣化类型和故障类型。
（2）当排放控制系统（与发动机电子管理系统以及排气系统或蒸发物控制系统中，任何与排放有关、向电子控制单元提供输入信号或从电子控制单元接受输出信号的零部件）失效导致排放超过规定的极限值（下文称为失效限值）时，obd系统必须指示它们的失效。
（3）汽油机obd系统必须监测下列项目：三效催化转化器；发动机在一定工况区域内
出现的缺火；氧传感器劣化；排放控制系统中其它一旦失效就会导致排放超过失效限值的零部件；排放控制系统中传感器和执行器电路是否接通；对于蒸发排放物控制系统中的炭罐控制阀，至少应监测其电路是否接通。
（4）每次发动机起动时，都必须开始一系列的诊断检测。
（5）obd系统应带有能让驾驶者感知故障存在的故障指示器，该器件只能用於指示启动了紧急程序或跛行回家程序（发动机管理系统发生故障时放弃部分控制功能，在不完备的状态下勉强维持车辆行驶的功能）。
排放一旦超过失效限值，发动机控制进入永久性排放失效模式（发动机管理控制器永久性地切换到以设定值代替一种失效零部件或系统输入信号的情形。在这情形下，失效的零部件或系统将导致车辆排放超出规定的失效限值），故障指示器应在两个运转循环（运转循环指由发动机起动、足以检测到可能存在的故障的运转模式以及发动机关闭这三部分组成的循环）以内激活。如果制造商有充分的理由，可以放宽到十个运转循环以内激活。
当发动机缺火达到制造商指定的程度，而可能引起催化转化器损坏时，故障指示器必须以明显的警示模式工作，例如灯光闪烁。
当汽车的点火开关处於接通位置，在发动机被起动或被拖转之前，故障指示器必须激活；发动机起动後，如果先前没有检测故障，故障指示器必须熄灭。?
（6）obd系统必须记录指示排放控制系统状态的代码。使用各种专设的状态代码来标识正确地工作的排放控制系统，以及那些需要进一步运转车辆才能全面地评价的排放控制系统。必须将由於劣化或故障或永久性排放失效模式引起故障指示器激活的失效代码储存起来，该失效代码必须标识故障的类型。故障指示器激活期间，车辆行驶经过的距离必须随时通过标准数据连接器的串行口读出。
（7）如果不再出现可能损坏催化转化器的缺火水平，或者如果发动机转入其缺火水平不会损坏催化转化器的其它转速和负荷条件之後继续运转，那麽故障指示器可以切换回到先前检测到缺火的第一个运转循环的激活状态（该激活状态也可能是其它故障引起），并在後续的运转循环中切换到正常的被激活模式。如果故障指示器切换回到先前的激活状态，那麽相应的失效代码和储存的冻结帧状况可以被擦除。对於缺火以外的所有其它故障，如果负责激活故障指示器的监测系统在三个相继的运转循环中不再检测到故障，并且没有识别到其它能独立地激活故障指示器的故障，那麽故障指示器可以被解除激活。
（8）如果在至少40个发动机暖机循环（在本指令中指充分运转车辆，使得冷却液温度从发动机起动时算起至少升高了22k，且至少达到70℃）内没有出现相同的失效，那麽obd 系统可以擦除失效代码、行驶过的距离和冻结帧信息。
（9）obd系统在下列情况可以自动地临时停止工作：obd系统的监测能力因燃油箱液位过低而受到影响，但是只要燃油量超过燃油箱名义容量的20%，obd系统就不得停止工作；发动机起动时环境温度低於-7℃，或海拔高于2500m时，制造商可以让obd系统停止工作；道路的路面情况十分恶劣；对于装有功率输出装置的车辆，允许让受到影响的监测系统停止工作，条件是当功率输出装置在工作时，监测系统才停止工作。
（10）型式认证主管机关除了对新车型进行型式认证以外，还要对已经行驶了超过新车型型式认证的ⅴ型耐久性试验里程的车辆，进行obd系统的型式认证，该项试验在ⅴ型耐久性试验结束时进行。进行这类试验时，制造商必须提供有缺陷的零部件和/或用于模拟失效的电气装置。但是，这些有缺陷的零部件或用于模拟失效的电气装置，在按照新车型型式认证试验程序中的ⅰ型测试循环进行试验时引起的车辆排放值，不得比规定的失效限值超出20%。
应当试验的失效模式包括：将催化转化器替换为劣化或有缺陷的催化转化器，或模拟相应失效模式的电气装置；符合发动机缺火监测要求的发动机缺火工况範围；将氧传感器替换
为劣化或有缺陷的氧传感器，或模拟相应失效模式的电气装置；断开蒸发物排放控制系统清洗电子控制装置（如果装有的话）的电路。对于这种特定的失效模式，不得进行ⅰ型测试；断开其它任何与排放有关、跟动力系管理计算机相连的零部件的电路。上述前4项失效模式均足以引起排放超过失效限值，在任何一种情形下进行试验时，故障指示器都必须在ⅰ型测试结束之前被激活。技术部门也可以采取类似断开电路的其它方法来替代上述情形。但在obd系统型式认证时，以模拟失效替代真正劣化或有缺陷的零部件的情形不得多於四项。
相应地，对於诊断信号的形成、储存和调用等也有严格的要求。
即使obd系统包含一个或多个不足（deficiency），不能完全满足规定的要求，制造商也可以要求型式认证主管机关接受该obd系统的型式认证。型式认证主管机关在考虑这类要求时，应确定顺从本附件的各项要求是否不切实际或不合理。型式认证主管机关将考虑制造商所提出、详细地描述了如技术可行性、订货至交货时间和生产周期等各种因素的数据，包括发动机或车辆设计以及计算机程序升级的逐步导入和逐步导出，以及所形成的obd系统在顺从本指令的要求方面有效到什麽程度和制造商在顺从本指令的要求方面所付出的努力。但是，型式认证主管机关不接受完全没有排放控制系统诊断监测功能的情况，也不接受不顾及obd失效限值的obd系统。
允许在自新车型型式认证之日起的两年内携带某项不足。如果能充分地证明，为了纠正该项不足对车辆必须进行的重大硬件改进和额外的导入时间超过两年，携带该项不足的期限可以宽容，但是最多不得超过三年。如果obd系统通过型式认证之後才发现某种不足，制造商可以要求原来的型式认证主管机关事後补办批准不足的手续。
（11）制造商向任何一家授权的经销商或修理厂提供维修资料後，应当在三个月内支付合理和非歧视性的费用之後向他人提供这些资料（包括後续的改进和补充资料），并相应地向型式认证主管机关通报。
eobd使管理更复杂
eobd在控制排放的硬件方面，对发动机管理系统提出一些要求，至少包括：
* 将发动机转速传感器安装在发动机离合器侧，以通过发动机转速的细微波动监测发动机缺火时避免受到曲轴扭振的影响；
* 车身垂直的加速度传感器（允许跟abs系统的加速度传感器共用）用于在道路十分差的条件下关闭eobd功能；
* 在三效催化转化器的後面增添一个氧传感器，以便用“浓”和“稀”混合气交替的方法监测三效催化转化器的储氧能力；对氧传感器监测其信号电压是否超出可能範围、响应速度是否过低、跳变时间之比是否超出规定範围、波动频率是否过低、氧传感器是否活性不足、氧传感器加热器是否加热过慢；
* 采用排气再循环系统的场合，要在进气岐管内安装压力传感器，以便进行对排气再循环率的控制，并在汽车海拔高度超过2,500米时关闭eobd功能；
* 在炭罐新鲜空气入口处安装截止阀，作为执行器和在密闭燃油箱加设压差传感器，以监测蒸发排放物控制系统的密封性。
需要说明的是，本文阐述的欧iii排放法规中有关obd的规定，并非中国政府公布的正式法律文本，所以仅供参考。但总体概念和操作程序没有太大出入。
eobd带来的启示
大量的开发和引进工作急待完成：各整车厂必须根据本厂产品的特点，如汽车的整备质量、发动机的排量、汽车动力性目标等确定其满足欧iii的发动机应当如何配置。相应地，发动机管理系统的承包商也要配合整车厂对发动机管理系统做出调整，包括在硬件和软件两方面如何引入obd系统；
必须准备维修和保养资料：根据指令70/220/eec（98/69/ec）附件xi的规定，制造商必
须向任何一家授权的经销商或修理厂提供维修和保养的资料，而且为此收取的费用必须在合理的範围内，并且不带歧视性；
对技术人员的要求更高：根据指令的规定，不再是过去那样完全根据ⅰ型测试中转鼓试验臺的排放测试数据定终身，这种局面要求各方的技术人员精通汽油机电子控制技术和obd 系统。有关各方都应当加强技术人员的培训。
KWP 2000 (ISO 15765-4) bus protocol question
| | KWP 2000 bus. I tried to get the speed alue from the bus by sending
| | the following string
| | 0xc2 0x33 0xf1 0x01 0x0d 0xf4.
| | On responce I receied two answers from 2 different ECUs:
| | 1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16
| | 1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66
| |
| | The first ECU sent me NACK
| | (This response code indicates that the requested action will not be
| | taken because the serer (ECU) does not support the arguments of the
| | request 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 the
| | request, bit it did !
You had sent a 'functional' request out to the functional address 0x33.
Any deice programmed to respond to that address will. Looking at the
standard, I see that it actually says:
"A module shall always respond to a request either with a positie or
negatie response when no transmission error has been detected."
By using functional addressing, what you actually asked was "Does
anybody know the ehicle speed (0x0D)?"
The first ECU said "I know nothing about ehicle speed", and the second
ECU said "It is 00." (the byte before the 0x66 checksum).
Once you know the specific ECU physical address 0x10 or 0xA4 aboe,
then you can be more specific with your queries.
| | And the second question is: why the first ECU did send the negatie
| | answer.
It did not say there was an error. It said that it did not support that
PID.
| | If you look at the j1979 PDF you will find there that "If an
| | ECU does not support any of the PIDs requested it is not allowed to | | send a negatie response message".
| |
I beliee that you are getting your standards confused. KWP2000 is also called ISO14230-4.
很专业，值得学习
y\有相关的标准吗?
讲得很专业
OBD II 都包含哪些协议？
各协议都是干嘛用的？
请大虾们指教
我搜集到的资料是
OBD II 都包含如下协议
ISO15765-4 (CAN)
?ISO14230-4 (KWP2000)
?ISO9141-2
?J1850 PW
?J1850 PWM
OBD-II通讯协议
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 manufacturer Recently I tried to install my product on Peuzeot(406 or something similar). There was KWP 2000 bus. I tried to get the speed alue from the bus by sending the following string 0xc2 0x33 0xf1 0x01 0x0d 0xf4. On responce I receied two answers from 2 different ECUs: 1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16 1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66 The first ECU sent me NACK (This response code indicates that the requested action will not be taken because the serer (ECU) does not support the arguments of the request 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 the request, bit it did ! And the second question is: why the first ECU did send the negatie answer. If you look at the j1979 PDF you will find there that "If an ECU does not support any of the PIDs requested it is not allowed to send a negatie response message". OBD 信息：我理解的OBD-II标准诊断插座列表
OBD车辆诊断系统技术需求说明
性能指标 3) 4) 工作环境 5) 数据保存 6) 通讯网络OBD需求 硬件要求 1) 处理器，使用 ARM 32 位处理，建议使用 Cortex-M0 2) 晶振：使用有源晶振应答；现在是无源晶体，不需要有源晶体 3) PCB： 4 层以上 PCB 4) 存储器： 8MB 以上 (5) OBD接口：包括 CAN、J1850 的 PWM 模式和 VPW模式、KWP2000 6) 低速容错 CAN： 1 路 (7) HDMI接口：终端通过HDMI接口跟OBD接口连接，线最长 1m，可以根据双方协定需求缩 短。 (1) 符合ISO7637、GB17619、GB18655等汽车电子相关技术标准 2) 主控 CPU：32 位 ARM7 工作电源：DC 8V ~ DC 36V， 30mA~2A 温度-30 C至+75 C相对湿度 20%—90% >1 0年(终端不保存数据，平台保存) 2G 8) 发动机工作时间分辨率： 1 分钟 (9) 功耗：待机w 10mA (可短信唤醒)，工作w 90mA (12V，无数据交互，无通话) 10) 短路 /过流保护：短路 /过流不造成损坏(双重保险) 11) 线路处理；硬件处理 (12)反接保护：电源线正负极接反(不高于35V)不损坏器件，不工作。 13) 线路处理；硬件处理 14) 数据交换方式： RS232、 CAN、 2G 15) 存储器： EEPROM、 Flash 闪存，且需正常保存于 ** 公司的平台下发的指令数据。 三、CDMA1X模块技术参数 (1)符合ISO7637、GB17619、GB18655等汽车电子相关技术标准 (2)CMDA 协议：IS-95 A/B, IS-98A, IS-126, IS-637A, IS-707A,IS-2000,IS-856 (3)速率：下载 153.6Kbps；上传 153.6kbps (4)通讯频率： 869Mhz ~ 893MHz (5)工作电压： DC 3.45V~4.5V (6)工作电流：w 500mA (典型)、w 2 A (峰值)、闲置w 60mA，待机w 4mA, (7)待机电流做到 3-5mA (8)工作温度：-30 C ~ +75 C； (9)消费电子；工作温度；-20——40，储存温度； -40——55度，考虑塑胶温度 (10)工作温度； -20—— 40，储存温度； -40—— 55 度，考虑塑胶温度 (11)SIM卡读取电压：支持 3V和1.8V自动识别 ( 12) 天线：内置 四、OBD读取字段需求 ( 1 )、第一期产品字段需求 7) 车速范围： 0 至 255 公里 / 小时
OBD通讯协议
OBD通讯协议 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 manufacturer Recently I tried to install my product on Peuzeot(406 or something similar). There was KWP 2000 bus. I tried to get the speed alue from the bus by sending the following string 0xc2 0x33 0xf1 0x01 0x0d 0xf4. On responce I receied two answers from 2 different ECUs: 1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16 1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66 The first ECU sent me NACK (This response code indicates that the requested action will not be taken because the serer (ECU) does not support the arguments of the request 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 the request, bit it did ! And the second question is: why the first ECU did send the negatie answer. If you look at the j1979 PDF you will find there that "If an ECU does not support any of the PIDs requested it is not allowed to send a negatie response message". OBD 信息：我理解的OBD-II标准诊断插座列表
车联网技术全面解析及主要解决方案盘点
车联网技术全面解析及主要解决方案盘点 车联网（IOV：Internet of Vehicle）是指车与车、车与路、车与人、车与传感设备等交互，实现车辆与公众网络通信的动态移动通信系统。 【慧聪汽车电子网】 车联网概念解析 2004年中国提出“汽车计算平台”计划，防范汽车工业“空芯化”现象；巴西政府强制所有车辆2014年前必须安装类似“汽车身份识别”的系统并联网；欧洲、日本的ITS（智能交通系统）计划中也都有“车联网”的概念；印度甚至要求所有黄包车都装上GPS与RFID；2011年初，中国四部委联合发文，对“两客一危”运营类车辆提出了必须安装智能卫星定位装置并联网的强制性要求……这些都是车联网的雏形。 美国国家网络可信身份标识战略白皮书NSTIC则是一个里程碑，它要求所有移动终端、包括汽车都必须安装“安全ID芯片”；美国DOT进一步要求，2012年所有运营类车辆都必须遵从M911。显而易见，车联网已经不只是一个汽车业信息化的问题了，而已经上升到了国家信息安全和国家战略层面，很多国家已经开始立法实施了。 什么是车联网 车联网（IOV：InternetofVehicle）是指车与车、车与路、车与人、车与传感设备等交互，实现车辆与公众网络通信的动态移动通信系统。它可以通过车与车、车与人、车与路互联互通实现信息共享，收集车辆、道路和环境的信息，并在信息网络平台上对多源采集的信息进行加工、计算、共享和安全发布，根据不同的功能需求对车辆进行有效的引导与监管，以及提供专业的多媒体与移动互联网应用服务。 从网络上看，IOV系统是一个“端管云”三层体系。 第一层（端系统）：端系统是汽车的智能传感器，负责采集与获取车辆的智能信息，感知行车状态与环境；是具有车内通信、车间通信、车网通信的泛在通信终端；同时还是让汽车具备IOV寻址和网络可信标识等能力的设备。 第二层（管系统）：解决车与车（V2V）、车与路（V2R）、车与网（V2I）、车与人（V2H）等的互联互通，实现车辆自组网及多种异构网络之间的通信与漫游，在功能和性能上保障实时性、可服务性与网络泛在性，同时它是公网与专网的统一体。 第三层（云系统）：车联网是一个云架构的车辆运行信息平台，它的生态链包含了ITS、物流、客货运、危特车辆、汽修汽配、汽车租赁、企事业车辆管理、汽车制造商、4S店、车管、保险、紧急救援、移动互联网等，是多源海量信息的汇聚，因此需要虚拟化、安全认证、实时交互、海量存储等云计算功能，其应用系统也是围绕车辆的数据汇聚、计算、调度、监控、管理与应用的复合体系。 值得注意的是，目前GPS+GPRS并不是真正意义上的车联网，也不是物联网，只是一种技术的组合应用，目前国内大多数ITS试验和IOV概念都是基于这种技术实现的。笔者以为，简单基于这样的技术来发展车联网，对国家战略领先和技术创新是非常不利的，会造成整体落后国际竞争的被动局面。 什么是GID IOV最核心的技术之一是根据车辆特性，给汽车开发了一款GID（GlobalID，相对于RFID）终端。它是一个具有全球泛在联网能力的通信网关和车载终端，是车辆智能信息传感器，同时也具有全球定位和全球网络身份标识（网络车牌）功能。 GID将汽车智能信息传感器、汽车联网、汽车网络车牌三大功能融为一体，具体表现为： 车辆状态的信息感知功能：GID与汽车总线（OBD、CAN等）相连，内嵌多种传感器，可感知和监控几乎所有车辆的动态与静态信息，包括车辆环境信息和车辆状态诊断信息等； 泛在通信功能：GID具有V2V、V2I和自组网（SON、移动AdHoc、AGPS等）的能力，具有车内联网以及多制式之间的桥接与中继功能，具备全球通信、全球定位与移动漫游能力；
tl718,obd汽车通讯协议芯片资料
竭诚为您提供优质文档/双击可除tl718,obd汽车通讯协议芯片资料 篇一：标准的obd2诊断程序+相关应用层协议 标准的汽车obd2诊断程序以及相关应用层协议下载 开发标准obd2诊断程序要准备的资料及硬件 1、因tl718已经为你建立了物理层、数据链层和部分应用层的协议，所以只要obd2标准应用层协议文本， iso15031-5或saej1979（这两个协议是相同的内容）。 这里可下载： 下载：saej1979-20xx670kb iso15031-53.46mb 2、tl718诊断接口1套或用tl718芯片自建电路。 3、家用pc机电脑一台。 4、安装软件：accessport调试软件及Vc++（或Vb、bc++等）你喜欢的开发软件。 5、符号obd2标准的汽车发动机电脑一块（或汽车一台） 准备好以上这些，你就可以开始你的obd2标准程序开发了！！！ tl718基本信息
tl718芯片的技术数据手册 tl718通过一个uaRt串口与单片机、pda或pcRs232通讯，在有的新的pc机上已没有装备Rs232串口，可以通过 虚拟串口实现与tl718通讯，例usbtoRs232、以太网toRs232、或蓝牙toRs232等等。 -------Rs232------obd2电缆 ----------|pc||tl718||汽车诊断口 |----------------------- 不管使用怎样的物理连接，你可以使用超级终端或串口调试工具，直接通过 键盘发送和接收字符。在使用串口调试软件前，首先必须设置正确的com端口号和正确的波特率。一般为9600波 特率（pin6=0V），或38400波特率（pin6=Vcc，ppoc设置默认值）。串口设置为：8个数据位，校验位：0，停止位1位。如果设置错误，将不能和tl718正常通讯。所有从tl718的响应以一个回车符（0x0d）及一个可选的换行符（0x0a）结束。正确连接，打开电源后。tl718将驱动测试led灯，（闪亮3次）后，发送： tl718starting 〉 如果正确收到以上信息代表串口及连接设置正确。第二行“〉”符号代表tl718为空闲状态，可以立即从Rs232接
obd协议
竭诚为您提供优质文档/双击可除 obd协议 篇一：汽车obd协议 汽车议简介 一．obd简介 早在20世纪80年代初，汽车工业发达国家的许多汽车制造商就开始广泛使用电喷发动机。电喷发动机控制系统中就设有第一代车载故障诊断系统（on_boarddiagnostics).以后车载故障诊断系统逐步在微机控制的自动变速器、防抱死制动系统、安全气囊、巡航系统中相继得到应用。该系统能在电控装置的工作过程中随时监测系统中各部分的工作状况，当电控系统出现故障时，故障信息存储在微机中，汽车维修人员按规定方法跨接诊断连接器中的相应端子，对汽车电控系统的故障进行分析、诊断。 二．obd发展史 obd的概念最早是由通用汽车(gm)于1982年引入的，其目的是监测排放控制系统。一旦发现故障，obd系统会点亮仪表板上的一个指示灯以通知驾驶员，同时在车载计算机（通常称作发动机控制单元或模块，即ecu或ecm）内记录
一个代码，这个代码可通过相应设备获取以便于故障排除。通用汽车提出这一概念引起加州空气资源委员会（caRb）的重视。caRb于1985年采用了sae所制定的标准，要求从 my1988起所有在加州销售的车辆都必须具有一些基本的obd 功能。之后，美国环保局(epa)要求自1991年起所有在美国销售的新车必须满足相关obd技术要求，这就是后来所说的obd-i。 汽车工程师协会(sae)对诊断接口、通讯方式等技术细节进行了进一步标准化工作，obd-i在此基础上发展成为第二代obd，即obd-ii。 obd-ii在诊断功能和标准化方面都有较大的进步。故障指示灯、诊断连接口、外部设备和ecu之间的通讯协议以及故障码都通过相应标准进行了规范。此外，obd-ii可以提供更多的数据被外部设备读取。这些数据包括故障码、一些重要信号或指标的实时数据，以及冻结桢信息等。此后的1998年10月13日欧盟委托iso组织在obd-ii制定了eobd标准，我国也在20xx年4月5日在eobd标准上制定了一套cobd 标准 新一代的无线传输系统obdiii系统能够利用小型车载无线收发系统，通过无线蜂窝通信，卫星通信或者gps系统将车辆的Vin,故障码及所在位置等信息自动通告管理部门。管理部门根据该车辆排放问题的等级对其发出指令，包括去
OBD传输协议定制开发
OBD传输协议定制开发 为了更好服务好客户，速锐得科技在OBD传输协议定制开发过程中可新增部分AT指令、重新定义部分命令字，修改部分AT指令格式，按照指定传输协议定制开发OBD产品。、速锐得科技的OBD产品带有自动点火判断、自动熄火判断、自动识别自动启停车型判断，不会给客户带来误报、误判，其油耗、里程的算法精准性，在国内都是处于领先水平。 1、整合G*SENSOR数据流，去除12组向量数据，在$OBD-RT数据后新增故障码数量、本次急加速次数、本次急减速次数、本次急转弯次数，在$OBD-HBT后新增累计急加速次数、累计急减速次数、累计急转弯次数，车辆碰撞采用触发式消息上报； 2、可修改调试模式下的串口数据显示； 3、可修改调试模式下不进入休眠，不进行掉电检测； 4、新增车速阀值设定/获取，超速将上报当前位置、速度信息； 5、新增获取电瓶电压指令； 6、新增低电压阀值设定/获取，休眠模式下，每1小时自动唤醒读一次电瓶电压，如低于阀值，将上报消息至后台； 7、新增车辆熄火后，自动生成本次行程报告； 8、修复SIM卡网络信号问题； 9、修改车辆启动后无网络信号延迟提醒机制； 10、修复flash数据问题； 11、修复调试串口缓存接收机制； 12、支持在线升级； 手册具体详情可以参考《车联网OBD标准智能硬件OBD+GPRS+GPS模块数据接API_V0.4.pdf》 一、协议规范 ● 服务器端AT请求指令语法规范 ● 终端上传数据包格式规范 三、终端模式切换 四、指令列表 五、终端主动上报消息格式定义 ● 01-默认数据流 ● 02-车辆启动提醒 ● 03-车辆熄火提醒 ● 04-终端准备进入休眠提醒 ● 05-终端掉电提醒 ● 06-车型协议不支持或者通讯失败提醒 ● 07-超速报警 ● 08-低电压报警 ● 09-车辆碰撞报警 六、终端系统设置指令 ● 81-请求终端设备信息 ● 82-请求终端当前时间 ● 83-设置终端当前时间 ● 84-设置上传间隔时间 ● 85-请求当前设置的上传间隔时间
obd的接口协议
竭诚为您提供优质文档/双击可除 obd的接口协议 篇一：obd_的基本常识介绍 obd的基本常识 更新时间：20xx-5-2214:07:11 obd是英文on-boarddiagnostics的缩写，中文翻译为“车载自动诊断系统”。 这个系统将从发动机的运行状况随时监控汽车是否尾 气超标，一旦超标，会马上发出警示。当系统出现故障时，故障(mil)灯或检查发动机(check engine)警告灯亮，同时动力总成控制模块(pcm)将故障信息存入存储器，通过一定的程序可以将故障码从pcm中读出。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。 obd是英文on-boarddiagnostic的缩写，中文翻译为“车载诊断系统”。这个系统随时监控发动机的运行状 obd云鼠（ugV04）图片 况和尾气后处理系统的工作状态，一旦发现有可能引起排放超标的情况，会马上发出警示。当系统出现故障时，故
障(mil)灯或检查发动机(check engine)警告灯亮，同时obd系统会将故障信息存入存储器，通过标准的诊断仪器和诊断接口可以以故障码的形式读取相关信息。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。 从20世纪80年代起，美、日、欧等各大汽车制造企业开始在其生产的电喷汽车上配备obd，初期的obd没有自检功能。比obd更先进的obd-Ⅱ在20世纪90年代中期产生，美国汽车工程师协会(sae)制定了一套标准规范，要求各汽车制造企 业按照obd-Ⅱ的标准提供统一的诊断模式，在20世纪90年末期，进入北美市场的汽车都按照新标准设置obd。 obd-Ⅱ与以前的所有车载诊断系统不同之处在于有严 格的排放针对性，其实质性能就是通过监测汽车的动力和排放控制系统来监控汽车的排放。当汽车的动力或排放控制系统出现故障，有可能导致一氧化碳(co)、碳氢化合物(hc)、氮氧化合物(nox)或燃油蒸发污染量超过设定的标准，故障灯就会点亮报警。 obdii的特点： 1.统一车种诊断座形状为16pin。 2.上有数值分析资料传输功能(datalinkconnectoR简 称dlc)。
OBD协议详情说明书(个人)
OBD协议数据流说明 需要确认的问题： 1、支持的车型？ 2、油耗、里程读取？ 3、OBD协议中是否支持读取和控制车门窗的状态信息？ 4、OBD能读取数据 5、比较本人整理的ISO15031-5和北京金奔腾科技公司的OBD协议 数据流 答案： 1、我国采用了EOBD相同的要求即ISO15031-5(道路车辆-车辆与排放诊断相 关装置通信标准-5排放有关的诊断服务)协议。 所以只要该车支持ISO15031-5的OBD2标准协议中所有项，则可以通过OBD接口读取出ECU中所有信息；若该车支持标准协议中部分项，则读取出支持项信息。(标准协议附在下面，由北京金奔腾汽车科技公司提供。) 2、在ISO15031-5协议中，油耗不能读取，只能读取燃油液位输入 (读出油 箱剩余油量与油箱容量的百分比)。在车上通过燃油液位传感器实现对剩余油量检测。 OBD输出信息中跟里程相关只有：故障灯点亮后行驶的里程数、消除故障后行驶的里程数。 里程获取办法： 1、虽然不能直接获得总里程，但可以总里程=安装前里程数+故障灯点亮 后行驶的里程数+消除故障后行驶的里程数。 2、OBD2协议中无法直接读取仪表上数据，只有通过购买汽车厂家的OBD2 协议的扩展，可获得汽车仪表系统数据获取，肯定能获取汽车总里程和车 门窗信息。由于成本太高，所以不现实。 3、在车轮处安装及车轮转过圈数的传感器 4、还有通过GPS获取总里程。 3、在ISO15031-5的OBD协议中不支持读取和控制车门窗的状态信息。 4、读取信息是从ISO15031-5协议中分析出来： 我们关注输出信息有： 注：PID：OBD系统输出的每个参数都对应一个使用16进制表示的PID (Parameter
汽车 OBD能够实现的功能解析
未来汽车技术的发展趋势是电子化、智能化、信息化和集成化。我国汽车产业正面临着全面的技术和产品提升，其中最重要的就是汽车电子智能信息化的快速发展。 近年来欧盟和美国等国家更是将物联网、车联网上升为国家战略高度，中国也在2009年启动“感知中国项目”,国家“十二五”规划明确提出，物联网将会在智能电网、智能交通等领域重点部署。汽车移动物联网(车联网)项目被列国家重大专项，国家计划出资百亿资金扶持。2011年4月6日国家财政部颁布《物联网发展专项资金管理暂行办法》，在实处上推动我国智能信息化发展。 随着汽车智能化增值服务的日益增强，现市场物联网，车联网也不断发展与成熟。相信中国将会在汽车高科技智能信息化方面会形成一个强大的汽车增值服务行业。 智能车载远程诊断模块 ★产品分类：分轿车和卡车故障诊断模块 ★产品功能： 1、远程读取故障码和清除故障码 2、加速度测试 3、精准读取里程和油耗 4、油耗实时监测 5、胎压监测 6、安全报警提醒 7、健康行驶报告 备注：卡车没有加速度测试、胎压监测、健康行驶报告功能。 ★产品技术参数： ◎规格：63mmx41mm ◎输出协议方式：RS232 ◎波特率：9600或19200 ◎工作电压：5v-36v
◎工作电流：25mA-70mA ◎协议支持：支持OBD-II车载诊断通讯协议及参数、ISO15765-4（CAN）、ISO14230-4 （KWP2000）、ISO9141-2、J1850VPW、J1850PWM ★产品特色: 1、汽车4S店和维修站最关心“里程”和“油耗”两个参数，通过精准“里程”的读取里程，可以通知车主定期回来维修和保养，同时也提醒车主何时对车进行保养。 2、方便企业管理自身车辆，便于对车辆进行评估考核和用车节省成本； 3、车主可以通过手动对车辆进行诊断检测，了解车辆的运行情况，实时掌握车辆的安全状况； 4、在线TSP服务，当车主外出行驶过程中出现故障时，可以远程对车辆进行整车系统扫描、整车故障诊断、清除历史（偶发）故障码，并将真实的故障码进行解析，远程提供维修指导等增值服务。车主亦可以发送诊断数据报告给维修站或4S店进行远程专家会诊，远程提供维 修指导。 ★应用领域：该模块广泛应用于车载GPS、车载DVD、车载PC、PND导航、MID以及平板电脑上。 产品二：车载智能故障远程诊断GPS系统 ★产品分类：分轿车和卡车智能车载远程诊断GPS系统 ★产品功能： 1、采用2G/3G网络通讯，支持GSM/GPRS通讯； 2、实时跟踪定位，轨迹回放； 3、支持GPS/LBS(GSM基站)双重定位； 4、设计有OBDII标准接口，能读取车辆仪表信息/故障 5、精准读取“里程”和“油耗”信息 6、远程读取汽车故障和清除故障码 7、一键报警/超速报警/越界报警（短信电话提示） 8、支持油量监测，ACC点火检测，空调开关检测； 9、防拆报警/手机断油/断电 10、后台与车辆直接相互通话 ★产品特色: 1、用户最关心“里程”和“油耗”两个参数，用于管理车辆和节省成本。 2、通过对车辆进行远程诊断，了解车辆的运行情况，实时掌握车辆的安全状况。 3、方便企业管理自身车辆，便于对车辆进行评估考核工作； 4、4S店和维修站通过精准“里程”的读取，可以通知车主定期回来维修和保养，避免客户流失。
OBD车辆诊断系统技术需求说明
OBD需求 一、硬件要求 （1）处理器，使用ARM 32位处理，建议使用Cortex-M0 （2）晶振：使用有源晶振 应答；现在是无源晶体，不需要有源晶体 （3）PCB：4层以上PCB （4）存储器：8MB以上 （5）OBD接口：包括CAN、J1850的PWM模式和VPW模式、KWP2000 （6）低速容错CAN：1路 （7）HDMI接口:终端通过HDMI接口跟OBD接口连接，线最长1m，可以根据双方协定需求缩短。 二、性能指标 （1）符合ISO7637、GB17619、GB18655等汽车电子相关技术标准 （2）主控CPU：32位ARM7 （3）工作电源：DC 8V ~ DC 36V，30mA~2A （4）工作环境：温度–30 ℃至+75 ℃相对湿度20%—90% （5）数据保存：>10年（终端不保存数据，平台保存） （6）通讯网络：2G （7）车速范围：0至255公里/小时 （8）发动机工作时间分辨率：1分钟 （9）功耗：待机≤10mA（可短信唤醒），工作≤90mA (12V，无数据交互，无通话) （10）短路/过流保护：短路/过流不造成损坏（双重保险） （11）线路处理；硬件处理 （12）反接保护：电源线正负极接反（不高于35V）不损坏器件，不工作。 （13）线路处理；硬件处理 （14）数据交换方式：RS232、CAN、2G （15）存储器：EEPROM、Flash闪存，且需正常保存于**公司的平台下发的指令数据。 三、CDMA1X模块技术参数 （1）符合ISO7637、GB17619、GB18655等汽车电子相关技术标准 （2）CMDA协议：IS-95 A/B, IS-98A, IS-126, IS-637A, IS-707A,IS-2000,IS-856 （3）速率：下载153.6Kbps；上传153.6kbps （4）通讯频率：869Mhz ~ 893MHz （5）工作电压：DC 3.45V~4.5V （6）工作电流：≤500mA（典型）、≤2 A（峰值）、闲置≤60mA，待机≤4mA，（7）待机电流做到3-5mA （8）工作温度：–30 ℃~ +75 ℃； （9）消费电子；工作温度；-20——40，储存温度；-40——55度，考虑塑胶温度（10）工作温度；-20——40，储存温度；-40——55度，考虑塑胶温度 （11）SIM卡读取电压：支持3V和1.8V自动识别 （12）天线：内置
OBD简介解析
?有效的控制在用车排放水平； ?为车辆的保养和维修提供了便利的手段； ?通过其提供的实时数据为爱好者提供了乐趣。 OBD的工作方式 ?识别排放相关部件的故障（参看OBD的诊断功能）； ?发现故障后通过仪表板上的故障指示器通知驾驶员； ?把故障诊断的相关信息存储在电控单元的存储器中，这些信息通过相应的设备，即扫描工具（诊断仪），或者安装了相应软件的计算机连接到车载诊断接口读取。
?2005年4月5日，国家环境保护总局【公告(2005)14号】颁布《轻型汽车污染物排放限值及测量方法（中国III、IV阶段）》GB 18352.3–2005，自2007年7月1日起实施。18352.3–2005明确了我国对车载诊断功能的相关要求。 ?2008年1月24日，国家环境保护总局办公厅【环办函(2008)35号】征求对《轻型汽车车载诊断（OBD）系统管理技术规范》草案的意见。 o《轻型汽车车载诊断（OBD）系统管理技术规范》征求意见稿 o《轻型汽车车载诊断（OBD）系统管理技术规范》编制说明 北京 ?2005年12月23日，北京环保局和北京市质量技术监督局发布公告【京环发(2005)214号】，宣布自2005年12月30日起，在北京市销售新定型车型（包括全新产品及产品扩展与更改）须安装车载诊断（OBD）系统，2005年12月30日前已 定型上市销售并通过国家第三阶段排放标准审核的车型可延迟安装OBD系统；2006 年12月1日后，停止在北京销售未安装OBD系统的新车。 ?2006年1月12日，北京环保局公布了【京环发(2006)4号】第一批达到国III排放标准，且带OBD功能的轻型车目录。 ?2006年11月15日，北京环保局再次发布公告【京环发(2006)214号】，重申半个月后的12月1日起，北京市将停止销售未安装车载诊断系统（OBD）的国Ⅲ轻型汽车。 广州
OBD 产品分析报告
OBD 产品分析报告 一、主流OBD分析 二、产品消费群体特征。 以年轻人有车群体，中低端车型为主。对互联网、汽车感兴趣，喜欢新鲜事物。部分客户可能因为本身没有行车电脑而选择购买。
三、产品芯片分析。 1.名称：元征GOLo4 价格：499 其诊断控制，连接芯片采用LAUNCH品牌，其实就是 元征自己研发的芯片，G229gps，MTK双核入门处理器，MTK GSM芯片。 2.名称：miniOBD 价格：20-30元 芯片采用PIC18F25K80，这款芯片模拟了国外 正品ELM327的2480芯片。蓝牙芯片采 用 BEKEN BK3231Q，信号差，容易掉线，焊 点粗糙，电流过大后会烧行车电脑。 2.名称：腾讯路宝盒子 价格：199 芯片采用st公司的STM32F103，三轴加速度 传感器采用ADI公司ADXL345，蓝牙采用ISSC 方案。 四、产品性能分析 可见，目前市场主流OBD都支持车况检查、手机APP连接，这里主要对几项必须功能进行简单描述： 1.车况检查，读取汽车电脑数据，对电脑数据进行解析。
2.碰撞提醒，车子不在车主身边，如汽车发生碰撞或被强开等事件，则会提醒车主。 3.WIFI，可提供乘客WIFI上网。 4.连接模式，主流连接模式采用蓝牙，辅助GPRS或WCDMA，不用蓝牙连接手机端无 法实时显示。 5.好友互动，可以与车主的好友进行互动，部分数据展示。 产品主要隐患：信息安全、车辆控制、数据准确率 五、政策环境。 2008年6月24日，环境保护部发布《车用压燃式、气体燃料点燃式发动机与汽车车载诊断（OBD）系统技术要求》，并宣布此要求从2008年7月1日起实施。 我国采用了EOBD相同的要求即ISO15031-5(道路车辆-车辆与排放诊断相关装置通信标准-5排放有关的诊断服务)协议。所以只要该车支持ISO15031-5的OBD2标准协议中所有项，则可以通过OBD接口读取出ECU中所有信息；若该车支持标准协议中部分项，则读取出支持项信息
OBD解析
OBD解析 EOBD：European On Board Diagnostic （欧洲）车载诊断系统。 OBD是一套复杂的、用于随时监测汽车排放的零部件故障的系统。汽车排放零部件是指：出现故障后会导致排放超过OBD限制的零部件。这和软件控制算法以及硬件系统组成密切相关。确定哪些零部件为“排放相关零部件”是EMS供应商在开发EOBD系统前期需要做的一项重要工作，他们必须要经过一系列试验来确定这些零部件。当然整车厂完全可以根据自己车辆的具体情况在车辆所配置的OBD系统中增加或者删除某些零部件。 EMS：Electronic Management System EOBD的焦点是放在排放上，如果排放超标（通过零部件是否故障来判断的），MIL指示灯就会点亮以提示驾驶员车辆的排放系统有问题，需要检修。 故障信息存储和故障定位 一旦检测到某个故障并得到确认，系统就会生成对应的故障代码，并将故障代码存储下来，供将来维修的时候使用。维修人员通过标准的扫描工具就可以读取故障码信息，根据故障码信息就可以确定发生故障的零部件以及故障类型，当然至于是什么原因引起的故障还需要维修人员自己进行分析。比如发生失火的时候，系统只会记录发生失火的气缸号以及存储发生失火时的冻结帧信息供以后检修时进行故障重现，但并不能明确指出引起失火的原因（引起失火的原因太多了），不过通过发生失火时存储的冻结帧信息一般可以判断出引起失火的原因。 OBD并不是直接监测排放中的废气是否超过法规值，而是通过监测排放相关的零部件故障的系统。OBD标定工作实际上就是确定一系列零部件的临界工作状态（包括催化器临界状态、氧传感器临界状态、导致催化器损坏的临界失火率、导致排放超标的临界失火率等等。过了临界状态则排放可能出现超标），然后ECU按照这个临界标准来判断零部件是否出现故障，如果是，则点亮MIL灯，说明排放超标。 由此我们可以看出，OBD是否能够可靠的工作，完全依赖于EMS供应商对零部件的这个临界态条件是否合理设置。所以我们提供的临界态样件需要严格控制，满足要求（特别是临界态催化器），同时对于重要零部件也提出了很好的耐久性要求。 催化转化器的车载诊断： 通过判断催化器前后氧传感器的电压来确定催化转化器的储氧能力（OSC：oxygen storage cablity）,Dephi的监测方法是改变空燃比（从15.6到13.6），如果后氧传感器对排气中氧含量的变化反应时间很短（反应时间小于标定时设定的劣化反应时间值），就说明催化器已经丧失储氧能力，被劣化。 在对催化器转化器的控制中，相对没有OBD系统的车辆而言，多了一个后级氧传感器，它的作用第一是监测后级的排气氧含量，第二是帮助系统更好的控制空燃比。氧传感器应该选择更容易起燃（达到工作温度）的氧传感器（加热型氧传感器）。 OBD中失火监测模块： 发动机失火时由于动力的突变，车辆会产生振动，所以OBD通过车辆的振动来判断失火，ECU模块通过计算得到的失火率如果超过了标定时给定的临界失火率，则点亮MIL指示灯。在路面非常颠簸时，通过： 1.加速度传感器（安装在发动机前舱减震支架处）的信号来判断是否暂时屏蔽失火监测模 块。或者： 2.通过安装在副驾驶一侧的驱动轮的转速信号来判断是否屏蔽失火监测模块。如果车辆安 装了ABS，则可以由ABS向ECU转发了转速信号，如果没有ABS，则需要安装一个转速传感器。（转速传感器比加速度传感器便宜50RMB）
平台通讯协议-OBD远程车况诊断协议V1
平台通讯协议-OBD远程车况诊断协议V1
7 状态掩码10 u8 汽车状态掩码，表示10类汽车状态支持与否 17 安全状态 1 u8 Bit0 1/0 ON/OFF ACC状态 Bit1 1/0 设防/撤防设防撤防状态Bit2 1/0 踩下/松开脚刹 Bit3 1/0 踩下/松开油门 Bit4 1/0 拉起/放下手刹 Bit5 1/0 插入/松开主安全带 Bit6 1/0 插入/松开副安全带 Bit7 1/0 预留 18 门状态 1 u8 Bit0 1/0 开/关左前门LF Bit1 1/0 开/关右前门RF Bit2 1/0 开/关左后门LB Bit3 1/0 开/关右后门RB Bit4 1/0 开/关后备箱TRUNK Bit5 1/0 开/关发动机盖 Bit6-7 预留 19 锁状态 1 u8 Bit0 1/0 落锁/开锁左前锁LF Bit1 1/0 落锁/开锁右前锁RF Bit2 1/0 落锁/开锁左后锁LB Bit3 1/0 落锁/开锁右后锁RB Bit4-7 预留 20 窗户状态 1 u8 Bit0 1/0 开/关左前窗LF Bit1 1/0 开/关右前窗RF Bit2 1/0 开/关左后窗LB Bit3 1/0 开/关右后窗RB Bit4 1/0 开/关天窗开关 Bit5 1/0 开/关左转向灯 Bit6 1/0 开/关右转向灯 Bit7 1/0 开/关阅读灯 21 灯光状态1 1 u8 Bit0 1/0 开/关近光灯Bit1 1/0 开/关远光灯Bit2 1/0 开/关前雾灯Bit3 1/0 开/关后雾灯Bit4 1/0 开/关危险灯Bit5 1/0 开/关倒车灯Bit6 1/0 开/关 AUTO灯Bit7 1/0 开/关示宽灯 22 开关状态A 1 u8 Bit0 1/0 ON/OFF 机油报警Bit1 1/0 ON/OFF 燃油报警Bit2 1/0 开/关雨刷 Bit3 1/0 开/关喇叭 Bit4 1/0 开/关空调 Bit5 1/0 开/关后视镜状态
所有柴油车诊断插座通讯协议和接线方法
所有柴油车诊断插座通讯协议和接线方法所有柴油车诊断插座通讯协议和接线方法 一、K线诊断线判断和接线步骤: 1.梯形OBD(AK-28形状)的7#，圆形16针(AK-33)的8#； 2.量取电压略低于整车电压1~2V左右； 3.诊断接头配线方式：电源、地线、信号线，请注意信号与电源的区别。 诊断方法: 1.请根据诊断仪提示使用专用接头，常使用：AK-28或AK-33； 2.若为玉柴则请使用：AK-35 3.万用接头使用方法:AK-35的K-LINE(蓝色)接到车辆的信号线，用点烟器车载供电，然后开始诊断；
二、CAN诊断线判断步骤: 1.用万用表量取诊断线电压:CAN高(CAN_H)为: 2.6V左右，CAN低(CAN_L)为:2.4V左右； 2.关闭钥匙量取信号线(CAN_H与CAN_L)之间电阻为120欧姆,若车辆上有其他Can网络则可能为60欧姆； 3.若以上皆不符合则请检查车辆线束，确保信号线能正常通信。 诊断方法: 1.请使用康明斯专用接头:AK-02或AK-32或AK-35诊断； 2.万用接头使用方法:AK-35的CAN_H连接车辆上CAN_H，CAN_L连接车辆上CAN_L；
注意：请确认车载取电。 备注：K—line 和CAN_L、CAN_H 是最常见最基本的诊断通讯方式 三、BOSCH 系统诊断接口规范——西门子VDO共轨诊断接口规范 一）BOSCH EDC7UC31 EDC16C39 EDC17/17 EDC16UC40 EDC16C8 EDC16M S6.3 诊断位置:继电器盒内,油门踏板上方,仪表盘附近,正副驾驶员中间等; 诊断座形状及配置: 1.方形标准OBD->用AK-02/28; 配置:电源线(1根),地线(1或2根),信号线(1根,7号位); 2.圆形16PIN->用AK-33; 配置:电源线(1根),地线(1根),信号线(1根,8号位); 注意:客车上注意与威伯科ABS诊断接口区别. 诊断线识别方法: 1.查车辆上常电源电压; 2.诊断接口上的信号线一般是低于常电源1V左右; 3.BOSCH EDC7 ECU多为89号信号线,EDC16 ECU多为25号信号线.
ecu通讯协议
竭诚为您提供优质文档/双击可除 ecu通讯协议 篇一：整车控制器通信协议最新版 纯电动汽车 动力系统网络通信协议 Version090302 本协议仅用于纯电动汽车动力系统的电子控制单元（ecu）之间进行控制器局域网络（传输速率500kbit/s）数字信息交换。 1本协议适用范围 本协议仅用于纯电动汽车动力系统电子控制单元之间的网络互通互连，使控制系统能正常工作。 2连接器管脚定义 采用db9插头，can-h(pin7)、can-l(pin2)、屏蔽线(pin5)、gnd(pin3,6)。 3报文格式 本协议采用29位扩展帧，符合sae1939协议，图2所示为can扩展帧格式。 4ecu的名称
本协议对网络上的每个ecu节点都规定了一个名称，名称表示了其所执行5动力系统can网络通信速率 电动汽车通信网络采用500kbps的通信速率。 6纯电动汽车动力系统网络通信报文6.1整车控制器(Vcu) 6.1.1Vcu发送的数据帧(Vcu2mcu) 注：电机给定转矩为带符号12位数据。两字节数据低字节在前，高字节在后；同一字节中高位在前，低位在后。 6.2电机控制器（mcu） 6.2.1mcu上传给Vcu的数据帧a(mcu2Vcua) 电机驱动器直流总线电压为无符号12位数据； 两字节数据低字节在前，高字节在后；同一字节中高位在前，低位在后。 6.2.2mcu上传给Vcu的数据帧b(mcu2Vcub) 两字节数据低字节在前，高字节在后；同一字节中高位在前，低位在后。 6.2.3mcu控制参数表 篇二：电动汽车通讯协议 文件编号:tkc/js(s)-eV33文件版本号:0/a版 安徽天康特种车辆装备有限公司 纯电动专用车辆通讯协议(VeR1.2) 编制:审核:批准: