AUTOSAR AP方法論和開發(fā)流程的最佳實踐

一

Adaptive AUTOSAR 方法論

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

1、架構(gòu)和設(shè)計階段：

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

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

ARXML文件是AUTOSAR的標(biāo)準(zhǔn)格式，用于描述應(yīng)用程序的元數(shù)據(jù)和部署清單。這個階段的輸出是一個系統(tǒng)配置描述（SCD），它展示了系統(tǒng)的靜態(tài)和動態(tài)特征。

2、軟件開發(fā)階段：

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

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

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

3、集成和部署階段：

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

二

AUTOSAR APApplication開發(fā)流程

自適應(yīng)AUTOSAR開發(fā)方法論包括以下幾個步驟:

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

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

(3)、應(yīng)用設(shè)計：定義和配置軟件組件（SWC），以及它們之間和網(wǎng)絡(luò)之間的數(shù)據(jù)映射和服務(wù)映射。

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

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

(6)、Machine設(shè)計：定義Machine的屬性和配置，以及Machine之間的通信結(jié)構(gòu)。

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

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

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

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

2.1 如何使用C++開發(fā)自適應(yīng)應(yīng)用程序？

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

（1)、定義系統(tǒng)的需求、功能和服務(wù)，并將它們分配到合適的目標(biāo)設(shè)備上。

（2)、設(shè)計系統(tǒng)的架構(gòu)和接口，并生成相應(yīng)的配置文件和元數(shù)據(jù)文件。

（3)、編寫C++代碼來實現(xiàn)系統(tǒng)的功能和邏輯，并遵循相應(yīng)的編碼規(guī)范和風(fēng)格。

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

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

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

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

2.2如何在AP AUTOSAR中實現(xiàn)服務(wù)間的通信?

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

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

然后，需要在應(yīng)用程序中創(chuàng)建代理（Proxy）和骨架（Skeleton）對象，分別用于調(diào)用和提供服務(wù)。代理和骨架對象都需要指定服務(wù)標(biāo)識和實例標(biāo)識，以唯一地標(biāo)識一個服務(wù)實例。

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

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

2.3AA的幾個術(shù)語

Adaptive application （AA）

承載Service的應(yīng)用實體

Executable

App的運行時實體，一個可執(zhí)行程序可以包含多個服務(wù)實例

Process

OS運行調(diào)度的實體

Machine

運行環(huán)境的物理資源

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

通過正式定義的接口來使用服務(wù)

實現(xiàn)服務(wù)有三種方式Event Method Field

定義服務(wù)傳輸?shù)臄?shù)據(jù)類型

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

三

自適應(yīng)應(yīng)用程序設(shè)計

3.1 AA開發(fā)流程

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

（1）獲得：系統(tǒng)設(shè)計文檔

-定義應(yīng)用系統(tǒng)中的各APP、及其之間的通信關(guān)系

-定義APP與AP平臺Foundation和Service模塊的交互關(guān)系

-定義APP的運行部署環(huán)境

（2）ARXML文件生成

-根據(jù)設(shè)計人員的使用習(xí)慣，自行選擇工具即可

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

AUTOSAR工具通常會提供代碼自動生成工具，如：根據(jù)AUTOSAR AP R21-11,生成代碼的語言標(biāo)準(zhǔn)兼容c++11和c++14。

3.2 AA的設(shè)計和建模：

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

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

3.3 服務(wù)接口的定義

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

接口是以中立的方式定義的，不依賴于服務(wù)實現(xiàn)的硬件平臺、操作系統(tǒng)和編程語言。這使得在各種系統(tǒng)上構(gòu)建的服務(wù)可以以一種統(tǒng)一和通用的方式互動。

例如：定義一個圖示的應(yīng)用服務(wù)接口設(shè)計：

RTA-VRTE DSL is used for the Application Design

3.4 基于服務(wù)接口ARXML文件的代碼生成

基于服務(wù)的定義生成應(yīng)用程序組件頭文件

用于服務(wù)發(fā)現(xiàn)的Skeletons (offer, register, …)

服務(wù)發(fā)現(xiàn)Proxy (discovery, subscribe,…)

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

用于方法實現(xiàn)和事件發(fā)布的Skeletons (server)

實現(xiàn)和編譯軟件組件

此步驟獨立于服務(wù)實例的定義

開發(fā)可執(zhí)行文件的主要功能

3.5 Adaptive AUTOSAR 應(yīng)用的可執(zhí)行文件

