大數據時代的當下，作為車載行業的設備終端，基本要與數據掛鉤，不僅要連接OBD或者CANBUS，還要求有大量的數據交互，在ADAS、DMS、車輛動態監控、發動機性能檢測、公車及出租車的車隊管理，還是礦卡工作時長監控等方面，應用都非常廣泛。

那么，我們需要解決幾個問題：

一、車載設備要的數據從哪里來？

基于車輛本身的數據，在行業這邊的應用，主要有2端，A、OBD接口。絕大部分車型都標配了OBD接口，不管是汽油車、柴油車、還是新能源及商用車等智能汽車，就連叉車，新款的也是帶有OBD自動診斷系統接口的；B、CAN總線網絡。據統計，國內的汽車在2013年后就標配了OBD2標準，當時的年代里，有85%以上用的是CAN2.0的數據接口網絡，我們在2016年做4S集團試乘試駕管理系統中，實際測試滿足CAN網絡標準的車型就達到了96.5%，可見，當下的情況，幾乎99%用的是CAN網絡了。

那么，通過OBD接口來采集數據，無疑是最簡單的方式。OBD在整車網絡上，本身就是一個重要的節點，但是真的把這一塊做好，做深是有難點的。之前的文章中也有提到過一些特殊情況，比如造成汽車不休眠、發動機起停技術的誤判、干擾ECU、CAN網絡通信故障、速率控制不對，請求指令錯誤、鎖車報警等等一系列的問題，這里不再贅述。

二、OBD采集數據的頻率

我們的方法是默認采用240ms對ECU請求，這個速率下，98%以上的車型都不會造成干擾，因為速率足夠慢，如果ECU不返回的數據，我們就跳過，顯示為空白。那么在下一包數據過來的時候，基本會有，大家可能認為，哎呀，數據這么慢，我怎么處理我們的上位機系統呢，這就要根據數據的多少，緊急性來區別。部分數據本身在整車上就傳輸得比較快，這種數據，反饋自然也就快，有的數據傳輸得慢，請求快了會造成網絡堵塞，還沒有數據返回。行業里，大多的通病就是“越快越好”，其實這里邊的“節奏”就體現了對車的理解，存在的高低之分，所以也決定了企業的生死。

這是個哲學問題，所有快的東西，絕大部分都不是好的，花開需要時節，稻穗成熟需要時間，孩子長大需要經歷，太早凋謝，催熟都是手段，而不是目的。比如我們要把一個芯片測試好，我們就需要大量的樣本，沒有大量的樣本，我就不能說我的“好”，測試樣本需要時間、需要周期、需要不同的環境，經過大量測試的樣本，那就是好的定義。

三、通過OBD接口采集車身私有協議下的控制系統數據，可能會存在的問題：

1、網關數據隔離，車載網關直接把數據隔離起來，不對OBD接口輸出數據，所有OBD請求的數據過來，網關這邊都要做識別，包括指令、速率、反饋。

2、指令不對。涉及的車型越多，指令越復雜，很多車都沒有指令可供請求，那么我們就需要破解診斷儀的“動作測試”中的請求與反饋，那么我們采用中斷式診斷請求，進入診斷儀請求模式。診斷請求數據是再比如停車、修理、維護的條件下，車是不運動的情況，請求一個的CAN ID 獲得 ECU反饋。以喇叭鳴笛信號舉例，我們需要連接通用診斷儀X431，然后通過X431發送鳴笛信號，界面上是“動作測試”。這個情況，在停車情況下，修車情況下可以用，因為接入了X431，并獲得X431授權，ECU處于診斷模式，通過CAN監聽工具，抓取X431發送請求的指令（車廠授權診斷儀廠家的），然后，X431給出反饋，請求后會有對應回復一包數據，通過這個方法，獲得喇叭信號。

3、對ECU造成干擾。我們還以喇叭信號舉例的話，你要請求多快？項目就只用這么一個信號嗎？這就造成了單一信號，或者不是多個信號請求頻率的問題，可能X431也沒辦法請求獲得這個指令，比如涉及汽車安全的“一票否決”的控車指令及其他涉及行車安全的指令，或者X431也沒有這么快的反饋，又回到第二大點的問題，造成各種困擾，這些困擾，其實都是請求數據過程中對ECU造成的干擾，為什么有的OBD就是活不了，為什么有的就越做越好，值得思考。

