一、AUTOSAR的背景介紹

AUTOSAR是AUTOmotive Open System Architecture（汽車開放系統(tǒng)架構(gòu)）的首字母縮寫，是由全球各大汽車整車廠、汽車零部件供應(yīng)商、汽車電子軟件系統(tǒng)公司聯(lián)合建立的一套標準協(xié)議，是對汽車技術(shù)開發(fā)一百多年來的經(jīng)驗總結(jié)。從2003年起，擬定了一個符合汽車電子軟件開發(fā)的、開放的以及標準化的軟件架構(gòu)。該架構(gòu)旨在改善汽車電子系統(tǒng)軟件的更新與交換，同時更方便有效地管理日趨復(fù)雜的汽車電子軟件系統(tǒng)。AUTOSAR規(guī)范的運用使得不同結(jié)構(gòu)的電子控制單元的接口特征標椎化，應(yīng)用軟件具備更好的可擴展性以及可移植性，能夠?qū)崿F(xiàn)對現(xiàn)有軟件的重用，大大降低了重復(fù)性工作，縮短開發(fā)周期。

AUTOSAR成員之間開展合作的主要目標是：使基本系統(tǒng)功能以及接口標椎化，使軟件開發(fā)合作伙伴之間能交換、轉(zhuǎn)換和集成各自的車載網(wǎng)絡(luò)功能，最大限度地提高車輛售后的軟件更新和系統(tǒng)升級效率。有了這個標準，AUTOSAR可以把范例從一個基于ECU的系統(tǒng)轉(zhuǎn)移到基于功能的系統(tǒng)進行設(shè)計開發(fā)，統(tǒng)籌技術(shù)和經(jīng)濟方面對不斷增長的E/E復(fù)雜性的汽車軟件開發(fā)的管理。由于AUTOSAR提倡“在標準上合作，在實現(xiàn)上競爭”的原則，其核心思想是“統(tǒng)一標準、分散實施、集中配置”，所以采用AUTOSAR將為OEM帶來很多好處，使得他們對于軟件采購和控制擁有更大和更靈活的權(quán)利。軟件系統(tǒng)的開放化和標準化將使更多的軟件供應(yīng)商進入汽車電子軟件行業(yè)，OEM將有更多的選擇，這將有利于提高軟件產(chǎn)品的質(zhì)量。

AUTOSAR的計劃目標主要有三個：

• 1）建立分層的體系架構(gòu)
• 2）為應(yīng)用程序的開發(fā)提供方法論
• 3）制定各種應(yīng)用接口規(guī)范

二、AUTOSAR的分層模型

為了實現(xiàn)應(yīng)用程序和硬件模塊之間的分離，AUTOSAR架構(gòu)被抽象成四層，由上至下依次為：應(yīng)用層（Application Layer）、運行時環(huán)境層（Run Time Environment，即RTE）、基礎(chǔ)軟件層（Basic Software，即BSW），以及微控制器層（Microcontroller）。如下圖所示。

AUTOSAR軟件體系結(jié)構(gòu)包含了完全獨立于硬件的應(yīng)用層（APP）和與硬件相關(guān)的基礎(chǔ)軟件層（BSW），并在兩者中間設(shè)立了一個運行時環(huán)境（RTE），從而使兩者分離，形成了一個分層體系架構(gòu)。RTE是專門為應(yīng)用軟件（AUTOSAR軟件組件和/或AUTOSAR傳感器/執(zhí)行器組件）提供通信服務(wù)的層。在RTE之上，軟件架構(gòu)風格從“分層”轉(zhuǎn)變?yōu)椤敖M件風格”。AUTOSAR軟件組件通過RTE與其他組件（內(nèi)部和/或內(nèi)部ECU）或服務(wù)進行通信。所以，這樣的分層結(jié)構(gòu)帶來兩個最大的好處，一方面，OEM可以專注于開發(fā)特定的、有競爭力的應(yīng)用層軟件（位于RTE之上），另一方面，它使OEM所不關(guān)心的基礎(chǔ)軟件層（位于RTE之下）得到標準化。

三、AUTOSAR的方法論

AUTOSAR為汽車電子軟件系統(tǒng)開發(fā)過程定義了一套通用的技術(shù)方法，即AUTOSAR方法論。該方法描述了從系統(tǒng)底層配置到ECU可執(zhí)行代碼產(chǎn)生過程的設(shè)計步驟，如下圖所示。

AUTOSAR設(shè)計和開發(fā)流程分為三個階段：系統(tǒng)配置、ECU設(shè)計與配置階段、代碼生成階段。

