軟件定義汽車 (SDV) 的特點是 AI、自主、連接和電氣化。最近，汽車行業(yè)已開始采用“基于服務”的方法來設計 SDV 的現(xiàn)代應用。這種稱為面向服務的架構(gòu) (SOA) 的方法為開發(fā)軟件應用提供了一種新范式，其特點是高重用性、易于更新以及與硬件的松散耦合。SOA 的構(gòu)建原則是一個應用由一組服務組成，這些服務可以被動態(tài)地發(fā)現(xiàn)、發(fā)布、訂閱和在運行時重新配置。SOA 的概念已被廣泛納入行業(yè)標準，包括 AUTomotive Open System ARchitecture (AUTOSAR)。

在 SOA 框架中，服務具有自包含、模塊化、松散耦合等特征，這使得創(chuàng)建本質(zhì)上非一體式的復雜分布式應用成為可能。基于 SOA 的應用可以使用自上而下或自下而上的方法來開發(fā)。在標準 SOA 軟件堆棧中，應用軟件由服務、平臺服務和中間件組成。它們都運行在高性能硬件或虛擬機上。

將舊應用遷移到 SOA 面臨的挑戰(zhàn)

由于舊應用的若干特性，將其遷移到 SOA 可能頗具挑戰(zhàn)性。這些特性包括：

一體式設計：舊應用通常采用一體式設計（圖 1），組件的耦合和互連均很緊密。這使得很難將其分解成若干單獨的服務，因為功能是相互交錯的，而不是模塊化的。

圖 1. 組件緊密耦合的一體式設計

執(zhí)行順序：舊應用的組件通常有預定義的執(zhí)行順序。這種順序執(zhí)行方式使得應用難以轉(zhuǎn)換為可動態(tài)發(fā)現(xiàn)和在運行時重新配置的獨立服務。

基于信號和基于時間的通信：舊應用通常依賴組件之間基于信號或基于時間的通信。在 SOA 中，通信通常基于服務接口和交換消息。將舊應用的通信機制調(diào)整到面向服務的方法需要仔細考慮各個事項，甚至可能需要重新設計通信協(xié)議。

克服這些挑戰(zhàn)通常需要全面分析舊應用的架構(gòu)，并仔細確定組件之間的服務邊界和依存關系。這可能需要將應用重構(gòu)為更加模塊化和松散耦合的若干單元，進而將這些單元封裝為 SOA 框架中的各個服務。

將舊應用組合轉(zhuǎn)換為服務是一項復雜的任務。例如，以前設計的一體式應用組合（如高速公路車道跟蹤應用）可以變換為單個服務，也可以分解為多個服務，如相機服務、視覺服務、雷達和車道導航服務。

系統(tǒng)專業(yè)知識和基于模型的設計有助于把一體式應用設計分解為若干服務函數(shù)，從而將各個邏輯組件進行封裝和抽象分離。它可以助力信號到服務接口的遷移并確定正確的執(zhí)行順序。在本文中，我們將介紹一個基于模型的設計工作流。此工作流可對新服務進行建模，亦可將您的傳統(tǒng)應用組合轉(zhuǎn)換為基于軟件定義汽車的 AUTOSAR Adaptive 概念的服務。

將傳統(tǒng)應用軟件組合分解成服務

將傳統(tǒng)應用軟件組合分解成 SOA 應用的服務涉及將一體式架構(gòu)分解成更小、更模塊化的組件（圖 2）。這對 SDV 來說意味著更大的靈活性、可擴展性和自適應性。

圖 2. 將傳統(tǒng)應用軟件組合分解成服務的步驟

將傳統(tǒng)應用軟件組合分解為 SOA 應用的服務涉及四個步驟。

識別和分析服務：識別組成 SOA 的服務、組件、功能、執(zhí)行順序和依存關系。對于工程師來說，這是最困難的部分。完成之后，他們必須分析服務，以將傳統(tǒng)的一體式應用分解成更小的組件（圖 3）。

