改裝車型號

熱點關注:

信息詳情

OBD車聯網如何在大數據上作文章?

時間:2013-06-20 11:51來源:東明汽車音響 作者:秩名 點擊:字號:

OBD車聯網按照“賣××”來分商業模式,有三種東西可賣:設備、服務、數據。

賣設備:把OBD設備賣給車聯網的運營商。OBD設備必須包含OBD模塊;通訊模塊多是藍牙的或GSM;定位模塊可以選擇GSM基站定位、或者GPS;還有些廠家的設備包含G-Sensor。

賣服務:一般是由車聯網運營商為車主提供各種用車管車服務,比如車隊管理;也包括增值服務,比如4S集團使用 OBD設備來加強與客戶的聯接。服務通常按年收費,服務費可能包含或者不包含設備價格。目前,面向個人車主的服務模式不給力。

賣數據:這種方式非常互聯網化,指通過對車聯網數據的分析,從而提供某種個性化的服務,這種服務不限于汽車使用,更側重汽車活動。目前盛行的是賣保險,從之前基于里程的PAYD,到考慮駕駛安全的的PHYD,發展到現在綜合各種因素的UBI。
OBD車聯網如何在大數據上作文章?

“賣××”的模式,不僅僅限于車聯網的OBD設備,對前裝的車機同樣試用。目前的UBI主要通過便于安裝和拆卸的OBD接口;將來則可能在汽車出廠時就已攜帶。

可控、開放是王道

以UBI為例,為了發揮數據的最大價值,數據應該具備一定的、可控的開放性,才能形成良好的生態鏈及其多樣性。具體而言,數據開放性體現在三點:設備、車聯網服務、保險服務。

設備。對于UBI運營平臺來說,設備是哪個廠家的并不重要,重要的是這些設備采集的數據能夠進入運營平臺。這些數據可以是異構的,即結構是不一樣的,但應該是同義的,即具備同樣的含義和價值。

車聯網服務。目前的車聯網服務商是要控制設備的,而OBD設備更多是由服務商自己做(因為需要賣設備來賺錢)。對這些服務商,UBI也可以采取數據合作的形式,讓車主自主選擇。另外,將來基于這些數據的其它衍生服務,應以OpenAPI的方式提供基礎數據。

保險服務。對于車聯網服務商來講,可以同時為幾家保險公司提供設備、系統或者服務,那么,他們就有可能讓自己的客戶來選擇保險公司。UBI運營平臺可以對此開放相關保險數據,而保險公司要控制的是現金流等金融操作。

當然,開放是相對的,必須是在可控的、安全的前提條件下。要做到數據的開放與可控,需要運營管理與技術處理的良好結合。

大數據挖掘之道

以賣數據中的賣保險為例,整個數據的處理流程,如下圖所示:
OBD車聯網如何在大數據上作文章?

 

如果是其它的賣數據方案,則駕駛行為模型、保費風險模型、汽車保險管理系統、保單理賠數據四個部分可能做相應的調整,比如,駕駛行為模型變為LBS的位置模型。

在上面的流程圖中,斜體部分標注了不同的環節對數據計算的要求。在對車輛做監控管理的時候,要求實時性高;當計算駕駛行為模型時,可以采取批處理的方式,若有一些及時性的要求,則可以結合事件驅動的計算模式;當做保險的風險模型時,則屬于BI的范疇,保費風險模型也是屬于近年出現的新需求。

針對這樣的系統,過去的方案一般是:關系數據庫+大內存+總線或消息系統,根據需要可能會包含工作流和規則引擎。若使用Java開源技術,那么這種方案里,通常是把數據庫操作組件、內存組件、總線組件等作為一個整體框架的組成部分,程序整體打包后運行在Server下;根據不同的需要,可能要解決分表、Fail over、熱部署等問題。

大數據技術普及的現在,對這樣的系統可選方案為:關系數據庫+NoSQL+流式計算+分布式批量計算+BI。這些方案目前都有較為成熟的技術,并且都較好地解決了透明化通信、熱部署、Fail over等編程及系統管理性問題。(注:上面的系統構成中沒有給出人的操作端、車的操作端等終端部分。而在這個方面,整個體系也有變化,過去以車機和PC為主,當前則多了手機。手機的加入,改變的不僅僅是多了一種顯示界面、多了很多操作方式,而是多了很多需求。)

關系數據庫用在車聯網運營管理部分,這個部分的業務和技術都已經比較成熟,指保存車及車主數據(包括維修保養)。

NoSQL用于管理從汽車上采集到的數據,以及后面流程的數據,但是,不同的部分應選用不同的、適應各自特性的NoSQL方案:

車輛行駛數據,更適合以日志文件的方式存儲。車輛上報的數據通常是基于字節編碼的比如ASN.1,需要計算時再解碼。

監控管理結果,更適合采用一種內存數據庫方案,可能需要支持快速讀寫歷史數據、以及定時或定量將數據寫入(固態)硬盤。

駕駛行為模型,則需要考慮解決變更計算參數后重新計算、增減模型因子后增刪相關數據、因子的值的類型多樣化(甚至是復合類型)、等問題。

保費風險模型,或者采用與目前保險公司方案兼容的,或者采用適合新型BI的(新型BI在后面會有介紹)。

流式計算用于滿足實時性要求高的汽車監管。不同的流式計算系統側重解決不同的問題。比如Storm解決了實時的分布式計算問題,包括計算流可以分布在一個或多個機器上、動態增減服務器及Fail over自管理、通信機制透明化、熱部署計算流等;Esper解決了事件之間的規則及關系問題。如果監控需求導致數據多且復雜,那么一個內存數據庫是有必要的。

分布式批量計算,目前最流行的方案就是Hadoop。當前Hadoop的熱點之一就是改造Hadoop以滿足一定的及時性要求,而不單單是批量處理;之所以說是及時性,因為它還達不到實時性的程度。

BI(商業智能)。在當前的大數據環境下,傳統的基于關系數據庫的方式呈現出幾個不足:1、傳統方案側重社會化(分析出整體模型,拿個體特征與其對比),難以滿足個體在某時某地的“復雜性/混沌的/發散的”的需求;2、傳統方案在數據量非常大時,可能是抽樣的,難以做到全量分析;3、更多互聯網公司的數據和企業化系統的數據,其存儲已經使用NoSQL方案,傳統方案難以匹配。能解決以上三個問題的BI框架還未成熟。

不管在數據處理的哪個環節,使用那種處理技術,對于數據的質量識別、優劣控制都是必須的。在車聯網中,從車機或OBD設備開始,由于車型的多樣性、設備工作環境的復雜性,數據就不可能達到統一的質量標準,如何處理不同的可用率的數據,如何對待由這些數據產生的價值精準性,是必須考慮的重點問題。

本文版權歸東明汽車音響網及作者所有,如需轉載請保留出處及鏈接!
本文原地址:http://www.rmpoak.live/news/hyfx/1103.html
關鍵詞:

車聯網

  • 電話咨詢

  • 4009981799
qqgame三张牌