OBD車聯(lián)網(wǎng)按照“賣××”來分商業(yè)模式，有三種東西可賣：設(shè)備、服務(wù)、數(shù)據(jù)。
賣設(shè)備：把OBD設(shè)備賣給車聯(lián)網(wǎng)的運營商。OBD設(shè)備必須包含OBD模塊；通訊模塊多是藍(lán)牙的或GSM；定位模塊可以選擇GSM基站定位、或者GPS；還有些廠家的設(shè)備包含G-Sensor。
賣服務(wù)：一般是由車聯(lián)網(wǎng)運營商為車主提供各種用車管車服務(wù)，比如車隊管理；也包括增值服務(wù)，比如4S集團(tuán)使用 OBD設(shè)備來加強(qiáng)與客戶的聯(lián)接。服務(wù)通常按年收費，服務(wù)費可能包含或者不包含設(shè)備價格。目前，面向個人車主的服務(wù)模式不給力。
賣數(shù)據(jù)：這種方式非?；ヂ?lián)網(wǎng)化，指通過對車聯(lián)網(wǎng)數(shù)據(jù)的分析，從而提供某種個性化的服務(wù)，這種服務(wù)不限于汽車使用，更側(cè)重汽車活動。目前盛行的是賣保險，從之前基于里程的PAYD，到考慮駕駛安全的的PHYD，發(fā)展到現(xiàn)在綜合各種因素的UBI。
“賣××”的模式，不僅僅限于車聯(lián)網(wǎng)的OBD設(shè)備，對前裝的車機(jī)同樣試用。目前的UBI主要通過便于安裝和拆卸的OBD接口；將來則可能在汽車出廠時就已攜帶。
可控、開放是王道
以UBI為例，為了發(fā)揮數(shù)據(jù)的最大價值，數(shù)據(jù)應(yīng)該具備一定的、可控的開放性，才能形成良好的生態(tài)鏈及其多樣性。具體而言，數(shù)據(jù)開放性體現(xiàn)在三點：設(shè)備、車聯(lián)網(wǎng)服務(wù)、保險服務(wù)。
設(shè)備。對于UBI運營平臺來說，設(shè)備是哪個廠家的并不重要，重要的是這些設(shè)備采集的數(shù)據(jù)能夠進(jìn)入運營平臺。這些數(shù)據(jù)可以是異構(gòu)的，即結(jié)構(gòu)是不一樣的，但應(yīng)該是同義的，即具備同樣的含義和價值。
車聯(lián)網(wǎng)服務(wù)。目前的車聯(lián)網(wǎng)服務(wù)商是要控制設(shè)備的，而OBD設(shè)備更多是由服務(wù)商自己做（因為需要賣設(shè)備來賺錢）。對這些服務(wù)商，UBI也可以采取數(shù)據(jù)合作的形式，讓車主自主選擇。另外，將來基于這些數(shù)據(jù)的其它衍生服務(wù)，應(yīng)以O(shè)penAPI的方式提供基礎(chǔ)數(shù)據(jù)。
保險服務(wù)。對于車聯(lián)網(wǎng)服務(wù)商來講，可以同時為幾家保險公司提供設(shè)備、系統(tǒng)或者服務(wù)，那么，他們就有可能讓自己的客戶來選擇保險公司。UBI運營平臺可以對此開放相關(guān)保險數(shù)據(jù)，而保險公司要控制的是現(xiàn)金流等金融操作。
當(dāng)然，開放是相對的，必須是在可控的、安全的前提條件下。要做到數(shù)據(jù)的開放與可控，需要運營管理與技術(shù)處理的良好結(jié)合。
大數(shù)據(jù)挖掘之道
以賣數(shù)據(jù)中的賣保險為例，整個數(shù)據(jù)的處理流程，如下圖所示：
如果是其它的賣數(shù)據(jù)方案，則駕駛行為模型、保費風(fēng)險模型、汽車保險管理系統(tǒng)、保單理賠數(shù)據(jù)四個部分可能做相應(yīng)的調(diào)整，比如，駕駛行為模型變?yōu)長BS的位置模型。
在上面的流程圖中，斜體部分標(biāo)注了不同的環(huán)節(jié)對數(shù)據(jù)計算的要求。在對車輛做監(jiān)控管理的時候，要求實時性高；當(dāng)計算駕駛行為模型時，可以采取批處理的方式，若有一些及時性的要求，則可以結(jié)合事件驅(qū)動的計算模式；當(dāng)做保險的風(fēng)險模型時，則屬于BI的范疇，保費風(fēng)險模型也是屬于近年出現(xiàn)的新需求。
針對這樣的系統(tǒng)，過去的方案一般是：關(guān)系數(shù)據(jù)庫＋大內(nèi)存＋總線或消息系統(tǒng)，根據(jù)需要可能會包含工作流和規(guī)則引擎。若使用Java開源技術(shù)，那么這種方案里，通常是把數(shù)據(jù)庫操作組件、內(nèi)存組件、總線組件等作為一個整體框架的組成部分，程序整體打包后運行在Server下；根據(jù)不同的需要，可能要解決分表、Fail over、熱部署等問題。
大數(shù)據(jù)技術(shù)普及的現(xiàn)在，對這樣的系統(tǒng)可選方案為：關(guān)系數(shù)據(jù)庫＋NoSQL＋流式計算＋分布式批量計算+BI。這些方案目前都有較為成熟的技術(shù)，并且都較好地解決了透明化通信、熱部署、Fail over等編程及系統(tǒng)管理性問題。（注：上面的系統(tǒng)構(gòu)成中沒有給出人的操作端、車的操作端等終端部分。而在這個方面，整個體系也有變化，過去以車機(jī)和PC為主，當(dāng)前則多了手機(jī)。手機(jī)的加入，改變的不僅僅是多了一種顯示界面、多了很多操作方式，而是多了很多需求。）
關(guān)系數(shù)據(jù)庫用在車聯(lián)網(wǎng)運營管理部分，這個部分的業(yè)務(wù)和技術(shù)都已經(jīng)比較成熟，指保存車及車主數(shù)據(jù)（包括維修保養(yǎng)）。
NoSQL用于管理從汽車上采集到的數(shù)據(jù)，以及后面流程的數(shù)據(jù)，但是，不同的部分應(yīng)選用不同的、適應(yīng)各自特性的NoSQL方案：
車輛行駛數(shù)據(jù)，更適合以日志文件的方式存儲。車輛上報的數(shù)據(jù)通常是基于字節(jié)編碼的比如ASN.1，需要計算時再解碼。
監(jiān)控管理結(jié)果，更適合采用一種內(nèi)存數(shù)據(jù)庫方案，可能需要支持快速讀寫歷史數(shù)據(jù)、以及定時或定量將數(shù)據(jù)寫入（固態(tài)）硬盤。
駕駛行為模型，則需要考慮解決變更計算參數(shù)后重新計算、增減模型因子后增刪相關(guān)數(shù)據(jù)、因子的值的類型多樣化（甚至是復(fù)合類型）、等問題。
保費風(fēng)險模型，或者采用與目前保險公司方案兼容的，或者采用適合新型BI的（新型BI在后面會有介紹）。
流式計算用于滿足實時性要求高的汽車監(jiān)管。不同的流式計算系統(tǒng)側(cè)重解決不同的問題。比如Storm解決了實時的分布式計算問題，包括計算流可以分布在一個或多個機(jī)器上、動態(tài)增減服務(wù)器及Fail over自管理、通信機(jī)制透明化、熱部署計算流等；Esper解決了事件之間的規(guī)則及關(guān)系問題。如果監(jiān)控需求導(dǎo)致數(shù)據(jù)多且復(fù)雜，那么一個內(nèi)存數(shù)據(jù)庫是有必要的。
分布式批量計算，目前最流行的方案就是Hadoop。當(dāng)前Hadoop的熱點之一就是改造Hadoop以滿足一定的及時性要求，而不單單是批量處理；之所以說是及時性，因為它還達(dá)不到實時性的程度。
BI（商業(yè)智能）。在當(dāng)前的大數(shù)據(jù)環(huán)境下，傳統(tǒng)的基于關(guān)系數(shù)據(jù)庫的方式呈現(xiàn)出幾個不足：1、傳統(tǒng)方案側(cè)重社會化（分析出整體模型，拿個體特征與其對比），難以滿足個體在某時某地的“復(fù)雜性/混沌的/發(fā)散的”的需求；2、傳統(tǒng)方案在數(shù)據(jù)量非常大時，可能是抽樣的，難以做到全量分析；3、更多互聯(lián)網(wǎng)公司的數(shù)據(jù)和企業(yè)化系統(tǒng)的數(shù)據(jù)，其存儲已經(jīng)使用NoSQL方案，傳統(tǒng)方案難以匹配。能解決以上三個問題的BI框架還未成熟。
不管在數(shù)據(jù)處理的哪個環(huán)節(jié)，使用那種處理技術(shù)，對于數(shù)據(jù)的質(zhì)量識別、優(yōu)劣控制都是必須的。在車聯(lián)網(wǎng)中，從車機(jī)或OBD設(shè)備開始，由于車型的多樣性、設(shè)備工作環(huán)境的復(fù)雜性，數(shù)據(jù)就不可能達(dá)到統(tǒng)一的質(zhì)量標(biāo)準(zhǔn)，如何處理不同的可用率的數(shù)據(jù)，如何對待由這些數(shù)據(jù)產(chǎn)生的價值精準(zhǔn)性，是必須考慮的重點問題。
