一

Adaptive AUTOSAR 方法論

AUTOSAR AP開發方法論包括三個主要階段，分別是：

1、架構和設計階段：

在這個階段，您需要確定系統的需求、功能和服務，并將它們分配到合適的Machine上。

根據個人習慣使用一些建模工具，例如[Simulink]、[ProVision]或[RTA-VRTE SDK]自帶的DSL腳本語言，來定義和設計應用程序的功能需求和架構。創建和配置服務接口、CP/AP互通性、軟件組件、SWC端口等，并生成ARXML文件。

ARXML文件是AUTOSAR的標準格式，用于描述應用程序的元數據和部署清單。這個階段的輸出是一個系統配置描述（SCD），它展示了系統的靜態和動態特征。

2、軟件開發階段：

在這個階段，您需要根據ARXML文件生成代碼框架，并使用C++語言開發自適應應用程序（AA）。

AA是運行在Machine上的進程，它們是軟件模塊，它們通過服務進行交互和協作。您需要遵循AUTOSAR C++標準，并使用CMakeList文件指定交叉編譯工具鏈和依賴項。

可能還需要使用代碼庫同步工具，例如[Git]或[SVN]，來管理和協作您的代碼。這個階段的輸出是一個應用程序清單，它說明了AA的屬性和依賴關系。

3、集成和部署階段：

在這個階段，需要使用一些集成和部署工具，例如 [RTA-VRTE SDK]，來將應用程序編譯成可執行文件，并部署到目標Machine上。然后，需要進行集成和測試，以驗證系統的功能、性能和安全性，并檢測并解決任何問題或缺陷。還需要配置應用程序的執行清單、服務實例清單和機器清單，以及任何其他需要的參數，并啟動執行管理來運行應用程序。

二

AUTOSAR APApplication開發流程

自適應AUTOSAR開發方法論包括以下幾個步驟:

(1)、系統設計：確定系統的需求、功能和服務，并將它們分配到合適的Machine上。

(2)、服務接口設計：定義服務的接口和屬性，以及服務之間的交互方式。

(3)、應用設計：定義和配置軟件組件（SWC），以及它們之間和網絡之間的數據映射和服務映射。

(4)、軟件開發：根據ARXML文件生成代碼框架，并使用C++語言開發自適應應用程序（AA）。

(5)、診斷設計：定義診斷需求和策略，并將診斷服務映射到SWC上。

(6)、Machine設計：定義Machine的屬性和配置，以及Machine之間的通信結構。

(7)、Machine清單：生成Machine清單文件，描述Machine的元數據和依賴關系。

(8)、軟件集群設計：定義軟件集群的屬性和配置，以及軟件集群之間的通信結構。

(9)、軟件集群集成：將應用程序編譯成可執行文件，并生成執行清單、服務實例清單和平臺模塊配置文件。

(10)、軟件打包：將可執行文件、清單文件和其他資源打包成軟件包，并指定更新策略。

2.1 如何使用C++開發自適應應用程序？

如果您想使用C++開發AUTOSAR自適應應用程序，您可以使用一些工具和方法來簡化您的工作流程。例如，您可以使用RTA-VRTE或Simulink來創建、模擬、驗證和生成符合AUTOSAR標準的C++代碼。無論您是使用AUTOSAR還是其他框架，開發C++自適應應用程序的一般步驟如下：

（1)、定義系統的需求、功能和服務，并將它們分配到合適的目標設備上。

（2)、設計系統的架構和接口，并生成相應的配置文件和元數據文件。

（3)、編寫C++代碼來實現系統的功能和邏輯，并遵循相應的編碼規范和風格。

（4)、編譯C++代碼并生成可執行文件，以及任何需要的庫文件和清單文件。

（5)、調試和測試C++代碼，并檢測并修復任何錯誤或缺陷。

（6)部署C++代碼到目標設備上，并進行集成和驗證。

一個基本的C++代碼示例：

2.2如何在AP AUTOSAR中實現服務間的通信?

在AP AUTOSAR中，服務之間的通信是通過ara::com API來實現的。ara::com API是一套基于C++11/14的接口，它提供了服務發現、服務訂閱、服務調用、事件通知等功能。ara::com API支持多種網絡綁定，如SOME/IP、DDS、IPC等，以適應不同的通信需求和場景。