四、速銳得結合OBD特性給了新方法

首先是數據部分，OBD部分根據上述的經驗和磨合，這一塊，不要客戶自己去開發。因為開發OBD這個領域是跟車型、年份、總線、車載通信網絡、速率、零部件等相關的，有的高精度的傳感器數據每秒是300萬的單個數據量，這個一般企業沒涉及過的根本處理不過來。思拓的辦法是把OBD集成到一個小組件里，直接通過串口，比如TTL、RS232、RS485對外輸出數據，這個形態可能有多種，包括對接車載上位機的接口也存在多種多樣，但是至少有一點，OBD的核心部件是不用太擔心的。

其次是供電部分，OBD能有效地對上位機提供供電功能，在OBD接口的16腳就是一個常電，不管是停車熄火還是啟動汽車狀態，都具備供電的特性。看上去這里只是需要連接一條線，但會引申出一個問題，車載設備，比如ADAS、DMS、駕校學時機、4G網關或者別的，如何來保證功耗。汽車的電瓶是有容量的，有容量那么在停車熄火的時候就會有功耗。那么就要結合OBD的數據來做判定了，判定的條件還不止于一種。

其中重要的邏輯包括：

1、電壓：基本的邏輯為汽車熄火狀態一般為12V，最低點火電壓10.8V，汽車點火后一般在13.5V，最高達到14.8V，大型硬派越野車電壓可以達到15V；

2、轉速：常規熄火轉速為0，點火后的轉速最低位大概在550轉，部分冷車點火轉速達到2200轉，只要設置400轉速的閾值，另外補充熄火后部分車型固定轉速不變的情況做排除；

3、水溫：汽車點火后的水溫一般都不會為0或者為空，熄火后的水溫有華氏度和攝氏度兩個類別；

4、發動機運行時長，汽車點火工作后，發動機開始運行，ECU控制單元會記錄發動機運行時長，就像飛機一共多少飛行時間的結果一樣，這個數據有點火到熄火的值，也有累計值，但是累計值，我們一般不做參考，其他汽車市場應用也極少，我們只作為判斷邏輯之一。在發動機自動啟停下，轉速為0，水溫不為0，電壓變低，但有發動機運行時長。

五、結語

以上，當數據和供電結合到一起，再結合最后客戶端上位機的應用，基本上都能解決大部分項目中的問題，這也是速銳得新型智能車載CANBUS數據采集OBD接口傳輸及取電安裝應用方式核心所在。

應用舉例：商用車里面還有個典型的應用，就是通過CAN數據獲取左右轉向信號，基于這個信息來處理ADAS車道偏離報警，比如核心要解決誤判報警的問題。如果ADAS攝像頭識別到車輛跨越車道線，且有轉向信號，AI算法就判斷為正常變道。如果沒有轉向信號，ADAS主機即刻發出車道偏離預警信息，在本地提醒司機做出糾正，同時上報平臺主動安全報警事件。現在很多都是通過IO信號線，接車輛左右轉向燈的信號來獲取，前裝車廠的ADAS是通過CAN來獲取轉向信號，這也是為什么以色列能做十年沉淀，我們搞后裝的接觸不到這塊，那么對這個數據的要求，可能實時性可能就沒那么快只是我們國內沒有企業去積累

我們采集的數據，都是工具，完成匹配好項目所需，才是目的。很多項目中，客戶不懂汽車、電子、總線、邏輯，一再強調功能、功能、功能，就會陷入“功能誤區”，功能越多，系統越復雜，涉及面就越是廣泛，另外還有車型、品牌、年份、總線通信邏輯等多種的不同。測試的范圍越廣、車型越多，暴露出來的問題也就越多。像第一章節中所說的問題，很多就是致命的，這些問題處理不到，就會導致一個項目掛上東南枝，或者讓一個數據開發企業走向無盡深淵。

審核編輯：劉清