【未來汽車應用軟體部署、管理將掀起新變革】容器掀起汽車第二次軟體化變革

每年1月舉行的美國CES電子消費大展，已成為各大車廠展示最新汽車技術和未來汽車的主舞臺，但是今年展覽很不一樣，除了各大車廠大秀軟體肌肉，第一次有車廠公開說，要把IT圈火紅的容器（Container）技術帶進汽車。

儘管在IT領域，容器技術發展已相當成熟，為因應汽車軟體化風潮，車界近幾年出現不少關於汽車軟體容器化的討論，大多只限於開發或測試階段導入，還沒有真正在汽車內部環境使用。所以，當福斯要讓汽車支援容器技術的消息一出，格外引人矚目。

其實早在多年前，賓士汽車就提出要用容器驅動汽車的概念，但當時還無法實現，現在福斯搶先一步完成，甚至福斯不是構想，而是已經開始實做。

福斯汽車與雲端平臺負責人Amen Hamdan在今年CES主題演講中透露，目前已經能提供一個嵌入式容器化應用的runtime，讓開發者可以使用容器將應用打包後送到車上的實例做更新，而且可以將應用拆分，對個別小型功能進行更新。儘管他沒有透露哪些汽車功能會先採用容器，但也預告：「今年把這項技術導入車上後，會推向更多車款。」他表示。

不只有車廠要讓汽車支援容器技術，去年5月，紅帽宣布要把企業級Linux帶進汽車上，也成了未來容器可以跑在汽車上的另一個關鍵證據。

容器技術很早就在Linux平臺上實現，對於Linux支援也更完整，例如最早推廣容器而聞名的Docker就是基於Linux containers發展而來，但在眾多支援Linux containers的IT廠商中，紅帽發展腳步最快，從2014年RHEL 7作業系統就內建Docker，後來歷經多個版本更新，對於容器應用功能支援更全面，發展到現在已經相當成熟。

從紅帽宣布與通用汽車的合作中透露出，未來紅帽車載OS將可以取得車上應用的底層控制權限，來支援安全和非安全車載相關應用，包括車載資訊娛樂系統、ADAS、車輛控制與車聯網等。甚至很快地，全球第一輛搭載車用RHEL的汽車今年上半年就會亮相，意味著，原先紅帽所擁有完整的容器開發平臺、應用工具等生態系都準備就緒，未來可以運用到汽車中。

過去容器技術的出現，顛覆IT產業，掀起傳統IT架構變革，如今，這項技術也開始進到傳統封閉汽車產業，不只有機會推翻傳統汽車應用部署和管理模式，更將引領汽車軟體化發展往下一階段邁進。

為何汽車軟體需要容器化？

容器技術最大特色是為應用程式提供了一種標準封裝格式，可以把應用程式連同環境一起打包，再發布到任何可執行容器的平臺上，來方便管理、移動和部署應用程式。

使用這種封裝格式，因為具有更好的移動性，軟體開發人員可以很容易將容器化汽車軟體部署到車上，不像採用傳統封裝的汽車軟體，除了安裝軟體之外，通常需額外加裝其他附加元件，來補足原本軟體執行所缺少的相關元件，才能順利執行。容器化汽車軟體因為在封裝過程中，已經預先把汽車應用軟體程式、組態及其相依性等所有執行需要使用的檔案、程式庫都打包起來，因此就不需要擔心環境不一致的問題。這是容器化汽車軟體和傳統汽車軟體最大的差異。

尤其，以後車廠需要常常為所有出廠的汽車更新軟體，來提供各種汽車功能與體驗服務，使用容器技術，就可以更容易透過OTA更新替換汽車元件上軟體，來減少現場更新維護的人力，不需要採用跟過去一樣更新方式，得由車主親自開回原廠，再由車廠技師將更新檔案安裝到要更新的汽車裝置上（如車載電腦等），就能完成汽車軟體更新的動作，甚至遇到有一些共通性功能需要更新時，還能共用同一個更新檔，不需要根據入門、旗艦型等不同等級車款來調整，各別發布更新。

容器化技術也是最能體現「搭建一次，隨處可用」精神。因此，用容器技術開發出來的應用，就可以很容易放在任何地方來執行，特別是在需要經常變動的汽車環境中，因為不需要考慮相依性的追蹤和異動，所以它的流通性更高，可以快速擴展，將有助於汽車軟體化生態的發展。

不過，汽車越來越軟體化，也容易導致汽車內部軟體系統越來越複雜且龐大，但透過容器技術，搭配其他調度管理工具，也能加以改善。

從軟體開發流程來看，更能確保不論是在測試環境，或上線前準備環境進行測試，都能和正式環境那套軟體環境保持一致，不容易受到不同環境配置差異的影響。

