一、AUTOSAR的背景介紹

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

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

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

• 1）建立分層的體系架構
• 2）為應用程序的開發提供方法論
• 3）制定各種應用接口規范

二、AUTOSAR的分層模型

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

AUTOSAR軟件體系結構包含了完全獨立于硬件的應用層（APP）和與硬件相關的基礎軟件層（BSW），并在兩者中間設立了一個運行時環境（RTE），從而使兩者分離，形成了一個分層體系架構。RTE是專門為應用軟件（AUTOSAR軟件組件和/或AUTOSAR傳感器/執行器組件）提供通信服務的層。在RTE之上，軟件架構風格從“分層”轉變為“組件風格”。AUTOSAR軟件組件通過RTE與其他組件（內部和/或內部ECU）或服務進行通信。所以，這樣的分層結構帶來兩個最大的好處，一方面，OEM可以專注于開發特定的、有競爭力的應用層軟件（位于RTE之上），另一方面，它使OEM所不關心的基礎軟件層（位于RTE之下）得到標準化。

三、AUTOSAR的方法論

AUTOSAR為汽車電子軟件系統開發過程定義了一套通用的技術方法，即AUTOSAR方法論。該方法描述了從系統底層配置到ECU可執行代碼產生過程的設計步驟，如下圖所示。

AUTOSAR設計和開發流程分為三個階段：系統配置、ECU設計與配置階段、代碼生成階段。

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

具體的開發流程如下：

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

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

提取特定ECU的描述
從系統配置描述文件中提取出與各個ECU相關的系統配置描述信息，提取的信息包括ECU通信矩陣、拓撲結構、映射到該ECU上的所有軟件組件，并將這些信息放在各個ECU的提取文件中。

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

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

四、AUTOSAR的接口類型

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

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

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

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

五、AUTOSAR的基礎軟件層

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

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

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

如下圖所示：

所以，總結一下，基礎軟件層BSW的組件及其功能對應如下：

系統：提供標準化的規定（針對操作系統、定時器以及錯誤存儲器）、ECU特定的服務（ECU狀態管理、看門狗管理）和庫函數；

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

通信：對汽車網絡系統、ECU通信系統以及ECU內部軟件的訪問入口進行標準化；

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

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

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

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

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

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

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

下面進行展開解釋：

1、微控制器抽象層

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

1.1、微控制器驅動

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

1.1.1、GPT Driver

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

GPT驅動的作用是：

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

1.1.2、WDG Driver

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

1.1.3、MCU Driver

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

1.1.4、Core Test

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

1.2、存儲器驅動

存儲器驅動由內部EEPROM驅動、內部Flash驅動、RAM測試和Flash測試四部分組成。

1.2.1、內部EEPROM驅動

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

1.2.2、內部Flash驅動

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

1.2.3、RAM測試

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

1.2.4、Flash測試

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

1.3、通信驅動

通信驅動由以太網（Ethernet）驅動、FlexRay驅動、CAN驅動、LIN驅動和SPI驅動五部分組成。

1.3.1、Ethernet驅動

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

1.3.2、FlexRay驅動

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

對內部或外部FlexRay通信控制器的驅動來說，需要進行下列處理：

• FlexRay控制器的初始化；
• 配置數據處理單元；
• 控制指令向通信控制器的傳遞；
• 從協議引擎到控制器主接口狀態數據的規定；
• 通信控制器和主處理機之間信息數據的傳輸。

1.3.3、CAN驅動

CAN驅動針對的是微控制器內部的CAN控制器，它可以實現以下功能：

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

此外，CAN驅動還具有以下特性：

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

CAN驅動是MCAL的一部分，可以執行硬件訪問、向上層提供獨立于硬件的API，而僅有的能夠訪問CAN驅動的上層是CAN接口（CAN Interface）。CAN驅動也可以為數據傳輸的初始化和通知接收事件的回調函數提供服務，該服務也是獨立于硬件的。除此之外，CAN驅動也可以控制從屬于同一個CAN硬件單元的CAN控制器的行為和狀態。

