|
<p>OBD-II Network Standards<br />
» J1850 VPW<br />
– Adopted by GM; also known as Class 2.<br />
– Adopted by Chrysler (known as J1850).<br />
– Some references to VPW mode heard about in regards to Toyota (and Honda ?).<br />
– 10.4 kbps, single wire.<br />
» J1850 PWM<br />
– Adopted by Ford; also known as Standard Corporate Protocol (SCP).<br />
– Also seen in some Mazda products.<br />
– Some references to PWM mode heard about in regards to Mitsubishi.<br />
– 41.6 kbps, two wire balanced signal.<br />
» ISO 9141 and ISO 9141-2 (also known as ISO 9141 CARB)<br />
– Seen in some Chrysler and Mazda products.<br />
– Seems to be more common in Europe.<br />
– 10.4 kbps, single wire.<br />
OBDII 通訊協議 <br />
obdii generic communication protocols by manufacturer <br />
Recently I tried to install my product on Peuzeot(406 or something<br />
similar). There was<br />
KWP 2000 bus. I tried to get the speed value from the bus by sending<br />
the following string<br />
0xc2 0x33 0xf1 0x01 0x0d 0xf4.<br />
On responce I received two answers from 2 different ECUs:<br />
1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16<br />
1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66<br />
<br />
The first ECU sent me NACK<br />
(This response code indicates that the requested action will not be<br />
taken because the server (ECU) does not support the arguments of the<br />
request message or the format of the argument bytes do not match the<br />
prescribed format for the specified service.)<br />
<br />
My question is: if there was something wrong with the arguments of the<br />
request message, the second ECU also should not understand the<br />
request, bit it did !<br />
And the second question is: why the first ECU did send the negative<br />
answer. If you look at the j1979 PDF you will find there that "If an<br />
ECU does not support any of the PIDs requested it is not allowed to<br />
send a negative response message".<br />
OBD 信息： obd-ii標準診斷插座列表</p>
<p><img alt="OBD-II通訊協議（如何知道汽車使用的哪一種） - 何正茂 - autolife愛汽車 愛生活" style="MARGIN: 0px 10px 0px 0px;" src="http://www.duosensoft.com/uploads/allimg/121104/1359302120-0.jpg" /><br />
端子號稱 端子接線<br />
---------------------------------------------------------------------<br />
4 搭鐵<br />
16 蓄電池正極，9-12v<br />
7，15 資料數據傳輸線（iso 9141-2）<br />
5 信號反饋線搭鐵<br />
2 sae j1850數據輸送線<br />
10 sae制造廠數據輸送線<br />
舉一實例；捷達前衛診斷座t16中；就有16 4 7三個端子按以上要求接線。<br />
EOBD 歐洲標準 <br />
新的 european obd 診斷坐連接標準 dlc-j1962<br />
================================================================================<br />
pin 1 ......sae j2411, gm single wire can;通用公司單線 can-bus<br />
pin 2 ......iso 11519-4 (bus+)(sae j1850), 和10號腳同時使用, 41.6 kbps pwm脈寬調制<br />
單線用法:只用2號腳1根線通訊10.4 kbps vpw可變脈寬調制 byte header + crc, <br />
no "checksum" or "inter-byte separation" (in frame response byte ?)<br />
pin 3 ...... chrysler, ccd+ (not obd) ;克萊斯勒 ccd-bus網線 h 線<br />
pin 4 ...... 底盤地 chassis ground<br />
pin 5 ...... 邏輯地 signal ground<br />
pin 6 ...... iso 15765-4;can-bus 高速診斷線 (h 線) ,250/500 kbit/s<br />
pin 7 ....... kwp1281或kwp2000 協議診斷線 (k線), 波特率10400/多數廠家默認kpw2000診斷線<br />
pin8 ........ 點火開關打開有電 ig+;點火開關 on/off 狀態識別用途<br />
pin9 ........ 7號腳不方便用時,啟用*kwp1281或kwp2000 協議診斷線 (k線), 波特率10400<br />
pin10 ....... iso 11519-4 (bus-)(sae j1850), 和 2號腳同時使用, 41.6 kbps pwm脈寬調制<br />
pin 11 ...... chrysler, ccd- (not obd) ;克萊斯勒 ccd-bus網線 l 線<br />
pin 12 ...... * k 線 制造廠保留用<br />
pin 13 ...... * k 線 制造廠保留用<br />
pin 14 ...... iso 15765-4;can-bus 高速診斷線 (l 線) ,250/500 kbit/s <br />
pin 15 ...... kwp1281或kwp2000 協議診斷線 (k線);7p不夠用或控制單元過多時啟用<br />
pin 16 ...... 長火線 bat+<br />
<br />
<strong>obdii和eobd的基本區別</strong></p>
<table width="493" height="190" cellspacing="0" cellpadding="0" border="1">
<tbody>
<tr>
<td style="text-align: center;"><strong>功能</strong></td>
<td style="text-align: center;"><strong>obdii </strong></td>
<td style="text-align: center;"><strong>eobd </strong></td>
</tr>
<tr>
<td>進行燃油箱及燃油系統的瀉漏試驗</td>
<td>是</td>
<td>不</td>
</tr>
<tr>
<td>探測發動機不（發）點火的轉速到</td>
<td>最大</td>
<td>4500r/min</td>
</tr>
<tr>
<td>故障發生經歷多少個駕駛周期故障指示燈才閃亮</td>
<td>2</td>
<td>2-10</td>
</tr>
<tr>
<td>用故障指示燈顯示汽車行駛距離</td>
<td>不</td>
<td>是</td>
</tr>
<tr>
<td>使用的通訊協議</td>
<td>sae j1850</td>
<td>iso 9141-2</td>
</tr>
</tbody>
</table>
<p><strong>OBDII協議 </strong><br />
Connected ISO9141 protocol to ECU Address 0x33 (protocol key bytes 0x08, 0x08)<br />
Direction Header bytes Payload bytes Checksum Byte Meaning<br />
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)<br />
Car -> Tester 0x00 0x00 Garbage!!<br />
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)<br />
Car -> Tester 0x00 0x00 0x00 Garbage!!<br />
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)<br />
Car -> Tester 0x00 0x00 0x00 0x00 Garbage!!<br />
Tester -> Car 0x68 0x6a 0xf1 0x01 0x00 0xC4 Request (Service 1, Parameter 0)<br />
Car -> Tester 0x00 0x00 0x00 0x00 0x00 Garbage!!<br />
Tester -> Car 0x68 0x6a 0xf1 0x02 0x00 0x00 0xC5 Request (Service 2, Parameter 0)<br />
Car -> Tester 0x00 0x00 0x00 0x00 0x00 0x00 Garbage!!<br />
It successfully negotiated the initialization of an ISO9141 protocol session<br />
(by responding key bytes "0x08, 0x08"), and then went berserk on me... every time I tried this,<br />
it has behaved the same way - useless. After a successful initialization,<br />
it just responds "zeros" back to every request,<br />
*********************************************************************************************************<br />
標準 OBD-II 有3種<br />
1. ISO 使用ISO-9141 (借用BOSH)使用 J1962-7 單線通訊 電平高低表示 邏輯 "1" 和 "0"<br />
2. SAE J1850 (借用 GM)使用 J1962-2 單線通訊 脈沖寬度表示 邏輯 "1" 和 "0"<br />
3. SAE J1850 (借用FORD)使用 J1962-2/J1962-10 2線通訊 可變脈寬.脈沖寬度表示 邏輯 "1" 和 "0"<br />
*********************************************************************************************************<br />
標準OBD-II 診斷之ISO標準部分使用 ISO9141物理連接 定義在J1962 的7號腳就是我們常說的 K 線<br />
標準OBD-II 協議 ISO-9141 特點 PCM動力系統 5波特率地址碼 33H 協議字 KB1:08H;協議字 KB2:08H;<br />
解碼器用KB2取反$F7H確認收到 $08 $08<br />
protocol to ECU Address 0x33 (protocol key bytes 0x08, 0x08) 解碼器地址碼$F1<br />
說話對象 首字節 工作字節 校驗和 字節含意<br />
============ ======== ================= ===== ========================<br />
解碼器 -> 車 68 6a f1 01 00 C4 請求 (命令 1, 參數 0)<br />
車 -> 解碼器 00 00 無意義<br />
解碼器 -> 車 68 6a f1 01 00 C4 請求 (命令 1, 參數 0)<br />
車 -> 解碼器 00 00 00 無意義<br />
解碼器 -> 車 68 6a f1 01 00 C4 請求 (命令 1, 參數 0)<br />
車 -> 解碼器 00 00 00 00 無意義<br />
解碼器 -> 車 68 6a f1 01 00 C4 請求 (命令 1, 參數 0)<br />
車 -> 解碼器 00 00 00 00 00 無意義<br />
解碼器 -> 車 68 6a f1 02 00 00 C5 請求 (命令 2, 參數 0)<br />
Car -> 解碼器 00 00 00 00 00 00 無意義<br />
三個基本通訊協議：<br />
1 iso 9141通訊協議電路。<br />
基本型chrysler（克萊斯勒）汽車和所有歐洲生產的汽車以及大多數亞洲進口的汽車都使用國際標準化組織sio 9141通訊協議電路。<br />
2 ase j1850 vpw（可變的脈沖寬度調節）通訊協議電路。<br />
美國通用（gm）汽車公司生產的轎車及輕型載貨車汽車使用ase j1850vpw通訊協議電路。<br />
3 ase j1850 pwm（脈沖寬度調節）通訊協議電路。<br />
福特（ford）汽車公司汽車使用該種通訊協議電路。<br />
根據iso 15031-5標準，can（控制器局域網）采用iso 15765-4標準。<br />
obdii和eobd都使用三個基本的通訊協議。然而有的制造商在通訊協議上做了一些修改。但是克萊斯勒和大多數亞洲進口的汽車和所有歐洲生產的汽車都使用國際標準化組織iso 9141通訊協議電路。<br />
美國車載診斷技術（obdii）<br />
歐洲車載診斷技術(eobd)<br />
從歐i到歐ii，雖然說排放限值有所趨嚴，相對來說還比較容易實現。歐iii的難點不僅在于排放限值收緊，應該說，從歐ii到歐iii是一個飛躍，兩者的主要差別在于：<br />
* 取消發動機起動後不采樣的40秒鐘怠速：歐i和歐ii排放法規的測試循環中，發動機起動後有一段40秒怠速階段，在此期間排出的廢氣不予采集；歐iii則取消了這怠速，從發動機開始起動就采集廢氣樣本；<br />
* 氮氧化物的排放單獨考核：在歐i和歐ii排放法規中，將碳氫化合物和氮氧化物的排放量合在一起算總賬，只對兩者之和制訂一個限值標準，但是歐iii分別規定碳氫化合物和氮氧化物的限值；<br />
* 增添-7℃以下的冷起動試驗：歐iii增添了一項在-7℃以下的環境進行的冷起動試驗；<br />
* 對排放控制裝置的耐久性要求更加嚴格：歐iii要求排放控制裝置在行駛5年或8萬公里之後，仍能滿足型式認證的排放要求；<br />
* 引入eobd：從歐iii開始要求引入歐洲車載診斷技術eobd，分階段執行相關的法規。 <br />
用於排放控制的系統 eobd（european on-board diagnostics），簡稱obd（on-board diagnostics），即“車載診斷技術”或簡稱“車載診斷”。歐i和歐ii排放法規階段的發動機管理系統都帶有車載故障診斷功能，但是在歐iii排 放法規中，obd隱含著專門用於排放控制的意思，根據定義，它是“用於排放控制的車載診斷系統”，而且必須能夠通過儲存在計算機存儲器中的失效代碼來識別 故障的可能範圍。<br />
美國加利福尼亞州率先于1994年以立法的形式提出了利用車載診斷技術對排放控制裝置實行故障監測的要求，稱為obdⅱ。後 來，歐洲也制訂了從2000年跟歐iii同時生效的指令70/220/eec（98/69/ec）附件xi。該指令適用于歐iii和歐iv排放法規，內容 包括：<br />
（1）所有車輛必須裝備obd系統，其設計、制造和安裝應能確保車輛在整個生命期內識別劣化類型和故障類型。<br />
（2）當排放控制系統（與發動機電子管理系統以及排氣系統或蒸發物控制系統中，任何與排放有關、向電子控制單元提供輸入信號或從電子控制單元接受輸出信號的零部件）失效導致排放超過規定的極限值（下文稱為失效限值）時，obd系統必須指示它們的失效。<br />
（3）汽油機obd系統必須監測下列項目：三效催化轉化器；發動機在一定工況區域內出現的缺火；氧傳感器劣化；排放控制系統中其它一旦失效就會導致排放 超過失效限值的零部件；排放控制系統中傳感器和執行器電路是否接通；對于蒸發排放物控制系統中的炭罐控制閥，至少應監測其電路是否接通。<br />
（4）每次發動機起動時，都必須開始一系列的診斷檢測。<br />
（5）obd系統應帶有能讓駕駛者感知故障存在的故障指示器，該器件只能用於指示啟動了緊急程序或跛行回家程序（發動機管理系統發生故障時放棄部分控制功能，在不完備的狀態下勉強維持車輛行駛的功能）。<br />
排放一旦超過失效限值，發動機控制進入永久性排放失效模式（發動機管理控制器永久性地切換到以設定值代替一種失效零部件或系統輸入信號的情形。在這情形 下，失效的零部件或系統將導致車輛排放超出規定的失效限值），故障指示器應在兩個運轉循環（運轉循環指由發動機起動、足以檢測到可能存在的故障的運轉模式 以及發動機關閉這三部分組成的循環）以內激活。如果制造商有充分的理由，可以放寬到十個運轉循環以內激活。<br />
當發動機缺火達到制造商指定的程度，而可能引起催化轉化器損壞時，故障指示器必須以明顯的警示模式工作，例如燈光閃爍。<br />
當汽車的點火開關處於接通位置，在發動機被起動或被拖轉之前，故障指示器必須激活；發動機起動後，如果先前沒有檢測故障，故障指示器必須熄滅。 ?<br />
（6）obd系統必須記錄指示排放控制系統狀態的代碼。使用各種專設的狀態代碼來標識正確地工作的排放控制系統，以及那些需要進一步運轉車輛才能全面地 評價的排放控制系統。必須將由於劣化或故障或永久性排放失效模式引起故障指示器激活的失效代碼儲存起來，該失效代碼必須標識故障的類型。故障指示器激活期 間，車輛行駛經過的距離必須隨時通過標準數據連接器的串行口讀出。<br />
（7）如果不再出現可能損壞催化轉化器的缺火水平，或者如果發動機轉入其缺 火水平不會損壞催化轉化器的其它轉速和負荷條件之後繼續運轉，那麼故障指示器可以切換回到先前檢測到缺火的第一個運轉循環的激活狀態（該激活狀態也可能是 其它故障引起），并在後續的運轉循環中切換到正常的被激活模式。如果故障指示器切換回到先前的激活狀態，那麼相應的失效代碼和儲存的凍結幀狀況可以被擦 除。對於缺火以外的所有其它故障，如果負責激活故障指示器的監測系統在三個相繼的運轉循環中不再檢測到故障，并且沒有識別到其它能獨立地激活故障指示器的 故障，那麼故障指示器可以被解除激活。<br />
（8）如果在至少40個發動機暖機循環（在本指令中指充分運轉車輛，使得冷卻液溫度從發動機起動時算起至少升高了22k，且至少達到70℃）內沒有出現相同的失效，那麼obd系統可以擦除失效代碼、行駛過的距離和凍結幀信息。<br />
（9）obd系統在下列情況可以自動地臨時停止工作：obd系統的監測能力因燃油箱液位過低而受到影響，但是只要燃油量超過燃油箱名義容量的 20%，obd系統就不得停止工作；發動機起動時環境溫度低於-7℃，或海拔高于2500m時，制造商可以讓obd系統停止工作；道路的路面情況十分惡 劣；對于裝有功率輸出裝置的車輛，允許讓受到影響的監測系統停止工作，條件是當功率輸出裝置在工作時，監測系統才停止工作。<br />
（10）型式認證 主管機關除了對新車型進行型式認證以外，還要對已經行駛了超過新車型型式認證的ⅴ型耐久性試驗里程的車輛，進行obd系統的型式認證，該項試驗在ⅴ型耐久 性試驗結束時進行。進行這類試驗時，制造商必須提供有缺陷的零部件和/或用于模擬失效的電氣裝置。但是，這些有缺陷的零部件或用于模擬失效的電氣裝置，在 按照新車型型式認證試驗程序中的ⅰ型測試循環進行試驗時引起的車輛排放值，不得比規定的失效限值超出20%。<br />
應當試驗的失效模式包括：將催化 轉化器替換為劣化或有缺陷的催化轉化器，或模擬相應失效模式的電氣裝置；符合發動機缺火監測要求的發動機缺火工況範圍；將氧傳感器替換為劣化或有缺陷的氧 傳感器，或模擬相應失效模式的電氣裝置；斷開蒸發物排放控制系統清洗電子控制裝置（如果裝有的話）的電路。對于這種特定的失效模式，不得進行ⅰ型測試；斷 開其它任何與排放有關、跟動力系管理計算機相連的零部件的電路。上述前4項失效模式均足以引起排放超過失效限值，在任何一種情形下進行試驗時，故障指示器 都必須在ⅰ型測試結束之前被激活。技術部門也可以采取類似斷開電路的其它方法來替代上述情形。但在obd系統型式認證時，以模擬失效替代真正劣化或有缺陷 的零部件的情形不得多於四項。<br />
相應地，對於診斷信號的形成、儲存和調用等也有嚴格的要求。<br />
即使obd系統包含一個或多個不足 （deficiency），不能完全滿足規定的要求，制造商也可以要求型式認證主管機關接受該obd系統的型式認證。型式認證主管機關在考慮這類要求時， 應確定順從本附件的各項要求是否不切實際或不合理。型式認證主管機關將考慮制造商所提出、詳細地描述了如技術可行性、訂貨至交貨時間和生產周期等各種因素 的數據，包括發動機或車輛設計以及計算機程序升級的逐步導入和逐步導出，以及所形成的obd系統在順從本指令的要求方面有效到什麼程度和制造商在順從本指 令的要求方面所付出的努力。但是，型式認證主管機關不接受完全沒有排放控制系統診斷監測功能的情況，也不接受不顧及obd失效限值的obd系統。<br />
允許在自新車型型式認證之日起的兩年內攜帶某項不足。如果能充分地證明，為了糾正該項不足對車輛必須進行的重大硬件改進和額外的導入時間超過兩年，攜帶 該項不足的期限可以寬容，但是最多不得超過三年。如果obd系統通過型式認證之後才發現某種不足，制造商可以要求原來的型式認證主管機關事後補辦批準不足 的手續。<br />
（11）制造商向任何一家授權的經銷商或修理廠提供維修資料後，應當在三個月內支付合理和非歧視性的費用之後向他人提供這些資料（包括後續的改進和補充資料），并相應地向型式認證主管機關通報。<br />
eobd使管理更復雜<br />
eobd在控制排放的硬件方面，對發動機管理系統提出一些要求，至少包括：<br />
* 將發動機轉速傳感器安裝在發動機離合器側，以通過發動機轉速的細微波動監測發動機缺火時避免受到曲軸扭振的影響；<br />
* 車身垂直的加速度傳感器（允許跟abs系統的加速度傳感器共用）用于在道路十分差的條件下關閉eobd功能；<br />
* 在三效催化轉化器的後面增添一個氧傳感器，以便用“濃”和“稀”混合氣交替的方法監測三效催化轉化器的儲氧能力；對氧傳感器監測其信號電壓是否超出可能範 圍、響應速度是否過低、跳變時間之比是否超出規定範圍、波動頻率是否過低、氧傳感器是否活性不足、氧傳感器加熱器是否加熱過慢；<br />
* 采用排氣再循環系統的場合，要在進氣岐管內安裝壓力傳感器，以便進行對排氣再循環率的控制，并在汽車海拔高度超過2,500米時關閉eobd功能；<br />
* 在炭罐新鮮空氣入口處安裝截止閥，作為執行器和在密閉燃油箱加設壓差傳感器，以監測蒸發排放物控制系統的密封性。<br />
需要說明的是，本文闡述的歐iii排放法規中有關obd的規定，并非中國政府公布的正式法律文本，所以僅供參考。但總體概念和操作程序沒有太大出入。<br />
eobd帶來的啟示<br />
大量的開發和引進工作急待完成：各整車廠必須根據本廠產品的特點，如汽車的整備質量、發動機的排量、汽車動力性目標等確定其滿足歐iii的發動機應當如 何配置。相應地，發動機管理系統的承包商也要配合整車廠對發動機管理系統做出調整，包括在硬件和軟件兩方面如何引入obd系統；<br />
必須準備維修和保養資料：根據指令70/220/eec（98/69/ec）附件xi的規定，制造商必須向任何一家授權的經銷商或修理廠提供維修和保養的資料，而且為此收取的費用必須在合理的範圍內，并且不帶歧視性；<br />
對技術人員的要求更高：根據指令的規定，不再是過去那樣完全根據ⅰ型測試中轉鼓試驗臺的排放測試數據定終身，這種局面要求各方的技術人員精通汽油機電子控制技術和obd系統。有關各方都應當加強技術人員的培訓。<br />
KWP 2000 (ISO 15765-4) bus protocol question <br />
| | KWP 2000 bus. I tried to get the speed value from the bus by sending<br />
| | the following string<br />
| | 0xc2 0x33 0xf1 0x01 0x0d 0xf4.<br />
| | On responce I received two answers from 2 different ECUs:<br />
| | 1) 0x83 0xf1 0x10 0x7f 0x01 0x12 0x16<br />
| | 1) 0x83 0xf1 0xa4 0x41 0x0d 0x00 0x66<br />
| |<br />
| | The first ECU sent me NACK<br />
| | (This response code indicates that the requested action will not be<br />
| | taken because the server (ECU) does not support the arguments of the<br />
| | request message or the format of the argument bytes do not match the<br />
| | prescribed format for the specified service.)<br />
| |<br />
| | My question is: if there was something wrong with the arguments of the<br />
| | request message, the second ECU also should not understand the<br />
| | request, bit it did !<br />
<br />
You had sent a 'functional' request out to the functional address 0x33.<br />
Any device programmed to respond to that address will. Looking at the<br />
standard, I see that it actually says:<br />
<br />
"A module shall always respond to a request either with a positive or<br />
negative response when no transmission error has been detected." <br />
<br />
By using functional addressing, what you actually asked was "Does<br />
anybody know the vehicle speed (0x0D)?"<br />
The first ECU said "I know nothing about vehicle speed", and the second<br />
ECU said "It is 00." (the byte before the 0x66 checksum).<br />
Once you know the specific ECU physical address 0x10 or 0xA4 above,<br />
then you can be more specific with your queries.<br />
<br />
| | And the second question is: why the first ECU did send the negative<br />
| | answer.<br />
<br />
It did not say there was an error. It said that it did not support that<br />
PID. <br />
<br />
| | If you look at the j1979 PDF you will find there that "If an<br />
| | ECU does not support any of the PIDs requested it is not allowed to<br />
| | send a negative response message".<br />
| |<br />
<br />
I believe that you are getting your standards confused. KWP2000 is also<br />
called ISO14230-4.</p>
|