不僅如此，因為有了容器技術，也讓軟硬體解耦變得更容易。過去汽車軟體開發流程上，必須考慮到車輛系統發布周期，導致軟體開發周期變長，因為軟硬體綁定，在軟體化汽車趨勢潮流下，首先就要把硬體和軟體架構分離，讓軟體可以單獨開發， 來縮短開發周期。由於容器技術是以應用程式為中心的虛擬化技術，可以讓這件事更容易被實現。

從硬體架構來看，過去汽車內部是一個大型分散式架構系統，配備許多ECU，各自提供不同車用功能，新一代汽車E/E（電子電氣）底層架構逐漸走向集中式架構，在這個新架構下，原本分布在汽車中的ECU開始向上集中到少數主要ECU或汽車中央電腦的HPC平臺上處理，也將帶動汽車正式環境部署容器應用的需求，更進一步將汽車傳統應用程式從ECU中移植到新架構，從而加速軟體化汽車的發展。

與傳統VM相比，容器化軟體也更輕量，可以用最小的方式將軟體所需執行的資源都封裝在一起，成為一個容器映像，再部署到汽車新舊裝置中。因為不需要借助作業系統來幫忙，因此就不需要先裝好一套作業系統，所以較不占用空間，啟動速度也更快。

容器本身擁有完整且成熟的生態系，是汽車擁抱容器技術帶來的另一個好處，有許多現成容器開發和管理工具，以及資安工具等，都可以直接套用，甚至，容器技術也是目前主流，所以當車廠開始使用這個技術以後，原本專精於容器的這群人能直接進來，成為車廠開發容器化汽車應用即戰力。

但是初期，汽車容器化軟體會以非安全相關的汽車應用為主，畢竟汽車軟體仍與一般消費性或企業軟體有所差別，更加強調功能安全性，不像手機軟體當機，只要重開就好，汽車軟體一旦當機，嚴重可能攸關生命安全，所以設計上必須把這些安全要求納入考量。這也是為什麼紅帽開發汽車Linux花了2年多，就是為了要取得ISO 26262汽車功能安全的認證，才能夠放進車上使用，這也成了容器技術進到汽車上後能不能有更多應用的挑戰。

汽車產業第二次軟體化變革

這不是汽車產業第一次技術大變革，而是近十年來第二次革新。過去因為電動車、自駕車的出現，汽車設計開始從硬體轉向軟體為中心，掀起第一波汽車軟體化的變革，從單一介面的軟體化開始，到汽車基礎架構軟體全面性改變。也因為汽車軟體越來越重要，甚至成了影響汽車應用或服務能不能更進一步延伸的關鍵。

從軟體化進一步發展到容器化應用，將是汽車軟體化下一階段發展。不同第一次軟體化變革，更追求軟體敏捷和彈性，來滿足未來更多汽車功能增長與頻繁更新需求，更要改善因為這波軟體化汽車風潮而越來越複雜的軟體系統架構，以便在汽車中管理及部署。這是汽車產業迎來第二次的軟體化變革。

不只是容器，未來更多雲原生技術將走進汽車

傳統汽車體質也因為這波新變革而有不一樣的改變，讓車廠更容易在汽車內採用雲原生，來支援對於汽車應用程式進行快速更新迭代、移轉或部署，不只增強敏捷性，還能提高員工生產力和縮短應用交付的時間。這些雲原生技術，將成為加速推動汽車軟體化發展另一個重要關鍵。

其實近兩年，不少大型車廠早就導入雲原生技術，運用容器、Kubernetes容器調度管理工具與微服務對汽車軟體開發流程進行現代化工程改造，並結合DevOps與CI/CD測試部署自動化，藉此來縮短軟體開發周期，以便更快推出新功能，包括福斯、賓士、福特、通用等，都已經實際採用。

不過，現階段想要在汽車上使用Kubernetes來管理汽車容器化應用，還是有困難，但為了管理這些汽車容器化應用，就需要有一個能管理汽車中多支容器的管理工具，為此，也有IT廠商試圖尋找替代方案。例如，紅帽就打算以Podman來取代Kubernetes，用來管理汽車內部多容器應用程式。

Podman同樣也是容器管理工具，但與採用多節點叢集架構的Kubernetes相比，Podman更加輕量，不需要處理多臺Pod主機叢集的網路連接、複雜的節點關係，因此就很適合在資源有限的汽車嵌入式環境中使用。

原本Kubernetes使用YAML檔來描述工作負載，包括containers和pods，來減少管理的複雜度，因為Podman同樣支援Kubernetes YAML檔，當以Podman搭配systemd使用時可以支援Kubernetes應用描述，這意謂著，可以在車輛中使用與雲端相同的Kubernetes宣告或描述，使用YAML來管理在單個節點上的多個汽車容器應用，而沒有Kubernetes本身多節點叢集管理負擔和複雜性。

從容器調度工具開始有了汽車專用版本的發展來看，也透露出，以後汽車環境不會只有單一容器，而是一個多容器的應用環境。甚至更進一步，還能發展成微服務架構。