• 第一階段：定義系統(tǒng)配置文件，這是系統(tǒng)設(shè)計者或架構(gòu)師的任務(wù)。包括選擇硬件和軟件組件，定義整個系統(tǒng)的約束條件。AUTOSAR通過使用信息交換格式和模板描述文件來減少初始系統(tǒng)設(shè)計時的工作量。系統(tǒng)配置的輸入是XML類型的文件，輸出是系統(tǒng)配置描述文件，系統(tǒng)配置的主要作用是把軟件組件的需求映射到ECU上。
• 第二階段：根據(jù)系統(tǒng)配置描述文件提取單個ECU資源相關(guān)的信息，提取出來的信息生成ECU提取文件。根據(jù)這個提取文件對ECU進行配置，例如操作系統(tǒng)任務(wù)調(diào)度，必要的BSW模塊及其配置，運行實體到任務(wù)的分配等，從而生成ECU配置描述文件。該描述文件包含了特定ECU的所有信息。
• 第三階段：生成代碼，是基于ECU配置描述文件指定的配置來產(chǎn)生代碼、編譯代碼，并把相關(guān)代碼鏈接起來形成可執(zhí)行文件。

具體的開發(fā)流程如下：

編寫系統(tǒng)配置輸入描述文件
在AUTOSAR中，所有的描述文件都是XML類型的文件。系統(tǒng)配置輸入文件包含三部分內(nèi)容：
1）軟件組件描述，定義了每個涉及的軟件組件的接口內(nèi)容，如數(shù)據(jù)類型，端口，接口等。
2）ECU資源描述，定義了每個ECU的資源需求，如處理器、存儲器、外圍設(shè)備、傳感器和執(zhí)行器等。
3）系統(tǒng)約束描述，定義了總線信號，軟件組件間的拓撲結(jié)構(gòu)和映射關(guān)系。

系統(tǒng)配置
系統(tǒng)配置的功能主要是在資源和時序關(guān)系的前提下，把軟件組件映射到各個ECU上，然后借助系統(tǒng)配置生成器生成系統(tǒng)配置描述文件。這個描述文件包括總線映射之類的所有系統(tǒng)信息以及軟件組件與某個ECU的映射關(guān)系。

提取特定ECU的描述
從系統(tǒng)配置描述文件中提取出與各個ECU相關(guān)的系統(tǒng)配置描述信息，提取的信息包括ECU通信矩陣、拓撲結(jié)構(gòu)、映射到該ECU上的所有軟件組件，并將這些信息放在各個ECU的提取文件中。

ECU配置
ECU配置主要是為該ECU添加必要的信息和數(shù)據(jù)，如任務(wù)調(diào)度、必要的基礎(chǔ)軟件模塊及其配置、運行實體及任務(wù)分配等，并將結(jié)果保存在ECU配置描述文件中，該文件包含了屬于特定ECU的所有信息，換言之，ECU上運行的軟件可根據(jù)這些信息構(gòu)造出來。

生成可執(zhí)行文件
根據(jù)ECU配置描述文件中的配置信息，生成RTE和基礎(chǔ)軟件配置代碼，完成基礎(chǔ)軟件和軟件組件的集成，最終生成ECU的可執(zhí)行代碼。

四、AUTOSAR的接口類型

通過RTE實現(xiàn)AUTOSAR軟件組件之間以及應(yīng)用層與基礎(chǔ)軟件之間的通信前提是：軟件組件之間必須有標準的AUTOSAR接口。AUTOSAR規(guī)范把汽車電子領(lǐng)域內(nèi)的一些典型的應(yīng)用劃分為若干個由一個或多個軟件組件組成的模塊，并詳細定義了這些軟件組件相關(guān)的參數(shù)，例如名稱、范圍、類型等。

AUTOSAR定義了三種接口：標椎化接口（Standardized Interface）、AUTOSAR接口（AUTOSAR Interface）和標準化的AUTOSAR接口（Standardized AUTOSAR Interface）。

• AUTOSAR接口是一種與應(yīng)用相關(guān)的接口，與RTE一并生成。基于AUTOSAR接口的端口可以用于軟件組件（Software Component,SWC）之間或者軟件組件與ECU固件之間（例如復(fù)雜驅(qū)動）的通信；
• 標準化AUTOSAR接口是一種特殊的AUTOSAR接口。這些在AUTOSAR規(guī)范中定義過的接口被SWC用于訪問AUTOSAR BSW模塊提供的服務(wù)，比如ECU管理模塊或者診斷事件管理模塊；
• 標椎化接口是AUTOSAR規(guī)范中用C語言定義的API。這些接口用于ECU內(nèi)部BSW模塊之間，RTE和操作系統(tǒng)之間或者RTE和COM模塊之間；

如圖所示，基礎(chǔ)軟件之間通過標椎化接口進行數(shù)據(jù)通信和操作調(diào)用的。故基礎(chǔ)軟件之間可以相互調(diào)用各自的API函數(shù)，但是微控制器抽象層只能被ECU抽象層所調(diào)用，底層驅(qū)動信息通過ECU抽象層傳遞給服務(wù)層使用。

五、AUTOSAR的基礎(chǔ)軟件層

在上述AUTOSAR的分層模型中，最重要也是最復(fù)雜的，莫過于基礎(chǔ)軟件層BSW了。所以，接下去會花大篇幅重點介紹一下這個BSW。

首先，對基礎(chǔ)軟件層BSW進行進一步的細分，劃分為4層：微控制器抽象層，ECU抽象層，服務(wù)層以及復(fù)雜驅(qū)動層。其中：

