1.AUTOSAR（Automotive Open System Architecture，汽車開放系統架構）是一個針對汽車行業的軟件架構標準，旨在提升汽車電子系統的模塊化、可擴展性、可重用性和互操作性。AUTOSAR的目標是為汽車電子控制單元（ECU）之間的軟件開發提供統一的標準，以支持多種不同的硬件平臺和操作系統，并促進供應商間的兼容性。

2.AUTOSAR Classic Platform架構如下圖所示：

• SWC（Application Software Components, 應用軟件組件）：這些是ECU上運行的實際應用程序，執行車輛功能的核心任務。例如，發動機控制、車輛安全、空調控制等。應用層組件與硬件和其他軟件組件之間通過接口進行通信，通常通過AUTOSAR定義的標準接口。

• RTE（Runtime Environment，運行時環境）：RTE是AUTOSAR架構的核心部分，它是軟件組件與基礎軟件層之間的中間件。RTE負責連接不同的應用軟件組件，提供統一的通信機制，確保不同軟件模塊間的互操作性。RTE的作用是將應用軟件與底層的硬件和服務隔離開，使得應用軟件不依賴于具體的硬件平臺和操作系統，增強了軟件的可移植性。

• BSW（Basic Software Layer，基礎軟件層）：該層主要是為應用層提供基礎服務，具體又可分為以下幾層：

• Microcontroller Abstraction Layer（微控制器抽象層，MCAL）：該層是對MCU芯片的抽象和封裝，由于Autosar CP是基于MCU的軟件架構，所以該層主要是實現MCU外設驅動)比如I/O驅動、Flash驅動、CAN驅動、看門狗驅動、定時器驅動等等。這一層是需要和硬件打交道的，這一層高度依賴MCU硬件，如果項目換MCU芯片，只需要修改這一層代碼適配驅動即可。
• ECU Abstraction Layer（ECU抽象層）：該層是對ECU的抽象和封裝，ECU上面除了主芯片MCU，還有很多外圍設備，比如外置Flash，外置電源管理芯等。這一層就是實現了整個ECU所有設備的封裝。外圍設備也是MCU主芯片控制的，這一層會使用到MCAL的接口。作為抽象層，屏蔽了下層驅動實現細節，將統一接口API暴露給上層以實現功能。該層從上層抽象MCAL層，并提供用于訪問外部和內部的驅動程序的API。
• Services Layer（服務層）：該層是向應用層提供服務的，這一將底層提供的服務封裝起來供應用層使用。比如通信服務、存儲服務、os 操作系統服務等。
• Complex Device Drivers（復雜驅動，CDD）：指的是有些模塊不適用于Autosar協議棧，通過手寫代碼自己封裝成CDD模塊，在項目開發中會經常有一些模塊直接作為CDD使用。

3.AUTOSAR Adaptive Platform是面向服務的架構，如下圖所示：

4.汽車電子開發流程：下圖是標準AUTOSAR流程，OEM從需求生成最終的文件(給到每一個ECU制造廠商)的主要流程。圖中流程需要軟件工具支持(比如Vector的PREEvision)，這樣就能自動生成相應的描述文件了。圖中綠色箭頭的含義是：設計之初，需要反復修改，首先是列需求，通過三種文件描述這些需求：SWC描述文件、系統描述文件、ECU資源文件，然后將這三種文件導入到系統配置編輯工具中，生成系統配置描述文件。該文件就是整車描述文件最后將系統配置描述文件導入到系統配置提取工具中，導出每一個ECU相應的提取文件，該文件就包含每一個ECU需要用到的信息，比如通信矩陣、SWC信息。

上圖中各個具體文件的作用是：

• SWC描述文件：即應用層軟件組件描述文件，包含的信息有：描述每個軟件組件需要的資源（比如存儲、CPU時間等），SWC直接的接口，運行機制

• 系統約束描述文件：主要是對整車公共資源的描述，包括網絡拓撲、通信矩陣、總線波特率、各種協議等

• ECU資源描述文件：描述每個ECU都需要實現什么功能，系統設計者通過該文件將不同功能的SWC分配到對應的ECU中，例如傳感器、執行器、存儲器、引腳分配

• 系統配置描述文件：上面3中文件的匯總