要實現服務之間的通信，首先需要定義好服務接口，包括服務標識、方法、事件、字段等。服務接口可以使用AUTOSAR Service Interface Description Language (ASIDL)來描述，也可以使用其他格式，如XML或JSON。

然后，需要在應用程序中創建代理（Proxy）和骨架（Skeleton）對象，分別用于調用和提供服務。代理和骨架對象都需要指定服務標識和實例標識，以唯一地標識一個服務實例。

接下來，需要使用ara::com API中的FindService方法來發現可用的服務實例，并訂閱感興趣的服務實例。FindService方法會返回一個Future對象，用于異步地獲取查詢結果。查詢結果是一個ServiceHandle對象的列表，每個ServiceHandle對象包含了一個服務實例的信息，如網絡地址、端口號、協議等。

最后，可以使用代理對象中的方法和事件來與服務實例進行通信。方法可以是同步的或者異步的，分別對應于請求-響應模式和火并忘模式。事件可以是單播的或者多播的，分別對應于一對一或者一對多的通知模式 。

2.3AA的幾個術語

Adaptive application （AA）

承載Service的應用實體

Executable

App的運行時實體，一個可執行程序可以包含多個服務實例

Process

OS運行調度的實體

Machine

運行環境的物理資源

AUTOSAR使用ARXML格式文件進行建模

通過正式定義的接口來使用服務

實現服務有三種方式Event Method Field

定義服務傳輸的數據類型

App之間的通信端口，需要在component 元素中定義provide/require Port

三

自適應應用程序設計

3.1 AA開發流程

為了完成應用軟件系統設計工作，一般需要先完成整車定義，并分析出對智能駕駛的功能需求：

（1）獲得：系統設計文檔

-定義應用系統中的各APP、及其之間的通信關系

-定義APP與AP平臺Foundation和Service模塊的交互關系

-定義APP的運行部署環境

（2）ARXML文件生成

-根據設計人員的使用習慣，自行選擇工具即可

-自適應AUTOSAR是一種用于開發汽車軟件的標準方法。它使用XML文件作為核心，這些文件叫做ARXML，它們包含了開發過程中所需的所有信息。我們可以利用這些文件在不同的工具之間導入和導出數據，比如Matlab Simulink和RTA-VRTE SDK。這樣可以方便地切換不同的工具和環境。

AUTOSAR工具通常會提供代碼自動生成工具，如：根據AUTOSAR AP R21-11,生成代碼的語言標準兼容c++11和c++14。

3.2 AA的設計和建模：

定義服務的接口、數據類型、SWC組件等信息，在SWC中定義Provide port和Required port。

這些信息會被 Execution Manifest 和 Service Instance Manifest引用。

3.3 服務接口的定義

自適應AUTOSAR服務是一種將應用程序分解為不同的功能單元（叫做服務）的組件模型。這些服務通過明確的接口和契約相互連接，實現協作和通信。

接口是以中立的方式定義的，不依賴于服務實現的硬件平臺、操作系統和編程語言。這使得在各種系統上構建的服務可以以一種統一和通用的方式互動。

例如：定義一個圖示的應用服務接口設計：

RTA-VRTE DSL is used for the Application Design

3.4 基于服務接口ARXML文件的代碼生成

基于服務的定義生成應用程序組件頭文件

用于服務發現的Skeletons (offer, register, …)

服務發現Proxy (discovery, subscribe,…)

用于方法調用和事件接收的Proxy (client)

用于方法實現和事件發布的Skeletons (server)

實現和編譯軟件組件

此步驟獨立于服務實例的定義

開發可執行文件的主要功能

3.5 Adaptive AUTOSAR 應用的可執行文件

為自適應平臺配置和生成序列化代碼 鏈接軟件組件、主函數、序列化代碼和中間件庫，以構建可執行的應用程序。

構建AA的可執行文件，需要幾方面的輸入：

服務接口定義后根據配置生成的代碼

AA應用層代碼實現

AP平臺提供的庫文件和API等

AA進程依賴的配置文件

一個可執行文件是應用程序的一部分，它有一個入口點（主函數）。