• 微控制器抽象層（MicroController Abstraction Layer，即MCAL），它位于BSW的最底層，包含了跟硬件相關(guān)的驅(qū)動程序、軟件模塊與直接訪問微控制器內(nèi)部和外圍的設(shè)備，可以用來訪問內(nèi)存、通信和I/O等；
• ECU抽象層（ECU Abstraction Layer），位于微控制器抽象層之上，對接微控制器抽象層所提供的驅(qū)動程序，并同時包含對外部設(shè)備的驅(qū)動程序，然后負責向上提供統(tǒng)一的訪問接口實現(xiàn)對通信、內(nèi)存或者I/O的訪問，從而使得上層模塊無須考慮這些資源由微處理器提供還是由外部設(shè)備提供；
• 服務(wù)層（Service Layer），提供各種類型的后臺服務(wù)，例如網(wǎng)絡(luò)服務(wù)、內(nèi)存管理和總線通信服務(wù)等，操作系統(tǒng)就位于這一層。服務(wù)層是基礎(chǔ)軟件的最高層，同時與應(yīng)用程序也有關(guān)聯(lián)。雖然對I/O信號的訪問由ECU抽象層覆蓋，但服務(wù)層負責提供以下接口：操作系統(tǒng)的功能、車輛網(wǎng)絡(luò)通信管理服務(wù)、存儲器服務(wù)（NVRAM管理）、診斷服務(wù)（包括UDS通信、錯誤存儲和故障處理）、ECU狀態(tài)管理，模式管理、邏輯和時間程序流監(jiān)控（Wdg管理器）、密碼服務(wù)（密碼服務(wù)管理）；
• 復(fù)雜驅(qū)動層（Complex Drivers Layer，即CCD），跨越于微控制器硬件層和RTE之間，其主要任務(wù)是整合具有特殊目的且不能用MCAL進行配置的非標準功能模塊，將該部分功能嵌入到AUTOSAR基礎(chǔ)軟件層中，從而實現(xiàn)處理復(fù)雜傳感器以及執(zhí)行器的特定功能和時間要求，提供集成特殊用途的功能，例如設(shè)備驅(qū)動程序，在AUTOSAR中未規(guī)定的、具有非常高的時間限制或用于遷移等目的；

如下圖所示：

所以，總結(jié)一下，基礎(chǔ)軟件層BSW的組件及其功能對應(yīng)如下：

系統(tǒng)：提供標準化的規(guī)定（針對操作系統(tǒng)、定時器以及錯誤存儲器）、ECU特定的服務(wù)（ECU狀態(tài)管理、看門狗管理）和庫函數(shù)；

內(nèi)存：對內(nèi)部和外部的內(nèi)存（非易失性存儲器）的訪問入口進行標準化；

通信：對汽車網(wǎng)絡(luò)系統(tǒng)、ECU通信系統(tǒng)以及ECU內(nèi)部軟件的訪問入口進行標準化；

輸入/輸出：對傳感器、執(zhí)行器以及ECU外設(shè)的訪問入口進行標準化；

同時，對BSW中的各個子層，還可以從功能上將其中的各個模塊劃分為4種類型，分別為驅(qū)動模塊Driver、接口模塊Interface、處理模塊Handler以及管理器Manager。

驅(qū)動模塊Driver
驅(qū)動模塊包含了控制和使用內(nèi)部或者外部器件的功能，分為內(nèi)部驅(qū)動和外部驅(qū)動。
1）內(nèi)部驅(qū)動
內(nèi)部器件位于微控制器（單片機）的內(nèi)部，例如內(nèi)部EEPROM、內(nèi)部CAN控制器、內(nèi)部ADC模塊等。
內(nèi)部驅(qū)動程序就是針對單片機內(nèi)部器件資源的驅(qū)動程序，這部分驅(qū)動程序?qū)儆谖⒖刂破鞒橄髮?#xff08;MCAL）。
2）外部驅(qū)動
外部器件是指單片機外部的ECU硬件，比如外部EEPROM、外部看門狗、外部Flash等。外部驅(qū)動程序就是針對單片機外部硬件資源的驅(qū)動程序，屬于ECU抽象層。外部驅(qū)動程序需要通過微控制器抽象層（MCAL）驅(qū)動程序來實現(xiàn)對外部器件的驅(qū)動。這種方法下AUTOSAR也支持嵌入在系統(tǒng)基礎(chǔ)芯片（SBCs）中的組件，像收發(fā)器以及看門狗等。例如，使用SPI通信接口的外部EEPROM驅(qū)動程序是通過SPI總線處理程序來驅(qū)動外部EEPROM的。但是有一種例外，對于和內(nèi)存映射相關(guān)的外部器件（如外部Flash存儲器），其驅(qū)動程序是可以直接對微控制器進行存取訪問的，所以這部分驅(qū)動程序?qū)儆谖⒖刂破鞒橄髮?#xff08;MCAL）。