• ECU提取文件：將系統配置描述文件信息分配給單個ECU，是單個ECU獲取屬于自己的信息

當供應商獲取到OEM廠商提供的單個ECU的配置文件之后，可以進行具體的ECU軟件開發，流程如下：

• EB用來配置Mcal驅動，生成arxml導入到DavinciConfigurator（用來配置操作系統和協議棧）中生成代碼。

• Davinci Developer是用來配置App層框架的（對應AUTOSAR Classic Platform架構中的RTE部分），然后導入到Davinci Configurator中生成代碼。

• Davinci Developer生成的arxml還會給一份到應用工程師（導入到MATLAB）然后通過MATLAB自動生成軟件框架，應用工程在里面添加模型代碼即可。

• 做EB、DaVinci Developer、DaVinci Configrator和Simulink工程師可以同步開發，最終集成一下即可。

• 開發可以從上到下也可以從下到上，就是說可以在Developer中設計好AppL框架導入到Matlab做代碼填充，也可以在Matlab中直接搭建好符合AutoSAR規范的代碼，然后導出arxml，再導入到Developer中，也能自動生成框架

靜態代碼：不會改變的源碼。動態代碼：配置工具配置出來的代碼xx_cfg.c、xx_cfg.h。

5.CAN通信：

從圖中可以看出，CAN總線通信需要CPU、CAN控制器、CAN收發器參與。從CAN收發器引出兩根線CAN_H_CAN_L，所有節點都掛接到這兩根線上，就形成了CAN的網絡結構。圖中有兩路CAN總線，帶有終端電阻120歐的是高速CAN，沒有帶終端120歐的是低速容錯CAN。

6.高速CAN總線的總線設計如圖所示，僅支持總線型拓撲結構，當前汽車領域用的最多的是CAN控制器集成到MCU中，使用外置CAN收發器，也就是圖中右邊這種設計：

CAN總線信號由CAN_H_CAN_L兩根線的差分信號，也就是通過CAN_H和CAN_L的電壓差來決定0、1信號。總線規定隱性電平為信號1（即CAN不工作時），顯性電平為信號0（即CAN工作時），其中隱形電平的時候CAN_H和CAN_L都為2.5V，此時電壓差就是0V，而顯性電平的時候CAN_H為3.5V， CAN_L為1.5V，此時電壓差就是2V。高速CAN，總線長度最大為40m，也就是當總線長度超過40m之后，總線的速率會受到影響，支線長度(節點和總線之間的距離)最長為0.3米，節點距離長度最大也是40m。

7.低速CAN：低速容錯CAN總線信號也是由CAN_H和CAN_L兩根線的差分信號，也就是通過CAN_H和CAN_L的電壓差來決定0、1信號。總線規定隱形電平為信號1顯性電平為信號0。其中隱形電平的時候CAN_H為0V，CAN_L為5V，此時電壓差就是-5V，顯性電平的時候CAN_H為3.50V，CAN_L為1.5V，此時電壓差就是2V。低俗容錯CAN除了支持總線型還支持星型。

8.相關概念：

• ECU（Electronic Control Unit）：是電子控制單元的縮寫，它是現代汽車、工業自動化、航空航天等領域中廣泛使用的電子設備。ECU 主要用于控制和管理車輛或設備的各種電子系統，通過接收來自傳感器的信號并執行相應的控制操作來提高設備的性能、可靠性和安全性。

• OTA（Over-the-Air）：是一種無線遠程更新技術，主要用于通過無線網絡（如Wi-Fi、蜂窩網絡、藍牙等）遠程向設備推送軟件、固件或配置更新。OTA 更新通常用于智能手機、汽車、物聯網設備、嵌入式系統等領域，以便無需物理接觸或連接外部設備的情況下，遠程升級、修復漏洞、優化性能或增加新功能。

• OEM（Original Equipment Manufacturer）：指的是“原始設備制造商”，即生產原始設備的公司，它設計并制造產品或組件，并將其作為品牌產品的一部分提供給其他公司進行銷售。OEM 通常指的是一個制造商生產的產品或部件，最終由另一家公司銷售并以其品牌名推出市場。

• BswM：管理整個BSW的模塊

• EcuM：管理ECU上下電等功能。