摘要

現(xiàn)代車輛應(yīng)用必須能夠處理多樣化的車輛配置，包括車輛銷售配置、功能即服務(wù)（FaaS）配置、訂閱制配置以及用戶偏好配置。如何利用現(xiàn)代車輛應(yīng)用的基礎(chǔ)架構(gòu) —— 面向服務(wù)架構(gòu)（SOA）和軟件定義車輛（SDV）—— 來實現(xiàn)此類可變配置？本文通過 “乘客歡迎” 案例，探討了不同的實施方案。

1. 引言

如今的汽車制造商必須應(yīng)對日益增長的車輛配置多樣性。這通常始于大量不同的車輛類型、變體和版本，以滿足不同客戶群體和地區(qū)特定法規(guī)要求。在銷售過程中提供廣泛的定制車輛配置，如今也已成為原始設(shè)備制造商（OEM）的常態(tài)。新興的 “功能即服務(wù)（FaaS）” 概念進一步增加了配置的多樣性。最后，越來越多的用戶特定車輛配置偏好也必須被納入考量。可變車輛配置給汽車應(yīng)用軟件開發(fā)者帶來了挑戰(zhàn)，因為他們的代碼必須適配所有可能的車輛配置，甚至可能包括不同配置的排列組合。本文的研究基于設(shè)計科學(xué)方法，旨在開發(fā)一種通用方法，以在軟件定義車輛（SDV）和面向服務(wù)架構(gòu)（SOA）的背景下應(yīng)對可變車輛配置問題。作為這一長期目標(biāo)的一部分，本文引入了 “乘客歡迎” 用例。其核心思路是，當(dāng)檢測到乘客靠近車輛時，車輛執(zhí)行一系列歡迎步驟。該歡迎序列將根據(jù)當(dāng)前配置，調(diào)用多個不同的車輛傳感器和執(zhí)行器。

本文的分析基于我們的研究成果以及已發(fā)表的研究，遵循車輛制造商（OEM）對此類用例的假設(shè)流程展開。如圖 1 所示，該流程涵蓋了通用車輛工程（包括變體定義）以及單個車輛的配置、制造和運營。本文從車輛工程視角（A）出發(fā)，重點關(guān)注車輛應(yīng)用開發(fā)（B），以及數(shù)字車輛服務(wù)如何通過 “信號到服務(wù)（Signal-to-Service）” 接口與物理車輛功能集成（C）。后續(xù)還將探討初始車輛配置（D）、功能即服務(wù) / 訂閱制（E）、用戶偏好（F）、軟件更新（G）以及車輛配置變更等內(nèi)容。

圖1、可變車輛配置的應(yīng)用

2. 研究方法

由于目前關(guān)于該問題的研究較為有限，本文旨在為軟件定義車輛（SDV）研究領(lǐng)域做出貢獻。研究問題為：如何利用現(xiàn)代車輛應(yīng)用的基礎(chǔ)架構(gòu)（即面向服務(wù)架構(gòu)（SOA）和軟件定義車輛（SDV））來實現(xiàn)可變車輛配置？本文遵循雙重科學(xué)研究范式 [10]：首先，通過文獻綜述從學(xué)術(shù)視角分析當(dāng)前研究現(xiàn)狀；其次，對原始設(shè)備制造商（OEM）和汽車供應(yīng)商進行了七次專家訪談，以了解行業(yè)視角下的需求與挑戰(zhàn)；最后，通過分析 “乘客歡迎” 用例的原型實現(xiàn)，對研究假設(shè)和結(jié)論進行初步驗證。

3. 車輛變體與可變因素

作為我們在 digital.auto 生態(tài)系統(tǒng)中研究的一部分，我們識別出未來車輛應(yīng)用必須考慮的以下車輛多樣性驅(qū)動因素：

· 物理車輛配置，包括初始車輛配置（D）、物理配置更新（H）和軟件更新（G）

· 功能即服務(wù)（FaaS）與訂閱制（E）

· 用戶偏好（F）

如下文所述，這些多樣性驅(qū)動因素對工程設(shè)計和應(yīng)用開發(fā)流程具有重大影響，因此本文首先對其進行分析。

3.1 研究現(xiàn)狀：物理車輛配置（D、H、G）

