基于SOA的車輛照明微服務架構設計與關鍵應用
摘要
本文探討了通過采用面向服務的架構(SOA)實現車輛照明系統的轉型。傳統的單體軟件設計與分布式電子電氣(E/E)架構緊密綁定,限制了系統的可擴展性并增加了開發復雜性。通過將照明功能模塊化設計為微服務并部署在集中式計算平臺上,能夠在靈活性、可復用性和可維護性方面獲得顯著優勢。文中提出了一種照明服務的功能分類方法,涵蓋美學類、信息類、強制類和娛樂類四大類別。關鍵應用場景包括車與萬物互聯(V2X)自適應近光控制和拓撲依賴式調平功能。這些示例展示了如何利用標準化接口(API)和持續集成 / 持續部署(CI/CD)流水線,實現照明功能的獨立開發、更新,并跨車輛平臺部署。所提出的方法能夠加快創新周期,支持量產(SOP)后的功能升級,并減少系統級集成工作量。最終,該方法將外部照明定位為軟件定義汽車(SDV)生態系統中一個完全集成的組件。
1. 引言
當今的汽車外部照明系統基于分布式電子電氣(E/E)架構構建,照明功能通過多個電子控制單元(ECU)執行,這些 ECU 通常集成在燈殼內部。這導致系統復雜性高、材料成本增加,并且在軟件集成和維護方面面臨越來越多的挑戰。電子控制單元(ECU)變體的激增進一步凸顯了對穩健更新架構的需求,推動了架構變革。對于管理傳統平臺的原始設備制造商(OEM)而言,向域導向型架構轉型提供了一條過渡路徑。核心照明功能(如自適應遠光(ADB))與硬件解耦并集中在域控制器(ECU)中,實現了硬件無關的軟件架構。下一步演進是在區域電子電氣(E/E)架構中采用集中式高性能計算機(HPC),其中區域控制器(ECU)負責管理外圍設備的電源供應和通信。
與此同時,即使對于高清投影等復雜功能,照明系統也正朝著無軟件設計的方向發展,從而降低硬件成本和復雜性。這些架構變革直接影響軟件設計:單體式照明應用必須演進為模塊化、面向服務的架構。我們的方法并非將所有功能整合到單個電子控制單元(ECU)中,而是主張將照明功能分解為微服務。圖 1 左側展示了當前的技術現狀,右側則呈現了未來的理想架構。這種方法支持靈活部署、提高可維護性,并更好地與未來軟件定義汽車(SDV)生態系統保持一致。面向服務的架構(SOA)原則可以逐步應用 —— 從基于域的系統到完全集中式架構 —— 提供可擴展性和長期適應性。

