如下展示了AUTOSAR的目標(biāo)、主要挑戰(zhàn)和解決方案以及這些解決方案所帶來的好處。

• 處理與系統(tǒng)相關(guān)的快速增長的電氣/電子復(fù)雜性；

• 產(chǎn)品修改、升級和更新的實(shí)施靈活性；

• 提高軟件解決方案的可擴(kuò)展性和交叉兼容性；

• 提高系統(tǒng)的軟件質(zhì)量和可靠性；

• 在早期開發(fā)階段啟用錯(cuò)誤檢測。

AUTOSAR 架構(gòu)

Autosar架構(gòu)的意義

現(xiàn)代車輛中電子/電氣系統(tǒng)的數(shù)量和這些系統(tǒng)的復(fù)雜性正在增加。車輛網(wǎng)絡(luò)日益復(fù)雜是 AUTOSAR 發(fā)展背后的動(dòng)力。

現(xiàn)代車輛每輛都有 一百多個(gè) ECU 。它們中的每一個(gè)都有大量的功能。不遵循標(biāo)準(zhǔn)，當(dāng)ECU硬件設(shè)計(jì)改變時(shí)，軟件開發(fā)最有可能要重寫。

AUTOSAR 的應(yīng)用范圍專用于汽車 ECU，并具有以下特性：

• 與硬件（傳感器和執(zhí)行器）的強(qiáng)交互，

• 連接到車輛網(wǎng)絡(luò)，如 CAN、LIN、FlexRay 或以太網(wǎng)，

• 計(jì)算能力和內(nèi)存資源有限的微控制器。

• 時(shí)間關(guān)鍵的系統(tǒng)和實(shí)時(shí)程序從內(nèi)部存儲器執(zhí)行。

分層 Autosar 架構(gòu)概述

AUTOSAR 架構(gòu)在三個(gè)軟件層之間的最高抽象級別上進(jìn)行了區(qū)分：應(yīng)用層，運(yùn)行時(shí)環(huán)境，基礎(chǔ)軟件。

應(yīng)用層

應(yīng)用層是 AUTOSAR 軟件架構(gòu)的最頂層，支持自定義功能實(shí)現(xiàn)。該層由特定的軟件組件和許多應(yīng)用程序組成，它們是一組相互連接的 AUTOSAR 軟件組件，并按照指令執(zhí)行特定任務(wù)。

每個(gè) AUTOSAR 軟件組件都封裝了完整應(yīng)用軟件的部分功能。AUTOSAR 沒有規(guī)定 AUTOSAR 軟件組件有多大。根據(jù)應(yīng)用程序的要求，AUTOSAR 軟件組件可能是一個(gè)小型的、可重復(fù)使用的功能，例如車道保持輔助、雨刷控制、自動(dòng)門解鎖等。

軟件組件之間的通信是通過使用虛擬功能總線的特定端口實(shí)現(xiàn)的。這些端口還可以實(shí)現(xiàn)軟件組件和 AUTOSAR 基礎(chǔ)軟件 (BSW) 之間的通信。

• 客戶端-服務(wù)端通信：客戶端可以通過支持操作的服務(wù)端發(fā)起操作的執(zhí)行，服務(wù)端執(zhí)行操作并立即將結(jié)果提供給客戶端（同步操作調(diào)用）。

• 發(fā)送者-接收者通信：這是一種異步通信模式，其中發(fā)送者提供一個(gè)或多個(gè)接收者所需的數(shù)據(jù)。

RTE 層為應(yīng)用軟件組件提供獨(dú)立于 ECU 的接口，為應(yīng)用軟件組件(SWC)提供通信服務(wù)。

• 客戶端/服務(wù)端端口，其中服務(wù)端是服務(wù)的提供者，客戶端是服務(wù)的用戶。
• 發(fā)送方/接收方端口，發(fā)送方將信息發(fā)送到一個(gè)或多個(gè)接收方。

AUTOSAR 基礎(chǔ)軟件 ( BSW ) 進(jìn)一步分為三層：

• 服務(wù)層，

• ECU抽象層，

• 微控制器抽象和復(fù)雜設(shè)備驅(qū)動(dòng)程序 (CDD)。

