面向智能汽車的SOA架構及服務調度機制研究 *

郝建平，蘇炎召，鐘志華，黃 晉

（清華大學車輛與運載學院，北京 100086）

前言

在軟件定義汽車中，面向服務的架構（serviceoriented architecture， SOA）是搭建軟件體系的總體設計理念，其與傳統軟件體系相比，最明顯的特征是能夠減少系統軟件和信號資源的浪費、提高開發軟件的可重用性［1］。SOA 賦予了軟件定義汽車豐富的軟件開發能力，用SOA 思想設計的SOA 軟件架構是軟件定義汽車發展的必然趨勢之一［2］。

現階段汽車SOA 主要依附于Adaptive AUTOSAR 標準（即AUTOSAR AP）實現，但由于AUTOSAR AP不能部署傳統AUTOSAR CP中邏輯執行時間（logical execution time，LET）等確定性和實時性機制，其不能保證程序運行的確定性和實時性，給安全關鍵性系統帶來相當大的隱患［3］。因此，目前汽車SOA 應用的軟件運行集中在智能座艙域內，將車燈、車窗、車輛狀態（如溫度、車速）傳感器等基礎硬件的功能作為原子服務，再進行該領域內組合服務的設計，聚焦于提升用戶駕駛的舒適性，而不參與安全關鍵性系統，如制動輔助、運動控制等，一方面由于這樣對智能汽車直接駕駛過程的影響較小，另一方面也是因為汽車廠商在SOA 應用初期為了降低測試成本和潛在危險做出的妥協。但這樣也難以利用SOA 的優勢對直接駕駛過程進行優化。因此，本文希望SOA 的實時性和確定性能滿足的前提下，將SOA 在汽車上的應用范圍從智能座艙域擴展到其他系統域，在原子服務目錄中加入了與自動駕駛等系統級功能關聯的軟件和算法。

實現一類功能時，可以存在多種可選的子服務，這樣的子服務可被分類為一個服務層級。顯然服務層級相較于單一的服務而言，存在選擇空間多的優勢，在不同的環境條件下，能通過選擇更合適的子服務來達到更好的運行效果?，F有智能汽車通常在自動駕駛的各個環節中采用固定的算法和硬件，雖然保持了運行的穩定性，但同時在某些場景下可能會顯著降低效率。如視覺傳感器在低光下、超聲波雷達在高速下運行效果不佳，因此汽車廠商須采用傳感器融合，同時啟用多種傳感器來保證傳感數據的精確性；不同類型的軌跡規劃、障礙物檢測等算法也會在不同環境下存在更優的選擇，但一般只會固定采用一種類型。由此可見，在多個服務層級中選擇當前環境下各服務層級中適合的子服務，即服務調度，可以帶來汽車SOA系統總體性能和效率的提升。

在計算機領域，服務網格（service grid）［4］作為大規模網絡計算系統的一種類型，也采用服務的方式來包裝系統機構中的資源，同樣也具有調度的需求，并采用服務質量（quality of service， QoS）的評價指標進行調度算法的設計［5］，這與汽車SOA 的調度需求有諸多相似之處，因此可以分析網格計算的服務機制設計思路，進行汽車SOA的設計。

綜上所述，為了盡可能發揮SOA 在軟件定義汽車上的應用價值，可以在目前的汽車SOA 架構中拓展SOA 的服務層級范圍，并引入服務調度算法，進而提升駕駛性能和效率。在不同的服務層級中，服務調度算法可以實時地選取當前環境下更適合的子服務，從而提升汽車在各種復雜環境條件下的自適應性，這也是軟件定義汽車應具備的重要特征。

1 汽車SOA架構及分類

1.1 可調度SOA層級分類

汽車SOA 架構一般為多層架構，從下至上分別為硬件層、服務層、應用和算法層［6］，遵循粒度逐漸增大的規律，將需要大量重復使用的服務劃分為小粒度，即原子服務；原子服務組合后可以成為粒度更大的組合服務，實現一套稍復雜的完整功能邏輯；而應用和算法層實現了若干完整的用戶級功能，可以調用各種原子服務和組合服務，是最完善和復雜的層級，如圖1所示。

