AUTOSAR整體思路概述
一、總體概述
AUTOSAR是Automotive Open System Architecture（汽車開放系統架構）的首字母縮寫，是一家緻力于制定汽車電子軟體标準的聯盟。AUTOSAR是由全球汽車制造商、部件供應商及其他電子、半導體和軟體系統公司聯合建立，各成員保持開發合作夥伴關系。自2003年起，各夥伴公司攜手合作，緻力于為汽車工業開發一個開放的、标準化的軟體架構。AUTOSAR這個架構有利于車輛電子系統軟體的交換與更新，并為高效管理愈來愈複雜的車輛電子、軟體系統提供了一個基礎。此外，AUTOSAR在確定産品及服務品質的同時，提高了成本效率。
整車軟體系統可通過AUTOSAR架構對車載網絡、系統記憶體及總線的診斷功能進行深度管理，它的出現有利于整車電子系統軟體的更新與交換，并改善了系統的可靠性和穩定性。目前支援AUTOSAR标準的工具和軟體供應商都已經推出了相應的産品，提供需求管理，系統描述，軟體構件算法模型驗證，軟體建構算法模組化，軟體構件代碼生成，RTE生成，ECU配置以及基礎軟體和作業系統等服務，幫助OEM實作無縫的系統軟體架構開發流程。
AUTOSAR計劃目标主要有三個：
1）建立獨立于硬體的分層軟體架構；
2）為實施應用提供方法論，包括制定無縫的軟體架構堆疊流程并将應用軟體整合至ECU；
3）制定各種車輛應用接口規範，作為應用軟體整合标準，以便軟體構件在不同汽車平台複用。
二、分層概述
AUTOSAR整體架構為分層式設計，以中間件RTE(Runtime Environment)為界，隔離上層的應用層（Application Layer）與下層的基礎軟體（Basic Software）。圖1是AUTOSAR體系架構分層标準。
圖 1 AUTOSAR體系架構分層标準
1、 Application Layer（應用層）
應用層中的功能由各軟體元件SWC（software component）實作，元件中封裝了部分或者全部汽車電子功能，包括對其具體功能的實作以及對應描述，如控制大燈，空調等部件的運作，但與汽車硬體系統沒有連接配接。
1） 軟體元件SWC（software component）
軟體元件SWC（software component）是由Atomic component最小邏輯單元組成。Atomic component最小邏輯單元有Application、Sensor/actuator兩種類型。其中Application是算法實作類型，能在各ECU上自由映射；Sensor/actuator是為Application提供I/O端口類型，用于與ECU綁定，但不可像Application那樣能在各ECU上自由映射。數個SWC的邏輯集合組合成Composition。圖2是SWC組成執行個體。
圖 2
2）端口Ports
端口Ports是用來和其他SWC通信。通信内容分為Data elements與operations。其中，Data elements用Sender/Receiver通信方式；operations用Client/Server通信方式。圖3是通信方式
圖3
發送—接收端口（Sender/Receiver）用來傳輸資料，具有一個通信端口可以包含多種資料類型特點。但如果一個資料類型要通過總線傳輸，那麼它必須與一個信号對應起來，資料類型既可以是簡單的資料類型(integer, float)，也可以是複雜類型(array, record)。通信方式:1:n或n:1
圖 4
用戶端—伺服器端口（Client/Serverr）用來提供Operation服務，具有一個用戶端—伺服器端口可以包含多種Operation和同步或是異步通信特點，一個用戶端—伺服器端口可以包含多種Operations操作，Operations操作也可被單個調用。通信方式:1:n或n:1。
圖 5
3）可運作實體（Runnables entities）
可運作實體（Runnablesentities），簡稱Runnables。可運作實體包含實際實作的函數，可以是具體的邏輯算法或是實際操作。可運作實體由RTE周期性或是事件觸發調用，如當接收到資料。
圖 6
2、Runtime environment層 （RTE）
中間件部分給應用層提供了通信手段，這裡的通信是一種廣義的通訊，可以了解成接口，應用層與其他軟體體的資訊互動有兩種，第一種是應用層中的不同子產品之間的資訊互動；第二種是應用層子產品同基礎軟體之間的資訊互動。而RTE就是這些互動使用的接口的集散地，它彙總了所有需要和軟體體外部互動的接口。從某種意義上來看，設計符合AUTOSAR的系統其實就是設計RTE。
SW-C之間的通信是調用RTE API函數而非直接實作的，都在RTE的管理和控制之下。每個API遵循統一的命名規則且隻和軟體元件自身的描述有關。具體通信實作取決于系統設計和配置，都由工具供應商提供的RTE Generator自動生成的。
在設計開發階段中，軟體元件通信層面引入了一個新的概念，虛拟功能總線VFB（Virtual Functional Bus）。它是對AUTOSAR所有通信機制的抽象，利用VFB，開發工程師将軟體元件的通信細節抽象，隻需要通過AUTOSAR所定義的接口進行描述，即能夠實作軟體元件與其他元件以及硬體之間的通信，甚至ECU内部或者是與其他ECU之間的資料傳輸。
圖 7
從圖中可以看到，有三種接口描述，我們先從定義的角度來看這三種接口有什麼不同。
1. StandardizedInterface（标準接口）：标準接口是在AUTOSAR标準中被标準化的接口，但是并沒有使用AUTOSAR接口技術，标準接口通常被用在某個ECU内部的軟體子產品之間的通訊，不能用于網絡通訊。
2. StandardizedAUTOSAR Interface（标準AUTOSAR接口）：标準AUTOSAR接口是在AUTOSAR标準中使用AUTOSAR接口技術标準化的接口，這樣的接口的文法和語義都被規定好了，這樣的接口通常使用在AUTOSAR服務中，這樣的接口是基礎軟體服務提供給應用程式的。
3. AUTOSARInterface（AUTOSAR接口）：AUTOSAR接口定義了軟體子產品和BSW子產品（僅僅是IO抽象和複雜驅動）之間互動的方式，AUTOSAR接口是以port的形式出現的，AUTOSAR将ECU内部的通訊和網絡通訊使用的接口進行了統一。
從上邊的定義中我們可以看出不同的接口使用的場景不同，及不同的子產品互動會使用到不同的接口。除了将接口歸類以外，這樣定義究竟有什麼實際的意義呢？從實際使用的角度來看，第一和第二類接口都是文法語義标準化的接口，即接口函數的數量、函數的名字、函數參數名字及數量、函數的功能、函數的傳回值都已經在标準裡邊定義好了。不同的公司的軟體在實施這些接口的時候雖然内容算法不同，但是它們長相和功能是一緻的，接口定義在AUTOSAR規範文檔裡邊是可以查得到的。第三類接口呢，AUTOSAR僅僅規定了簡單的命名規則，這類接口高度的和應用相關，比如BCU控制大燈打開的接口可以是Rte_Call_RPort_BeamLight_SetDigOut也可以是Rte_Call_RPort_HeaderLight_Output，公司可以自己定義，又比如儀表想要從CAN總線上獲得車速，改接口可以是Rte_IRead_RE_Test_RPort_Speed_uint8也可以是Rte_IRead_Test_RE_RPort_Spd_uint8，這些接口必須通過RTE互動。
圖 8
3、Basic software層（BSW）
雖然汽車中有各種不同的ECU，它們具有各種各樣的功能，但是實作這些功能所需要的基礎服務是可以抽象出來的，比如IO操作，AD操作，診斷，CAN通訊，作業系統等，無非就是不同的ECU功能，所操作的IO、AD代表不同的含義，所接收發送的CAN消息代表不同的含義，作業系統排程的任務周期優先級不同。這些可以被抽象出來的基礎服務被稱為基礎軟體。根據不同的功能對基礎軟體繼續可以細分成四部分，分别為服務層（Service Layer），ECU抽象層（ECUAbstract Layer），複雜驅動（ComplexDriver）和MCAL（Microcontroller Absstraction Layer），四部分之間的互相依賴程度不盡相同。
服務層（Service Layer），這一層基礎軟體提供了汽車ECU非應用相關的服務，包括OS，網絡通訊，記憶體管理（NVRAM），診斷（UDS，故障管理等），ECU狀态管理子產品等，它們對ECU的應用層功能提供輔助支援，這一層軟體在不同領域的ECU中也非常相似，例如不同的ECU中的OS的任務周期和優先級不同，不同的ECU中的NVRAM的分區不同，存儲的内容不同。
ECU抽象層（ECU Abstract Layer），這一層軟體提供了ECU應用相關的服務，它是對一個ECU的抽象，它包括了所有的ECU的輸入輸出，比如AD，DIO，PWM等，這一層軟體直接實作了ECU的應用層功能，可以讀取傳感器狀态，可以控制執行器輸出，不同領域的ECU會有很大的不同。
MCAL（Microcontroller Absstraction Layer），這一層軟體是對ECU所使用的主要晶片的抽象，它跟晶片的實作緊密相關，是ECU軟體的最底層部分，直接和主要晶片及外設晶片進行互動，它的作用是将晶片提供的功能抽象成接口，然後把這些接口提供給上邊的服務層/ECU抽象層使用。
複雜驅動（Complex Drivers），汽車ECU中有一些領域的ECU會處理相當複雜的硬體信号，執行相當複雜的硬體動作，例如發動機控制，ABS等，這些功能相關的軟體很難抽象出來适用于所有的汽車ECU，它是跟ECU的應用以及ECU所使用的硬體緊密相關的，屬于AUTOSAR構架中在不同的ECU上無法移植的部分。
圖 9
圖10是BSW層中各個子子產品說明。
圖 10
4、Microcontroller層
底層驅動層是由晶片生産廠家提供。
三、開發工具
上圖是AutoSar開發流程階段及各個階段可以使用的開發工具。從網上調研情況來看，Vector和EB公司有整套的開發工具鍊。其中，Vector中的DaVinciDeveloper和DaVinci ConfiguratorPro開發工具使用較為普遍，建議采用Vector公司開發工具鍊。
從開發流程上看，各個開發階段分别都有各自的開發工具：
1） 系統設計階段即需求開發與系統功能設計，采用PREEvision開發工具（價格咨詢未回郵件）；
2） SWC功能軟體開發階段即ECU功能描述，采用DaVinciDeveloper開發工；（價格咨詢未回郵件）；
3） BSW基礎軟體及RTE設計，采用DaVinciConfigurator Pro開工具（價格咨詢未回郵件）；
4） 頭檔案和C代碼采用MATLAB·Simulink工具自動生成。（盜版）
上圖展示Vector公司開發AutoSar時所用的功能元件，其中紅色字型是Vector工具鍊中自帶元件。根據需要，暫定需要OS、SYS、DIAG、MEM、COM、CAN、FR、ETH、MCAL元件，價格在咨詢當中。
黑色字型是底層硬體供應商提供。現已咨詢到，瑞薩供應商底層驅動售價$20K。
四、開發流程
MATLAB·Simulink和Real-TimeWorkshop Embedded Coder生成AUTOSAR标準的代碼是透明和直覺的過程，它支援兩種不同的工作流程：自上而下和自下而上。我們采用自上而下開發方式。
自上而下，從架構模型到Autosar SC。在自上而下的開發流程中，系統工程師使用架構生成工具（如davinci tool suite）來設計整車ECU網絡。當然，工程師也可以使用其他的架構設計工具。架構軟體會輸出一個XML來描述對應的元件，該檔案裡包含了元件的一些必要資訊比如：runnables，接口，資料類型等等。Matlab軟體可以利用架構軟體生成的XML檔案自動建立Simulink架構模型，裡面包含了接口子產品以及相應的Autosar相關設定。之後系統工程師就可以在該架構模型的基礎上，完善内部的控制子產品。