如今的原始設(shè)備制造商（OEM）必須處理多種不同的車輛類型、變體和版本。這是由市場需求以及不同地區(qū)的法規(guī)要求所驅(qū)動的。多樣性引發(fā)的復(fù)雜性是原始設(shè)備制造商（OEM）的主要成本驅(qū)動因素之一。沃爾沃汽車集團的瓦爾德?安蒂尼揚（Vard Antinyan）指出，僅 4 個變化點（車輛型號、發(fā)動機類型、排放區(qū)域和驅(qū)動類型）的不同組合及子變體，就可產(chǎn)生 114 種軟件變體。

目前，產(chǎn)品線工程（Product Line Engineering）和基于模型的系統(tǒng)工程（Model Based Systems Engineering）被用于應(yīng)對車輛變體的復(fù)雜性。為了有效管理變體和車輛配置，部分原始設(shè)備制造商（OEM）依賴于基于規(guī)則的車輛配置管理系統(tǒng)。單輛車輛的初始配置在制造時即可確定，如圖 2 所示。

圖2、初始車輛配置

一個值得探討的問題是：需要配置特定信息的應(yīng)用程序，應(yīng)當(dāng)從制造過程中創(chuàng)建的靜態(tài)數(shù)據(jù)集獲取該信息，還是應(yīng)在運行時動態(tài)獲取最新的車輛配置信息？車輛配置在制造后可能發(fā)生變化的情況包括：物理組件故障（降級配置）、物理車輛重新配置以及軟件更新。物理車輛改裝范圍廣泛，從加裝拖車掛鉤等功能到更換電動汽車的動力電池，部分供應(yīng)商甚至支持升級中央車輛計算機。

除物理配置外，軟件配置也起著重要作用。過去，軟件更新通常是被動的，主要用于解決功能問題。對于空中下載更新（OTA），原始設(shè)備制造商（OEM）最關(guān)注的是安全性和可靠性。然而，領(lǐng)先的電動汽車（EV）企業(yè)正越來越多地利用軟件更新提供功能增強和新的終端用戶功能。

3.2 研究現(xiàn)狀：功能即服務(wù)（FaaS）與訂閱制（E）

除了在銷售過程中為客戶提供車輛配置選項外，原始設(shè)備制造商（OEM）如今還在考慮將物理功能作為訂閱服務(wù)提供 —— 有時也稱為 “功能即服務(wù)（FaaS）”（這與將整車作為服務(wù)提供不同，例如汽車共享服務(wù)）。功能即服務(wù)（FaaS）和訂閱制服務(wù)在汽車行業(yè)是一個相對較新的話題，相關(guān)學(xué)術(shù)研究較少。不過，汽車研究機構(gòu)如 SBD [3]、CR [4] 和 RTInsights [5] 已對此進行了相關(guān)報道。例如，豐田（車輛遠(yuǎn)程啟動現(xiàn)已成為豐田互聯(lián)服務(wù)訂閱的一部分）、梅賽德斯 - 奔馳 EQS（將全后輪轉(zhuǎn)向作為訂閱服務(wù)提供）、寶馬（將集成行車記錄儀作為訂閱服務(wù)提供）。其他功能即服務(wù)（FaaS）案例還包括特斯拉的完全自動駕駛功能（Full Self-Driving Feature）和通用汽車凱迪拉克的駕駛輔助系統(tǒng)。例如，保時捷為客戶提供了兩種選擇：一次性購買電動汽車?yán)m(xù)航優(yōu)化器，或按月訂閱使用。

這些案例的共同點是，原始設(shè)備制造商（OEM）在車輛制造時就將所需的硬件組件安裝到車輛中，這實際上承擔(dān)了客戶可能永遠(yuǎn)不會訂閱相關(guān)功能的風(fēng)險。

以座椅內(nèi)置按摩功能為例：傳統(tǒng)方式是在銷售過程中將其作為車輛配置的一部分，以物理功能形式提供。

而新的方式 —— 即功能即服務(wù)（FaaS）—— 如圖 3 所示：每輛車輛都采用相同的物理配置，包括座椅按摩器。這有助于降低車輛設(shè)計和內(nèi)部結(jié)構(gòu)的復(fù)雜性，從而減少部分成本。但總體商業(yè)模式仍需權(quán)衡按摩器的單位成本與可能的平均訂閱收入。車主現(xiàn)在可以自主決定訂閱哪些服務(wù)，并可采用基于需求的定價（例如利用人工智能），結(jié)合微支付，以匹配個性化的訂閱計劃。

圖3、功能即服務(wù)

3.3 用戶偏好（F）