圖1 通用SOA架構圖

符合服務調度要求的SOA 服務層級須滿足兩個條件：其硬件或軟件的功能可以被抽象為SOA 中的服務，即符合SOA 應用的硬性條件；其最終實現的功能存在被調度的必要性，即在環境影響下能發生顯著性能變化，或能提升用戶體驗。

SOA 服務層級可以由硬件或軟件組成。對于硬件而言，SOA 應用條件的主要限制為通信協議。汽車SOA 的通信協議通常使用SOME/IP，是一種適用SOA 大數據和標準化傳輸的先進協議［7］，屬于車載以太網的范疇，而與傳統汽車大量使用的CAN 通信協議存在很大的不同［8］。主要區別可以概括為：CAN協議的實時性高，為微秒級的硬實時協議，數據量小，在須保證可靠和實時性的汽車硬件上仍無法取代；SOME/IP 一類的以太網協議傳輸帶寬大、但實時性沒有CAN 協議高，能實現毫秒級的軟實時要求，適合用于傳輸多媒體數據，以及實時性要求相對較低硬件。

因此，對于仍須使用CAN 協議的動力與控制功能域的執行器硬件，如電動機、轉向控制等硬件，屬于具有硬實時要求的硬件服務［9］，由于無法接入SOA 服務，也無法用于服務調度。根據不同的功能區間，可以將可調度的硬件層級分為如表1 所示的幾種類型，并分別對每種類別進行了若干舉例。

自動駕駛域的硬件以激光雷達等感知傳感器為代表，其性能會受到環境變化的顯著影響，具有服務調度的必要性；車身與座艙域、動力與控制域的傳感器可以為智能軟件算法提供汽車運動或環境的信息，車身與座艙域的執行器作為軟件的輸出，都與后者具有直接相關性，因此也可以隨軟件一起進行服務調度。而動力控制功能域的執行器一般采用CAN協議，現階段一般無法被直接抽象為SOA 服務，但可以采用“服務代理”的方式，將整個舊的軟件模塊包裝為軟件黑盒，成為一個類似軟件服務的整體功能，保留在舊架構下的既有成熟代碼［10］。但這種方式作為額外的轉接層，會降低效率和可被用戶察覺的性能，影響實時性，因此對于實時性要求高的模塊，只應該在服務代理的黑盒預留出實時性要求不高的狀態發布類信息接口，也就被歸類到動力與控制域的傳感器范疇，因此執行器由于硬實時的需求，在嚴格意義上仍然暫時不能接入SOA。

對于軟件服務層級而言，理論上現階段智能網聯汽車的各類軟件都可以被抽象為SOA 服務，如表2 所示，但應用最廣泛、最多討論的功能域為智能座艙相關的對人智能類型軟件。此類軟件投入成本相對較小，對汽車運行的影響小，試錯成本較低，適合作為SOA 車用探索階段的軟件類別。其他可被調度的類型還有自動駕駛相關軟件算法、對車和路智能的智能座艙軟件，及控制通信的車聯網軟件等，這些功能對汽車的行駛性能有直接影響，測試成本較大，適宜在SOA 應用更成熟廣泛后再納入體系；或因車路云系統本身不夠成熟，相關基礎設施也沒有普及應用，不適宜在現階段就考慮SOA 的部署。但這些技術的相關成本和成熟應用問題得到改善后，將其納入SOA 的可調度層級中，能將汽車SOA 的服務范圍拓展到更通用的范圍。

表2 可調度SOA軟件服務層級分類

1.2 影響調度的關鍵環境因素分類