接口模塊Interface
接口模塊包含了對其次級模塊進行抽象的功能，比如對一個特定功能的硬件進行抽象。它提供一個通用的接口函數(shù)（API）來訪問一種特定的器件類型，且與該類型器件的數(shù)目無關(guān)，同時也與器件的具體硬件實現(xiàn)無關(guān)。
接口模塊不會改變數(shù)據(jù)的內(nèi)容。一般來說，接口屬于ECU抽象層。例如，CAN通信系統(tǒng)的接口模塊提供一個通用的接口函數(shù)來訪問CAN通信網(wǎng)絡(luò)，并且與ECU上CAN控制器的數(shù)目以及硬件實現(xiàn)無關(guān)。

處理模塊Handler
處理模塊是一個專用的接口，它控制一個或多個客戶端對一個或多個驅(qū)動程序進行并行、多重以及異步地訪問。也就是說，它起著緩沖、隊列、仲裁以及多路復(fù)用的功能。同時，處理程序也不會改變數(shù)據(jù)本身的內(nèi)容。處理模塊通常會并入驅(qū)動程序或是接口模塊中（如SPIHandlerDriver、ADC Driver等）。

管理器Manager
管理器為多重的客戶端提供特定的服務(wù)。當單純的處理程序不能滿足對多重的客戶端進行抽象時，就需要用到管理器來進行處理。除了處理功能外，管理器還可以對數(shù)據(jù)內(nèi)容進行評估、改變或是適應(yīng)數(shù)據(jù)內(nèi)容。
一般而言，管理器屬于服務(wù)層。例如，非易失性隨機存儲器（NVRAM）的管理器負責對內(nèi)部或是外部存儲設(shè)備進行并行的訪問，如Flash、EEPROM存儲器等。同時，它也可以完成分布式并且可靠的數(shù)據(jù)存儲、數(shù)據(jù)校驗以及默認值的規(guī)定等。

從上面的劃分角度出發(fā)，同時考慮到基礎(chǔ)軟件層主要用于向上提供基礎(chǔ)軟件服務(wù)，包括標準化的系統(tǒng)功能以及功能接口。所以，也可以從服務(wù)類型的角度，將上述4個子層更進一步的細分成一系列的基礎(chǔ)服務(wù)軟件組件，包括系統(tǒng)服務(wù)（System Services）、存儲服務(wù)（Memory Services）、通信服務(wù)（Communication Services）、以及IO服務(wù)（I/O Services）等，如下圖：

下面進行展開解釋：

1、微控制器抽象層

微控制器器抽象層位于AUTOSAR分層模型中的BSW的最底層，它包含內(nèi)部驅(qū)動，可以直接訪問微控制器和片內(nèi)外設(shè)。進一步的，MCAL又可分為微控制器驅(qū)動模塊組（Microcontroller Drivers）、存儲器驅(qū)動模塊組（Memory Drivers）、通信驅(qū)動模塊組（Communication Drivers）、以及I/O 驅(qū)動模塊組（I/O Drivers）。各個部分又由具體的與微控制器硬件相對應(yīng)的驅(qū)動模塊組成，如下圖：

1.1、微控制器驅(qū)動

微控制器驅(qū)動由通用定時器驅(qū)動（General Purpose Driver，GPT Driver）、看門狗驅(qū)動（Watchdog Driver，WDG Driver）、微控制器單元驅(qū)動（Microcontroller Unit Driver，MCU Driver）和內(nèi)核測試（Core Test）四個部分組成。

1.1.1、GPT Driver

在AUTOSAR中有兩類定時器，操作系統(tǒng)定時器和硬件定時器。該模塊使用通用定時器單元的硬件定時器通道，為操作系統(tǒng)或者其他基礎(chǔ)軟件模塊提供計時功能。一個典型的時間周期是50us-5ms。

GPT驅(qū)動的作用是：

• 啟動和停止硬件定時器；
• 得到定時器數(shù)值；
• 控制時間觸發(fā)的中斷；
• 控制時間觸發(fā)的中斷喚醒。

1.1.2、WDG Driver

WDG Driver的功能主要是初始化和觸發(fā)看門狗。WDG Driver有內(nèi)部WDG Driver和外部WDG Driver。內(nèi)部WDG Driver控制MCU的內(nèi)部看門狗定時器，提供觸發(fā)功能和模式選擇服務(wù)；外部WDG Driver控制外部硬件看門狗，與內(nèi)部WDG Driver一樣，提供觸發(fā)功能和模式選擇服務(wù)。

1.1.3、MCU Driver

MCU Driver位于MCAL層，可以直接訪問微控制器硬件，它的主要功能是初始化、休眠、復(fù)位微控制器以及提供其他MCAL軟件模塊所需的與微控制器相關(guān)的特殊功能。MCU Driver還能夠使能并設(shè)置MCU時鐘，例如CPU時鐘、外圍器件時鐘、預(yù)分頻器等參數(shù)。

1.1.4、Core Test

Core Test（內(nèi)核測試）模塊包含周期性測試和啟動測試。內(nèi)核測試模塊可以對CPU所有寄存器進行測試，提供中斷控制和異常檢測。該模塊還對算術(shù)邏輯單元、存儲保護單元和緩存控制器等進行檢測。