1.3.4、LIN驅動

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

該模塊可以完成下列任務：

• LIN硬件的初始化；
• 調度表的處理；
• LIN報文的發送（通過標志位和函數接口確認）；
• LIN報文的接收（通過標志位和函數接口指示）；
• 睡眠和喚醒；
• 協議差錯的處理；
• 報文的超時監測；

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

1.3.5SPI驅動

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

配置SPI驅動應遵循以下步驟：

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

1.4、I/O驅動

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

1.4.1、PORT驅動

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

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

1.4.2、DIO驅動

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

1.4.3、ADC驅動

ADC驅動對微控制器內部模數轉換單元進行初始化和控制。它可以提供啟動和停止模數轉換的服務，分別用來開啟和禁用模數轉換的觸發源。

1.4.4、PWM驅動

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

1.4.5、ICU驅動

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

ICU驅動可以提供以下服務：

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

1.4.6OCU驅動

OCU驅動的作用是對微控制器內部的輸出比較單元（Output Compare Unit）進行初始化和控制。當計數器的值到達某個閾值時，OCU模塊會自動開始比較并執行相應的操作。

OCU驅動還可以為下列功能提供服務：

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

2、ECU抽象層

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

2.1、I/O硬件抽象

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

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

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

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

2.2、存儲器硬件抽象

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

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

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

2.3、板載設備抽象

板載設備抽象包含ECU板載設備驅動，例如內部或外部看門狗，這些驅動訪問ECU板載設備通過μC抽象層。

3、服務層

服務層是基礎軟件層的最高層，它可以實現與應用層軟件的關聯。I/O信號可以通過ECU抽象層進行獲取，此外服務層還提供：操作系統功能、汽車網絡通信以及管理功能、內存服務、診斷服務（包含統一診斷服務UDS，錯誤記憶和故障處理）、ECU狀態和模式管理、邏輯與暫時程序流程監管（看門狗管理）、加密服務等；

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

按照服務對象的不同，服務層又分為三個部分，分別為通信服務，內存服務、和系統服務。

3.1、通信服務

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

3.1.1、CAN

CAN通信服務是一組帶有CAN通信系統的車輛網絡通信。為CAN網絡提供統一的接口。應用程序中隱藏協議和消息屬性。

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

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

Generic NM Interface 只包含一個調度程序，不包含其他功能，對于網關ECUs，它還可以包括NM協調器功能，允許同步多個不同的網絡（相同或不同類型的）同步喚醒它們或關閉他們。

CAN NM是針對特定CAN網絡的，并且通過車輛CAN網絡系統進行具體實現。可以通過底層網絡適配器（CAN NM）與CAN Generic NM interfaces 連接。

通信系統特定的CAN狀態管理器能夠管控與通信系統相關的啟動和關閉功能。此外，它還可以通過控制COM的不同選項來實現發送PDU以及監控信號超時的功能；

3.1.2、J1939

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

J1939通信服務具有以下屬性：

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

3.1.3、 LIN （LIN Master）

LIN通信服務是一組車輛LIN通信系統的模塊。其主要任務是為LIN通信網絡提供一套統一的接口，同時從應用程序中隱藏協議內容和消息屬性。

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

底層LIN驅動：實現LIN協議并對特定硬件進行調整；支持簡單的UART和基于LIN硬件的復雜框架；

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

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

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

3.1.4、Communication Services – LIN Slave

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

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

3.1.5、TCP/IP

TCP/IP通信服務是一組用于車輛TCP/IP通信系統的模塊。其主要任務是為Ethernet通信網絡提供一套統一的接口，同時從應用程序中隱藏協議內容和消息屬性。

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

3.2、存儲器服務

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

3.3、系統服務

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

這些服務為應用程序和基本軟件（BSW）模塊提供基本服務。

4、復雜驅動層

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。