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

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

一、車載設(shè)備要的數(shù)據(jù)從哪里來？

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

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

二、OBD采集數(shù)據(jù)的頻率

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

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

三、通過OBD接口采集車身私有協(xié)議下的控制系統(tǒng)數(shù)據(jù)，可能會存在的問題：

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

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

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

四、速銳得結(jié)合OBD特性給了新方法

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

其次是供電部分，OBD能有效地對上位機提供供電功能，在OBD接口的16腳就是一個常電，不管是停車熄火還是啟動汽車狀態(tài)，都具備供電的特性?？瓷先ミ@里只是需要連接一條線，但會引申出一個問題，車載設(shè)備，比如ADAS、DMS、駕校學(xué)時機、4G網(wǎng)關(guān)或者別的，如何來保證功耗。汽車的電瓶是有容量的，有容量那么在停車熄火的時候就會有功耗。那么就要結(jié)合OBD的數(shù)據(jù)來做判定了，判定的條件還不止于一種。

其中的邏輯包括：

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

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

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

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

五、結(jié)語

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

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

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

并不是不知者無畏，而是成本太高。

附上PPT首頁，請各位需要的朋友聯(lián)系，獲取完整28頁應(yīng)用介紹。