對于不同的SOA 服務層級，不同環境因素的影響也不相同。對其性能或功能有顯著影響的環境變化，稱之為關鍵環境因素，否則為非關鍵因素。能對服務造成影響的環境因素，可以大致按表3分為4種類型：天氣條件、路面條件、交通條件和車輛狀況。一般天氣條件中的關鍵環境因素為負面影響，對汽車的硬件造成功能阻礙，如雨雪或能見度降低的天氣；路面條件即為影響汽車動力經濟性、操穩性、平順性等性能的路面因素，與汽車駕駛息息相關；交通條件主要影響自動駕駛相關軟硬件，對其算法的運行效率有影響；車輛狀況可能影響座艙內的環境舒適程度，以及與駕駛性能的參數相關。

表3 影響調度的關鍵環境因素分類及示例

2 SOA設計與建模

2.1 SOA服務層級建模

一組功能目標相近，且服務粒度大小相近的子服務可以構成一個服務層級。其中，硬件服務層級與硬件直接關聯，提供最基礎的功能，位于SOA 架構底層；而軟件服務層級中的子服務一般為實現一類功能的算法或其他軟件，不與硬件直接關聯。為了實現一個系統功能，需要對SOA 架構發起相應的服務請求。

應用和算法層的一個功能往往需要多個存在上下調用關系的服務層級共同實現，在縱向上可以分類為不同的服務層級束。

為了體現這種橫縱向服務層級關系，表現功能域拓展后的SOA 架構，文中給出了如圖2 所示的問題模型：某汽車SOA架構中包含m個硬件服務層級，n個軟件服務層級，其中硬件子服務由Lij表示，軟件子服務由Mij表示。 其中，i為服務層級序號，j為每個服務層級中的子服務序號。

圖2 功能域擴展的汽車SOA模型

在每個服務層級中，子服務都具有可選性，可啟用其中若干個以滿足系統的功能需求；同時，滿足上下調用關系的不同服務層級中，也可能存在關聯的子服務，即上層子服務需要固定啟用下層的子服務，存在依賴性。

2.2 服務響應參數建模

2.2.1 硬件服務層級

定 義 2 維 向 量Lij∈R3，i= 1，2， …，m，j=1， 2， …，k來描述第i個硬件的參數：

式中：Cost為服務資源負載；S為服務能力。服務資源負載包括計算資源和能耗兩個部分。

計算資源負載又可包括CPU、內存、存儲容量、網絡以及GPU 等關鍵元器件的資源消耗情況，根據計算資源負載的各組成部分及能耗在車輛上的影響程度大小，可以采用不同的影響系數，并添加或減少關鍵元器件的種類。例如，對于CPU、內存、網絡和能耗4 種因素影響最大的車輛而言，服務資源負載可以用式（2）表示：

式中：P為實際消耗的資源數量，單位為相應資源的單位，MB、kJ 等；C為對應的資源系數，用于進行去單位化和設定每種資源的加權量，單位為MB-1、kJ-1等。

服務能力表示該服務硬件在當前環境下的運行效果，對于不同的硬件種類，選取最關鍵的幾種評價指標。對于可調度SOA 硬件，最典型的即為環境感知傳感器，其服務能力可用分辨率表示，單位為PPI（pixels per inch，PPI）。

2.2.2 軟件服務層級

定 義 2 維 向 量Mij∈R3，i= 1，2， …，n，j=1，2， …，k來描述第i個傳感器的參數：

式中：Te為服務預計完成時間。服務資源負載的計算與硬件服務層級相同，而服務預計完成時間可根據車機操作系統給出預估時間，用于評價同類功能軟件服務在執行某個任務時的難易程度。

2.2.3 調度方案變量

對于一個服務層級Li或Mi，定義調度方案變量Xi∈Rk，維度與該層級子服務的數量相同；Xi第j個元素的值，Xi[j]= 0 or 1，代表服務層級自上而下總計第j個備選子服務是否啟用，0 表示不被調用，1 表示被調用。例如，對于具有4 個子服務的M3服務層級，調度方案X3∈R4。對所有服務層級的調度方案進行總和，可得系統的整體調度方案。

