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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 3. 將軟件組件分解為服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為 AUTOSAR Adaptive 應(yīng)用配置服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：黃飛