最后，未來可能產(chǎn)生大量額外車輛配置數(shù)據(jù)的另一個領(lǐng)域是用戶偏好。基于在 digital.auto 和 COVESA 社區(qū)中對原始設(shè)備制造商（OEM）領(lǐng)域?qū)＜业脑L談，以及起亞、雷克薩斯、奧迪、豐田和寶馬等原始設(shè)備制造商（OEM）的車輛設(shè)置和偏好選項綜述，車輛應(yīng)用必須考慮的用戶偏好可能包括以下領(lǐng)域：

· 警告提示：通知駕駛員和其他乘員的頻率、聲音、音量及其他方式 —— 從安全帶警告到車道保持輔助系統(tǒng)發(fā)出的警告

· 信息娛樂：音響系統(tǒng)配置、音樂偏好、通用信息娛樂偏好、語言選項

· 便捷功能：座椅位置及其他座椅功能（如按摩和加熱）、暖通空調(diào)（HVAC，供暖、通風(fēng)和空調(diào)）及氣候控制功能（包括溫度、制冷或制熱強度以及氣流方向）

· 手動駕駛輔助功能：例如燈光設(shè)置、后視鏡位置、方向盤位置

· 駕駛性能：例如車輛的加速和制動性能，或與前車保持的自動安全距離

3.4 案例：乘客歡迎

“乘客歡迎” 案例是 digital.auto 倡議參與者（包括博世和達(dá)索系統(tǒng)）開展的首批項目之一。其核心思路是，車輛識別到駕駛員靠近時，執(zhí)行一系列歡迎步驟。本文介紹了一個略有簡化的版本，包含 6 個步驟，如圖 4 所示。該圖展示了每個步驟對物理車輛配置、功能訂閱和用戶偏好的依賴關(guān)系。第一步是啟動歡迎序列，作為邏輯步驟，它不涉及任何物理車輛組件。但歡迎序列本身被定義為一項訂閱服務(wù)，且可與特定用戶偏好相關(guān)聯(lián) —— 例如，包含哪些具體步驟以及如何執(zhí)行這些步驟。第二步是打開車門，這依賴于物理車輛配置中是否配備車門電機和防止車門碰撞障礙物的安全傳感器。此外，用戶可能會指定一些偏好，如車門打開的速度以及提示車門即將打開的警報聲。接下來，車輛將播放燈光序列，在此案例中僅涉及車輛的標(biāo)準(zhǔn)燈光功能（本文未明確提及）。用戶可以配置特定的燈光模式和顏色。為了使車內(nèi)環(huán)境符合用戶偏好，隨后將根據(jù)用戶偏好調(diào)整暖通空調(diào)（HVAC）和座椅位置。暖通空調(diào)（HVAC）僅依賴標(biāo)準(zhǔn)車輛配置，而座椅調(diào)整則需要可選的座椅電機。最后，當(dāng)駕駛員入座后，將獲得歡迎式背部按摩。該功能被定義為訂閱功能 —— 這意味著所有車輛都會預(yù)裝該硬件，但僅向?qū)嶋H訂閱的客戶開放使用。一個需要明確的問題是，按摩功能訂閱是 “乘客歡迎” 功能訂閱的一部分，還是一項獨立的訂閱服務(wù)。本文后續(xù)將探討該案例的實施方案。

圖 4、乘客歡迎序列

4. 車輛工程（A）

為了支持 “乘客歡迎” 等具有可變車輛配置的用例，車輛工程必須奠定相應(yīng)的基礎(chǔ)。

4.1 基礎(chǔ)架構(gòu)

首先，需提供實際的設(shè)備、傳感器和執(zhí)行器。其次，需要合適的電子 / 電氣（E/E）架構(gòu)來集成不同的物理組件。當(dāng)前行業(yè)趨勢是從帶有專用域控制器的域架構(gòu)，向帶有專用區(qū)域控制器的集中式或區(qū)域架構(gòu)轉(zhuǎn)變，以減少線束。第三，需要足夠靈活的軟件架構(gòu)，以應(yīng)對該領(lǐng)域應(yīng)用預(yù)期的高功能復(fù)雜性和交互動態(tài)性。軟件定義車輛（SDV）的設(shè)計初衷正是為了解決這一問題。除了當(dāng)前具有高實時性和功能安全要求的嵌入式功能外，軟件定義車輛（SDV）還支持混合服務(wù)質(zhì)量（QoS）應(yīng)用，通過虛擬機監(jiān)控程序（hypervisors）和軟件容器化技術(shù)，為服務(wù)質(zhì)量可控（Quality Managed）或僅需基礎(chǔ)服務(wù)質(zhì)量（QM-only）的應(yīng)用（如 “乘客歡迎” 案例這類服務(wù)質(zhì)量要求較低的應(yīng)用）提供支持。最后，面向服務(wù)架構(gòu)（SOA）必須支持不同車載軟件組件之間的交互，潛在情況下還需支持車外軟件組件的交互。為了實現(xiàn)電子 / 電氣（E/E）架構(gòu)到面向服務(wù)架構(gòu)（SOA）的映射，需要一個 “信號到服務(wù)（Signal-to-Service）” 框架，下文將對此進行介紹。