圖 3. 將軟件組件分解為服務

定義服務和接口：在識別服務后，必須定義它們之間的接口。這涉及指定用于服務間通信的協(xié)議和數(shù)據(jù)格式，以及定義指定服務間交互的條款和條件的服務合約。

定義服務合約：此步驟指定服務之間交互的條款和條件。AUTOSAR 架構(gòu)版本 22-11 中引入了這些概念。該架構(gòu)指定服務的版本控制，支持在不破壞現(xiàn)有客戶端兼容性的情況下發(fā)布新版本的服務。

實現(xiàn)和部署服務：實現(xiàn)服務并將其部署為獨立應用，具有自己的工件，包括接口描述。

使用基于模型的設計遷移到服務

基于模型的設計已用于開發(fā)非 AUTOSAR 框架和 AUTOSAR Classic 框架的應用。它還可用于為 AUTOSAR Adaptive 和通用 SOA 框架開發(fā)基于 SOA 的應用。對于 SDV 應用，業(yè)界通常利用通用 SOA 或基于 AUTOSAR Adaptive 平臺的 SOA。基于模型的設計的優(yōu)勢在于可以提供統(tǒng)一的開發(fā)平臺，有效地處理所有類型平臺（包括 SOA、AUTOSAR Classic 和 AUTOSAR Adaptive）的整個開發(fā)過程，能夠確保全面的一致性和效率。

使用基于模型的設計將一體式應用組件分解為服務涉及以下步驟：

識別和分析服務：了解各種組件、其功能、執(zhí)行順序以及它們之間的依存關系。一個一體式應用的所有組件均部署為一個可執(zhí)行文件進行部署（圖 4）。然而，當分解成服務時，每個單獨的服務均獨立部署。

圖 4. 所有 Simulink 模型作為一個可執(zhí)行文件進行部署

例如，圖 4 中有一個在 Simulink 中開發(fā)的高速公路車道跟隨應用，它作為一個一體式應用組合進行部署。使用 Simulink 將這樣的一體式組件分解成服務（圖 5）需要依據(jù)單一職責原則和依賴倒置原則。根據(jù)這些原則，高速公路車道跟隨模型可分解為多項服務，如雷達、視覺和車道。這些服務具有良好定義的職責和松散耦合的依存關系，支持隔離對服務的更改，并且最小化更改對其他服務的影響。

圖 5. 使用基于模型的設計將一體式舊應用分解為服務

一體式應用分解成若干基于 SOA 的服務，并用客戶端-服務器端口將它們連接起來

定義服務和接口：使用接口定義的服務是服務邊界的一部分。服務邊界同樣定義了服務與其他服務交互的通信通道。服務邊界還封裝功能，以實現(xiàn)重用、可維護性、版本控制、可見性、編排和其他好處。使用 System Composer，您可以配置相關服務組件的端口以實現(xiàn)數(shù)據(jù)一致性，并通過原型來表示這些服務之間的交互方式。這提供了服務之間依存關系和交互的可視化表示（圖 6）。

圖 6. 在 Simulink 中配置服務組件的服務接口和端口

定義服務合約：我們建議為服務建立清晰的邊界，定義其輸入、輸出和行為。這讓服務可以獨立地開發(fā)、測試和部署，而不需要與架構(gòu)的其他部分緊密耦合。通過定義服務合約，您可以了解服務的功能和限制，并且可以更輕松地與它們集成。此外，服務合約可以在不破壞與現(xiàn)有客戶端的兼容性的情況下發(fā)布新版本的服務。

實現(xiàn)和部署：使用基于模型的設計中的客戶端-服務器接口，您可以創(chuàng)建 SOA 軟件架構(gòu)模型。圖 8 展示了在 Simulink 中作為服務實現(xiàn)的 LaneGuidanceApp、DetectionApp、雷達和視覺算法。

圖 8. Simulink 中 SOA 服務的算法實現(xiàn)

此外，您可以使用 Embedded Coder 為通用 SOA 應用生成 C++ 代碼。