2.2.4 約束條件

服務調度的約束條件較為寬泛，主要目的是避免極端情況下出現系統宕機，（C1～C6）以及保證系統能對需要調用的服務具有優先操控權，因此還需引入系統需求功能覆蓋約束（C7）。

服務最大完成時間約束（C1）：

式中：n表示該層級具有的子服務數量；Tmax則為設定的最大服務完成時間。

系統服務資源約束（C2～C5）：

式中Costmax表示對應資源的設定最大值上限。

硬件服務能力下限約束（C6）：

式中Smin表示對應硬件服務能力的設定最小值下限。

系統需求功能覆蓋約束（C7）：

式中Psyst表示系統功能需求開啟的子服務集合，需要優先確保系統開啟需求的子服務。

3 SOA調度算法

3.1 服務置信度

每個服務層級中，在當前環境條件下每個子服務的運行可靠性和響應效果的綜合效果為服務置信度。在網格計算的服務調度機制中，通常會采用基于信任的QoS［11-12］和性能的QoS［13］，以分別提升服務提供者和接受者的可信程度，并進一步采用基于如啟發式的方法實現機制，如經典的Min-Min 算法［14］。在網格計算中，性能QoS 包括最終服務期限等與時間相關的參數和精度等與準確性相關的參數，而信任QoS 是用來評價服務信息的真正可信程度。服務置信度結合了類似于網格計算中QoS 的信任和性能兩個維度的理念，用于綜合表征汽車SOA 上的服務運行效果。其中信任的理念體現在加入的運行穩定性的評價指標，數據越穩定，表明其服務失效的可能性相對而言更低，也就具備更高的可信度；性能的理念體現在服務參數中的負載、服務能力和預計完成時間，更優秀的指標也就表征了更強的性能。

服務置信度Conf由服務參數L和M估計得出。LiT和MiT為短時間段T內由每隔T/n時間采集的一系列服務參數Li和Mi構成的二維離散數列，為其標準差的模。

運行效果參數α1、α2，運行穩定性參數β1、β2，滿足：

對于硬件服務層級：

對于軟件服務層級：

3.2 基于服務置信度的子服務更新算法

該算法的目的是更新某個具體層級的服務調度方案，需要在整體算法中被多次復用。為了便于表述，后文將該算法稱為算法1。該算法的具體流程如下，流程圖如圖3所示。

圖3 算法1流程圖

（1）輸入需要更新子服務調度方案的服務層級，根據服務層級為硬件層級或軟件層級，獲取所有子服 務 的Cost、S或Cost、Te，得 到 所 有 子 服 務 的Li或Mi。

（2）考慮系統功能覆蓋約束C7，選擇系統功能需求開啟的子服務集合Psyst中包含的子服務。由于約束條件C1～C6主要為了避免極端情況下的宕機，在這里認為系統提出需求的服務本身滿足約束條件C1～C6。

（3）考慮最大完成時間約束條件C1，系統服務資源約束C2～C5，硬件服務能力下限約束C6，當其中的子服務不滿足約束條件時，不選擇這些子服務。

（4）其他沒有被約束條件限制的子服務，計算所有的服務置信度Confi，構成集合{Conf}，其中步驟（2）中指定開啟的系統需求子服務單獨列出，構成的服務置信度集合為{Confsyst}，此時，{Conf}不包含{Confsyst}的元素。

（5）比較{Conf}中所有元素和{Confsyst}的平均將其從{Conf}去除。

（6）若{Conf}中仍有剩余元素，選擇{Conf}中最大的元素對應的子服務，并加上步驟（2）中優先級更高的{Confsyst}構成輸出的調度方案。

通過步驟（4）～步驟（6），能在滿足系統功能需求的條件下，通過其他可能服務置信度更高的子服務進一步提升最終調度方案的平均服務置信度。

3.3 服務調度選擇算法