4.2 信號到服務(wù)（Signal-to-Service，B）

“信號到服務(wù)” 的核心思想是對面向信號的電子 / 電氣（E/E）架構(gòu)進行抽象，使高層軟件能夠通過一組應(yīng)用程序接口（API），將車輛及其物理組件視為一系列傳感器和執(zhí)行器進行調(diào)用。這有時也被稱為硬件抽象層（HAL）。此類方法的示例包括安卓汽車硬件抽象層（Android Automotive HAL）和 COVESA 車輛信號規(guī)范（VSS，Vehicle Signal Specification）。VSS 為車輛信號引入了領(lǐng)域分類法，包括專用語法和車輛信號目錄。

VSS 信號目錄以樹形結(jié)構(gòu)呈現(xiàn)，圖 5 展示了其中的一個片段。該樹形結(jié)構(gòu)包括邏輯分支（如座艙（Cabin）、座椅（Seat））以及代表傳感器和執(zhí)行器的葉節(jié)點（如角度（Angle）、傾斜度（Recline））。通過不同編程語言的映射，開發(fā)者可以編寫如下代碼：例如，vehicle.Cabin.Seat.Row1.Pos1.Backrest.Recline.set (50)（此代碼使用了由 Eclipse SDV 和 digital.auto 開發(fā)的 VSS Python 映射）。需要注意的是，這種為開發(fā)者提供的高度抽象和便捷性是有代價的：實現(xiàn) VSS 應(yīng)用程序接口（API）并將其映射到復(fù)雜的車輛電子 / 電氣（E/E）架構(gòu)，其難度不容低估。這些映射不僅需要集成控制器局域網(wǎng)（CAN）和本地互聯(lián)網(wǎng)絡(luò)（LIN）等面向信號的技術(shù)，還必須解決安全問題 —— 例如，防止應(yīng)用程序接口（API）在車輛高速行駛時將駕駛員座椅調(diào)整到過于靠近方向盤的位置。然而，一旦 “信號到服務(wù)” 層部署完成，它將成為高層面向服務(wù)架構(gòu)（SOA）的基礎(chǔ)，包括復(fù)合服務(wù)和應(yīng)用服務(wù)。

圖5、COVESA VSS樹表示（摘錄）

5. 利用 “信號到服務(wù)” 和面向服務(wù)架構(gòu)管理可變車輛配置（C）

假設(shè)軟件定義車輛（SDV）、“信號到服務(wù)” 和汽車面向服務(wù)架構(gòu)（SOA）等基礎(chǔ)架構(gòu)已部署完成，現(xiàn)在的問題是如何利用它們來支持本文開頭所述的可變車輛配置。“乘客歡迎” 案例采用的基本方法是以 VSS 信號樹為起點，然后補充所需數(shù)據(jù)，包括制造配置數(shù)據(jù)、訂閱數(shù)據(jù)和用戶偏好。圖 6 展示了一個示例。以下幾點值得關(guān)注：

· COVESA VSS 將 “車輛。座艙。駕駛員位置（Vehicle.Cabin.DriverPosition）” 定義為一個信號，用于指示駕駛員座椅的位置（即左側(cè)或右側(cè)）。該信息在制造時即可確定，且后續(xù)不會改變。

· 不同執(zhí)行器的狀態(tài)（可用、不可用、未知）可直接映射到 VSS 樹中的節(jié)點。未來研究的一個有趣方向是，是否存在將狀態(tài)分配給分支節(jié)點（從而適用于多個傳感器和執(zhí)行器）的合理場景。

· 本示例中的訂閱服務(wù)按車輛進行管理。理論上，訂閱服務(wù)也可針對個人（例如在汽車共享場景中）。本示例中的訂閱服務(wù)包括基礎(chǔ)訂閱（按摩套餐）和復(fù)合訂閱（乘客歡迎）。

· 本示例中，按摩套餐訂閱適用于所有前排座椅。

