大數(shù)據(jù)時代的當下,作為車載行業(yè)的設備終端,基本要與數(shù)據(jù)掛鉤,不僅要連接OBD或者CANBUS,還要求有大量的數(shù)據(jù)交互,在ADAS、DMS、車輛動態(tài)監(jiān)控、發(fā)動機性能檢測、公車及出租車的車隊管理,還是礦卡工作時長監(jiān)控等方面,應用都非常廣泛。
那么,我們需要解決幾個問題:
一、車載設備要的數(shù)據(jù)從哪里來?
基于車輛本身的數(shù)據(jù),在行業(yè)這邊的應用,主要有2端,A、OBD接口。絕大部分車型都標配了OBD接口,不管是汽油車、柴油車、還是新能源及商用車等智能汽車,就連叉車,新款的也是帶有OBD自動診斷系統(tǒng)接口的;B、CAN總線網(wǎng)絡。據(jù)統(tǒng)計,國內(nèi)的汽車在2013年后就標配了OBD2標準,當時的年代里,有85%以上用的是CAN2.0的數(shù)據(jù)接口網(wǎng)絡,我們在2016年做4S集團試乘試駕管理系統(tǒng)中,實際測試滿足CAN網(wǎng)絡標準的車型就達到了96.5%,可見,當下的情況,幾乎99%用的是CAN網(wǎng)絡了。
那么,通過OBD接口來采集數(shù)據(jù),無疑是最簡單的方式。OBD在整車網(wǎng)絡上,本身就是一個重要的節(jié)點,但是真的把這一塊做好,做深是有難點的。之前的文章中也有提到過一些特殊情況,比如造成汽車不休眠、發(fā)動機起停技術的誤判、干擾ECU、CAN網(wǎng)絡通信故障、速率控制不對,請求指令錯誤、鎖車報警等等一系列的問題,這里不再贅述。
二、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)絡堵塞,還沒有數(shù)據(jù)返回。行業(yè)里,大多的通病就是“越快越好”,其實這里邊的“節(jié)奏”就體現(xiàn)了對車的理解,存在的高低之分,所以也決定了企業(yè)的生死。
這是個哲學問題,所有快的東西,絕大部分都不是好的,花開需要時節(jié),稻穗成熟需要時間,孩子長大需要經(jīng)歷,太早凋謝,催熟都是手段,而不是目的。比如我們要把一個芯片測試好,我們就需要大量的樣本,沒有大量的樣本,我就不能說我的“好”,測試樣本需要時間、需要周期、需要不同的環(huán)境,經(jīng)過大量測試的樣本,那就是好的定義。
三、通過OBD接口采集車身私有協(xié)議下的控制系統(tǒng)數(shù)據(jù),可能會存在的問題:
1、網(wǎng)關數(shù)據(jù)隔離,車載網(wǎng)關直接把數(shù)據(jù)隔離起來,不對OBD接口輸出數(shù)據(jù),所有OBD請求的數(shù)據(jù)過來,網(wǎng)關這邊都要做識別,包括指令、速率、反饋。
2、指令不對。涉及的車型越多,指令越復雜,很多車都沒有指令可供請求,那么我們就需要破解診斷儀的“動作測試”中的請求與反饋,那么我們采用中斷式診斷請求,進入診斷儀請求模式。診斷請求數(shù)據(jù)是再比如停車、修理、維護的條件下,車是不運動的情況,請求一個的CAN ID 獲得 ECU反饋。以喇叭鳴笛信號舉例,我們需要連接通用診斷儀X431,然后通過X431發(fā)送鳴笛信號,界面上是“動作測試”。這個情況,在停車情況下,修車情況下可以用,因為接入了X431,并獲得X431授權,ECU處于診斷模式,通過CAN監(jiān)聽工具,抓取X431發(fā)送請求的指令(車廠授權診斷儀廠家的),然后,X431給出反饋,請求后會有對應回復一包數(shù)據(jù),通過這個方法,獲得喇叭信號。
3、對ECU造成干擾。我們還以喇叭信號舉例的話,你要請求多快?項目就只用這么一個信號嗎?這就造成了單一信號,或者不是多個信號請求頻率的問題,可能X431也沒辦法請求獲得這個指令,比如涉及汽車安全的“一票否決”的控車指令及其他涉及行車安全的指令,或者X431也沒有這么快的反饋,又回到第二大點的問題,造成各種困擾,這些困擾,其實都是請求數(shù)據(jù)過程中對ECU造成的干擾,為什么有的OBD就是活不了,為什么有的就越做越好,值得思考。
四、速銳得結(jié)合OBD特性給了新方法
首先是數(shù)據(jù)部分,OBD部分根據(jù)上述的經(jīng)驗和磨合,這一塊,不要客戶自己去開發(fā)。因為開發(fā)OBD這個領域是跟車型、年份、總線、車載通信網(wǎng)絡、速率、零部件等相關的,有的高精度的傳感器數(shù)據(jù)每秒是300萬的單個數(shù)據(jù)量,這個一般企業(yè)沒涉及過的根本處理不過來。思拓的辦法是把OBD集成到一個小組件里,直接通過串口,比如TTL、RS232、RS485對外輸出數(shù)據(jù),這個形態(tài)可能有多種,包括對接車載上位機的接口也存在多種多樣,但是至少有一點,OBD的核心部件是不用太擔心的。
其次是供電部分,OBD能有效地對上位機提供供電功能,在OBD接口的16腳就是一個常電,不管是停車熄火還是啟動汽車狀態(tài),都具備供電的特性??瓷先ミ@里只是需要連接一條線,但會引申出一個問題,車載設備,比如ADAS、DMS、駕校學時機、4G網(wǎng)關或者別的,如何來保證功耗。汽車的電瓶是有容量的,有容量那么在停車熄火的時候就會有功耗。那么就要結(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),只要設置400轉(zhuǎn)速的閾值,另外補充熄火后部分車型固定轉(zhuǎn)速不變的情況做排除;
3、水溫:汽車點火后的水溫一般都不會為0或者為空,熄火后的水溫有華氏度和攝氏度兩個類別;
4、發(fā)動機運行時長,汽車點火工作后,發(fā)動機開始運行,ECU控制單元會記錄發(fā)動機運行時長,就像飛機一共多少飛行時間的結(jié)果一樣,這個數(shù)據(jù)有點火到熄火的值,也有累計值,但是累計值,我們一般不做參考,其他汽車市場應用也極少,我們只作為判斷邏輯之一。在發(fā)動機自動啟停下,轉(zhuǎn)速為0,水溫不為0,電壓變低,但有發(fā)動機運行時長。
五、結(jié)語
以上,當數(shù)據(jù)和供電結(jié)合到一起,再結(jié)合最后客戶端上位機的應用,基本上都能解決大部分項目中的問題,這也是速銳得新型智能車載CANBUS數(shù)據(jù)采集OBD接口傳輸及取電安裝應用方式核心所在。
應用舉例:商用車里面還有個典型的應用,就是通過CAN數(shù)據(jù)獲取左右轉(zhuǎn)向信號,基于這個信息來處理ADAS車道偏離報警,比如核心要解決誤判報警的問題。如果ADAS攝像頭識別到車輛跨越車道線,且有轉(zhuǎn)向信號,AI算法就判斷為正常變道。如果沒有轉(zhuǎn)向信號,ADAS主機即刻發(fā)出車道偏離預警信息,在本地提醒司機做出糾正,同時上報平臺主動安全報警事件?,F(xiàn)在很多都是通過IO信號線,接車輛左右轉(zhuǎn)向燈的信號來獲取,前裝車廠的ADAS是通過CAN來獲取轉(zhuǎn)向信號,這也是為什么以色列的公司能做十年的沉淀,我們國內(nèi)搞后裝的接觸不到這塊,那么對這個數(shù)據(jù)的要求,可能實時性可能就沒那么快,只是我們積累的還不夠啊!
我們采集的數(shù)據(jù),都是工具,完成匹配好項目所需,才是目的。很多項目中,客戶不懂汽車、電子、總線、邏輯,一再強調(diào)功能、功能、功能,就會陷入“功能誤區(qū)”,功能越多,系統(tǒng)越復雜,涉及面就越是廣泛,另外還有車型、品牌、年份、總線通信邏輯等多種的不同。測試的范圍越廣、車型越多,暴露出來的問題也就越多。像第一章節(jié)中所說的問題,很多就是致命的,這些問題處理不到,就會導致一個項目掛上東南枝,或者讓一個數(shù)據(jù)開發(fā)企業(yè)走向無盡深淵。
并不是不知者無畏,而是成本太高。
附上PPT首頁,請各位需要的朋友聯(lián)系,獲取完整28頁應用介紹。