1. 程式人生 > >AUTOSAR架構概述

AUTOSAR架構概述


                                    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相關設定。之後系統工程師就可以在該框架模型的基礎上,完善內部的控制模組。