· 本示例中的偏好按個人進行管理。這帶來了一個挑戰(zhàn)：一個人在車內(nèi)可能處于不同位置（例如駕駛員或乘客）。因此，偏好與特定座椅位置的關(guān)聯(lián)必須是動態(tài)的 —— 例如，通過車載攝像頭等先進傳感器結(jié)合人工智能自動確定。

圖 6、補充了可變配置數(shù)據(jù)的車輛信號規(guī)范（VSS）

該示例表明，車輛配置數(shù)據(jù)必須與運行時數(shù)據(jù)相結(jié)合，才能支持 “乘客歡迎” 等復(fù)雜用例。在確定物理功能的可用性時，何時使用靜態(tài)制造配置數(shù)據(jù)，何時使用實時車輛數(shù)據(jù)，可能并不總是明確的。理論上，使用實時系統(tǒng)數(shù)據(jù)更為可取，因為它能更好地反映當(dāng)前系統(tǒng)狀態(tài)（例如處理組件故障或組件改裝）。然而，控制器局域網(wǎng)（CAN）和 AUTOSAR 等當(dāng)前底層車輛標(biāo)準(zhǔn)并不直接支持動態(tài)組件狀態(tài)發(fā)現(xiàn) —— 盡管 AUTOSAR ADAPTIVE 等下一代標(biāo)準(zhǔn)以及 SOME/IP 等相關(guān)面向服務(wù)架構(gòu)（SOA）協(xié)議提出支持具有運行時服務(wù)發(fā)現(xiàn)功能的動態(tài)面向服務(wù)架構(gòu)（SOA），但這仍可能需要一定時間才能實現(xiàn)。

6. 車輛應(yīng)用軟件

基于上述概念，現(xiàn)在可以開發(fā)實際的車輛應(yīng)用軟件。在本研究中，“乘客歡迎” 應(yīng)用以虛擬原型的形式開發(fā)，可在開放獲取的 digital.auto 原型平臺上在線獲取。

圖 7 展示了其基本原理：在軟件定義車輛（SDV）層中，執(zhí)行 “乘客歡迎” 序列。該應(yīng)用通過 COVESA VSS 訪問虛擬車輛功能。在本案例中，虛擬車輛功能通過達(dá)索系統(tǒng)的 CATIA 3D 建模與仿真平臺實現(xiàn)。為此，CATIA 已擴展為原生支持 VSS 標(biāo)準(zhǔn)。

圖7、乘客歡迎應(yīng)用

這種方法的一大優(yōu)勢是，可以在完全虛擬的環(huán)境中測試所有可能的車輛配置變體：與真實車輛相比，3D 模型更容易配置，可反映所有需要測試的選項（例如駕駛員座椅左側(cè) / 右側(cè)、車輛配備 / 未配備座椅電機等）。通過創(chuàng)建具有不同變體的虛擬測試車輛，可以全面測試 “乘客歡迎” 序列的實現(xiàn)，以驗證其對所有可能組合的支持 —— 相比之下，創(chuàng)建和重新配置物理測試車輛的成本要高得多。

圖 8 展示了其基本流程：在初始開發(fā)階段，基于虛擬車輛（例如達(dá)索 CATIA 中的虛擬車輛）開發(fā) “乘客歡迎” 序列。在此階段，將測試所有車輛變體，以完善 “乘客歡迎” 序列，確保其支持所有變體（包括不同的車輛配置、訂閱模式和用戶偏好）。只有當(dāng)代碼穩(wěn)定后，才會在真實硬件上進行測試 —— 從初始試驗板到實際試點、A/B/C 測試，最終進入量產(chǎn)階段（SOP）。

圖8、虛擬與物理測試

7. 結(jié)論與展望

基于 “乘客歡迎” 用例的實施經(jīng)驗，利用面向服務(wù)架構(gòu)（SOA）和軟件定義車輛（SDV）應(yīng)對可變車輛配置的復(fù)雜性，是一種具有潛力的方法。然而，當(dāng)前我們的研究存在兩個主要局限性：

首先，我們必須更有效地處理不同的產(chǎn)品和功能主題配置（問題域）以及相應(yīng)的類型配置（解決方案域）。為此，基于類型的產(chǎn)品線工程（TPLE，Type-based Product Line Engineering）是一種值得關(guān)注的方法，我們計劃對其進行研究，并可能將其整合到 “乘客歡迎” 場景中。

其次，必須將該概念從純虛擬開發(fā)推進到包含真實硬件的測試環(huán)境。為此，需要在全汽車級測試環(huán)境和更適合學(xué)生使用的測試環(huán)境之間找到平衡。建立此類物理測試環(huán)境將是本研究下一步的計劃。