該算法為整體算法，控制汽車整體的調度過程運行。為了減少計算資源的消耗，在某一服務層級的服務置信度下降不超過10%時，不對該服務的選擇方案更新；同時，為了避免出現服務置信度穩步下滑，影響整體運行效率，系統每隔一個初始化周期后會進行重置，重新選擇各服務層級的調度方案。后文將該算法稱為算法2，具體流程如下所示，流程圖如圖4所示。

圖4 算法2流程圖

（1）對所有服務層級運行算法1，獲得初始的子服務調度方案X。

（2）每隔時間δt，獲取每個層級正運行的服務參數Li或Mi，計算服務置信度，并計算服務置信度相較Nδt內最大值的變化幅度p，其中N為記錄當前檢測點之前的時間間隔數目， 該服務層級的變化幅度p記為

（3）當p≤-10%時，對該服務層級重新運行算法1，更新子服務的選擇，轉步驟（2）。

（4）當p＞-10%時，不改變該服務層級的調度情況，轉步驟（2）。

（5）每隔一個初始化周期Tinit后，轉步驟（1）。

4 模擬實驗設計

4.1 簡化系統模型

為了更具體地展示服務調度機制的運行過程，以及驗證服務調度的優勢，文中設計了簡化的軟件和硬件雙層模型，在參數模擬下進行服務調度過程的仿真，并設計幾種典型的環境場景，將其與不進行服務調度的效果進行對比，驗證其在能耗和服務能力上的優勢。

如圖5 所示，SOA 模型選為雙層架構，每個服務層級分別由3 個子服務組成。汽車上布置3 組自動駕駛汽車常用的傳感器類型：攝像頭組、激光雷達組和超聲波雷達組［15-16］。每個傳感器組的布置方案都能覆蓋車身周圍的足夠范圍，使自動駕駛功能正常工作。3 種傳感器類型不僅應用廣泛，并且在不同環境中的工作特性差異明顯，能夠更典型地表現出應對不同環境的服務運行差異性；而常用的毫米波雷達的工作特性與激光雷達相似，故而僅選取了其中的一種。

圖5 簡化SOA雙層模型

汽車SOA 除傳感器服務層級外，擁有一層具有3 個子服務的上層算法層級，代表運動物體追蹤（moving object tracking， MOT）層級，分別為：立體視覺MOT、傳感器融合MOT、深度學習MOT［15］，同樣，假定這3 種的軟件層級在不同環境下工作特性同樣差異較大，更為典型。

在簡化模型中，設置運行效果參數α1= 0.8，α2= 0.9，運行穩定性參數β1= 0.2 ，β2= 0.1。由于信任QoS 的理念不是直接對應在運行穩定性一個因素上，因此根據性能QoS 理念的運行效果應該作為更加重要的因素；硬件層級的運行穩定性受環境影響和安裝位置等影響更大，因此提高了硬件層級相較于軟件層級的運行穩定性參數。

4.2 設計場景驗證

4.2.1 高速路場景

Case1 設置為高速路場景。硬件傳感服務層級L1、L2、L3分別為：攝像頭組、激光雷達組、超聲波雷達組。此場景只影響硬件傳感服務層級。在高速路場景下，速度會對超聲波雷達的感知能力產生不利影響［17］，因此設定歸一化后的服務能力平均值=0.4；對于服務資源負載，以各傳感器靜止且工況條件最適宜時的負載作為標定。在傳感器的運行工況變差時，更難獲取傳感數據，且運算模塊進行處理時會消耗更多的資源，因此選取服務資源負載，如表4 所示。同時，運行工況變差時，服務能力和資源負載的數據浮動值會提高，由此如表4 可以設定標準差的數值。

由設定的參數計算當前場景下的Conf(Li)，并應用算法1 和算法2 進行排序。對于某些自動駕駛汽車而言，不需要處理激光雷達的數據就可以實現滿足自動駕駛功能。此時，攝像頭的服務置信度最高，考慮約束條件后可以得出調度方案變量為