一個應用程序可以由一個或多個可執行文件實現。

3.6 Adaptive AUTOSAR執行管理的配置

3.6.1 創建可執行文件

可以為單個目標ECU定義多個可執行文件。一旦創建可執行文件，可以通過選擇新創建的可執行文件的名稱在執行編輯器中打開可執行文件。

在可執行文件中，以下屬性是必需的：

Software Component Prototype - 對軟件組件的引用，定義提供和需要的端口。

Executable Path:可執行文件的路徑（在目標ECU上）。

Executable Version:可執行文件的版本。版本字符串應遵循AUTOSAR的強修訂標簽格式：（MajorVersion. MinorVersion. PatchVersion. BuildInformation）。

Reporting to EXM - 定義應用程序是否使用ReportExecutionState API報告其執行狀態。定義為活動的可執行文件預期表現為自適應應用程序并報告其狀態。定義為非活動的可執行文件不預期報告，并在啟動時立即假定為kRunning狀態。定義一個可執行文件為非活動意味著可以使用執行管理來啟動非AUTOSAR進程，并且這些進程可以參與執行依賴性。

3.6.2創建進程

在自適應平臺中，進程元素代表一個獨立的可執行實例。一個單一的可執行文件可以在多個進程中實例化。每個進程必須有一個名稱和一個清單文件。在其中可以設置進程元素和功能組狀態。

General：定義總體屬性。可執行文件定義了關聯的可執行元素（多個進程可以引用同一個可執行文件）。

Machine：定義自適應平臺實例（即機器）以及活動函數組狀態（狀態集取決于所選機器中定義的狀態）。也可以選擇性地分配核心親和力。

Access Management：定義與進程相關的標識符，包括UID/GID（定義用戶和組ID）。執行管理器支持將其子進程的真實用戶id和真實組id設置為可配置值。取決于ID，進程將有定義的權限來執行。有兩點需要考慮：

*可配置的UID必須存在于部署目標中。

*可配置的GID必須存在于部署目標中。

Arguments ：定義啟動進程時使用的命令行參數和環境變量。

Scheduling ：定義特定于進程的調度參數。

Logging & Tracing：為此進程定義應用程序ID、默認日志級別等。

Resource Consumption：定義對進程可用的資源限制。

Others：定義RTA-VRTE Starter Kit特定配置，包括函數集群關聯和終止配置。

3.6.3軟件集群包含的進程

每個進程的引用必須添加到相關的軟件集群。如果ContainedProcess為空，FlatCFG文件將無法正確生成。

如果在執行編輯器中配置了可執行文件或進程，但沒有將任何一個添加到軟件集群包含的進程列表中，將不會生成任何exm___flatcfg.json文件。

在RTA-VRTE中執行管理編輯器中配置APP自啟動

3.7應用程序設計與執行清單的關系

Adaptive autosar應用程序是由Adaptive Application SWC（Software Component）組成的軟件架構，它實現了服務接口的功能。

在自適應平臺中，可執行配置元素將可執行代碼與SWC組件原型關聯起來。

執行清單是一種描述應用部署相關信息的文件，它和可執行代碼綁定，包括應用程序的名稱、版本、依賴關系、啟動順序等。每一個可執行程序都可以在Execution Editor中創建一個執行清單，執行清單根據應用程序的設計生成，反映了應用程序的部署信息，指導了應用程序在機器上的運行。

3.8 Adaptive AUTOSAR 開發方法論小結

（1)、在AP工具鏈/平臺配置，工具中配置平臺、目標硬件信息，如處理器型號、核心數、機器 IP 地址、SOME/IP 端口等信息，生成Machine Manifest

（2)、在AP工具鏈/應用設計工具中定義服務，如數據類型、服務接口、SWC組件等

a) AP 工具鏈自動生成 Application Design 的 ARXML 文件

b) AP 工具鏈/代碼生成器基于Application Design的 ARXML 生成 Proxy 和 Skeleton 的 .h 和 .cpp 文件

（3)、軟件開發

a) Service應用實現 Skeleton的接口

b) Client 應用通過 Proxy 類（經由 COM）間接調用 Service

c) 編譯生成可執行文件

（4)、軟件集成