1.2、存儲器驅(qū)動

存儲器驅(qū)動由內(nèi)部EEPROM驅(qū)動、內(nèi)部Flash驅(qū)動、RAM測試和Flash測試四部分組成。

1.2.1、內(nèi)部EEPROM驅(qū)動

內(nèi)部EEPROM驅(qū)動提供初始化服務(wù)，以及對內(nèi)部EEPROM的讀寫、寫、擦除等操作。該驅(qū)動模塊一次只能接受一個任務(wù)。

1.2.2、內(nèi)部Flash驅(qū)動

內(nèi)部Flash驅(qū)動提供內(nèi)部Flash初始化服務(wù)，以及對內(nèi)部Flash的讀、寫、擦除等操作。該驅(qū)動還可以將Flash訪問代碼下載到RAM中，如果需要的話，也可以執(zhí)行寫、擦除操作。

1.2.3、RAM測試

RAM測試模塊通過軟件對RAM存儲進行測試。該模塊包含后臺測試和前臺測試。其中，后臺測試是異步服務(wù)，前臺測試是同步服務(wù)。

1.2.4、Flash測試

flash測試模塊提供算法來測試諸如數(shù)據(jù)/程序閃存、程序SRAM等非易失性存儲器，這些存儲器可以是集成在微控制器內(nèi)部的，也可以是外部映射到微控制器的存儲器。

1.3、通信驅(qū)動

通信驅(qū)動由以太網(wǎng)（Ethernet）驅(qū)動、FlexRay驅(qū)動、CAN驅(qū)動、LIN驅(qū)動和SPI驅(qū)動五部分組成。

1.3.1、Ethernet驅(qū)動

Ethernet驅(qū)動模塊使用以太網(wǎng)驅(qū)動層訪問某些控制器，對所使用的以太網(wǎng)控制器的硬件特性進行抽象，為上層的以太網(wǎng)使用提供統(tǒng)一的接口。可由由若干個以太網(wǎng)驅(qū)動模塊復(fù)合起來組成。

1.3.2、FlexRay驅(qū)動

FlexRay驅(qū)動用來抽象不同的FlexRay通信控制器及其硬件相關(guān)的特性。通信控制器的FlexRay協(xié)議強制特性經(jīng)過封裝后只能通過統(tǒng)一的API進行訪問。API提供了映射到基于實際通信控制器的硬件訪問序列的抽象功能操作。因此，使用FlexRay驅(qū)動可以保證FlexRay接口獨立于硬件。

對內(nèi)部或外部FlexRay通信控制器的驅(qū)動來說，需要進行下列處理：

• FlexRay控制器的初始化；
• 配置數(shù)據(jù)處理單元；
• 控制指令向通信控制器的傳遞；
• 從協(xié)議引擎到控制器主接口狀態(tài)數(shù)據(jù)的規(guī)定；
• 通信控制器和主處理機之間信息數(shù)據(jù)的傳輸。

1.3.3、CAN驅(qū)動

CAN驅(qū)動針對的是微控制器內(nèi)部的CAN控制器，它可以實現(xiàn)以下功能：

• 對CAN控制器進行初始化；
• 發(fā)送和接收報文；
• 對報文的數(shù)據(jù)和功能進行通知（對接收報文的指示、對發(fā)送報文的確認）；
• 溢出和錯誤處理；
• 喚醒檢測；

此外，CAN驅(qū)動還具有以下特性：

• 單個或多個CAN通道；
• CAN驅(qū)動的多重實例化；
• 對接收報文的中斷/輪詢模式；