圖1、從單片設計(左)到微服務(右)
2. 行業挑戰
2.1 傳統電子電氣(E/E)架構中的模塊化問題
分布式電子電氣(E/E)架構依賴高度優化的嵌入式軟件,這些軟件針對特定的硬件約束進行定制,尤其是在邊緣設備中。在汽車照明領域,這導致單個電子控制單元(ECU)內的軟件緊密耦合,每個電子控制單元(ECU)專門負責控制特定的照明模塊,從而限制了靈活性和可復用性。為克服這些限制,本文提出了一種模塊化架構。照明功能被劃分為通用服務(例如基于車輛或環境狀態的駕駛模式)和設備特定驅動程序。這種解耦允許平臺無關的服務通過即插即用的方式在不同車型系列中復用,而硬件特定驅動程序則通過標準化抽象與系統交互。這種基于微服務的設計減少了對特定電子電氣(E/E)配置的依賴,并支持可擴展部署。然而,為滿足實時性能要求 —— 尤其是對于自適應照明或投影等高級功能 —— 帶有硬件加速器(如圖形處理器(GPU))的片上系統(SoC)仍然至關重要。
2.2 通過集中化、標準化和持續集成 / 持續部署(CI/CD)實現可擴展照明
隨著照明功能計算強度的增加以及在邊緣設備上的分布式部署,系統復雜性和開發成本急劇上升 —— 尤其是當多個供應商使用不兼容的工具鏈和持續集成 / 持續部署(CI/CD)流水線時。這種碎片化環境導致軟件棧不一致、授權工作重復以及集成延遲。
通過域控制器(ECU)或高性能計算機(HPC)集中計算資源,為簡化開發提供了機會。架構、接口和交付格式(如容器)的標準化是關鍵。容器化技術支持照明微服務的可重現、平臺無關部署,并由現代持續集成 / 持續部署(CI/CD)流水線提供支持。這種方法支持一致且自動化的構建和測試流程,確保軟件發布的可靠性和可重復性。版本控制環境增強了可追溯性,并支持長期可維護性。通過簽名和驗證的服務包增強了安全性,同時簡化的空中下載(OTA)更新和回滾機制使部署更加靈活。
總之,這種統一的工具鏈策略加快了開發速度,促進了軟件復用,并確保在量產(SOP)時交付經過認證的基準版本。量產(SOP)后,它支持動態功能配置 —— 例如個性化照明動畫或特定區域的燈光特征 —— 支持持續創新,并將外部照明定位為軟件定義的體驗平臺。
2.3 照明系統中僵化的軟件結構對靈活性的阻礙
傳統上,即使內部設計是模塊化的,照明軟件也會被編譯成一個單一的大型二進制文件。因此,任何更改 —— 無論是錯誤修復、功能更新還是擴展 —— 都需要重新構建整個程序。這種緊密耦合的方法使開發變得復雜,尤其是在照明與其他應用程序共存的集中式系統中。照明系統還依賴大量校準參數來微調性能,而無需修改代碼。隨著時間的推移,這些參數的數量不斷增加,導致內存使用率上升,并使配置管理更加復雜。針對不同市場或變體的校準集,在制造過程中和現場更新時都需要復雜的架構支持。這種結構難以管理個性化功能的持續開發和部署,即使是簡單的燈光動畫也是如此。核心問題在于軟件邏輯與固定系統資源的僵化耦合。
2.4 照明功能在高級駕駛輔助系統(ADAS)中的應用
高級駕駛輔助系統(ADAS)在提升安全性和舒適性方面發揮著關鍵作用,外部照明通過近光調平、無眩光遠光和符號投影等功能做出貢獻。其中許多功能依賴于非照明系統的輸入,例如前視攝像頭的目標檢測數據。然而,照明和高級駕駛輔助系統(ADAS)功能通常是獨立開發的,導致時間線不一致和互操作性有限。無眩光遠光很好地說明了這一挑戰,它需要與目標檢測更新進行持續協調。如果在功能需求上沒有早期對齊,集成將變得復雜,降低系統效率并導致基于權宜之計的解決方案。當照明被用于積極支持高級駕駛輔助系統(ADAS)時 —— 例如通過調整光束模式以增強目標可見性或投影導航引導提示 —— 這一問題會更加突出。雖然潛力巨大,但成功實施需要更緊密的跨域協調和持續、對齊的開發工作。
2.5 面向服務的架構(SOA)照明系統的安全考量
設計車輛照明服務需要遵守既定的安全和安保原則,尤其是在從單體架構向面向服務的架構(SOA)轉型時。這些原則 —— 如簡潔性、明確的職責分離和可追溯的數據流 —— 必須盡早整合,以避免后期進行昂貴的重新設計。無論采用何種架構,ISO 26262 和 ISO/SAE 21434 等標準仍然適用。雖然面向服務的架構(SOA)不會降低安全和安保要求,但它提高了模塊化和透明度,使驗證和認證更加易于管理。這種結構化方法支持更快的評估,并增強了對系統完整性的信心 —— 隨著車輛系統變得越來越復雜,這是一個重要優勢。
3. 提出的方法和應用場景
為評估基于微服務的架構在車輛照明中的優勢、劣勢和特點,我們提出了四類分類方法,根據服務功能的目的和價值貢獻進行分類:
1. 美學類 —— 塑造環境體驗的服務,通過照明影響情緒或感知質量(例如心理測量效果)。
2. 信息類 —— 向車輛周圍環境傳達信息的服務,例如狀態指示器或上下文驅動的消息(例如廣告)。
3. 強制類 —— 為滿足法律和安全法規而必需的服務,確保符合道路使用標準。
4. 娛樂類 —— 通過個性化或游戲化增強用戶體驗的服務。
根據這一分類,可以確定照明微服務的不同應用場景。
應用場景 1:基于車與萬物互聯(V2X)的自適應近光 ——“強制類與信息類” 集成
作為說明性示例,考慮一個與車與萬物互聯(V2X)基礎設施集成的自適應近光應用場景。在這種情況下,車與萬物互聯(V2X)輸入提供近光的動態調光值,使道路照明與當地街燈亮度保持一致。這種自適應調整有助于在外部照明已經充足時降低功耗和減少不必要的光線排放。
從面向服務的架構(SOA)角度,我們定義了兩個不同的微服務(見圖 2):
· 強制類近光服務:處理物理燈光開關輸入,并提供安全關鍵的調光目標值。
車與萬物互聯(V2X)近光服務:處理外部輸入(例如車與萬物互聯(V2X)消息),以提供可選的調光目標值。