為自適應(yīng)平臺配置和生成序列化代碼 鏈接軟件組件、主函數(shù)、序列化代碼和中間件庫，以構(gòu)建可執(zhí)行的應(yīng)用程序。

構(gòu)建AA的可執(zhí)行文件，需要幾方面的輸入：

服務(wù)接口定義后根據(jù)配置生成的代碼

AA應(yīng)用層代碼實現(xiàn)

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

AA進程依賴的配置文件

一個可執(zhí)行文件是應(yīng)用程序的一部分，它有一個入口點（主函數(shù)）。

一個應(yīng)用程序可以由一個或多個可執(zhí)行文件實現(xiàn)。

3.6 Adaptive AUTOSAR執(zhí)行管理的配置

3.6.1 創(chuàng)建可執(zhí)行文件

可以為單個目標(biāo)ECU定義多個可執(zhí)行文件。一旦創(chuàng)建可執(zhí)行文件，可以通過選擇新創(chuàng)建的可執(zhí)行文件的名稱在執(zhí)行編輯器中打開可執(zhí)行文件。

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

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

Executable Path:可執(zhí)行文件的路徑（在目標(biāo)ECU上）。

Executable Version:可執(zhí)行文件的版本。版本字符串應(yīng)遵循AUTOSAR的強修訂標(biāo)簽格式：（MajorVersion. MinorVersion. PatchVersion. BuildInformation）。

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

3.6.2創(chuàng)建進程

在自適應(yīng)平臺中，進程元素代表一個獨立的可執(zhí)行實例。一個單一的可執(zhí)行文件可以在多個進程中實例化。每個進程必須有一個名稱和一個清單文件。在其中可以設(shè)置進程元素和功能組狀態(tài)。

General：定義總體屬性?？蓤?zhí)行文件定義了關(guān)聯(lián)的可執(zhí)行元素（多個進程可以引用同一個可執(zhí)行文件）。

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

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

*可配置的UID必須存在于部署目標(biāo)中。

*可配置的GID必須存在于部署目標(biāo)中。

Arguments ：定義啟動進程時使用的命令行參數(shù)和環(huán)境變量。

Scheduling ：定義特定于進程的調(diào)度參數(shù)。

Logging & Tracing：為此進程定義應(yīng)用程序ID、默認(rèn)日志級別等。

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

Others：定義RTA-VRTE Starter Kit特定配置，包括函數(shù)集群關(guān)聯(lián)和終止配置。

3.6.3軟件集群包含的進程

每個進程的引用必須添加到相關(guān)的軟件集群。如果ContainedProcess為空，F(xiàn)latCFG文件將無法正確生成。

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

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

3.7應(yīng)用程序設(shè)計與執(zhí)行清單的關(guān)系

Adaptive autosar應(yīng)用程序是由Adaptive Application SWC（Software Component）組成的軟件架構(gòu)，它實現(xiàn)了服務(wù)接口的功能。

在自適應(yīng)平臺中，可執(zhí)行配置元素將可執(zhí)行代碼與SWC組件原型關(guān)聯(lián)起來。

執(zhí)行清單是一種描述應(yīng)用部署相關(guān)信息的文件，它和可執(zhí)行代碼綁定，包括應(yīng)用程序的名稱、版本、依賴關(guān)系、啟動順序等。每一個可執(zhí)行程序都可以在Execution Editor中創(chuàng)建一個執(zhí)行清單，執(zhí)行清單根據(jù)應(yīng)用程序的設(shè)計生成，反映了應(yīng)用程序的部署信息，指導(dǎo)了應(yīng)用程序在機器上的運行。

3.8 Adaptive AUTOSAR 開發(fā)方法論小結(jié)

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

（2)、在AP工具鏈/應(yīng)用設(shè)計工具中定義服務(wù)，如數(shù)據(jù)類型、服務(wù)接口、SWC組件等

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

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

（3)、軟件開發(fā)

a) Service應(yīng)用實現(xiàn) Skeleton的接口

b) Client 應(yīng)用通過 Proxy 類（經(jīng)由 COM）間接調(diào)用 Service

c) 編譯生成可執(zhí)行文件

（4)、軟件集成

在 AP 工具鏈/可執(zhí)行文件配置工具中配置可執(zhí)行文件路徑、實例（進程）數(shù)、啟動參數(shù)、環(huán)境變量、調(diào)度策略、UID/GID 等信息，生成Execution Manifest

（5)、AP工具鏈提取

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

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

a) 目標(biāo)硬件中SW Configuration Management 根據(jù) Manifest 信息部署、驗證、安裝應(yīng)用。

