伴隨著智能手機的發展和普及，消費者對智能和互聯網帶來的變化已經有了充分的認識，然而如今的汽車卻很難與"智能"聯繫起來；尤其是汽車裡那塊難用的屏幕，也讓手機支架成為大部分車主必備的裝備。這種奇怪的現象讓我們不禁要問車載系統什麼時候才能像手機一樣方便智能？
再豪華的汽車也逃不掉被手機支架支配的恐懼
也正是這種疑問把已經發展百年的汽車推到了一個變革的時間點——智能化、網聯化，讓沉悶的汽車行業開始波濤洶湧。汽車企業和互聯網企業開始嘗試研發適合汽車的智能車聯繫統；尤其是在阿里巴巴和上汽基於AliOS系統開發的斑馬智聯車機受到市場認可以後，從吉利、長安這些自主汽車巨頭，到百度、騰訊等互聯網豪強都紛紛入局，大家都希望能在這一場變革中找到新的爆發點。
2016年，上汽與阿里合資的斑馬推出基於AliOS的斑馬系統
2017年，百度發佈DuerOS系統，騰訊推出AI in car系統，蔚來推出NOMI系統
2018年，吉利推出GUKI生態系統，比亞迪推出DiLink系統，長安與騰訊合資開發車載系統
……
那到底什麼樣的車聯繫統才是真正適合汽車的？哪個車聯繫統才能為消費者和駕駛員帶來真正的方便和智能？我們來做一個詳細的解析。
汽車與手機的差異
從Andriod到IOS，智能手機的普及讓消費者對方便好用的系統已經有了一個基礎的認知；也正是因為這類成熟的智能操作系統在前，大部分消費者在車載場景下也會很自然的有相同的需求。但其實我還是要說明，直接把手機和車機等價也確實有點難為汽車行業了。
車載系統遠不是手機搬到汽車裡這麼簡單。汽車級的系統在可靠性、成本、開發週期、交互上都有應該遵守的邏輯。
1. 汽車的可靠性要求高
汽車動輒十多年的使用壽命要求，又要面對高低溫、振動等各種複雜環境，加上三年/十萬公里的質保要求，讓車內的電子零部件的要求相對手機平板都要高很多，我們可以對比一下中控車機和手機的可靠性測試差別。可以看到車機在各項指標中都比手機嚴格很多。這個基本的要求給車機的軟硬件開發都帶來了很多的要求，比如處理器要耐高溫、屏幕模組要防撞擊等等……
汽車系統與手機試驗標準的差異
2. 處理器性能限制
在普通消費者心中，手機處理器的性能已經非常強大，這些消費級的處理器（例如華為麒麟980、高通845），性能確實一流，但其工作溫度範圍一般都只能在-10~50℃左右；但按照上面提到的車載使用環境，這些處理器卻不合格，簡言之，不滿足車規級AEC-Q100標準。處理器要達到車載的使用要求，在工藝製程和性能上必須要妥協。這也導致同期的汽車級處理器性能都比同期的手機處理器要落後了約兩代。
英特爾2017年發佈的車載芯片Apollo Lake，工作溫度範圍-40℃~110℃，最高性能版本4核2.4GHz
3. 人機交互差異
手機的人機交互和界面設計並不適合汽車，如果僅僅是簡單的將手機系統移植到汽車上，就會出現下圖這樣的情況，車機屏幕上整齊排列著app的圖標和小小的字。這種偷懶的設計既不美觀又不利於駕駛員操作，一股腦的把所有手機app堆到車機上也顯然沒有充分考慮用戶使用場景，難道我會在碩大又不順滑車機屏幕上發微信？
車聯繫統的關鍵要素
如今大部分的車聯繫統都是基於開源的Android或Linux經過二次開發而來的；針對汽車和手機的差異，除了沿用Android的部分層級和模塊，還需要針對車載場景進行一些定製化開發和優化。
Android系統架構
具體而言，相比於手機操作系統，完整的車聯操作系統一般應該滿足以下幾個關鍵要素：
1. 支持車輛控制
結合車輛原有的功能才能實現更好的體驗，車載操作系統需要具有支持車輛控制的層級和模塊；一般是需要包含車載CAN總線功能和相關控制權限。
2. 集成汽車專用服務
相比於手機，汽車還包含很多特有的服務功能，將這些功能集成到操作系統中能提高服務的實施效率和功能的安全性，例如與手機連接、車輛診斷、遠程通信等功能。
3. 專門的電源管理
汽車啟動時車載系統也需要迅速開機（幾秒內），點火時造成供電系統異常電壓波動和衝擊問題（12V電源大範圍跳變），這都要求車載操作系統具備專門的電源管理方案，需要在操作系統中對不必要的部分進行裁剪和優化，以保證電源異常時的正常運行。
4. 支持低成本硬件優化
由於車規級的要求和成本的限制，汽車上的處理器CPU性能都不及手機處理器，為了實現足夠的效果，滿足汽車長達十多年的使用週期，操作系統在這方面也具備相應的優化功能。
下圖是完整的車載操作系統具備的層級和功能舉例。一個汽車需要實現完整的車聯功能，理論上除了包含Android/Linux的內核、應用層、系統層以外，至少還需要汽車服務、車輛控制的層級。
完整車聯操作系統層級
業界解決方案對比
我們再回頭來看這兩年出現的各種"智能車聯操作系統"，按照上一節嚴格的層級定義，其實很多系統並不都屬於完整的操作系統，大部分都只包含了少數層級和模塊，或者只重寫了一部分模塊來適應車載場景，只有極少數定製了所有的層級。這些系統按照深度定製的層級，大致可以分為三類，借用手機行業的說法分為超級app、ROM、定製操作系統。
1. 超級app
這一類雖然名叫系統，但其實只是將智能導航、語音交互、雲服務等功能做成類似手機app的形式，在應用層通過調用系統已有的車輛服務接口實現相關功能；也沒有支持汽車服務的層級和模塊，其他部分沿用現有系統。典型代表有騰訊AI in car（最近更名為Tai）、百度DuerOS。
由於只開發了應用程序，這種方案的開發週期短，成本低，只需要車企提供相應的控制接口即可實現車聯網功能。騰訊車聯方案最快僅需要半年時間即可落地（2017年11月與廣汽合作，2018年5月聯合推出祺雲智聯繫統）。當然缺點也比較明顯，由於沒有與系統下層深度整合，只能按需求調用相關資源，導致部分功能體驗有瑕疵；另外在升級的時候，也只能在現有功能上升級，無法憑空調用新的下層接口，實現與車輛相關的新功能。這種方案比較適合車載系統開發基礎薄弱，希望快速落地智能網聯的車載系統的汽車企業。
2. ROM
基於自身需求對應用層、框架層和汽車服務層進行定製，更下層則沿用裁剪後的Android組件，類似於手機中的各種ROM。此方案更側重框架層和汽車服務層，能提供靈活的車輛服務功能，是希望自研操作系統，而不被互聯網綁架的汽車企業的首選。典型代表有吉利GKUI、比亞迪DiLike等。
這種解決方案針對汽車深度定製，與汽車本身功能進行整合，能提供較為完整的智能車聯功能，汽車企業可根據自身的設計和需求對用戶界面、車輛功能進行定製化開發，能掌握足夠的主動權。但由於更底層的網絡連接、安全管理等方面沿用Android系統，具有一定安全性和可靠性的隱患。而車企一般不具有互聯網生態，在上層的雲服務中多數還是需要與互聯網企業進行合作。另外，因為對底層涉及的不多，在不同的車型搭載的時候需要重新適配和開發，無法直接複用。這個方案適合具備一定軟件系統開發能力基礎和人才儲備的汽車企業，但這條路並不好走。
3. 定製操作系統
基於Android系統，對其內核、硬件驅動、系統服務等底層進行重構。重寫硬件抽象層和相關的資源調度模塊，並根據不同的底層硬件，對系統進行有針對性的優化。形成一個整體的打包解決方案。典型代表有AliOS、AGL（Automotive Grade Linux）、Android Auto等。
這種方案將硬件資源深度整合優化，集中調用，對汽車層面的硬件調度更為合理；作為整體的解決方案，在對底層硬件進行適配以後即可在全車型通用。但是，這種深度整合的系統，需要大量的時間和人力投入；比如阿里巴巴為克服Android系統的限制，經過手機、車機的迭代經過十年，投入超過百億才完成了AliOS，今天更是將AliOS上升到集團戰略；而谷歌基於Android開發的auto版本，現在還沒有發佈。所以這套方案一般的企業短期內無法模仿研發，但一旦成功也可以築起較高的技術壁壘。
對比
汽車如何擁抱互聯網
上述三種方案在現在這個汽車亟需提升車內互聯體驗的時間點來說，談不上絕對的好與壞；各汽車企業的需求、戰略和可支配資源都不一樣，在選擇車載系統的解決方案上也會有相應的差異和取捨；也就是看相關企業是為了迅速落地，趕上這波浪潮快速獲利賺快錢，還是著眼於未來，長遠規劃深度佈局。
雖然目前看來合作開發深度融合的上汽和阿里已經佔得一絲先機，但其他企業也正調動資源追趕，依靠戰略合作和合資迅速拉起戰線，這場智能網聯汽車的爭奪戰才剛剛開始。
在這種廣泛的競爭中，消費者們也應該相信，有朝一日當我們進入車裡的第一件事將會是語音喚醒智能車載智能助手，而不是把手機架到支架上。
（轉自：知乎汽車大V 史高拔）
閱讀更多 科技圈熱潮 的文章