為 AUTOSAR Adaptive 應用配置服務

您可以使用 Simulink 建模結(jié)構(gòu)為 AUTOSAR Adaptive 無縫配置這些服務。如圖 9 所示，我們使用 System Composer 中直觀的 AUTOSAR 編輯器，成功地將所有服務作為 AUTOSAR Adaptive 服務進行了集成。隨后，我們?yōu)槊總€端口和接口建立了必要的映射，確保它們與對應的 AUTOSAR Adaptive 屬性保持一致。

圖 9. 設計、開發(fā) AUTOSAR Adaptive 應用的服務并為其生成 C++ 代碼

以雷達服務為例，它鏈接到一個 Simulink 模型。該模型在根級使用 Simulink Function 模塊來創(chuàng)建Adaptive methods (3:50)服務接口。此處，AUTOSAR 服務接口的方法定義了一個軟件組件（建模為提供接口的服務器）和另一個軟件組件（建模為需要接口的客戶端）之間的交互。

在 Simulink 中，客戶端-服務器通信可以用同步或異步調(diào)用行為進行建模。同步客戶端模型導致客戶端執(zhí)行阻塞，也就是說客戶端會向服務器發(fā)送請求并等待響應。異步客戶端模型不會導致執(zhí)行阻塞，也就是說客戶端會發(fā)送請求、在發(fā)送請求后繼續(xù)當前執(zhí)行并在收到服務器響應后進行處理。

雷達服務是一個使用客戶端-服務器通信的服務器。在圖 9 中，代碼映射 UI 顯示了 Simulink Function 模塊和函數(shù)元素端口的映射 - radarCtrl.Adjust 和 radarCtrl.Calibrate 及其各自的 Adaptive 端口。

此外，您還可以在 Methods 服務接口的 AUTOSAR 字典中查看和編輯 AUTOSAR 屬性（圖 10）。

圖 10. 用于查看/編輯屬性的 AUTOSAR 字典

LaneGuidanceApp 服務作為客戶端運行，并通過異步調(diào)用利用客戶端-服務器通信（圖 11）。此示例中的客戶端使用異步通信，并受益于非阻塞執(zhí)行，能夠在向服務器發(fā)送請求后繼續(xù)執(zhí)行。在 Simulink 模型中，它使用帶有 Message Triggered Subsystem 模塊的 Function-Call Subsystem 模塊來異步執(zhí)行函數(shù)調(diào)用。代碼映射 UI 顯示 Simulink 函數(shù)調(diào)用方與對應 AUTOSAR Adaptive 端口。

圖 11. 映射到 LaneGuidanceApp 服務的 AUTOSAR 屬性的 Simulink 模型

同樣，所有其他 SOA 服務都是根據(jù) Simulink 中的 AUTOSAR Adaptive 概念進行配置的。

經(jīng)過驗證和仿真后，每個 AUTOSAR Adaptive 服務都可以作為獨立應用程序進行部署，并具有自己的工件，包括 C++ 代碼和 AUTOSAR 接口描述，其中包含機器、執(zhí)行和 ServiceInstanceManifest 文件。最后，使用 Embedded Coder 生成 AUTOSAR Adaptive C++ 代碼以及對應的軟件描述和清單文件，以便進一步集成到工作流中（圖 12）。

圖 12. AUTOSAR Adaptive 應用程序的 C++ 代碼接口文件生成

結(jié)論和將來的工作

基于模型的設計為系統(tǒng)開發(fā)提供了一種結(jié)構(gòu)化方法，支持創(chuàng)建表示應用架構(gòu)、組件和交互的模型。在本文中，我們通過高速公路車道跟隨參考示例說明了如何使用基于模型的設計將傳統(tǒng)一體式應用分解為服務，然后將它們配置為 AUTOSAR Adaptive 應用程序。這些模塊化服務可作為一個開端，使工程師能夠創(chuàng)建、仿真和生成 C++ 代碼以及清單文件，以便進一步集成到工作流中。

審核編輯：黃飛