圖2、控制近光燈的兩種不同服務(用例1)
這兩個服務由一個監控安全機制(例如通過虛擬機監控程序或專用安全控制器)進行監控和管理。關鍵的是,車與萬物互聯(V2X)服務在非安全關鍵路徑中運行,以確保它不會影響必須始終滿足 ASIL-B(或更高)安全標準的強制類近光服務。輸出仲裁邏輯(即輸出開關或多路復用器)也必須包含在安全路徑中,以保證在所有條件下的一致和可觀察行為。這種架構分離具有以下關鍵優勢:
· 符合法規要求的照明功能安全完整性。
· 非關鍵服務(如車與萬物互聯(V2X))的模塊化可擴展性。
· 獨立的生命周期管理,允許車與萬物互聯(V2X)服務獨立演進或故障,而不影響核心功能。
應用場景 2:作為娛樂服務的拓撲依賴式調平功能
作為娛樂類別的代表性應用場景,我們研究了一種旨在增強個性化和用戶體驗的拓撲依賴式調平功能。傳統上,前照燈調平功能作為固定邏輯服務實現,基于預定義的車輛參數計算步進電機驅動程序的目標角度。這一核心功能通常是靜態的且經過安全驗證,幾乎沒有個性化或動態自適應的空間。相比之下,拓撲依賴式調平服務引入了新的以用戶為中心的定制層。例如,系統可以根據車輛當前位置(如城市道路與鄉村道路)、駕駛模式甚至駕駛員偏好來調整光束角度。為了在保留現有調平邏輯完整性的同時集成此功能,提出了以下基于面向服務的架構(SOA)的兩步法:
架構準備 —— 服務層解耦
將標準調平邏輯與執行器(步進電機驅動程序)之間的直接鏈接解耦(見圖 3 步驟 1)。引入一個中間切換服務,能夠將多個調平輸入路由到執行器。這允許在標準和個性化調平輸出之間靈活選擇。

