隨著各種能力與功能部署到當代汽車平台的成長速度越來越快，新增功能包括先進駕駛輔助系統(ADAS)、自動駕駛(AD)與升級的車載資訊娛樂系統(IVI)，汽車製造商正面對著一個轉型至軟體定義的未來。
這項轉型是汽車市場未來發展的關鍵，它透過降低成本與創造全新的營收機會，增加更多業務收入並提升利潤率。藉由促成車內各項功能單元的整合，來管控與日俱增的開發與整合成本。讓不同款式與世代的汽車可重複使用程式碼，進而攤提軟體投資的初始成本。
在汽車領域裡為這類嵌入式系統開發程式碼，軟體是寫在隨著選定處理器一起交付的機板支援套件(BSP)內可用的API上，這向來是個問題。由於應用程式碼需仰賴基本BSP內的特定API，沒人能保證它從甲處理器移植到乙處理器的可攜性。
本文將介紹現行市場上軟體可攜性與可組合性的解決方案。
雲端原生簡化軟體部署
當人們考慮以安全且有條理的方式，推出由許多功能性元件構成的複雜軟體解決方案時，即會想到在雲端運行的大規模應用程式的架構。基礎建設市場與雲端服務供應商(CSP)，藉由採用在軟體開發中最佳的「雲端原生」(Cloud-native)實務作法，以及打造可協助降低複雜性且提升品質的工作流程與工具，來應對複雜的軟體部署問題。
採行雲端原生定義的技術、工作流程與設計型態，是為了管理開發中、部署與更新應用程式相關的複雜性。而可擴充開放架構(Scalable Open Architecture for Embedded Edge, SOAFEE)的目標在於引進雲端原生開發環境的效益，來應對車用領域特定的挑戰與限制，例如功能性安全(Functional Safety, FuSa)與快速且精準的即時控制。
雲端原生領域的一項基本要求，就是讓軟體與硬體脫離的能力，以確保工作負載可以輕易地被部署在不同的硬體，毋需重新架構基本的軟體。理想的解決方案是在毋需重新編譯應用程式碼的情況下，促成二進制軟體的可攜性。
雲端原生應用導入汽車產業
雲端原生運算基金會(The Cloud-Native Computing Foundation, CNCF)是一個開放原始碼的基金會，負責管理雲端原生部署使用的工具規格與實作。這個社群的會員對於雲端原生的定義如下所述：
「雲端原生的技術讓企業組織得以在例如公有雲端、私有雲端與混合雲端等現代化、動態的環境中，打造並運行可擴充的應用項目。容器、服務網格、微服務、不可變的基礎設施與宣告式API，是這種方式的典型範例。
這些技術可促成彈性、可管理與可觀察的鬆耦合(Loosely Coupled)系統。結合強健的自動化作業後，讓工程師在最不費力的情況下，頻繁且可預測地做出具影響力的改變。
雲端原生運算基金會藉由培養與維持一個開源、不偏好特定廠商的專案生態系，嘗試帶動大家採納這個典範。藉由將最尖端技術的型樣普及化，使大家都能輕鬆運用這些創新。」
從這個定義可以看到，雲端原生解決方案不全然非得部署在雲端。他們鼓勵大家使用建立在尖端設計型樣的技術，例如容器、微服務與宣告式API。
這些目標非常貼近安謀國際(Arm)在汽車領域內的目標。本文接下來的幾個章節，將詳細闡釋其中的一些技術，以及它們與SOAFEE架構目標的關係。
SOAFEE所需容器符合開放容器倡議組織規範
Google把容器的定義形容為：容器是使用者應用程式碼輕量化的封包再加上一些相依性，如運行軟體服務所需的特定版本的程式設計語言執行環境(Runtime)與函式庫。
基本來說，容器能以便利的方式來封裝與部署應用程式。容器的環境由開放容器倡議組織(Open Container Initiative, OCI)定義，並由兩個主要部分組成，包含容器執行環境規格以及容器鏡像規格；第三個部分則陳述與容器登錄檔(如hub.docker.com)溝通的標準，為容器分配規格。
執行環境規格涵蓋必備的系統需求與介面，以便讓容器在系統上成功運作。同時鏡像規格則是定義如何構成鏡像，讓容器執行環境接受。 這種針對容器生態系採用標準架構的方式的威力，在於它鼓勵大家以容器執行環境實作為中心進行創新，並依此打造解決方案，滿足特定部署中特定領域的需求。OCI儘管針對具備RunC的容器執行環境推出參考實作，還是有許多適用於不同領域的其它容器執行環境，如表1為部分容器執行環境清單。
這裡要強調的是，沒有一體適用的解決方案決定使用何種容器執行環境。但可確保的是任何依據OCI容器規格打造的容器，都能不經修改就在平台上運作。
SOAFEE的目標鎖定在利用應用程式與執行環境間強大的分離度，來確保容器執行環境可以滿足汽車領域要求極高的部署特性，以及必要時OCI內部的上游標準得以陳述這些需求。
微服務
微服務架構是一種軟體設計的型樣，可打造鬆耦合的協作服務，並藉由把這些服務編制在一起，打造出功能性的解決方案。這些服務具備定義清楚的輸入與輸出介面，而這些介面設定了服務與系統中其它元件之間的協定。
在雲端原生部署中，微服務會封裝在容器裡。這可讓它在被定義過的容器執行環境中執行，而部署作業則可透過調配工具進行管理與監控。這部分稍候會進一步討論。
微服務之所以被定義為鬆耦合，原因是只要遵守輸入與輸出API協定中定義的預期行為，任何一個服務出現變化，都不致影響系統中另一個服務的效能。此一特性同時也意謂微服務可在系統的其它部分，單獨進行測試；如此，即可讓較大、較為複雜的系統，在編制完整的系統進行整合測試前，分解成個別服務的單元測試。
調配工具
調配工具是雲端原生系統中相當重要的元件。它負責管理基於微服務解決方案的配置、部署與監控。調配工具本身由數個標準介面構成(表2)。
就像雲端原生生態系的其它層面，這些標準介面有多種可滿足特定使用場景需求的實作。如果想讓容器執行環境接受調配工具管理，它需要實作CRI介面，而本文先前描述過的所有執行環境都要遵照此一需求。
當這些介面一起接受調配工具管控，就可以藉由配置網路來管理複雜應用程式的部署，並促成微服務彼此間的通訊與取用資料來源，以維護微服務運作所需。
調配工具有數個選項，其中預設的選項是kubernetes(也稱為k8s)；但有些實作像k3s的足跡比較小，更適合嵌入及資源受限的環境。
DevOps
雲端原生的工作流程層面，通常稱為DevOps流程(圖1)。工作流程分為兩個主要部分。Dev涵蓋開發工作流程，Ops則涵蓋部署的作業層面。如果以清楚定義且受管控的方式，把這兩種規則集合起來，就有可能簡化工作流程管理的應用程式的開發、部署與持續改進。
圖1 雲端原生DevOps工作流程可劃分為兩個部分
資料來源：commons.wikimedia.org/wiki/File:Devops-toolchain.svg
從圖1可看出DevOps是個持續進行的流程，其中已部署容器的作業監控，會輸出並回饋進入下一個階段的開發週期。
這就是如何促成已交付之工作負載品質的持續提升。經過一段時間後，採用此流程將提升整體的品質，同時降低產品上市時程與整體成本。
SOAFEE擴展雲端原生環境部署
SOAFEE利用雲端原生的框架，讓使用者從最佳實務與標準中獲益；但問題是處理汽車的解決方案時，還會出現額外的需求與限制，這包括了如何將混用不同應用處理器、與具備加速功能的即時處理器的工作負載，部署在異質運算架構上。
透過由成員社群所組成的SOAFEE各個技術工作小組，SOAFEE將目標放在瞭解目前雲端原生實作間的落差，並與制定相關標準的機構在前端運作。透過多方協作、縮短落差後，期望能將雲端原生的解決方案應用在汽車以及安全相關的領域中。
為安全/即時需求強化調配工具
調配工具排程框架的某些層面，若能使用下列標準技術，即可因應目前這些新增的需求：
1. Node Affinity：用來限定工作負載的部署位置。
2. Taints and Tolerations：用來描述某些節點如何互相吸引或互斥。
3. Pod Overhead：用來描述特定工作負載將會消耗的系統資源量。
目前是系統中存在落差，而SOAFEE將與上游的標準制定社群合作，將描述即時及安全需求的語言標準化。
在即時需求的實例，包含需要的I/O頻寬、獲保障的執行時間、快取記憶體政策等。
另一方面，至於安全需求實例，則包含免於干擾、Split-lock核心，以及可用性等。
SOAFEE的各個技術工作小組將專注在這些延伸的領域，並提出共用的語言，以便將意向陳述給調配工具。如此一來即可確保工作負載部署到基本系統的正確位置，而低階的架構功能，則可針對每個Pod進行配置來符合要求。
容器執行環境強化
既然調配工具能適切的陳述工作負載的額外執行環境需求，緊接著就要強化容器的執行環境以符合這些需求。主要的做法是使用前述的如RunX等虛擬化的容器執行環境，以便透過VMM與執行環境本身的協作，將對特權系統資源的控制，從容器執行環境特權權限較低的執行環境中分離出來。
SOAFEE工作小組將負責選擇正確的初始執行環境。之後若需要修改時，會在前端與OCI制定標準團體合作，也會針對選定容器執行環境實作進行強化。
可攜的工作負載
SOAFEE的一個關鍵價值主張，就是工作負載可重複使用。透過這個方法，在不經修改的情況下，讓促成最終版應用程式的特定微服務，重複使用在各種不同產品線與解決方案，以降低這些複雜軟體解決方案的部署成本。
為此，人們需要瞭解加速器與高頻寬的I/O裝置，在毋需對該加速器或I/O裝置特定架構實作重新編譯的情況下，穩定存取工作負載。在瞭解與探索這個概念的同時，必須留意與功能性安全及即時(Real Time)相關的特定領域需求。
其中一個產業標準是VirtIO。VirtIO提供半虛擬化環境，可存取已有效標準化工作負載的加速器，並促成後端加速器高效率的卸載。 表面上，VirtIO似乎是可攜性問題的完美解決方案，但VirtIO目前的版本仍有一些問題。首先，它在設計時並未考量到功能性安全或即時工作負載。其次，它的介面並未涵蓋所有汽車領域的需求。例如，VirtIO沒有透過像TVM等用戶空間，可供機器學習加速使用的介面，也缺乏像控制器區域網路(CAN Bus)等對接特定汽車I/O裝置的標準介面。
由於SOAFEE是優先採用現行的標準，並在功能性安全的領域內進行調適來符合原本的用途，而非建立可能造成生態系碎片化的全新標準，因此SOAFEE會在VirtIO標準組織內，於前端解決這些問題，確保能在virtqueue架構中陳述即時的限制，促成業界協作，為缺少的介面定義出合理的VirtIO實作。
測試與驗證
打造基於微服務的解決方案，隨之而來的絕佳機會，就是能針對元件與系統層級的測試與驗證，促成持續整合/持續交付(CI/CD)所需的工具。例如，可以利用SOAFEE工作負載的可攜性功能，允許工作負載在雲端執行訓練與測試，以對工作負載的效能產生第一層的信心。同樣的工作負載隨後可部署在實驗室基準的基礎設施中，讓軟體與硬體都能應用於迴路驗證。
本文稍早介紹的標準DevOps工作流程，描述雲端原生的部署作業如何管理複雜工作負載的品質，以及SOAFEE如何促成此一工作流程的採用與強化。SOAFEE專案正在與系統整合商、工具廠商及雲端服務供應商(CSP)合作，以實現這樣的能力。人們很快就能看到更多關於SOAFEE的重要細節。
開源參考實作
所有的努力都將以SOAFEE要求的開源參考實作形式集中作業，包括足以實現此雲端原生願景所需的所有元件。參考實作將以Yocto處方檔案的形式交付，讓基本平台移植到替代用的硬體。
這個參考實作隨後可供Autoware、AGL與其它前端豐富的軟體堆疊使用，以便落實真正可攜、容器化、微服務架構的實作，並可在所有以SOAFEE架構實作的平台上運行。
(本文作者為Arm首席軟體架構師)