人們總是對智慧汽車未來的樣子充滿幻想，自從「軟體定義汽車」這句話誕生開始，軟體就被寄予了定義未來汽車的期望。可是隨著人與車之間場景的多樣化和複雜化的不斷提升，誰來定義軟體本身呢？ 是汽車廠商、供應商，還是軟體開發商？
在 4 月 9 日上汽零束 SOA 平臺開發者大會上，零束給出了一種新的解題思路。將定義軟體和汽車服務的權利開放，不僅是開放給供應商和第三方開發者，更是開放給普通使用者。這種開放是怎麼實現的？SOA 平臺又是什麼呢？
什麼是汽車 SOA？
SOA 是一個在網際網路行業耳熟能詳的軟體技術，如今，隨著智慧汽車中軟體重要性的提升，SOA 理念逐漸引入了汽車領域。汽車上的 SOA，就是將汽車各子系統中最小功能的邏輯單位抽離出來，封裝成服務，組成一種粗粒度小、松耦合的服務架構。這些最小單元的功能模組就像樂高中的基礎件一樣，既可以互不干涉的獨立呼叫，也能在各子系統中互相相容。
比如我們將主駕座椅按摩作為一個「基礎件」，它既可以單獨呼叫；也可以與疲勞檢測功能配合，來實現疲勞預警；同時也可以與其他 ADAS 功能配合，實現其他預警功能。
SOA 平臺的執行，離不開中央集中式電子架構這個智慧汽車大腦和神經網路的支援。以中央計算單元為核心，透過高速通訊技術把智慧座艙域、智慧駕駛域和智慧互聯域有機地組織起來，才能實現整車底層功能的互聯互通，實現功能的獨立呼叫和相容互動，將軟體結構原子化，做到軟硬體的解耦。
因此，在這次的 SOA 平臺開發者大會中，我們看到零束推出的「銀河」智慧汽車全棧解決方案，不僅包括了 SOA 軟體平臺，也包括中央集中式電子架構、基於物聯網 IOT 方案的整車資料工廠、保證整車生命週期內可持續迭代更新的全棧 OTA 和網路安全解決方案。這些基礎技術一起，為 SOA 開放者平臺打下了堅實的基礎。
SOA 平臺，給汽車搭載上「APP Store」
以 SOA 理念來打造整車功能，將汽車各功能模組化，是當下很多車企的重頭戲，比如寶馬在中央計算平臺將整車功能進行劃、抽取和封裝，大眾利用面向服務的架構（MEB 架構）來實現軟體的可擴充套件性和複用率等等。而零束這次的驚喜，是把 SOA 軟體平臺全面開放，讓更多的第三方開發者甚至普通使用者，也參與到軟體功能的打造中。
零束這次把整車的智慧控制演算法、感知裝置和執行裝置都封裝成統一可呼叫的服務，將 SOA 平臺打造成專業的整合式開發環境。這樣一來，汽車的 SOA 平臺就像是手機上的「APP Store」，成了軟體的孵化器。開發者根據零束提供的可呼叫服務，開發出各種服務和應用，上傳到 SOA 平臺；使用者可以根據自己的需求，選擇訂閱自己喜歡的服務。和下載 app 一樣，根據功能不同，這些服務有的是免費的，有的需要付費。
在平臺的打造過程中，降低門檻，讓更多的人參與進來，至關重要。目前零束 SOA 開放著平臺分為三種模式，面向普通使用者的場景工坊、面向第三方開發者的 Z-ONE Studio Lite、面向 OEM 和供應商的專業版 Z-ONE Studio，類似於「簡單版」「高階玩家版」和「專業版」三個模式。
「簡單版」，面向普通使用者的場景工坊，介面類似於手機的控制系統，在類似 ipad 等移動端可以透過對圖形的拖拽和引數選擇，定製專屬場景，並一鍵同部到自己的汽車。比如自己設定個「生日模式」，在生日當天啟動汽車後，自動觸發音樂播放器和氛圍燈，用「happy birthday」的歌聲給自己一個小儀式感等等。這種模式的設定不僅針對自己的汽車，也能同步上傳到平臺，看著別人給自己的模式點贊或者訂閱，這也許能衍生出一種新的社交方式。
「高階玩家版」，即面向第三方開發者的 Z-ONE Studio Lite 中，採用的是類似流程圖式的輕應用架構，透過調整流程圖中各功能間的關係和引數，來打造不同的場景。同時平臺右側配合的視覺化模擬效果，可以實時模擬車內的效果，讓開發變得快速、直觀。
如果說面對普通使用者和第三方開發者的工具，主要是根據對車內已有的功能進行模組化組合，來打造不同場景，還處在「量變」的階段；那在專業版的 Z-ONE Studio 上，我們更期望能看到軟體功能「質變」的發生。很遺憾在這次的開發者大會中，零束並沒有向我們展示專業版是如何具體實施的，這也讓我們在期待 SOA 開發者平臺的同時，看到了更多的挑戰和不確定性。
新的模式下，新的挑戰
新的嘗試總要面臨接踵而來的新挑戰，汽車 SOA 平臺也不例外。我們從不懷疑 SOA 模式下技術的可行性，不過 SOA 開發者平臺帶動的全新的使用者與汽車互動模式、開發者與汽車和使用者間新的商業模式，依然帶給我們未知的好奇和挑戰。
比如，對於汽車至關重要的安全性問題。
我們能接受從「APP Store」下載的 app 出現閃退、崩潰的情況，但在汽車上對於軟體的容錯率顯然低得多，功能性軟體一旦出現問題，在駕駛過程中都有可能造成安全隱患，這顯然是使用者和車企都無法接受的。安全性的高要求，對平臺和 OEM 的監管提出了更高的標準。與高標準的監管相應的，是 SOA 平臺准入門檻的提升，而讓平臺活躍起來恰好相反，需要的是將准入門檻降低。讓更多的開發者參與進來，才能打造更強的服務和功能，吸引更多使用者；同時更多使用者的參與，才能吸引更多更優秀的開發者加入進來。
這就像天平的兩端一樣，一邊是「高標準嚴要求」，一邊是低門檻吸引更多參與者，這種挑戰的難度可想而知。
除了安全問題外，智慧汽車這個巨大的移動載體承載的海量資料，也造成了不小的挑戰。
單就汽車本身來說，將底層打通的中央集中式電子架構目的就是實現功能的互通和資料的共享，但並不是所有資料都適合「共享」，因此就需要在資料分類分級上下足功夫。更何況資料涉及的不只是電子架構本身，舉個例子，第三方開發者提供的軟體產生的資料，究竟是歸開發者所有，還是歸車企所有呢？
此外，
如何調動開發者參與 SOA 平臺的積極性，也是個不小的難題。
一個軟體開發商在開發手機軟體時，只需要做安卓版和 iOS 兩個版本，而當軟體上車時，要面臨數不清的汽車品牌、車型。雖然目前零束 SOA 平臺使得軟體可以在上汽旗下 R 汽車和智己汽車上通用，但有更多的車型加入進來，降低軟體研發的邊際成本，顯然才是開發商所期待的。
與較高的開發成本相對應的問題，是開發者平臺將如何實現商業的變現？目前座艙內的使用場景，還無法像手機一樣實現收入閉環，我們能在手機 app 裡直接購買服務、產品，但當類似的購買行為發生在汽車軟體上時，我們還是會第一反應掏出手機、掃碼，車載軟體無法從使用者身上直接獲得營收……
在尚且沒有明確的利益共享的情況下，僅用下載量來打動開發者，動力似乎沒有那麼足。
最後
儘管在目前的 SOA 開放者平臺中，還有很多沒有給出答案的猜想和潛在的挑戰，但零束的這次 SOA 平臺釋出，讓我們看到了汽車軟體敞開懷抱、走向使用者的一步嘗試，也看到了一種新的未來商業兌換的可能性。至於 SOA 這一步能走多遠，不只需要零束和上汽的努力，也需要更多供應商甚至整個汽車行業的參與，共同將定義軟體的權利交給大家。