CAN驅(qū)動是MCAL的一部分，可以執(zhí)行硬件訪問、向上層提供獨立于硬件的API，而僅有的能夠訪問CAN驅(qū)動的上層是CAN接口（CAN Interface）。CAN驅(qū)動也可以為數(shù)據(jù)傳輸?shù)某跏蓟屯ㄖ邮帐录幕卣{(diào)函數(shù)提供服務(wù)，該服務(wù)也是獨立于硬件的。除此之外，CAN驅(qū)動也可以控制從屬于同一個CAN硬件單元的CAN控制器的行為和狀態(tài)。

1.3.4、LIN驅(qū)動

LIN驅(qū)動使用標準的通用異步收發(fā)器（Universal Asynchronous Receiver Transmitter，UART）或者串行通信接口（Serial Communication Interface，SCI）進行通信。

該模塊可以完成下列任務(wù)：

• LIN硬件的初始化；
• 調(diào)度表的處理；
• LIN報文的發(fā)送（通過標志位和函數(shù)接口確認）；
• LIN報文的接收（通過標志位和函數(shù)接口指示）；
• 睡眠和喚醒；
• 協(xié)議差錯的處理；
• 報文的超時監(jiān)測；

LIN驅(qū)動也是MCAL的一部分，可以執(zhí)行硬件訪問、向上層提供獨立于硬件的API。僅有的能夠訪問LIN驅(qū)動的上層是LIN接口（LIN Interface）。一個LIN驅(qū)動可以支持多個通道，但是這些通道要屬于同一個LIN硬件單元。

1.3.5SPI驅(qū)動

SPI驅(qū)動模塊是微控制器內(nèi)部同步通信串行接口的驅(qū)動。SPI驅(qū)動為SPI總線上不同的設(shè)備（如EEPROM/Watchdog等）提供讀寫訪問服務(wù)。一個SPI設(shè)備可以被所使用的SPI硬件和相關(guān)的片選信號識別。該模塊可以在主、從或者主-從模式下運行。

配置SPI驅(qū)動應(yīng)遵循以下步驟：

• 選擇SPI驅(qū)動的功能級別，配置可選擇的功能特性；
• 根據(jù)數(shù)據(jù)用途來定義SPI通道，它們可以是SPI驅(qū)動的內(nèi)部緩沖器，或者是由用戶提供的外部緩沖器；
• 根據(jù)硬件屬性來定義SPI任務(wù)，它們會包含一系列使用這些屬性的通道；
• 最后定義任務(wù)序列，以優(yōu)先級排序的方式來傳遞數(shù)據(jù)；

1.4、I/O驅(qū)動

I/O驅(qū)動由PORT驅(qū)動、DIO驅(qū)動、ADC驅(qū)動、PWM驅(qū)動、ICU驅(qū)動、OCU驅(qū)動六部分組成。

1.4.1、PORT驅(qū)動

PORT驅(qū)動初始化就是對微控制器的整個PORT模塊進行初始化配置。

很多端口和管腳被分配有多種不同的功能，即可以進行引腳功能復(fù)用，比如通用I/O、模數(shù)轉(zhuǎn)換、脈寬調(diào)制等功能。因此，對PORT必須有一個整體的配置和初始化，對各管腳的具體配置和使用取決于微控制器和ECU的引腳功能分配。PORT初始化數(shù)據(jù)應(yīng)當盡可能高效地寫到每個端口。DIO驅(qū)動中所用到的端口的配置和初始化都是在PORT驅(qū)動模塊中完成的。因此，在使用DIO功能之前，應(yīng)先進行PORT的初始化。

1.4.2、DIO驅(qū)動

DIO驅(qū)動對微控制器硬件管腳的訪問進行了抽象，除此之外，還可以對管腳進行分組。該模塊通過DIO通道、DIO端口以及DIO通道組來讀寫數(shù)據(jù)，而且這類操作是同步的。

1.4.3、ADC驅(qū)動

ADC驅(qū)動對微控制器內(nèi)部模數(shù)轉(zhuǎn)換單元進行初始化和控制。它可以提供啟動和停止模數(shù)轉(zhuǎn)換的服務(wù)，分別用來開啟和禁用模數(shù)轉(zhuǎn)換的觸發(fā)源。

1.4.4、PWM驅(qū)動

PWM驅(qū)動為微控制器PWM模塊提供初始化和控制服務(wù)，可生成周期和占空比都可變的脈沖。

1.4.5、ICU驅(qū)動

ICU驅(qū)動控制的是微控制器的輸入捕獲單元（Input Capture Unit），有兩種模式：正常模式和休眠模式。

ICU驅(qū)動可以提供以下服務(wù)：

• 信號邊沿檢測及通知；
• 中斷喚醒；
• 周期性信號時間的測量；
• 邊沿時間戳捕獲；
• 邊沿/脈沖計數(shù)；

1.4.6OCU驅(qū)動

OCU驅(qū)動的作用是對微控制器內(nèi)部的輸出比較單元（Output Compare Unit）進行初始化和控制。當計數(shù)器的值到達某個閾值時，OCU模塊會自動開始比較并執(zhí)行相應(yīng)的操作。

OCU驅(qū)動還可以為下列功能提供服務(wù)：

• 啟動或停止輸出通道；
• 設(shè)定某個閾值；
• 啟用或禁用某個通道的通知函數(shù)；
• 獲取計數(shù)器數(shù)值；

2、ECU抽象層

ECU抽象層負責提供統(tǒng)一的訪問接口，實現(xiàn)對通信、內(nèi)存或者IO口的訪問，從而無須考慮這些資源是由微處理器提供的還是由外部設(shè)備提供的。外部設(shè)備的驅(qū)動就位于這一層。ECU抽象層主要包括板載設(shè)備抽象、存儲器硬件抽象、通信硬件抽象以及IO硬件抽象4個部分。

2.1、I/O硬件抽象

I/O硬件抽象是一組模塊從外設(shè)I/O設(shè)備（片上或板載）和ECU硬件布局（例如μC pin腳連接和信號電平倒置）抽象出來。I/O硬件抽象不會從傳感器/執(zhí)行器中抽象出來。不同的I/O設(shè)備可以通過I/O信號接口訪問。

通信硬件抽象是一組模塊從通信控制器和ECU硬件布局抽象出來。對于所有的通信系統(tǒng)都需要一個特定的通信硬件抽象（e.g. for LIN, CAN, FlexRay）。

例如：一個ECU微控制器有2個內(nèi)部CAN通道和一個附加的板載帶有4個CAN控制器的ASIC芯片，CAN-ASIC通過SPI方式連接微控制器。

通信驅(qū)動被訪問通過總線特定的接口（CAN Interface）。

2.2、存儲器硬件抽象

存儲器硬件抽象是一組模塊從外設(shè)存儲設(shè)備（芯片或板載）和ECU硬件布局抽象出來。

例如：芯片上的EEPROM和外部的EEPROM設(shè)備都可以通過相同的機制訪問。

存儲設(shè)備被訪問通過存儲器特定的抽象/仿真模塊（例如EEPROM 抽象）。

2.3、板載設(shè)備抽象

板載設(shè)備抽象包含ECU板載設(shè)備驅(qū)動，例如內(nèi)部或外部看門狗，這些驅(qū)動訪問ECU板載設(shè)備通過μC抽象層。

3、服務(wù)層

服務(wù)層是基礎(chǔ)軟件層的最高層，它可以實現(xiàn)與應(yīng)用層軟件的關(guān)聯(lián)。I/O信號可以通過ECU抽象層進行獲取，此外服務(wù)層還提供：操作系統(tǒng)功能、汽車網(wǎng)絡(luò)通信以及管理功能、內(nèi)存服務(wù)、診斷服務(wù)（包含統(tǒng)一診斷服務(wù)UDS，錯誤記憶和故障處理）、ECU狀態(tài)和模式管理、邏輯與暫時程序流程監(jiān)管（看門狗管理）、加密服務(wù)等；

服務(wù)層的主要任務(wù)是為應(yīng)用程序、RTE以及基礎(chǔ)軟件模塊提供最基本的服務(wù)。服務(wù)層的上層接口保證了微控制器和ECU硬件的獨立。

按照服務(wù)對象的不同，服務(wù)層又分為三個部分，分別為通信服務(wù)，內(nèi)存服務(wù)、和系統(tǒng)服務(wù)。

3.1、通信服務(wù)

通信服務(wù)是一組用于車輛網(wǎng)絡(luò)通信的模塊（CAN、LIN、FlexRay以及Ethernet）。通信服務(wù)通過通信硬件抽象來與通信驅(qū)動程序進行交互。其主要任務(wù)是為車輛通信網(wǎng)絡(luò)和車載網(wǎng)絡(luò)的診斷通道提供一個統(tǒng)一的接口，為網(wǎng)絡(luò)管理提供統(tǒng)一的五福，以及從贏哦有那個程序中隱藏相關(guān)協(xié)議和消息屬性。

3.1.1、CAN

CAN通信服務(wù)是一組帶有CAN通信系統(tǒng)的車輛網(wǎng)絡(luò)通信。為CAN網(wǎng)絡(luò)提供統(tǒng)一的接口。應(yīng)用程序中隱藏協(xié)議和消息屬性。

CAN通信服務(wù)的實施與單片機和ECU硬件無關(guān)，但部分依賴于CAN通信本身；

AUTOSAR COM、Generic NM （Network Management）Interface 和 Diagnostic Communication Manager對于所有車輛網(wǎng)絡(luò)系統(tǒng)都是相同的，并且每個ECU作為一個實例存在。

Generic NM Interface 只包含一個調(diào)度程序，不包含其他功能，對于網(wǎng)關(guān)ECUs，它還可以包括NM協(xié)調(diào)器功能，允許同步多個不同的網(wǎng)絡(luò)（相同或不同類型的）同步喚醒它們或關(guān)閉他們。

CAN NM是針對特定CAN網(wǎng)絡(luò)的，并且通過車輛CAN網(wǎng)絡(luò)系統(tǒng)進行具體實現(xiàn)。可以通過底層網(wǎng)絡(luò)適配器（CAN NM）與CAN Generic NM interfaces 連接。

通信系統(tǒng)特定的CAN狀態(tài)管理器能夠管控與通信系統(tǒng)相關(guān)的啟動和關(guān)閉功能。此外，它還可以通過控制COM的不同選項來實現(xiàn)發(fā)送PDU以及監(jiān)控信號超時的功能；

3.1.2、J1939

J1939通信服務(wù)是對普通CAN通信協(xié)議棧的拓展，主要應(yīng)用在商用車上。其主要任務(wù)是提供J1939通信所需的協(xié)議服務(wù)，同時從應(yīng)用程序中隱藏不需要的協(xié)議和消息屬性。

J1939通信服務(wù)具有以下屬性：

• J1939通信服務(wù)的實施與單片機和ECU硬件無關(guān)，它是基于CAN通信的；
• AUTOSAR COM、通用網(wǎng)絡(luò)管理接口（Generic NM Interface）以及診斷通信管理器（Diagnostic Com.Manager）對所有的車輛網(wǎng)絡(luò)系統(tǒng)都是通用的，并且作為每個ECU的一個實例而存在；
• 支持在配置階段未知的動態(tài)幀標識符；
• J1939網(wǎng)絡(luò)管理器管控每一個ECU的特定地址分配，但它不支持休眠/喚醒處理以及其他相關(guān)的概念，如局部網(wǎng)絡(luò)等；
• 提供J1939診斷和請求處理；

3.1.3、 LIN （LIN Master）

LIN通信服務(wù)是一組車輛LIN通信系統(tǒng)的模塊。其主要任務(wù)是為LIN通信網(wǎng)絡(luò)提供一套統(tǒng)一的接口，同時從應(yīng)用程序中隱藏協(xié)議內(nèi)容和消息屬性。

LIN（主）通信服務(wù)具有以下屬性：與LIN 2.1兼容的通信協(xié)議棧：調(diào)度表管理器，用于傳輸LIN幀和處理切換到其他調(diào)度表的請求；傳輸協(xié)議，用于診斷；一個喚醒和休眠接口；

底層LIN驅(qū)動：實現(xiàn)LIN協(xié)議并對特定硬件進行調(diào)整；支持簡單的UART和基于LIN硬件的復(fù)雜框架；

Lin Interface 控制喚醒/休眠 API，并且允許從節(jié)點保持總線 awake （分散管理的方法 decentralized approach）；

通信系統(tǒng)特定LIN State Manager 依靠 Start-up 和 Shutdown 特性處理通信。此外，它還控制來自通信管理器的通信模式請求。LIN state manager 還通過接口COM 控制 I-PDU 組。

當發(fā)送LIN幀時，LIN接口需要數(shù)據(jù)的時刻（即在發(fā)送LIN幀之前）從PDU路由器請求幀（I-PDU）的數(shù)據(jù)。

3.1.4、Communication Services – LIN Slave

LIN Slave 通常是 “智能” 執(zhí)行器，并且被視為黑盒。由于它們提供的硬件能力和資源非常少，并不打算將AUTOSAR軟件組件轉(zhuǎn)移到這樣的系統(tǒng)上。因此，沒有必要在LIN Slave 上安裝AUTOSAR系統(tǒng)。

LIN Slave 可以連接為完整的ECUs。但他們不被迫使用AUTOSAR SW架構(gòu)。也許他們可以使用同樣標準的AUTOSAR模塊（比如EEPROM，DIO）。

3.1.5、TCP/IP

TCP/IP通信服務(wù)是一組用于車輛TCP/IP通信系統(tǒng)的模塊。其主要任務(wù)是為Ethernet通信網(wǎng)絡(luò)提供一套統(tǒng)一的接口，同時從應(yīng)用程序中隱藏協(xié)議內(nèi)容和消息屬性。

TCP/IP通信服務(wù)具有下屬屬性：TCP/IP模塊實現(xiàn)TCP/IP協(xié)議家族（TCP/UDP/IPv4/IPv6/ARP/ICMP/DHCP）主要協(xié)議，并通過以太網(wǎng)（Ethernet）提供動態(tài)的、基于Socket的通信；Socket適配器模塊是TCP/IP模塊中的唯一上層模塊；

3.2、存儲器服務(wù)

Memory Services由一個模塊組成，即 NVRAM 管理器。它負責非易失性（non volatile）數(shù)據(jù)的管理（從不同的內(nèi)存驅(qū)動讀/寫）。向應(yīng)用程序提供非易失性數(shù)據(jù)。提供非易失性數(shù)據(jù)管理機制，如保存、加載、校驗和保護驗證、可靠存儲等。

3.3、系統(tǒng)服務(wù)

System Services 包含一組模塊，并且模塊的函數(shù)可以被所有層的模塊使用。例如實時操作系統(tǒng)（包括定時器服務(wù)）和錯誤管理器。
其中一些服務(wù)是：μC相關(guān)的（如操作系統(tǒng)：OS），并可能支持特殊μC功能（如加密服務(wù)管理：Crypto Service Manager），部分ECU硬件和應(yīng)用程序相關(guān)（如ECU狀態(tài)管理器：ECU State Manager）等。

這些服務(wù)為應(yīng)用程序和基本軟件（BSW）模塊提供基本服務(wù)。

4、復(fù)雜驅(qū)動層

復(fù)雜驅(qū)動（CCD）層跨越于微控制器硬件層和RTE之間，其主要任務(wù)是整合具有特殊目的且不能用MCAL進行配置的非標準功能模塊，將該部分功能嵌入到AUTOSAR基礎(chǔ)軟件層中，從而實現(xiàn)處理復(fù)雜傳感器以及執(zhí)行器的特定功能和時間要求。

復(fù)雜驅(qū)動程序跟單片機和ECU硬件緊密相關(guān)。其上層程序接口是根據(jù)AUTOSAR指定并且實施的；其下層程序接口受標準接口程序的限制。

復(fù)雜驅(qū)動可以使用特定的中斷或是復(fù)雜的微控制器外設(shè)（如PCP/TPU）來直接訪問微控制器，從而實現(xiàn)對復(fù)雜傳感器的評估和執(zhí)行器的控制，比如噴油控制，電磁閥控制，增量位置檢測等。

總結(jié)

以上是生活随笔為你收集整理的精心整理吐血推荐的AUTOSAR科普介绍材料的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。