1.2.3 AUTOSAR方法論

AUTOSAR的方法論表述了從系統底層開發配置到ECU可執行代碼生成的設計和執行步驟。其開發方法是基于虛擬功能總線（Virtual Function Bus，VFB）的方法，故在論述清楚AUTOSAR的方法論之前，需要先說清楚什么是虛擬功能總線。

在AUTOSAR中，應用程序被設計為相互連接的軟件組件組合。虛擬功能總線是這些軟件組件交互的通信機制。在系統配置階段，軟件組件被映射到特定的ECU上。但是在軟件編寫階段，還沒有辦法確定ECU的個數和軟件需要部署的具體ECU，故軟件組件之間的虛擬連接被映射為本地連接，或是基于車載網絡的通信機制。一個軟件組件包含一部分或全部的功能模塊，一個軟件組件由代碼實現和與之關聯的正式描述文件組成。虛擬功能總線的概念實現了應用軟件與基礎軟件的嚴格隔離，進而使軟件組件可以獨立于通信機制，并和其他軟件組件相互通信。

通過VFB可以實現整個軟件系統的完整通信，包括所有的功能提供者（架構中稱為Provider或Server）和軟件功能的使用者（架構中稱為Receiver或Client）。因此，VFB也可以為軟件提供檢查功能，驗證軟件組件間通信的可信性。

如圖1-19所示，VFB需要給整個軟件系統的所有軟件組件提供如下基礎功能：

1）與系統中其他的軟件組件進行通信。

2）與系統中的傳感器和執行器進行通信。

3）訪問標準服務。

4）響應工作模式變化。

5）與系統中的標定、測量系統進行交互。

而VFB中，軟件組件間通信通過端口（Port）通信實現，而端口的類型是由接口（Interface）定義的。設計軟件組件的時候不必考慮每個軟件組件具體要分配到哪個ECU上，也不必考慮軟件組件間如何在車載網絡中通信。故VFB的存在可以在確定車輛ECU和電氣架構前就確定整個汽車電子軟件的功能架構。

介紹了VFB后，再來詳細講解一下AUTOSAR的設計和開發流程。

AUTOSAR在開發過程中，主要分為三個階段：系統配置階段、ECU設計與配置階段、代碼生成階段。

1.系統配置階段

在系統配置階段，用戶需要定義系統配置文件。這是系統設計者或架構師的任務，包括選擇硬件和軟件組件，定義整個系統的約束條件。AUTOSAR通過使用信息交換格式和模板描述文件來減少初始系統設計時的工作量。系統配置的輸入是ARXML類型的文件，輸出是系統配置描述文件，系統配置的主要作用是把軟件組件的需求映射到ECU上。

在AUTOSAR中，所有的描述文件都是ARXML類型的文件。系統配置輸入文件包含三部分內容：

1）軟件組件描述，定義每個涉及的軟件組件的接口內容，如數據類型、端口、接口等。

2）ECU資源描述，定義每個ECU的資源需求，如處理器、存儲器、外圍設備、傳感器和執行器等。

3）系統約束描述，定義總線信號以及軟件組件間的拓撲結構和映射關系。

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

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

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

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

當然，AUTOSAR方法論不僅涵蓋了從VFB設計到生成代碼軟件集成之間的所有步驟，還包括了標定、存儲映射和數據保護等方法。其不僅規定了每一個步驟的行為，還規定了各步驟之間的銜接方式。

2.ECU設計與配置階段

在ECU設計與配置階段有三部分工作需要完成：建立VFB系統、開發軟件功能組件以及開發系統和子系統。

根據前一階段制定的方針做具體工作。因為所有的軟件組件設計都是基于VFB的，所以在此時還沒有ECU的概念，所有的軟件組件都放在一起開發。整個功能描述獨立于任何的ECU和網絡。

這一階段需要做的包括：具體設計VFB中的接口、模式、數據類型、軟件組件及其定時。完成這一步后，整個VFB可以確定有哪些軟件組件，以及這些軟件組件互相之間的關系和通信等。

接下來是軟件組件的設計階段。

建立完VFB后，需要著手開始軟件組件的設計。設計完成后，可以通過RTE代碼生成器生成頭文件，用戶進而可以自己開發控制算法。

AUTOSAR Classic Platform體系結構在最高抽象級別上區分了運行在微控制器上的三個軟件層：應用層（Application Layer）、運行時環境（Runtime Environment，RTE）和基本軟件（Basic Software，BSW），如圖1-20所示。

