構建面向未來的靈活信息娛樂系統
加入技術交流群
盡管具備這些優勢，HTML5 這樣的移動應用程序環境并不總是內置人機界面的最佳基礎。車外的世界充斥著不可預知的網絡內容和安全隱患，對人機界面正常運行的威脅尤其令人擔憂。從啟動時間、性能、內存使用來看，這種環境與原生工具包仍然不可同日而語。
這是否意味著汽車公司必須從原生人機界面工具包和移動應用程序環境之間作出選擇呢？其實不然。舉例來說，下圖顯示基于QNX 車載信息娛樂平臺的主機在原生工具包創建的人機界面上同時運行來自多種移動環境的應用程序。不同開發環境構建的組件在同一個顯示屏上和平相處，而且彼此之間也沒有明顯的斷層。
要成功組合這些環境，軟件平臺需要支持多種關鍵技術。首當其沖的是構圖——將來自多個應用窗口的輸出合并到一個顯示屏上。這些窗口可能需要橫向排列、重疊、混合，或是其它一些類似的操作。為了快速有效地執行這種合并，平臺的圖像框架應該利用圖像處理器（GPU） 的硬件加速。在這樣設計得當的系統里，用戶無需手動切換環境，就能與用不同環境創建的組件進行互動，組件的轉換也天衣無縫。
提取服務
為了將這些環境組合起來，平臺還必須提供一個提取層，實現多種工具和語言創建的應用程序與系統服務的互動。例如，在一個基于發布/ 訂閱式消息傳遞的提取層上，應用程序通過數據對象獲得多種服務，例如，多媒體引擎、數據引擎、聲音識別引擎、車輛總線、智能手機、藍牙應用規范、免提電話以及聯系人數據庫。這些數據對象具有多種屬性， 每一種屬性對應一個特征，例如當前廣播電臺的頻率或是發動機的每分鐘轉速（RPM）。系統服務發布這些對象并修改其屬性，其它程序隨即訂閱這些對象，就能及時接收這些屬性的更新。
理想情況中，這一個信息層是與編程語言無關，用不同語言（C、C++、 HTML5、 Java、JavaScript 等） 編寫的程序，無需了解彼此的特性，也能互相交流。因此， 在像HTML5 這樣的高端環境下編寫的應用程序很容易接入設備驅動器提供的服務，或其他用C 語言或C++ 語言編寫的低端服務。
有效控制應用
來自移動世界的應用程序有助于豐富并延伸娛樂信息系統的用戶體驗。盡管如此，保護汽車安全，使其免受移動應用程序類似“西部荒蠻”時期突襲是十分重要的。因此，系統軟件平臺必須使用一個容器將這一類應用程序隔離，以免汽車遭受惡意編碼應用程序的攻擊。
與時俱進
一個信息娛樂系統要與時俱進，必須支持空中（OTA）軟件升級。隨著汽車與快速演進的云服務和移動設備日漸相連，該需求的重要性愈為突顯。理想狀況下，OTA 部署將使用汽車的內置調制解調器，也可以使用智能手機連接技術，如NFC 來簡化汽車- 手機配對的任務，因為許多用戶發現傳統的藍牙配對很困難，而且比較耗時。
基于可行性和經濟因素，OTA 更新應盡可能少地耗費時間和網絡帶寬。理論上，一個信息娛樂系統應該支持細粒度更新，只下載新的或修改過的軟件組件。發布/ 訂閱結構使更新更易于部署，因為它為軟件組件間提供了寬松、靈活的連接，能更新或替換任何組件， 同時不影響與之通信的組件。一個微內核操作系統還能使設備驅動、虛擬機、文件系統、網絡站以及其它系統級服務像獨立進程一樣運行，可動態更新，從而簡化了細粒度更新。
綜上所述，維持信息娛樂系統的競爭力不能簡單地靠堆砌應用程序來做到。在應用程序模式中，司機必須下意識地從一個應用轉換到另一個應用，從而造成駕駛分心。因此，Pandora 或Slacker 等流行的音樂服務應被無縫整合到收音機用戶界面上；同樣地，興趣點或基于位置的服務應用也應被整合到導航系統中。
因此，理想的汽車應用程序其實根本不是一個應用， 而是一個插件。插件結構賦予車內自然界面以新的內容和特性，使得用戶更易理解應用程序并與之互動。
評論