AUTOSAR

**AUTOSAR**（汽車開放系統架構）合作夥伴關係成立於 2003 年，是一種面向汽車行業內各組織的開發夥伴關係。該聯盟為汽車電子控制裝置開發開放的、標準化的軟體架構。

## 歷史

AUTOSAR 由寶馬集團（BMW）、博世公司（Bosch）、大陸集團（Continental）、戴姆勒 - 克萊斯勒公司（DaimlerChrysler）、西門子威迪歐（Siemens VDO）汽車電子公司以及大眾公司（Volkswagen）於 2003 年 7 月聯合建立，旨在為汽車電氣 / 電子構架開發一套開放的行業標準。2003 年福特汽車公司（Ford Motor Company）加入聯盟，成為其核心成員。2003 年 12 月，標緻雪鐵龍汽車公司（Peugeot Citroën Automobiles S.A.）和豐田汽車公司（Toyota Motor Corporation）加入聯盟。2004 年 11 月通用汽車公司（General Motors）成為其核心成員 。

2008 年 2 月，西門子威迪歐（Siemens VDO）汽車電子公司被大陸集團（Continental）收購，不再是 AUTOSAR 獨立核心成員。

自 2003 年起，AUTOSAR 共推出了四版主要的標準化汽車軟體構架和一個驗收測試版。AUTOSAR 的開發成果可以分為三個階段：

* 第一階段（2004-2006）：標準規範的初步開發階段（1.0、2.0 和 2.1 版）
* 第二階段（2007-2009）：標準規範中的架構及其方式的補充階段（3.0、3.1 和 4.0 版）
* 第三階段（2010-2013）：維持和部分改進階段（3.2、4.1 和 4.2 版）

2013 年 AUTOSAR 始終努力維持著現有標準規範，並對部分標準加以改進（包括 R4.2 版和驗收測試標準 1.0）。

2016 年，AUTOSAR 開始著手自適應平台的開發工作。 2017 年初發布首個版本（17-03），2017 年 10 月和 2018 年 3 月相繼發布版本 17-10 和 18-03。 其目標是在 2018 年 10 月聯合發布 AUTOSAR 經典平台、自適應平台和基礎，以此為節點結束主要開發活動。

## 理念

AUTOSAR 制訂一系列標準規範，包括基礎軟體模塊規範介紹、應用接口定義規範以及基於標準轉換形式建立一套通用的開發方法論，以應用於不同廠家生產的車輛以及不同供應商提供的電子部件。

## 軟體架構

AUTOSAR 採用三層架構：

* 基礎軟體：標準化的軟體模塊（大多數），本身並不參加實際工作，但能夠為上層軟體功能正常運行提供必需服務 。
* 運行環境（RTE）：源自網絡撲拓結構中的中介軟體，用以實現 ECU 內部及不同 ECU 間的通信交換（應用軟體組件之間以及基礎軟體和應用軟體之間）。
* 應用層：應用軟體組件與運行環境相輔相成。

## AUTOSAR 方法論

* 系統配置描述：包含所有系統信息以及不同 ECU 之間約定的信息（例如匯流排信號的定義）。
* ECU 信息抽取：包含從系統配置描述抽取的特定 ECU 所需要的信息（例如特定 ECU 獲取的信號）。
* ECU 配置描述：包含特定 ECU 所需要的所有基礎軟體配置信息。 根據這些信息生成執行軟體、基礎軟體模塊代碼以及軟體組件代碼。

## 經典平台

AUTOSAR 經典平台（Classic Platform） 是基於 OSEK 標準的嵌入式實時 ECU 標準。 其可交付成果主要為規範。 
AUTOSAR 經典平台架構區分了在微控制器上運行的應用、運行時環境（RTE）和基礎軟體（BSW）這三個軟體層之間的最高抽象級。 應用軟體層基本獨立於硬體。 軟體組件之間通過 RTE 進行通信，訪問 BSW 也必須通過 RTE，RTE 可視為應用程式的完整接口。

BSW 分為三個主要層次並具有複雜的驅動因素：

* 服務層， 2016
* ECU（電子控制單元）抽象層和 2016
* 微控制器抽象層。2016

服務層劃分為代表系統、內存和通信服務基礎設施的多個功能組。

經典平台的一個基本概念是虛擬功能匯流排（VFB）。 該虛擬匯流排是尚未部署到特定 ECU 的 RTE 抽象集，這些 RTE 將應用程式與基礎架構分離。 它通過專用埠進行通信，這意味著應用軟體的通信接口必須映射到這些埠。 VFB 處理單個 ECU 內和多個 ECU 之間的通信。 從應用程式角度來看，不需要了解有關低級別技術或依賴關係的詳細知識。 這樣就使得應用軟體的開發和使用無需依賴硬體進行。