對于其他自動駕駛車輛，需要進行傳感器融合算法［17］，如補充激光雷達數據進行融合等才能獲取足夠感知數據，此時系統需求開啟的服務集合Psyst=[0，1，0]。又因為攝像頭的服務置信度大于激光雷達，根據算法1，攝像頭服務也需要開啟，考慮約束條件后調度方案變量為

則此時求解結果：同時啟用攝像頭組和激光雷達組。

4.2.2 交通參與者較多場景

軟件服務層級M1、M2、M3在Case 2 中代表運動物體追蹤（MOT）層級，分別為：立體視覺MOT、傳感器融合MOT、深度學習MOT。此場景只影響軟件算法服務層級。立體視覺算法相對來說計算資源消耗較低，但依賴于環境中存在足夠的紋理和深度信息；傳感器融合算法對計算資源要求較高，但適合跟蹤各種類型的物體，包括沒有明顯紋理的物體；深度學習的方法便于處理復雜場景和多目標跟蹤，但需要更多的訓練數據和計算資源［18］。根據這些特征，對于服務響應時間，深度學習方法具有最高的效率，處理速度更快，用時應最短，其次是傳感器融合和立體視覺方法。對于服務資源負載，標定值1 時取為適中處理數據下的負載情況，在環境場景變化時，既需要考慮各子服務本身的負載變化幅度，也需要考慮不同子服務間本身的負載差距，可以按一定的參數選取。由于立體視覺方法計算復雜度最小，其次為傳感器融合方法和深度學習方法。三者的數據波動性一般都不大，傳感器融合分析數據量較大，相對而言穩定性稍高。由以上分析，進行歸一化后得到表5的設定數據。

表5 擁堵道路場景軟件層級服務置信度

計算當前場景下的Conf(Mi)，可得此場景下深度學習的服務置信度最高，為0.61，并應用算法1和算法2，考慮約束條件后得出該軟件服務層級的服務方案變量：

則此時求解結果：啟用深度學習MOT。需要注意的是，不同復雜程度的交通參與者復雜程度、不同的算法在響應時可能有不同的調度結果。

4.2.3 隧道低光照場景

此場景同時影響軟件算法服務層級和硬件傳感服務層級。低光下攝像頭組的傳感能力受到影響，一并影響立體視覺MOT 的運行效果；同時隧道無行人和非機動車，交通參與者復雜性和數量相比適中處理數據的標定場景降低?？梢栽O定攝像頭和立體視覺MOT 的各項參數受到影響，傳感器融合由于也具有攝像頭數據，也受到較小的影響。對于超聲波雷達，隧道中行車速度較低，但距離其最適宜的低速行駛工況仍有部分降低；深度學習方法受到的影響較小，且其負載更高，但受環境影響的變化幅度較低。綜合以上分析，進行歸一化后可以得到表6 和表7的設定數據。

表6 隧道低光照場景硬件層級服務置信度

表7 隧道低光照場景軟件層級服務置信度

計算當前場景下的Conf(Mi)和Conf(Li) ，并應用算法1 和算法2，可得兩個層級中，分別為激光雷達和傳感器融合子服務的服務置信度最高，考慮約束條件后，可得出該雙層服務層級的服務變量方案為

則此時求解結果：在硬件服務層級啟用激光雷達，在軟件服務層級啟用傳感器融合MOT。

4.3 調度優勢分析

不進行服務調度時，在本文的簡化雙層SOA 服務層級中，硬件服務層級的全部子服務開啟，在所有場景中都始終采集數據進行處理；軟件服務層級在所有場景下只選擇一種固定的子服務運行。而進行服務調度時，按照上面設計的3 種服務場景通過系統進行多次場景服務的切換，進行服務能耗的對比分析，并同時比對整體服務能力的變化，進而可以分析服務調度的優勢。開啟更多的子服務會產生更多的能耗，而整體的服務能力可以近似認為和服務能力最高的子服務相近。在場景的環境沒有影響到該服務層級時，負載設置為1。

