4 5
例如，福斯汽車的執行長 Herbert Deiss 最近表示，
他們打算「擁有」(也就是開發、整合及部署) 車輛中大
約 60% 的軟體，這跟目前的汽車產業有很大的差異，
現在大部分的軟體出自於供應商。
若要在軟體定義的車輛中成為領頭羊或脫穎而出，
做出這類投資的 OEM 必須針對汽車軟體堆疊的端對端
架構，設計出以策略、目標導向的框架。盲目投入資
金與人力無法解決問題，運用這些資源來遵循清楚的
藍圖，並打造差異化產品與經驗，才能真正解開難題。
對大多數 OEM 而言，若要以節省成本的方式執行軟
體定義車輛的藍圖，通常會需要仰賴合作夥伴提供的
解決方案，和/或開放原始碼軟體，特別是在採用軟
體的過程之中 (而非創造價值的過程)。像這類相對複
雜的軟體元件僅需要針對特定 OEM 平台稍微進行自
訂，因此要在內部建立整個堆疊不太符合經濟效率。此外，有許多第 3 方開發人員也想透過規模經濟，
盡可能擴大可觸及的市場，同時縮小對 OEM 自訂解決方案所需要的投資。從頭開發能提供與可擴充供
應商解決方案類似功能的自訂內部元件，可能會讓車輛平台開發藍圖額外增加二至四年的時間，而且最
後還做出更不理想的產品。
讓中介軟體將軟體與硬體解耦
汽車製造商和供應商以往會針對獨特的硬體和裝置作
業系統環境開發軟體。這種作法帶來了複雜的老舊
技術問題，使得軟體定義車輛的演化進程 (而非變革)
變得十分艱難。這類軟體雖然可以改善資源運用效
率，卻也會將軟體與特定部署架構「綁成一對」，使
得更新、整合和/或擴充至額外的車輛平台或系統變
得相當困難。
中介軟體是解耦這類軟體最重要的工具，並且為軟體
建立可更新、可擴充和可攜帶的平台。
中介軟體的名稱取自於其功能：介於不同的元件或環
境「之間」。在這類情境中，中介軟體會在特定元件
上的硬體特定執行時間、裝置作業系統，與部署於系
統上執行的應用程式軟體之間建立界線。
實際上，中介軟體需要了解裝置特定的執行時間，並
且將部署特定的細節轉譯成高階軟體的標準化介面。
可以採用以下形式：API (例如豐田汽車的 Arene 平
台)、SDK (例如 BlackBerry 的 IVY 解決方案) 和/或整
體應用程式平台 (例如 Android Runtime、AUTOSAR
Adaptive Runtime for Applications 以及 IVY)。這類完整堆疊的執行時間是為了要解決車輛軟體結構的特定
問題。AUTOSAR Adaptive 的執行時間通常會用來打造特定領域的解決方案；Android 執行時間通常會用於
託管應用程式 (.apks)，並提供豐富有趣的 UX；IVY 的執行時間則支援在汽車上安全地執行分析工作負載。
已連接的中介軟體：業界參照
若要有效率地開發和支援軟體定義車輛平台，中介軟體策略是必要的。因為中介軟體不是單一元件，
而是一組軟體元件，提供全方位的沙盒環境和抽象 (屬於上述所列所有執行時間的一部分)，因此汽車
製造商必須採取車輛整體系統的視角，提供軟體架構來因應各個領域 (例如自動駕駛和數位駕駛艙)
以及其相關聯的中介軟體。
其中一個汽車特定的連結中介軟體範例是 BlackBerry 和 Amazon Web Services (AWS) 合作開發
IVY，以協助 OEM 符合這些常見需求。下方圖 5 列出了此平台的應用。此圖表中的範例是一個中介
軟體產品 (IVY)， 與 AUTOSAR 和 Android 中介軟體元件搭配使用。其示範 OEM 可以如何選擇包含
各種開放原始碼、標準化或買入元件的中介軟體策略，(「擁有」車輛的軟體庫存不代表需要自行開
發所有項目)。
在這個案例中，IVY 的「綜合感應器」(特別是處理資料或訓練演算法的小型分析應用程式) 會在車輛
上使用標準化的車輛感應器介面運作。這個架構模式提供了同質的抽象層，讓 OEM、第 3 方開發人
員、供應商和其他經過授權的利害關係人可以建立應用程式，且無須擔心硬體或特定車輛平台的工
程設計。
結合這類常見的業界中介軟體解決方案後，OEM 就可以達成可擴充的整合，顯示軟體定義車輛的彈性。
圖 5 - 透過 AUTOSAR Adaptive 和 Android Automotive 部署 BlackBerry IVY
圖 2 與圖 3
圖 4