每一層都有不同的功能模塊，不同層之間的模塊交互都是指定的。

微控制器抽象層是基礎(chǔ)軟件的最底層，這意味著 MCAL 模塊可以直接訪問硬件資源。MCAL 包含內(nèi)部驅(qū)動(dòng)程序，這些驅(qū)動(dòng)程序是直接訪問 μC 和內(nèi)部外圍設(shè)備的軟件模塊。

顧名思義，MCAL 層使上層獨(dú)立于 HW（MCU）。

• 操作系統(tǒng)功能
• 車聯(lián)網(wǎng)通訊及管理服務(wù)
• 內(nèi)存服務(wù)（NVRAM 管理）
• 診斷服務(wù)（UDS、錯(cuò)誤處理、內(nèi)存）
• ECU狀態(tài)管理、模式管理
• 邏輯和時(shí)間程序流監(jiān)控（WdgM）

AUTOSAR COM模塊詳細(xì)說明

本節(jié)列出了 AUTOSAR COM 模塊所有功能模塊。有關(guān) AUTOSAR COM 模塊在通信堆棧中的放置，請參閱下圖。

該模塊是AUTOSAR MCAL層的一部分（例如：CanDrv，LinDrv，F(xiàn)rDrv），它實(shí)際上與ECU的底層硬件進(jìn)行交互，并為其上層提供獨(dú)立于硬件的接口。此模塊取決于硬件，并且驅(qū)動(dòng)程序代碼可能會(huì)根據(jù)基礎(chǔ)硬件而有所不同。BusIf是唯一可以訪問此總線驅(qū)動(dòng)程序的模塊。

多核微控制器的分層軟件架構(gòu)

隨著汽車領(lǐng)域?qū)τ?jì)算資源的需求越來越高，OEM和Tier 1正在逐步引入多核 ECU 在其電子架構(gòu)中的使用。此外，這些多核 ECU為新功能的引入提供了基礎(chǔ)， 例如功能安全要求的實(shí)施。

AUTOSAR 4.0 版引入了對多核嵌入式 RTOS 的支持。AUTOSAR 4.0 規(guī)范中引入了多核啟動(dòng)/關(guān)閉、核間通信 (IOC) 等新概念，以擴(kuò)展單核操作系統(tǒng)規(guī)范。

改進(jìn)后的 Autosar 架構(gòu)如下所示：

功能安全

系統(tǒng)的安全性取決于特定功能的預(yù)期操作。功能安全標(biāo)準(zhǔn) ISO26262 源自 IEC-61508，指導(dǎo)我們采用基于汽車特定風(fēng)險(xiǎn)的方法來開發(fā)電氣和電子 (E/E) 系統(tǒng)。功能安全的目標(biāo)是正確執(zhí)行預(yù)期操作，否則系統(tǒng)將發(fā)生故障并轉(zhuǎn)移到可預(yù)測的安全狀態(tài)。軟件是影響系統(tǒng)級復(fù)雜性的參數(shù)之一。可以使用軟件開發(fā)的新技術(shù)和概念來最小化復(fù)雜性，從而有助于實(shí)現(xiàn)功能安全。AUTOSAR R4.0 考慮了對現(xiàn)代汽車軟件開發(fā)很重要的功能安全方面。

Autosar下有很多開發(fā)方法來檢測和報(bào)告軟件開發(fā)每個(gè)階段的功能錯(cuò)誤。即使功能安全在整個(gè)產(chǎn)品開發(fā)的每個(gè)階段都適用并遵循，直到涉及到用戶。

以下是導(dǎo)致 E2E 保護(hù)檢測到的錯(cuò)誤的典型干擾源列表：

SW相關(guān)來源：

S1。大多數(shù)生成的 RTE 中的錯(cuò)誤，

S2。部分生成和部分手動(dòng)編碼的 COM 中的錯(cuò)誤

S3. 網(wǎng)絡(luò)堆棧錯(cuò)誤

S4. 生成的 IOC 或 OS 出錯(cuò)

硬件相關(guān)資源：

H1。硬件網(wǎng)絡(luò)故障

H2。網(wǎng)絡(luò)電磁干擾