由于實際場景的數據采集和定量難度較大，在本文的初步研究中將采用虛擬的隨機數組作為服務參數指標中的負載、服務能力及服務預計完成時間數據輸入。為了在簡化條件下更好地模擬實際駕駛場景中數據的自然波動，這些服務參數的隨機數組服 從 正 態 分 布X～N(μ，σ2)，式 中，μ= 1，σ=即本節中設定的各場景下標準差，見表4～表7。

自動駕駛汽車運行時，由于不斷計算消耗的能源相比傳統汽車而言更不可忽視。因此，采用考慮了系統計算資源消耗等計算機負載的服務資源負載Cost來表示汽車整體能耗情況是可行的。

如圖6 設置一組場景循環，每隔一個時間間隔切換一組場景。時間間隔為單位時間的虛擬量，表示一次更換場景的單位時間，包含一組正態分布隨機數組的所有數據。隨后，將上述生成的各場景下正態分布隨機數組經過調度與否的疊加計算后，按場景的輪換，在MATLAB 中繪制為圖7～圖9，分別展示調度與否的能耗、軟件層級服務預計完成時間和硬件層級服務能力3個維度的模擬情況對比。

圖6 調度場景對比設置

圖7 調度與否的能耗對比分析

由圖7 可見，進行服務調度的組別在能耗負載上明顯更低。通過計算，在模擬場景下，進行調度與不調度的能耗平均比值為64.33%，在本文所列場景循環中可能降低能耗3至4成。

根據圖8，對于軟件層級的預計服務時間，在某些場景下，如Case2 中，由于軟件服務層級中不同子服務性能差距較大，進行調度能夠顯著降低服務預期完成時間。整體而言，進行調度也能維持小于等于不進行調度的Te。對于本文的場景循環，Te的平均比值約為70.19%，進行服務調度可降低3 成左右的服務預計完成時間。

圖8 調度與否的預計服務時間對比分析

對于硬件層級的服務能力，由圖9 可得，進行服務調度的平均服務能力與不進行調度的比值約96.61%，與不進行調度的子服務全部開啟情況相近。這說明服務調度在該場景循環下可以保持絕大部分的服務能力，維持性能。

圖9 調度與否的服務能力對比分析

綜合以上分析可以得出，開啟服務調度后，能在一定的環境場景下顯著降低由于計算資源等消耗產生的能耗，一定程度上降低軟件服務的預計完成時間，并能和不進行調度的服務能力表現相近。

5 結論

在通用SOA 架構的基礎上，本文歸類并分析了可被調度的SOA 服務層級，以及會影響服務調度的環境因素。在此基礎上，提出了面向智能汽車功能域可拓展的SOA 架構，可以適配更廣泛的SOA 服務層級，便于跨域服務調度?；诖?，本文設計了一個相對完整的SOA 服務調度機制，以服務置信度為調度核心，實現子服務調度方案的最優選擇。綜合考慮服務能力、負載和數據穩定性等因素，通過測定服務響應參數計算獲得服務置信度，并通過基于服務置信度的子服務更新算法和服務調度選擇算法實現服務調度流程，提高智能汽車應對環境變化的自適應能力。

在簡化的SOA 雙層模型中，本文設計了3 種典型場景以演示服務調度的過程，模擬實驗結果表明：所提方法顯著降低了計算資源負載等原因引起的服務能耗與預計服務時間，分別為36%和30%；且該方法能保持服務能力與不調度的情況相近，為原有的96.61%。由此可見，調度算法能夠在維持服務能力的同時，降低汽車在環境場景切換時的能耗，在一定程度上提升自適應性。

為了使數據的設定更符合實際情況，未來還需要在實車上進行數據測定和驗證，以對調度算法進行優化和改進。同時，還可以采用更先進的數據通信方式，來將汽車動力系統容納到可被調度的SOA服務層級中，以更大程度地拓展SOA的優勢。