AUTOSAR Adaptive概述

2003年，汽車行業的高端玩家們發起了汽車嵌入式系統軟件架構標準化項目——AUTOSAR（汽車開放系統架構）。2017年，為適應汽車的發展趨勢（智能化、網聯化等），應對汽車E/E系統開發面臨的新的挑戰（高性能處理器的應用，自動駕駛的軟件實現，高帶寬通信需求，車與外界的互聯互通等），AUTOSAR組織推出了AUTOSAR Adaptive。

于是，在AUTOSAR的體系內有了兩大概念：AUTOSAR Classic Platform（后面將簡稱CP）和AUTOSAR Adaptive Platform（后面將簡稱AP）。AP的出現并不會取代CP，而是一種補充。目前，AP主要應用于MPU（Microprocessor Unit），CP則應用于MCU（Microcontroller Unit）。關于CP的詳細介紹請參考我們的公眾號《淺談AUTOSAR架構及開發方法》。

在不同的語境下，AP有不同的含義。首先AP是一個標準，它標準化了軟件開發的方法論，軟件分層結構，軟件模塊之間的接口以及編程語言，目前該標準的最新版本是R19.11（2019年11月發布）。從軟件實現的角度，AP是一個運行在POSIX操作系統上的基礎軟件平臺，也可稱為一種平臺級的中間件，其核心是ARA（AUTOSAR Runtime for Adaptive Application）。

AUTOSAR Adaptive架構圖 （ 圖片源自AUTOSAR_EXP_PlatformDesign R19.11）

ARA是應用程序（AP中稱為Adaptive Application）運行時的基礎環境，可以提供多種本地功能供應用程序調用，這些本地功能在AP中統稱為Function Clusters，其分為兩個部分：Foundation Function Clusters和Service Function Clusters。

上面對AP進行了一些簡單的介紹，接下來本文將重點討論基于PREEvision的AP設計流程。PREEvision是一款架構開發工具，使用該工具進行AP的設計，需重點關注AP方法論。如前所述，AUTOSAR AP是一個標準，它對軟件開發的方法論進行了標準化，其方法論實現的標準流程如下圖所示：

圖AP development workflow（圖片來源AUTOSAR_EXP_PlatformDesign）

相關概念介紹：

Machine：在AP的概念體系中，Machine代表一種計算資源，它可以是真實存在的處理器（Process Unit），也可以是一個虛擬機（Virtual Machine），AP軟件則運行在某一特定的Machine上。

Manifest：Manifest是一種AUTOSAR模型的描述文件，主要包含AP軟件部署涉及到的一些配置信息（比如Service Instance Manifest會包括服務接口的版本信息，SD參數信息等內容）。

注：AUTOSAR Adaptive的方法論詳細介紹可以參考AUTOSAR_TR_AdaptiveMethodology文檔

PREEvision中AUTOSAR Adaptive的基本設計流程

PREEvision中AP設計流程（圖片來源PREEvision Help文檔）

PREEvision中AUTOSAR Adaptive設計內容主要包含以下幾個部分：

1）軟件層

• 服務設計：服務定義，服務角色定義
• 服務接口設計：設計Method，Event及Property；并完成數據類型的定義；
• 服務接口部署：選擇SOA的通信方式，如SOME/IP等；并將服務接口與通信協議進行映射；
• 服務接口序列化：定義服務接口（Method/Event/Properties）的序列化方式及屬性
• Adaptive Application設計：設計Adaptive SW components，Executables及Adaptive Applications

2）硬件層

• 基于以太網的硬件拓撲設計
• Machine設計及部署（Deployment）：創建machine，設計machine的狀態及服務發現等內容

3）通信層

• 軟/硬件映射：Adaptive Application SWC與Machine映射
• 服務實例化：基于軟/硬件映射生成服務實例；完成服務實例的配置
• 以太網通信設計：TP/IP地址及SOME/IP SD設計等

下面小編將基于PREEvision 9.5 SP1的Demo介紹PREEvision中AP的基本設計流程。

基本設計流程如下：

1.服務及服務接口設計

AP是一個面向服務的軟件架構（SOA），關于SOA的相關概念可以參考我們的微信公眾號《汽車為什么非要用SOA》。基于AP平臺的軟件開發，首先需要進行服務及服務接口的設計。

• 服務設計：服務是對功能單元的抽象描述；服務的定義包含服務的ID以及服務角色（服務提供方及服務消費方）的定義。本示例定義了兩個服務：Navigator及TrafficInformation。

若服務之間存在依賴關系，也需在服務設計階段明確，用于指導后續的軟件開發。

• 服務接口設計：服務接口定義了服務的功能特性，是Method、Event及Property的集合。

設計methods（包括F&F methods）、events及properties:

設計服務接口數據類型：

不同于CP的設計，在AP中，對于implementation data type，需定義數據類型C++相關屬性。

• 服務接口部署：

選擇應用協議（如SOME/IP），將服務接口與應用層協議進行綁定。目前PREEvision僅支持SOME/IP。

設計SOME/IP Interface：完成SOME/IP interface版本，以及method/event ID等屬性的定義。

• 服務接口序列化屬性定義：

序列化是一種將數據轉化為比特流，方便數據在通信鏈路上傳輸的技術手段；在AP中支持SOME/IP的序列化功能；在該Demo示例中選擇SOME/IP的序列化方式。對于SOME/IP序列化的屬性設置，與CP類似，此處不再贅述。

2.Adaptive軟件設計：

前面定義了服務和服務接口，接下來需要定義應用層軟件架構。在AUTOSAR Adaptive中，軟件架構由Adaptive Application SWC（Software Component）組成，類似于CP中SWC的概念。服務及服務接口是一種抽象的概念，Adaptive Application SWC是服務接口的軟件實現。一個服務接口至少需要一對Adaptive Application SWC來實現，一個Adaptive Application SWC實現了服務接口的調用，承擔服務客戶端的角色；另一個實現了服務接口Method/Event/Property的具體功能，承擔服務端的角色。

• AP軟件架構設計：

前面定義了兩個服務Navigator以及TrafficInformation，對應的Adaptive軟件架構設計的如下圖所示：

Adaptive Application SWC port與Service Interface 一一對應。Service Interface在軟件層的體現如下圖所示：

• Adaptive application設計：

在AUTOSAR Adaptive方法論中，Adaptive application是Executables（可執行文件）的集合，一個Executable源于一個Adaptive Application SWC。

Adaptive application有兩種類型：Application level和Platform Level。在本示例中定義的Adaptive application都是Application level。

今天就講到這里，給大家賣個關子吧，想要了解更多關于AUTOSAR Adaptive的內容，請持續關注“懌星科技”，我們后續將持續推出關于AUTOSAR Adaptive的其他設計內容，我們下周見咯~

總結

以上是生活随笔為你收集整理的软件接口设计_基于PREEvision的AUTOSAR Adaptive设计——上篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。