應用層部分是指實現特定的ECU功能的那部分軟件，這部分軟件負責實現ECU的邏輯功能，比如說，通過算法控制前照燈、空調、電機等，它是汽車功能的一種抽象，與ECU所使用的硬件沒有關系。應用層又可以細分為軟件組件（SWC），軟件組件之間的信息交互不能直接進行，必須通過RTE。通過SWC概念的設計，對應用層軟件進一步解耦，使得應用層中的SWC具有了被替換的可能。

中間件部分給應用層提供了通信手段，這里的通信是一種廣義的通信，可以理解成接口。應用層與其他軟件體的信息交互有兩種：一種是應用層中的不同模塊之間的信息交互；另一種是應用層模塊同基礎軟件之間的信息交互。而RTE就是這些交互使用的接口的集散地，它匯總了所有需要和軟件體外部交互的接口，如圖1-21所示。從某種意義上來看，設計符合AUTOSAR的系統其實就是設計RTE。

雖然汽車中有各種不同的ECU，它們具有各種各樣的功能，但是實現這些功能所需要的基礎服務是可以抽象出來的，比如I/O操作、AD操作、診斷、CAN通信、操作系統等，無非就是不同的ECU功能，所操作的IO/AD代表不同的含義，所接收發送的CAN消息代表不同的含義，操作系統調度的任務周期優先級不同。這些可以被抽象出來的基礎服務被稱為基礎軟件。根據不同的功能，可以將基礎軟件（BSW）繼續細分成四部分：服務層（Service Layer）、ECU抽象層（ECU Abstract Layer）、微控制器抽象層（MCAL）和復雜驅動（Complex Driver）。四部分之間的互相依賴程度不盡相同。

1）服務層（Service Layer）。這一層基礎軟件提供了汽車ECU非應用相關的服務，包括OS、網絡通信、內存管理（NVRAM）、診斷（UDS、故障管理等）、ECU狀態管理模塊等，它們對ECU的應用層功能提供輔助支持。這一層軟件在不同領域的ECU中也非常相似，例如不同ECU中的OS的任務周期和優先級不同，不同ECU中的NVRAM的分區不同、存儲的內容不同。

2）ECU抽象層（ECU Abstract Layer）。這一層軟件提供了ECU應用相關的服務，它是對一個ECU的抽象，包括了所有ECU的輸入輸出，比如AD、DIO、PWM等。這一層軟件直接實現了ECU的應用層功能，可以讀取傳感器狀態，可以控制執行器輸出，不同領域的ECU會有很大的不同。

3）微控制器抽象層（MCAL）。這一層軟件是對ECU所使用的主控芯片的抽象，它與芯片的實現緊密相關，是ECU軟件的最底層部分，直接與主控芯片及外設芯片進行交互，它的作用是將芯片提供的功能抽象成接口，然后把這些接口提供給上邊的服務層/ECU抽象層使用。

4）復雜驅動（Complex Driver）。汽車ECU中有一些領域的ECU會處理相當復雜的硬件信號，執行相當復雜的硬件動作，例如發動機控制、ABS等，這些功能相關的軟件很難抽象出來適用于所有的汽車ECU，它是與ECU的應用以及ECU所使用的硬件緊密相關的，屬于AUTOSAR構架中在不同的ECU平臺上無法移植的部分。

簡單來說，第二階段設計的軟件層有如下特點：

1）應用軟件層大部分是獨立于硬件的。

2）軟件組件之間的通信通過RTE訪問BSW。

3）RTE表示應用程序的完整接口。

4）基礎軟件分為三個主要層（服務層，ECU抽象層，微控制器抽象層）和復雜的驅動程序。

5）服務，ECU（ECU）抽象和微控制器抽象。

6）服務被進一步劃分為代表系統、內存和通信服務基礎設施的功能組。

3.代碼生成階段

最后一個階段是代碼生成和軟件集成。軟件集成是以ECU為單位的。在AUTOSAR概念中，一個ECU就意味著一個微控制器加上外圍電路和軟件配置，因此，每個微控制器都需要ECU配置。在這一階段首先需要進行RTE配置。RTE的配置包括建立OS任務，并將運行實體映射到OS任務上。然后是配置BSW，其中包括通信棧、操作系統、系統服務、存儲、診斷、MCAL等基礎軟件模塊。

在配置完成后，則是生成RTE、BSW、OS和MCAL代碼。這些代碼都是在不同的配置工具中分別生成，而最后放在編譯器中統一編譯成可執行文件。