H3. 上下文切換期間或內(nèi)核之間通信時(shí)的微控制器故障

開發(fā) SWC 接口時(shí)采用的一個(gè)實(shí)用方法示例是為數(shù)據(jù)正確性提供端到端保護(hù)。

對于每個(gè)傳輸安全相關(guān)數(shù)據(jù)的 RTE Write 或 Read 函數(shù)（如 Rte_Write_<p>_<o>()），都有對應(yīng)的 E2E 保護(hù)封裝函數(shù)。

1. 封裝函數(shù)調(diào)用 AUTOSAR E2E 庫。

2. 包裝函數(shù)是軟件組件的一部分，最好是生成的。

3. 封裝函數(shù)與相應(yīng)的 RTE 函數(shù)具有相同的簽名，只是代替Rte_ 的是E2EPW_。

4. E2EPW_ 函數(shù)由 SW-C 的應(yīng)用邏輯調(diào)用，封裝函數(shù)執(zhí)行保護(hù)/檢查并在內(nèi)部調(diào)用 RTE 函數(shù)。

5. 對于 ECU 間通信，通過 E2E 保護(hù)發(fā)送的數(shù)據(jù)元素是按字節(jié)數(shù)組。字節(jié)數(shù)組被復(fù)制到 COM I-PDU 而不做任何更改。

ECU 設(shè)計(jì)和配置方法

AUTOSAR 為系統(tǒng)開發(fā)步驟提供了一種通用的技術(shù)方法。該圖顯示了使用 AUTOSAR 技術(shù)構(gòu)建 ECU 的設(shè)計(jì)步驟概覽。這意味著必須為系統(tǒng)中的每個(gè) ECU 執(zhí)行這些步驟。

需要注意的是，AUTOSAR 沒有規(guī)定執(zhí)行開發(fā)活動(dòng)的精確順序。Autosar 既不講述流程，也不講述商業(yè)模式和“角色”和“責(zé)任”。

下圖是通常遵循的工作流程的示例。下圖分別描述了 BSW 和應(yīng)用軟件的開發(fā)流程。

此階段的主要活動(dòng)是從系統(tǒng)配置描述中提取特定于 ECU 的信息、ECU 配置以及可執(zhí)行 ECU 軟件的生成。以下部分將更詳細(xì)地描述這些活動(dòng)。

提取特定于 ECU 的信息

AUTOSAR ECU Configuration Extractor工具（例如 System Desk，Da-Vinci）從特定 ECU 所需的系統(tǒng)配置描述中提取信息。這是映射到此特定 ECU 的系統(tǒng)配置描述的所有元素的一對一副本。輸出是系統(tǒng)配置的 ECU 摘錄。網(wǎng)絡(luò)數(shù)據(jù)庫（例如 CAN.dbc）文件是生成 ECU 提取物 (.arxml) 的輸入。

配置（BSW）ECU

ECU 配置主要處理RTE 和基礎(chǔ)軟件模塊的配置。該配置基于系統(tǒng)配置的 ECU 摘錄中可用的參數(shù)?？捎?SWC 實(shí)現(xiàn)和 BSW 模塊描述的集合。BSW 還包含供應(yīng)商特定的 ECU 配置。這是必要的，因?yàn)檩敵?ECU 配置描述具有靈活的結(jié)構(gòu)，在 ECU 提取時(shí)不定義固定數(shù)量的配置參數(shù)。

必須在 BSW 配置期間定義通信模塊、MCAL、操作系統(tǒng)或 AUTOSAR 服務(wù)。

軟件組件實(shí)現(xiàn)

SWC 的初始工作從提供軟件組件描述 [SWCTempl] 的必要部分開始。即組件內(nèi)部行為描述作為軟件組件相關(guān)模板的一部分。內(nèi)部行為描述了組件的調(diào)度相關(guān)方面，即可運(yùn)行實(shí)體及其響應(yīng)的事件。此外，行為指定組件（或更準(zhǔn)確地說是哪個(gè)可運(yùn)行組件）如何響應(yīng)接收到的數(shù)據(jù)元素等事件。但是，它沒有描述組件的詳細(xì)功能行為。