在 AP 工具鏈/可執行文件配置工具中配置可執行文件路徑、實例（進程）數、啟動參數、環境變量、調度策略、UID/GID 等信息，生成Execution Manifest

（5)、AP工具鏈提取

Application Design中的服務接口信息，在服務實例配置工具中添加額外的 SOME/IP 配置，如 Service ID，Method ID，Event ID 等，生成Service Instance Manifest

(6)、上述可執行文件、Execution Manifest、Service Instance Manifest（Processed Manifest）作為一個 SW Package 上傳到目標硬件

a) 目標硬件中SW Configuration Management 根據 Manifest 信息部署、驗證、安裝應用。

b) 根據 AP 平臺的實現，可以（不強制）預處理 Manifest 文件，如導入數據庫，以提高執行效率

c) EM 根據 Execution Manifest的信息調用OS接口啟動、配置、關閉應用（FC 以及 AA）

四

Adaptive AUTOSAR Working with ARXML

清單是ARXML文件中定義的一種特殊的元素，它們用來描述AP的部署信息，比如SWC、可執行文件、機器等。清單元素被放在package里，每個package都指定了一個單獨的元素類型。你也可以在package里嵌套其他的package，以便按照你的需要創建復雜的樹結構，以便按照你的需要對系統進行劃分。

清單本身（通常）被分成多個ARXML文件，這樣可以讓模型以基本上任意的方式在多個文件中分割，例如，一個文件包含機器信息，另一個文件包含可執行文件。這種方法比單個整塊文件有很多優勢，比如更方便重用單個元素，更方便片段化地測試元素，以及更強的配置管理，因為單個元素可以受到細粒度的控制。

使用ARXML定義的配置（模型）

?指定為一個或多個ARXML文件

模型能夠以基本上任意的方式在多個文件中拆分，易于重用/測試/配置管理

?Machine相關的信息保存在一個文件中

?可執行文件信息保存在另一個文件中

哪些配置可以拆分？

?由AUTOSAR定義的

?并非所有元素都是“可拆分的”，一個可拆分的元素在工具合并的不同包中可以有多個不同的定義

?不同的配置元素可以任意分布在文件中

?不同的ARXML文件必須具有相同的包路徑才能合并

?一些元素本身可以拆分，工具會根據需要執行合并，但不會修改底層文件

這個示例中，有兩個ARXML文件，分別包含兩個package。每個package指定了一個EL類型的元素。第一個文件中的packageB包含了EL1和EL2的定義，第二個文件中的packageB包含了EL3和EL4的定義。因為packageB是可分割的，所以工具會合并兩個文件中的packageB的定義，形成一個完整的packageB元素。但是，工具不會改變兩個文件的內容，它們仍然保持原來的樣子。

那么，在哪里可以分割配置呢？這實際上是由AUTOSAR規定的，因為并非所有元素都是“可分割的”。一個可分割的元素可以在不同package中有多個不同的定義，并且工具會合并它們——這里唯一的規則是，不同的ARXML文件必須有相同的package路徑才能合并。

最后，請注意，該工具會根據需要進行合并，但不會改變底層文件——它們會保持工具發現的原樣！

清單在ARXML中定義時，需要遵循XML的語法規則，例如：

?XML聲明必須放在第一行，第一列，并且聲明語句之前不能有任何空格和注釋。

?XML有且僅有一個根元素。

?XML中的標簽區分大小寫，并且對應的開始標簽和結束標簽必須大小寫一致。

?XML元素需正確嵌套，并且標簽需成對。

?XML的屬性值須加引號。

?XML支持實體引用和注釋。

? ? ? ?

五

RTA-VRTE—車輛計算機的 AUTOSAR平臺 基礎軟件框架

配備微處理器的車輛計算機是未來網絡化和自動化駕駛 E/E 架構的核心組件。其先決條件是安全可靠的平臺軟件框架，使得車輛制造商和服務提供商能夠專注于功能。

平臺軟件框架必須支持以下功能：

1)可靈活高效地集成具有不同安全要求的跨域功能；

2)可在一個ECU 上清楚地將軟件與不同供應商分開；

3)在整個車輛生命周期中具備持續安全更新能力；

4)支持軟件和服務領域的新商業模式。