圖3、左:原始水平;右:兩步擴展(用例2)
功能集成——拓撲基服務的部署
然后部署新的拓撲依賴式調平服務,并將其作為替代輸入連接到切換邏輯(見圖 3 步驟 2)。該服務在安全關鍵路徑之外運行,可以獨立更新、擴展或替換。它利用實時地圖數據或地理位置輸入,根據道路類型或環境動態調整前照燈位置。
這種方法具有以下幾個關鍵優勢:
· 個性化和舒適性:支持基于實際駕駛條件或用戶偏好的動態燈光自適應。
· 模塊化部署:允許分階段推出,無需修改經過認證的基礎功能。
· 隔離性和安全性:將標準調平服務保持在安全關鍵執行路徑中,確保符合法規要求。
通過利用面向服務的架構(SOA),拓撲依賴式調平功能等特性成為靈活、模塊化的附加組件,而不是緊密集成的單體。這支持了一個可擴展的生態系統,其中以娛樂為重點的服務可以隨著用戶需求的變化而演進,同時不影響基礎安全功能。
這兩個應用場景都展示了面向服務的架構(SOA)如何為車輛照明帶來靈活和可擴展的開發。強制類安全關鍵功能被封裝和保護,而擴展或個性化功能則獨立引入。這種模塊化降低了開發風險,支持靈活的功能交付,并與軟件定義汽車(SDV)不斷發展的需求保持一致。在未來的軟件定義汽車(SDV)框架中,標準化的車輛照明接口(API)將發揮核心作用。該接口(API)將主要用于兩個目的:
1. 控制各個照明功能;
2. 與其他車輛域(如高級駕駛輔助系統(ADAS))接口,以支持跨功能特性。
汽車照明供應商面臨的關鍵挑戰之一是將現有的單體照明算法轉換為模塊化、封裝的微服務 —— 每個微服務都與特定的照明功能對齊。這些微服務需要能夠獨立運行,支持模塊化更新和跨車輛平臺復用。對于具有分布式傳統電子電氣(E/E)架構的原始設備制造商(OEM)而言,轉型初期可能需要涉及混合架構。這些架構將彌合傳統組件與新興區域或集中式軟件定義汽車(SDV)平臺之間的差距。每個照明微服務都將有自己的開發和生命周期管理,并由標準化的持續集成 / 持續部署(CI/CD)流水線提供支持。這些流水線將包括:
· 自動化測試和驗證;
· 安全部署機制;
· 數字簽名或證書,以確保服務完整性和網絡安全合規性。
這種方法不僅支持更快的創新周期,還確保了在多供應商軟件定義汽車(SDV)生態系統中的法規一致性和長期可維護性。
4. 結論與展望
面向服務的架構(SOA)極大地改進了軟件組件集成到車輛中的方式。關鍵是引入一個從底層到應用層的分層模型作為理想架構,包括層間的接口和協議。更高的目標是在操作系統之上實現穩健的中間件,因為它承載著以客戶為中心的功能,但首先,當從傳統架構過渡時,必須集成或遷移底層功能。一旦包括中間件在內的較低層成熟且穩健,上層服務和應用程序的開發速度就可以大大加快。通過靈活的設計,可以通過不同層虛擬建立垂直連接,實現從頂層到底層的直接信號流,適用于各個應用場景或應用程序。這種所謂的 “虛擬服務垂直層” 代表了傳統的物理垂直集成,不同之處在于物理邊界被打破,一層的變化不會影響更高層(見圖 4)。這種理念適用于照明系統,特別是對于傳統功能的轉型和新可能性的實現。它是實現所討論的應用場景的基礎,并允許照明系統通過其自身的虛擬服務垂直層與不同域集成。

圖4、SDV層模型
高級駕駛輔助系統(ADAS)越來越依賴外部照明服務 —— 例如,通過突出車輛周圍的目標,提高攝像頭傳感器的可見性。在這種跨域應用中,傳統的單體照明算法被證明效率低下,并且缺乏跨域實時處理所需的靈活性。
相比之下,將照明功能封裝為各自具有特定功能生命周期的微服務,支持資源高效處理、更輕松的集成和有針對性的更新。這種模塊化方法不僅提高了性能,還與可擴展軟件定義汽車(SDV)平臺的架構原則保持一致。此外,這種基于微服務的架構支持對用戶特定和個性化照明功能日益增長的需求,特別是在信息娛樂、環境照明和交互式車輛通信等領域。服務可以獨立開發、部署或升級,而不影響核心安全關鍵照明功能。
為實現并加速這一轉型,標準化的車輛照明接口(API)至關重要。這些接口(API)充當核心照明功能和更高層域服務的通用接口。通過開源軟件定義汽車(SDV)計劃定義和發布這些接口(API)以及相應的服務設計,行業可以:
· 促進原始設備制造商(OEM)和一級供應商之間的互操作性;
· 鼓勵在概念驗證(PoC)項目上的合作;
· 驗證與高級駕駛輔助系統(ADAS)、信息娛樂和環境傳感系統的跨域集成。
這種開放和模塊化的設計范式為面向未來、面向服務的照明架構奠定了基礎,該架構具有適應性、安全性和可擴展性。
(添加微信號NewCarRen咨詢)
