OBD-II Network Standards
» J1850 VPW
– Adopted by GM; also known as Class 2.
– Adopted by Chrysler (known as J1850).
– Some references to VPW 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 value from the bus by sending
the following string
0xc2 0x33 0xf1 0x01 0x0d 0xf4.
On responce I received 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 server (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 service.)

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 negative
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 negative response message".
OBD 信息： obd-ii标准诊断插座列表

    端子号称         端子接线
---------------------------------------------------------------------
4         搭铁
16        蓄电池正极，9-12v
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 vpw可变脉宽调制 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协议 
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 (Service 1, Parameter 0)
Car -> Tester 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)
Car -> Tester 0x00 0x00 0x00 0x00 0x00 Garbage!!
Tester -> Car 0x68 0x6a 0xf1 0x02 0x00 0x00 0xC5 Request (Service 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... every time I tried this,
it has behaved the same way - useless. After a successful initialization,
it just responds "zeros" back to every 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 vpw（可变的脉冲宽度调节）通讯协议电路。
  美国通用（gm）汽车公司生产的轿车及轻型载货车汽车使用ase j1850vpw通讯协议电路。
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和欧iv排放法规，内容 包括：
（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 value from the bus by sending
| | the following string
| | 0xc2 0x33 0xf1 0x01 0x0d 0xf4.
| | On responce I received 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 server (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 service.)
| |
| | 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 device 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 positive or
negative response when no transmission error has been detected." 

By using functional addressing, what you actually asked was "Does
anybody know the vehicle speed (0x0D)?"
The first ECU said "I know nothing about vehicle 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 above,
then you can be more specific with your queries.

| | And the second question is: why the first ECU did send the negative
| | 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 negative response message".
| |

I believe that you are getting your standards confused. KWP2000 is also
called ISO14230-4.