此外，還需滿足傳統的車輛要求：

1)滿足最高安全性要求；

2)具備實時能力，即使在多次軟件更新后（不受干擾）；

3)具有成本效益 ；

4)生命周期內車輛軟件具有可維護性。

目前，市面上也有一些解決方案，比如博世與ETAS 共同開開發的基于 AUTOSAR 的 RTA-VRTE （車輛運行環境）。這一基礎軟件框架包含操作系統、AUTOSAR 自適應基礎軟件、虛擬機監控程序、安全元素。

VRTE的建立原則是面向服務的架構（ SOA ），所以能夠在 ECU 上集成不同供應商的軟件構建基塊（服務）。虛擬機監控程序可以分離不同安全級的功能，最高可達 ASIL D級，并支持持續的空中安全軟件更新。

ISOLAR-VRTE是一個用于開發自適應AUTOSAR應用程序和車輛計算機解決方案的架構設計工具。自適應AUTOSAR是一種新的汽車軟件標準，它可以讓您的汽車電子設備更加智能、靈活和安全。

ISOLAR-VRTE可以讓您設計和配置自適應AUTOSAR應用程序的功能、服務和通信，并生成標準的AUTOSAR清單文件。

ISOLAR-VRTE還提供了一些自動化和簡化的功能，比如代理/骨架生成器、應用程序設計編輯器、執行管理配置編輯器和SOME/IP配置編輯器。

RTA-VRTE SDK是一套用于構建和運行自適應AUTOSAR應用程序的軟件工具。

RTA-VRTE SDK包含運行庫和支持代碼。

*運行庫是一些預編譯的軟件模塊，它們實現了自適應AUTOSAR平臺的功能，比如通信、服務發現、診斷等。

*支持代碼是一些源代碼文件，它們可以幫助您創建和配置自適應AUTOSAR應用程序，比如代理、骨架、清單等。

RTA-VRTE SDK可以在不同的操作系統和硬件上運行，因為它是高度可移植和靈活的。它已經與QNX和Linux等合作伙伴的產品集成，也可以與其他供應商的產品兼容。

ISOLAR-VRTE和RTA-VRTE SDK是一套完整的自適應AUTOSAR開發環境，它可以讓您輕松地創建和測試基于AUTOSAR標準的應用程序。它們基于Eclipse技術和Artop AUTOSAR開放工具平臺，可以與其他第三方工具集成在定制環境中。

應用領域

適用于所有功能強大、基于微處理器的車輛計算機，例如 HAD/ADAS 和具有以下要求的連接應用：

1)AUTOSAR 自適應架構

2)一個控制單元上來自不同供應商且具有不同安全等級的軟件

3)軟件空中更新

4)高達 ASIL-D 級的安全攸關系統

5)車輛獨立軟件（應用商店）

6)車輛網絡安全要求

優點

1)OEM 和第 1 層能夠以可靠的 AUTOSAR 自適應一致性軟件框架（該框架也用于博世車輛計算機）為基礎，專注其核心業務；

2)早期預覽程序（包括 VRTE 軟件、軟件開發工具、培訓和咨詢）通過快速實施和測試新的 E/E 架構和 AUTOSAR 自適應應用，可以快速提升軟件能力；

3)可針對每個車輛 OEM 和軟件供應商提供客制化可升級解決方案；

4)ECU整個生命周期的服務，如集成支持、客戶特定調整、更新和升級管理。

工具鏈集成

ISOLAR-VRTE基于Eclipse技術和Artop AUTOSAR開放工具平臺。開發AUTOSAR Adaptive應用程序和車輛計算機解決方案的開發者可以從架構設計工具ISOLAR-VRTE和平臺軟件框架RTA-VRTE的組合中受益。

同樣，基于AUTOSAR Classic標準的ECU軟件開發者多年來一直從ETAS ISOLAR-A/B工具和ETAS RTA-CAR硬實時基本軟件的組合中受益。

與博世集團共同開發的RTA-VRTE結合了各領域的車輛軟件技術，包括E/E 架構、復雜實時軟件、物聯網和車輛硬件（車載和后端）。RTA-VRTE 與網絡安全結合，提供符合車輛要求的功能安全、實時行為和可靠性。

審核編輯：劉清