閱讀下文前，建議對OBD有初步了解，可閱讀下面兩篇：
玩轉車聯網1---初識OBD和行車助手
玩轉車聯網2--汽車內部通訊和車聯網整體架構
上一篇博文提到了汽車內部的通訊方式，但是我們的程序是如何與OBD之間進行通訊的呢？
這里就涉及到兩個問題：通訊方式和通訊協議。先上一張OBD安裝在蒙迪歐致勝上的效果圖：
1. 通訊方式
對於大多數的OBD硬件來說，多采用藍牙、WIFI、串口等幾種方式。
下面看看幾種模式在實際使用場景中，對於普通消費者的優缺點：
| 優點 | 缺點 | |
| 藍牙 | 可與智能手機連接，不占用智能手機網絡信道 | 因為大部分用戶的藍牙功能是關閉的，用戶可能會上車后可能忘記打開藍牙 |
| WIFI | 可與智能手機連接，用戶一般情況下會打開手機WIFI功能 | 由於智能手機連接OBD后，相當於構成個車內局域網，因此占用手機網絡信道，不能上外網 |
| 串口 | 非常穩定， 適合作為檢測設備 | 不可與智能手機連接 |
根據利弊分析，作為消費級的產品，采用串口作為通訊方式肯定是不行的。藍牙和WIFI相比較，藍牙模塊的成本更低，更加穩定，因此優先選擇藍牙模塊。我相信這也是為什么大多數的可穿戴設備選擇藍牙的原因。當然，在軟件設計上，可以將藍牙和WIFI虛擬成一個ICommunication接口，方便程序的擴展。本文不作重點講述，以后會在Android藍牙自動重連章節着重展開。
2. 市面上的OBD
上文中對於OBD的通訊方式有了簡要介紹，再進行通訊協議之前，我們先說說市面上的OBD吧。
市面上有眾多OBD產品，最常用的是Elm327（便宜，淘寶上40幾塊，藍牙的），當然還有EST527, XTool,國外還有好多，從幾十到上千不等。為什么會有價格差別？
1.產品質量，所謂一分價錢一分貨
2.軟件支持，其他廠商的可以配合他們自己的硬件實現特有的軟件服務，例如將OBD同保險和汽車維修服務掛鈎。
3.硬件支持，其他廠商會增加GPS/GPRS/3G等模塊，不需要智能手機，可以通過OBD硬件直接將數據傳到后台。
但是我想做的是一個相對通用的開發者平台，盡量支持市面上的OBD硬件。一個廠商或者一個開發者的能力是有限的，降低開發門檻，提供最基礎的SDK服務，發揮廣大人民的想象力，開發出更多更實用的應用。
那么是否有這種可能性呢？答案是可能的。因為大部分的硬件廠商都是在Elm327上進行擴展，我們只要把Elm327吃透，支持一種新的設備也是很迅速的事情。
3. 通訊協議
回歸正題，那么OBD的通訊協議時怎樣的呢，這里只做簡單介紹。
3.1 OBD能提供的服務
OBD主要有下面九種服務，每一種服務都可以延伸很多東西，我們先着重關注服務1（Mode1)。
Mode 1: 請求動力系當前數據（發動機轉速、速度、水溫、油耗等數據）
Mode 2: 請求凍結禎數據
Mode 3: 請求排放相關的動力系診斷故障碼
Mode 4: 清除/復位排放相關的診斷信息
Mode 5: 請求氧傳感器監測測試結果
Mode 6: 請求非連續監測系統OBD測試結果
Mode 7: 請求連續監測系統OBD測試結果
Mode 8: 請求控制車載系統，測試或者部件（中國市場開發的OBD系統不支持該模式）
Mode 9: 讀車輛和標定識別號
即使Mode1下真正能讀取的數據遠遠不止下面這些，暫且說幾個最常用的吧。
油耗系:讀取動力系數據（瞬時油耗、當前油量）
引擎類（速度、發動機轉速）
溫度系(水溫等數據）
故障碼類（故障碼個數，故障碼詳細，清除故障碼等）。
3.2. OBD數據協議格式
這里是基礎的基礎，我們以CAN總線的OBD數據格式為例，其中ELM327也是采用這種數據格式。
ID表示CAN總線的ID；
PCI表示協議控制的信息數；
7 data bytes非常關鍵，表示Mode+PID，例如，如果是車速，那么這里就應該是01(Mode1) + 0D(車速)
Checksum:校驗碼
3.3. 最簡單的OBD消息交互---獲取水溫
以獲取水溫為例：
發送：>01 05 (Mode1:01 動力系, PID:05 水溫)
返回：41 05 7B
下面是返回的解釋：
41=40+01,具體40是什么有點忘了,表示是從01 <Mode1返回的，05表示是PID05
7B轉換成10進制為7*16 + 11 = 123 (華氏溫度),
即123-40 = 83攝氏度。
哎哎，終於寫完了，比較討厭寫這種純技術類的文章，好累。
最后發一張正在開發的Android車機界面原型圖，鼓勵自己.