嵌入式處理器設計大廠Arm也看好雲原生將成為軟體化汽車更進一步發展所必備的關鍵技術。從Arm所揭露一張汽車軟體化發展架構圖也反應出這個趨勢。未來汽車內部軟體堆疊架構，將從服務導向SOA架構，逐步轉向微服務架構的過程，在這個新架構下，以後汽車內部軟體應用程式將全部變成一支支微服務程式，來取代傳統單體式設計的應用程式。甚至更進一步，未來微服務架構還要能夠支援混合關鍵性任務（mixed critically）調度需求，以便符合車規即時處理和功能性安全的要求。

對於汽車軟體化發展而言，拆分微服務顆粒度的好處是，可以將單一應用程式分拆成多個小型功能的微服務，因此更能應對經常變動的汽車應用程式的環境所需。並透過API讓不同微服務能夠彼此溝通和相互串聯來提供汽車服務。福斯目前也正在嘗試把這項技術運用在汽車上，未來還要透過API，讓開發者可以很容易取得汽車功能相關數據進行應用開發。

當車廠開始把更多雲原生帶進汽車，以雲原生技術打造汽車基礎架構，就像現在許多大型企業資料中心都是雲原生資料中心，大力擁抱基礎架構程式碼化（Infrastructure as Code），使用軟體的方法管理資料中心的設計、硬體架構和維運。汽車也就像是一個裝輪子的雲原生資料中心，讓汽車基礎架構應用開發、部署與維運，都可以透過自動化方式來執行時，汽車將不只是容器化汽車，更是一輛雲原生汽車。

從嵌入式處理器設計大廠Arm所揭露一張汽車軟體化發展架構圖能看見，未來汽車內部軟體堆疊架構，將從服務導向SOA架構，逐步轉向微服務架構的過程。在這個新架構下，以後汽車內部軟體應用程式將變成一支支微服務程式，來取代傳統單體式設計的應用程式。甚至更進一步，未來微服務架構還要能夠支援混合關鍵性任務（mixed critically）調度需求，以便符合車規即時處理和功能性安全的要求。圖片來源／Arm

大型開源社群力推SDV風潮，也加快汽車軟體容器化推動

過去2年來，軟體定義汽車（Software Defined Vehicle,SDV）或軟體化汽車風潮迅速竄起，不只是傳統大型車廠積極投入，如福斯、通用、福特、賓士等，更有不少IT廠商、大型公雲業者搶進，就連大型開源社群都大力支持。

去年3月，旗下有許多知名物聯網專案的Eclipse開源軟體基金會，成立了一個新的SDV工作小組，這也是第一個由大型開源軟體社群所發起的SDV專案計畫。該小組任務是要為軟體定義汽車打造一個程式優先的開源平臺，目的是要徹底改變汽車產業傳統軟體開發方式，因此初期工作項目，包括建立車載應用runtime堆疊、雲端汽車OS與整合開發工具鏈，讓汽車製造商和供應商可以安全可靠的方式部署、配置和監控車輛軟體，也提供跨不同車型、車廠車載軟體開發所用。初期成員有微軟、ZF、Arm、Bosch、紅帽、ETAS等，一年後成員數增加到30多家，日本汽車大廠豐田也加入。

其實，早在Eclipse SDV成立前，就已經有相關SDV開源專案推出，其中又以紅帽主導的CentOS Automotive SIG為代表，不只要建立與汽車相關開源軟體，更要改造CentOS發展汽車Linux，作為車廠打造新車載OS的參考設計與概念驗證。

CentOS Automotive SIG成立不到一個月，另一家嵌入式處理器設計大廠Arm也力推SOAFEE新架構，這是一個可擴充嵌入式邊緣軟體框架，Arm希望藉由SOAFEE架構，將雲原生技術導入車用領域，加速推動SDV發展，包括自動駕駛、先進駕駛輔助系統（ADAS）等，讓汽車業者更容易開發能在Arm裝置執行的混合關鍵型應用。目前已有第一個版本釋出。截至去年底參與該專案成員超過50家，涵蓋半導體晶片廠商、軟體供應商、系統整合商、雲端服務供應商、車廠與Tier1汽車供應商等。

就連知名代工大廠鴻海，也瞄準軟體化汽車的商機，在2年前成立MIH開放電動車聯盟，在鴻海號召下，成立一年就有超過2千家業者加入，希望藉由打造開放汽車硬體框架打破傳統封閉的汽車開發環境，讓不只傳統車廠，其他行業都能加入，進而推動汽車產業的變革。期間還釋出了電動車開發者工具平臺EV Kit，能提供純電動車整車設計軟體介面及硬體規格。至今更以此架構推出三輛不同等級的電動車。

透過引進這些開源軟體與社群的力量，未來將會有許多開源工具、軟體套件提供，搭配開放式硬體架構，將有助於未來汽車軟體容器化加速發展。