| 作者Shwetha Bhadravathi Patil 和 Nukul Sehgal，MathWorks

軟件定義汽車 (SDV) 的特點是 AI、自主、連接和電氣化。最近，汽車行業(yè)已開始采用“基于服務”的方法來設(shè)計 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)性。這些特性包括：

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

圖 1. 組件緊密耦合的一體式設(shè)計。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用基于模型的設(shè)計遷移到服務

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

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

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

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

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

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

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

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

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

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

圖 7. 每個服務的模型都帶有輸入、輸出及其應用邏輯。您可以仿真這些模型并觀察服務之間的交互。

實現(xiàn)和部署：使用基于模型的設(shè)計中的客戶端-服務器接口，您可以創(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. 設(shè)計、開發(fā) AUTOSAR Adaptive 應用的服務并為其生成 C++ 代碼。

視頻：如何在 Simulink 中為 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é)論和將來的工作

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

審核編輯：湯梓紅