經典平台還可以使用 Franca 接口描述語言（IDL）集成 GENIVI 等非 AUTOSAR 系統。

## 自適應平台

為適應新用例的需求，AUTOSAR 開發了自適應平台（Adaptive Platform）。 一個突出的例子是

高度自動化駕駛，在該環境中，駕駛員暫時和 / 或部分地將駕駛責任轉移給車輛。 這種情況下需要與交通基礎設施（例如交通標誌、交通燈）、雲伺服器（例如訪問最新的交通信息或地圖數據）等進行通信，或使用微處理器和高性能計算硬體進行並行處理（例如 GPU）。

此外，Car-2-X 應用還需要與車輛和車外系統進行交互溝通。 這意味著該系統必須具備安全的車載通信功能、支持跨域計算平台、智慧型手機集成、非 AUTOSAR 系統集成等。 此外，還需要採取專門的措施，保證雲服務的安全，例如安全雲交互和應急車輛優先。 它們可支持遠程和分布式服務，例如遠程診斷、空中下載（OTA）更新、修復和交換處理。

AUTOSAR 目前正在對 AUTOSAR 自適應平台進行標準化處理，使其支持客戶應用的動態部署，並為需要高端計算能力的應用提供適宜的環境。 該平台的核心是基於 POSIX 標準的作業系統。 根據 IEEE1003.13（即 PSE51），作業系統可以通過 POSIX 的子集從應用中調用。 自適應平台的一個關鍵特性是面向服務的通信。

自適應平台可以使用兩種類型的接口：服務和應用程式編程接口（API）。 該平台由分布在服務層中的功能聚類和 AUTOSAR 自適應平台基礎組成。

功能聚類：

* 彙編自適應平台的功能 2016
* 確定需求規格說明書的聚類 2016
* 從應用和網絡角度描述軟體平台的行為 2016
* 但是，不得限制實現自適應平台的架構的最終軟體設計。2016

AUTOSAR 自適應平台基礎中的功能聚類在每台（虛擬）機器中必須至少有一個實例，而服務則可以分布在車內網絡中。

自適應平台服務包括：

* 更新和配置管理
* 狀態管理
* 網絡管理
* 診斷

AUTOSAR 自適應平台包含規範和代碼。 與經典平台相比，AUTOSAR 開發的實現可縮短驗證周期並說明基本概念。 該實現適用於所有 AUTOSAR 成員。

## 基礎

基礎標準的目的是加強 AUTOSAR 平台之間的互操作性。 基礎包含 AUTOSAR 平台之間共享的通用需求和技術規範（例如協議）以及常用方法。

## 驗收測試

為了降低測試的工作量及測試成本，AUTOSAR 驗收測試規範於 2014 年應運而生。 驗收測試規範實則為利用相應平台指定接口的系統測試規範。 另外也考慮了在匯流排上的指定行為。 可將其視為針對特定平台功能的黑盒測試用例。 標準驗收測試規範有助於實現以上目標。

## 標準化應用接口

AUTOSAR 以製造商和供應商之間功能性接口的標準化以及軟體各分層接口的標準化為基礎，實現其技術目標。

## 組織結構

AUTOSAR 入會形式分為五種。 成員合作方式不同，身份職責也不同： [14]

* 核心合作夥伴 2016
* 高級合作夥伴 2016
* 一般合作夥伴 2016
* 開發合作夥伴 2016
* 觀察員 2016

核心合作夥伴有寶馬、博世、大陸、戴姆勒、福特、通用汽車、標緻雪鐵龍、豐田和大眾等 9 位創立成員。 [15] 這些公司主要負責 AUTOSAR 開發聯盟的組織、管理和調控。 [14] 其中，執行董事會負責制定全局策略和整體發展路線圖。 [16] 指導委員會負責處理非技術性日常事務、會員入會、公共關係以及合約問題。 [17] 指導委員會任命主席和副主席，任期為九個月。  AUTOSAR 發言人負責外聯工作。 

高級合作夥伴和開發合作夥伴在核心合作夥伴組建的項目領導小組的協調和監督下開展工作。 一般成員根據 AUTOSAR 已發布的標準文件開展工作。 觀察員目前以學術合作和非商業項目的形式參與聯盟活動。

截至 2018 年 2 月，AUTOSAR 開發聯盟的成員公司已超過 200 家。

## 參見

## 外部連結

* 官方網站