b) 根據(jù) AP 平臺的實現(xiàn)，可以（不強制）預(yù)處理 Manifest 文件，如導(dǎo)入數(shù)據(jù)庫，以提高執(zhí)行效率

c) EM 根據(jù) Execution Manifest的信息調(diào)用OS接口啟動、配置、關(guān)閉應(yīng)用（FC 以及 AA）

四

Adaptive AUTOSAR Working with ARXML

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

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

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

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

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

?Machine相關(guān)的信息保存在一個文件中

?可執(zhí)行文件信息保存在另一個文件中

哪些配置可以拆分？

?由AUTOSAR定義的

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

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

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

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

這個示例中，有兩個ARXML文件，分別包含兩個package。每個package指定了一個EL類型的元素。第一個文件中的packageB包含了EL1和EL2的定義，第二個文件中的packageB包含了EL3和EL4的定義。因為packageB是可分割的，所以工具會合并兩個文件中的packageB的定義，形成一個完整的packageB元素。但是，工具不會改變兩個文件的內(nèi)容，它們?nèi)匀槐３衷瓉淼臉幼印?/p>

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

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

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

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

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

?XML中的標(biāo)簽區(qū)分大小寫，并且對應(yīng)的開始標(biāo)簽和結(jié)束標(biāo)簽必須大小寫一致。

?XML元素需正確嵌套，并且標(biāo)簽需成對。

?XML的屬性值須加引號。

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

? ? ? ?

五

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

配備微處理器的車輛計算機是未來網(wǎng)絡(luò)化和自動化駕駛 E/E 架構(gòu)的核心組件。其先決條件是安全可靠的平臺軟件框架，使得車輛制造商和服務(wù)提供商能夠?qū)Ｗ⒂诠δ堋?/p>

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

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

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

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

4)支持軟件和服務(wù)領(lǐng)域的新商業(yè)模式。

此外，還需滿足傳統(tǒng)的車輛要求：

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

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

3)具有成本效益 ；

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

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

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

ISOLAR-VRTE是一個用于開發(fā)自適應(yīng)AUTOSAR應(yīng)用程序和車輛計算機解決方案的架構(gòu)設(shè)計工具。自適應(yīng)AUTOSAR是一種新的汽車軟件標(biāo)準(zhǔn)，它可以讓您的汽車電子設(shè)備更加智能、靈活和安全。

ISOLAR-VRTE可以讓您設(shè)計和配置自適應(yīng)AUTOSAR應(yīng)用程序的功能、服務(wù)和通信，并生成標(biāo)準(zhǔn)的AUTOSAR清單文件。

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

RTA-VRTE SDK是一套用于構(gòu)建和運行自適應(yīng)AUTOSAR應(yīng)用程序的軟件工具。

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

*運行庫是一些預(yù)編譯的軟件模塊，它們實現(xiàn)了自適應(yīng)AUTOSAR平臺的功能，比如通信、服務(wù)發(fā)現(xiàn)、診斷等。

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

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

ISOLAR-VRTE和RTA-VRTE SDK是一套完整的自適應(yīng)AUTOSAR開發(fā)環(huán)境，它可以讓您輕松地創(chuàng)建和測試基于AUTOSAR標(biāo)準(zhǔn)的應(yīng)用程序。它們基于Eclipse技術(shù)和Artop AUTOSAR開放工具平臺，可以與其他第三方工具集成在定制環(huán)境中。

應(yīng)用領(lǐng)域

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

1)AUTOSAR 自適應(yīng)架構(gòu)

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

3)軟件空中更新

4)高達 ASIL-D 級的安全攸關(guān)系統(tǒng)

5)車輛獨立軟件（應(yīng)用商店）

6)車輛網(wǎng)絡(luò)安全要求

優(yōu)點

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

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

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

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

工具鏈集成

ISOLAR-VRTE基于Eclipse技術(shù)和Artop AUTOSAR開放工具平臺。開發(fā)AUTOSAR Adaptive應(yīng)用程序和車輛計算機解決方案的開發(fā)者可以從架構(gòu)設(shè)計工具ISOLAR-VRTE和平臺軟件框架RTA-VRTE的組合中受益。

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

與博世集團共同開發(fā)的RTA-VRTE結(jié)合了各領(lǐng)域的車輛軟件技術(shù)，包括E/E 架構(gòu)、復(fù)雜實時軟件、物聯(lián)網(wǎng)和車輛硬件（車載和后端）。RTA-VRTE 與網(wǎng)絡(luò)安全結(jié)合，提供符合車輛要求的功能安全、實時行為和可靠性。

審核編輯：劉清