• <dl id="m3hdh"></dl>

    <output id="m3hdh"></output>

          1. <output id="m3hdh"></output>

                  1. <output id="m3hdh"></output>

                  2. <dl id="m3hdh"><font id="m3hdh"><nobr id="m3hdh"></nobr></font></dl>
                  3. <dl id="m3hdh"></dl>
                  4. <dl id="m3hdh"></dl>
                      <dl id="m3hdh"></dl>

                      <li id="m3hdh"></li>

                      OBD通讯协议知识

                      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标准诊断插座列表

                      OBD-II通讯协议(如何知道汽车使用的哪一种) - 何正茂 - autolife爱汽车 爱生活
                      端子号称 端子接线
                      ---------------------------------------------------------------------
                      4 搭铁
                      16 蓄电池正极,9-12v
                      7,15 资料数据传输线(iso 9141-2)
                      5 信号反馈线搭铁
                      2 sae j1850数据输送线
                      10 sae制造厂数据输送线
                      举一?#36947;?#25463;达前卫诊断座t16中;就有16 4 7三个端子按以上要求接线。
                      EOBD ?#20998;?#26631;准
                      新的 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 eobd
                      进行燃油箱及燃油系?#36710;?#27899;漏试验
                      探测发动机不(发)点火的转速到 最大 4500r/min
                      ?#25910;?#21457;生经历多少个驾驶周期?#25910;?#25351;示灯才闪亮 2 2-10
                      用?#25910;?#25351;示灯显示汽车行驶距离
                      使用的通讯协议 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 (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标准部?#36136;?#29992; ISO9141物理连接 定义在J1962 的7号脚就是我们常说的 K 线
                      标准OBD-II 协议 ISO-9141 特点 PCM动力系统 5波特?#23454;?#22336;码 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(克莱斯勒)汽车和所有?#20998;?#29983;产的汽车以?#25353;?#22810;数亚洲进口的汽车都使用国际标准化组织sio 9141通讯协议电路。
                      2 ase j1850 vpw(可变的脉冲宽度调节)通讯协议电路。
                      美国通用(gm)汽车公司生产的轿车及轻型载货车汽车使用ase j1850vpw通讯协议电路。
                      3 ase j1850 pwm(脉冲宽度调节)通讯协议电路。
                      福特(ford)汽车公司汽车使用该种通讯协议电路。
                      根据iso 15031-5标准,can(控制器局域网)采用iso 15765-4标准。
                      obdii和eobd都使用三个基本的通讯协议。然而有的制造商在通讯协议上做了一些修改。但是克莱斯勒和大多数亚洲进口的汽车和所有?#20998;?#29983;产的汽车都使用国际标准化组织iso 9141通讯协议电路。
                      美国车载诊断技术(obdii)
                      ?#20998;?#36710;载诊断技术(eobd)
                      从欧i到欧ii,虽然说?#27431;?#38480;值有所趋严,相对来说还比较容?#36164;?#29616;。欧iii的难点不仅在于?#27431;?#38480;值收紧,应该说,从欧ii到欧iii是一个飞跃,两者的主要差别在于:
                      * 取消发动机起动後不采样的40秒钟怠速?#21495;穒和欧ii?#27431;欧?#35268;的测试循环中,发动机起动後有一段40秒怠速阶段,在此期间排出的废气不予采集;欧iii则取消了这怠速,从发动机开始起动就采集废气样本;
                      * 氮氧化物的?#27431;?#21333;独考核:在欧i和欧ii?#27431;欧?#35268;中,将碳氢化合物和氮氧化物的?#27431;?#37327;合在一起算总账,只对两者之和制订一个限值标准,但是欧iii分别规定碳氢化合物和氮氧化物的限值;
                      * 增添-7℃以下的冷起动试验?#21495;穒ii增添了一项在-7℃以下的环境进行的冷起动试验;
                      * 对?#27431;?#25511;制装置的?#36884;?#24615;要求更加严格?#21495;穒ii要求?#27431;?#25511;制装置在行驶5年或8万公里之後,仍能满足型式认证的?#27431;?#35201;求;
                      * 引入eobd:从欧iii开始要求引入?#20998;?#36710;载诊断技术eobd,分阶段执行相关的法规。
                      用於?#27431;?#25511;制的系统  eobd(european on-board diagnostics),简称obd(on-board diagnostics),即“车载诊断技术”或简称“车载诊断”。欧i和欧ii?#27431;欧?#35268;阶段的发动机管理系统都带有车载?#25910;?#35786;断功能,但是在欧iii排 ?#27431;?#35268;中,obd隐含着专门用於?#27431;?#25511;制的意思,根据定义,它是“用於?#27431;?#25511;制的车载诊断系统?#20445;?#32780;且必须能够通过储存在计算机存储器中的失效代码?#35789;?#21035; ?#25910;系?#21487;能範围。
                      美国加利福尼亚州率先于1994年以立法的形式提出了利用车载诊断技术对?#27431;?#25511;制装置实行?#25910;?#30417;测的要求,称为obdⅱ。後 来,?#20998;?#20063;制订了从2000年跟欧iii同时生效的指令70/220/eec(98/69/ec)附件xi。该指令适用于欧iii和欧iv?#27431;欧?#35268;,内容 包括:
                      (1)所有车辆必须装备obd系统,其设计、制造和安装应能确保车辆在整个生命期内识别劣化类型和?#25910;?#31867;型。
                      (2)当?#27431;?#25511;制系统(与发动机电子管理系统以及排气系统或蒸发物控制系统中,任何与?#27431;?#26377;关、向电子控制单元提供输入信号或从电子控制单元接受输出信号的零部件)失效导致?#27431;?#36229;过规定的极限值(下文称为失效限值)时,obd系统必须指示它们的失效。
                      (3)汽油机obd系统必须监测下列项目:三效催化转化器;发动机在一定工况区域内出现的缺火;氧传感器劣化;?#27431;?#25511;制系统中其它一旦失效就会导致?#27431;?超过失效限值的零部件;?#27431;?#25511;制系统中传感器和执行器电路是否?#27833;ǎ?#23545;于蒸发?#27431;?#29289;控制系统中的炭罐控?#21697;В?#33267;少应监测其电路是否?#27833;ā?br /> (4)?#30475;?#21457;动机起动时,都必须开始一系列的诊断检测。
                      (5)obd系统应带有能让驾驶者感知?#25910;?#23384;在的?#25910;?#25351;示器,该器件只能用於指示启动了紧急程序或跛行回?#39029;?#24207;(发动机管理系统发生?#25910;?#26102;放弃部分控制功能,在不完备的状态下勉强维持车辆行驶的功能)。
                      ?#27431;?#19968;旦超过失效限值,发动机控制进入永久性?#27431;?#22833;效模式(发动机管理控制器永久性地切换到以设定值代替一?#36136;?#25928;零部件或系统输入信号的情形。在这情形 下,失效的零部件或系统将导致车辆?#27431;?#36229;出规定的失效限值),?#25910;?#25351;示器应在两个运转循环(运转循?#20998;?#30001;发动机起动、足以检测到可能存在的?#25910;系脑?#36716;模式 以及发动机关闭这三部分组成的循环)以内激活。如果制造商有充分的理由,可以放宽到十个运转循环以内激活。
                      当发动机缺火达到制造商指定的程度,而可能引起催化转化器损坏时,?#25910;?#25351;示器必须以明显的警示模式工作,例如灯光闪烁。
                      当汽车的点火开关处於?#27833;?#20301;置,在发动机被起动或被拖转之前,?#25910;?#25351;示器必须激活;发动机起动後,如果先前没有检测?#25910;希收?#25351;示器必须熄灭。 ?
                      (6)obd系统必须记录指示?#27431;?#25511;制系统状态的代码。使用各种专设的状态代码来标识正确地工作的?#27431;?#25511;制系统,以及那些需要进一步运转车辆才能全面地 评价的?#27431;?#25511;制系统。必须将由於劣化或?#25910;?#25110;永久性?#27431;?#22833;效模式引起?#25910;?#25351;示器激活的失效代码储存起来,该失效代码必须标识?#25910;系?#31867;型。?#25910;?#25351;示器激活期 间,车辆行驶经过的距离必须随时通过标准数据连接器的串行口读出。
                      (7)如果不再出现可能损坏催化转化器的缺火水平,或者如果发动机转入其缺 火水平不会损坏催化转化器的其它转速和负?#21830;?#20214;之後继续运转,?#36235;峁收?#25351;示器可以切换回到先前检测到缺火的第一个运转循环的激活状态(该激活状态?#37096;?#33021;是 其它?#25910;?#24341;起),并在後续?#33041;?#36716;循环中切换到正常的被激活模式。如果?#25910;?#25351;示器切换回到先前的激活状态,?#36235;?#30456;应的失效代码和储存的冻结帧状况可以被擦 除。?#36896;度?#28779;以外的所有其它?#25910;希?#22914;果负责激活?#25910;?#25351;示器的监测系统在三个相继?#33041;?#36716;循环中不再检测到?#25910;希?#24182;且没有识别到其它能独立地激活?#25910;?#25351;示器的 ?#25910;希趋峁收?#25351;示器可以被解除激活。
                      (8)如果在至少40个发动机暖机循环(在本指令中指充分运转车辆,使?#32654;?#21364;?#20309;?#24230;从发动机起动时算起至少升高了22k,且至少达到70℃)内没有出现相同的失效,?#36235;醥bd系统可以擦除失效代码、行驶过的距离和冻结帧信息。
                      (9)obd系统在下列情况可以自动地临时停止工作:obd系?#36710;?#30417;测能力因燃油箱?#20309;?#36807;低而受?#25509;?#21709;,但是只要燃油量超过燃油箱名义容量的 20%,obd系统就不得停止工作;发动机起动时环境温度低於-7℃,或海拔高于2500m时,制造商可以让obd系统停止工作;道路的路面情况十分恶 劣;对于装有功率输出装置的车辆,?#24066;?#35753;受?#25509;?#21709;的监测系统停止工作,条件是当功率输出装置在工作时,监测系统才停止工作。
                      (10)型式认证 主管机关除了对新车型进行型式认证以外,还要对已经行驶了超过新车型型式认证的ⅴ型?#36884;?#24615;试验里程的车辆,进行obd系?#36710;?#22411;式认证,该项试验在ⅴ型?#36884;?性试验结束时进行。进行这类试验时,制造商必须提供有缺陷的零部件和/或用于模拟失效的电气装置。但是,这些有缺陷的零部件或用于模拟失效的电气装置,在 按照新车型型式认证试验程序中的ⅰ型测试循?#26041;?#34892;试验时引起的车辆?#27431;?#20540;,不得比规定的失效限值超出20%。
                      应当试验的失效模式包括?#33322;?#20652;化 转化器替换为劣化或有缺陷的催化转化器,或模拟相应失效模式的电气装置?#29615;?#21512;发动机缺火监测要求的发动机缺火工况範围;将氧传感器替换为劣化或有缺陷的氧 传感器,或模拟相应失效模式的电气装置;断开蒸发物?#27431;?#25511;制系统清洗电子控制装置(如果装有的话)的电路。对于这种特定的失效模式,不得进行ⅰ型测试;断 开其它任何与?#27431;?#26377;关、跟动力系管理计算机相连的零部件的电路。上述前4项失效模式均足以引起?#27431;?#36229;过失效限值,在任?#25105;?#31181;情形下进行试验时,?#25910;?#25351;示器 都必须在ⅰ型测试结束之前被激活。技术部门?#37096;?#20197;采取类似断开电路的其它方法来替代上述情形。但在obd系统型式认证时,以模拟失效替代真正劣化或有缺陷 的零部件的情形不得多?#31471;?#39033;。
                      相应地,?#36896;?#35786;断信号的形成、储存和调用等也有严格的要求。
                      ?#35789;筼bd系统包含一个或多个不足 (deficiency),不能完全满足规定的要求,制造商?#37096;?#20197;要求型式认证主管机关接受该obd系?#36710;?#22411;式认证。型式认证主管机关在考虑这类要求时, 应确定顺从本附件的各项要求是否不切?#23548;?#25110;不合理。型式认证主管机关将考虑制造商所提出、详细地描述了如技术可行性、订货?#20004;?#36135;时间和生产周期等各种因素 的数据,包括发动机或车辆设计以及计算机程序升级的逐步导入和逐步导出,以及所形成的obd系统在顺从本指令的要求方面有效到什麽程度和制造商在顺从本指 令的要求方面所付出的努力。但是,型式认证主管机关不接受完全没有?#27431;?#25511;制系统诊断监测功能的情况,也不接受不顾及obd失效限值的obd系统。
                      ?#24066;?#22312;自新车型型式认证之日起的两年内携带?#35802;?#19981;足。如果能充分地证明,为?#21496;?#27491;该项不足对车辆必须进行的重大硬件改进和额外的导入时间超过两年,携带 该项不足的期限可以宽容,但是最多不得超过三年。如果obd系统通过型式认证之後才发现某种不足,制造商可以要求原来的型式认证主管机关事後补办批准不足 的?#20013;?br /> (11)制造商向任?#25105;?#23478;授权的经销商或修理厂提供维修资料後,应当在三个月内支付合理?#22836;?#27495;?#26377;?#30340;费用之後向他人提供这些资料(包括後续的改进和补充资料),并相应地向型式认证主管机关通报。
                      eobd使管理更复杂
                      eobd在控制?#27431;?#30340;硬件方面,对发动机管理系统提出一些要求,至少包括:
                      * 将发动机转速传感器安装在发动机离合器侧,以通过发动机转速的细微波动监测发动机缺火时避免受到曲轴扭振的影响;
                      * 车身垂直的加速度传感器(?#24066;?#36319;abs系?#36710;?#21152;速度传感器共用)用于在道路十分差的条件下关闭eobd功能;
                      * 在三效催化转化器的後面增添一个氧传感器,以便用“浓”和“稀?#34987;?#21512;气交替的方法监测三效催化转化器的储氧能力;对氧传感器监测其信号电压是否超出可能範 围、响应速度是否过低、跳变时间之比是否超出规定範围、波动频率是否过低、氧传感器是否活性不足、氧传感器加热器是否加热过慢;
                      * 采用排气再循环系?#36710;某?#21512;,要在进气岐管内安装压力传感器,以便进行对排气再循环率的控制,并在汽车海拔高度超过2,500?#36164;?#20851;闭eobd功能;
                      * 在炭罐新鲜空气入口处安装截止阀,作为执行器和在密闭燃油箱加设压差传感器,以监测蒸发?#27431;?#29289;控制系?#36710;?#23494;封性。
                      需要说明的是,本文阐述的欧iii?#27431;欧?#35268;中有关obd的规定,并非中国政府公布的正式法律文本,所以仅供参考。但总体概念和操作程序没有太大出入。
                      eobd带来的启示
                      大量的开发和引进工作急待完成:各整车厂必须根据本厂产品的特点,如汽车的整备质量、发动机的排量、汽车动力性目标等确定其满足欧iii的发动机应当如 何配置。相应地,发动机管理系?#36710;某?#21253;商也要配合整车厂对发动机管理系统做出调整,包括在硬件和软件两方面如?#25105;?#20837;obd系统;
                      必须准备维修和保养资料:根据指令70/220/eec(98/69/ec)附件xi的规定,制造商必须向任?#25105;?#23478;授权的经销商或修理厂提供维修和保养的资料,而且为此收取的费用必须在合理的範围内,并且不带歧?#26377;裕?br /> 对技术人员的要求更高:根据指令的规定,不再是过去那样完全根据ⅰ型测试中转鼓试验臺的?#27431;?#27979;试数据定终身,这种局面要求各方的技术人?#26412;?#36890;汽油机电子控制技术和obd系统。有关各方?#21152;?#24403;加强技术人员的培?#24608;?br /> 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.