以下文章來源於焉知自動駕駛，作者Aimee

歡迎關注我的微信公眾號：

阿寶1990

，每天給你汽車乾貨，我們始於車，但不止於車

汽車應用軟體開發已成為汽車開發過程中最複雜，最關鍵的活動。AUTOSAR（汽車開放系統架構）為汽車電子控制單元（ECU）開發了標準化的開放軟體體系結構，是主機廠、供應商以及工具和半導體供應商的合作伙伴。重點是管理汽車電氣/電子（E / E）架構開發中日益增長的複雜性，旨在實現新技術並提高開發效率-而不影響質量。Autosar旨在軟體架構、開發方法、應用程式介面三個技術領域中實現標準化。

除此重點外，AUTOSAR的關鍵成功因素還在於其開發協議，該協議從法律層面控制著合作伙伴與其精益組織之間的關係，從而區分了即核心合作伙伴和其他合作伙伴（保費，開發和合作夥伴），從而參照精益流程以快速做出決策。

為了掌握OEM和供應商之間軟體模組（例如駕駛員輔助系統）的複雜性，整體來說AutoSar有如下9個目標：

1.軟體的可移植性。

OEM和供應商應能夠在車輛網路內重用軟體。也可以在不同OEM的不同汽車平臺上使用相同的軟體。

2.對不同車輛和平臺型號的可擴充套件性。

AUTOSAR應提供用於開發可適用於不同車輛以及車輛平臺和硬體的軟體系統的機制。這意味著AUTOSAR應該是可配置的，以便可以整合到不同的車輛中。

3.支援不同的功能域。

AUTOSAR應該能夠在儘可能多的功能域中重用軟體元件。這包括與非AUTOSAR系統的資料交換，例如與車輛資訊娛樂系統的通訊。

4.定義開放式體系結構。

AUTOSAR的體系結構應該是可維護的，可適應的和可擴充套件的。因此，錯誤可以不斷修復。可以實現將來的要求和個性化增強。

5.開發高度可靠的系統。

AUTOSAR必須實現可用性，可靠性，功能安全性，完整性，維護性和安全性。透過這種方式，例如可以考慮對功能安全性的要求。

6.自然資源的可持續利用。

支援使用有效利用自然資源和使用可再生能源的技術。

7.各種夥伴之間的合作。

汽車行業的特點是合作伙伴之間的廣泛合作。AUTOSAR應透過定義資料交換格式和允許來自不同合作伙伴的基本軟體和應用程式整合的體系結構來支援協作。

8.汽車ECU基本軟體功能的標準化。

基本軟體應可用於不同的功能域，OEM和供應商。然後可以將基本軟體作為產品提供。

9.支援適用的汽車國際標準和最新技術。

AUTOSAR應與現有和相關的國際標準相容。這允許在當前和將來的車輛系統中使用AUTOSAR。一個例子是對現有和將來的匯流排系統的支援，例如FlexRay，CAN，乙太網等。

這些專案目標在高階系統要求的“ AUTOSAR主要要求規範”中進行了詳細說明。下面的示例說明了這一點：專案目標“軟體的可移植性”分為以下主要要求：– AUTOSAR的軟體架構應分為功能層。– AUTOSAR應提供與硬體的隔離層，以允許儘可能多的軟體部分獨立於硬體進行設計。– AUTOSAR應允許在整個車載網路中免費分發應用軟體。主要特徵和核心功能是根據主要要求得出的。從中得出“軟體需求規範”（SRS）。這些SRS的詳細資訊產生了“軟體規範”（SWS）。下圖顯示了它們的相關性。“軟體規範”構成了將AUTOSAR標準實施到軟體中的基礎。

其中，AUTOSAR的標準化分為軟體架構、開發方法、應用程式介面三個技術領域。

AutoSar的軟體架構

ECU軟體體系結構的主要概念在於透過軟體抽象層-執行時環境（RTE）來拆分獨立於硬體的應用程式軟體和麵向硬體的基本軟體（BSW）。一方面，該抽象層支援為駕駛員輔助系統開發特定於OEM且具有競爭力的軟體應用程式。另一方面，它簡化了與OEM無關的BSW的標準化過程。此外，這是ECU軟體針對不同汽車系列和變體進行可擴充套件性的前提。它提供了在多個ECU之間分佈應用程式以及整合來自不同來源的軟體模組的可能性。

BSW進一步分為以下幾層：“服務”，“ ECU抽象”，“微控制器抽象”，執行時環境從基本軟體中提取應用程式層，並組織它們之間進行資料和資訊通訊。這構成了在應用程式級別上面向元件，與硬體無關的軟體結構的基礎，其中軟體模組為獨立的單元。例如，駕駛員輔助系統的功能由軟體模組實現。這些軟體模組共同構成了應用程式。各個軟體模組僅直接與RTE通訊。因此，無論通訊發生在ECU內還是超出ECU邊界，通訊都經過清晰設計來確保獨立性，可以在不瞭解所使用或計劃的硬體的情況下開發軟體元件，或者在ECU之間分配現有軟體模組。

AutoSar設計方法論

除了軟體體系結構以外，AUTOSAR還對汽車軟體的開發方法進行了標準化，從而促進了現代系列專案相關合作夥伴的合作。AUTOSAR設計方法論解決了將ECU和各種ECU中的軟體模組整合到具有不同匯流排系統的車輛通訊網路中。它定義了通用工件和相關活動，尤其是活動的依賴性。該設計方法可應用於應用軟體的開發，執行時環境和系統配置中。對於產生或可以在AUTOSAR設計方法中使用的資訊，AUTOSAR定義了具有語義約束的正式資料交換格式（AUTOSAR方案）。此資訊作為形式描述儲存在AUTOSAR XML（。arxml）檔案中。許多工具將這些描述用於RTE和AUTOSAR BSW的配置和生成。例如，軟體元件描述為應用程式軟體提供了標準化的元件模型。或者，系統描述使用交叉連結的ECU例項定義系統上的純軟體層與物理系統體系結構之間的關係。它描述了網路拓撲，每個通道的通訊以及各個ECU上軟體模組的分配。AUTOSAR設計方法的原理如下圖所示。

AutoSar的設計方法原理

AUTOSAR應用程式介面–所顯示的介面符號

除了描述汽車工業中E / E系統的基本能力外，實際交換格式還需要許多方面支援，例如文件，需求可追溯性和各種工件的生命週期。此外，整合的變型管理使OEM和供應商可以表達基本的AUTOSAR產品系列，並在必要時與合作伙伴交換此資訊。這些變體的共同理解和統一解釋是成功開展專案合作的關鍵要素。

AutoSar應用介面

透過應用程式介面確保應用程式模組與RTE的連結。AUTOSAR一方面透過語法將基本介面機制標準化，另一方面在車輛域主體中標準化應用程式介面的語義、內部和舒適性，動力傳動系統，底盤以及乘客和行人保護。其重點是針對廣泛引入的應用程式的介面規範，以強調軟體模組的重用和交換。最後，標準化應用程式介面的使用對於應用程式的重用至關重要。來自AUTOSAR所有合作伙伴的專家都對介面規範進行了標準化，例如關於使用的資料型別，單位和縮放因子。它們允許軟體設計人員和開發人員在擴充套件或複用軟體模組的情況下使用它，而不依賴於任何特定的硬體或ECU。駕駛員輔助系統等應用程式包括差異化的競爭功能。因此，AUTOSAR並沒有標準化應用程式的內部功能過程（例如演算法），而是將在應用程式之間交換的資訊。

系統架構：虛擬功能匯流排（VFB）

為了開發功能系統架構，AUTOSAR引入了虛擬功能匯流排的概念-VFB。VFB允許描述整個系統中，即整個車輛中應用模組之間的功能互動。此描述獨立於實際的ECU架構和實施的網路。這樣，VFB從硬體中提取了應用程式。AUTOSAR將單個應用程式描述為軟體元件（SWC）。VFB既提供了它們之間的通訊機制，也提供了使用基本軟體到軟體元件的服務的機制（請參見圖7，上部）。各種機制由所謂的埠表示（參見6。1節）。在進一步的過程中，功能系統體系結構對映到物理體系結構上，這意味著ECU和網路拓撲。在此，將軟體元件分配給ECU。在每個ECU中，VFB的功能都由RTE和底層基本軟體實現（請參見圖7，下部）。為了避免造成誤解，應明確指出：AUTOSAR已指定VFB概念。此概念已在市場上可用的各種系統架構工具中實現。

AUTOSAR設計方法概述

應用軟體架構

AUTOSAR軟體體系結構的層模型將應用軟體以軟體元件的形式放置在應用層中。可以將軟體元件分組為再次在外部充當軟體元件的合成。透過這種通用元件概念，可以將軟體元件的任何巢狀層次結構實現為一個系統。可以獨立於硬體設計和開發應用程式軟體，軟體元件透過埠進行通訊，每個埠代表一個某些溝通機制。在應用程式之間進行通訊時，最重要的機制是用於形成由資料傳送者發起的在“傳送者-接收者”之間的通訊端，以及用於由接收者發起的通訊的“客戶端”。除此之外，還有其他埠用於過程控制（外部觸發事件）或用於訪問某些引數（校準，操作模式，非易失性儲存器）。每個埠都有一個介面，用於確定要通訊的資料型別。AUTOSAR用程式語言C定義了埠的精確對映。下圖顯示了ECU內部以及不同ECU中的應用程式之間的通訊路徑。軟體元件由稱為“軟體元件模板”的特定AUTOSAR的正式描述。除了對埠和介面的描述之外，它還包含所謂的內部行為。該術語成立於AUTOSAR的早期，但不幸的是經常引起誤解。在AUTOSAR的上下文中，“內部行為”描述了與時間或事件相關的過程控制（事件和排程）的元件。這包括“可執行實體”的定義，即由底層作業系統按事件或時間安排的最小軟體實體。明確要在元件中實現的演算法不屬於“內部行為”。

實際上，有幾種典型的方法可以填寫或編輯軟體元件說明。許多用於基於模型的開發的設計工具可以從圖形模型中生成軟體元件描述，並允許編輯相應的條目。同樣，RTE生成器通常允許編輯軟體元件說明。對於具有特定硬體要求的應用程式，例如依賴於某些感測器或執行器的軟體，AUTOSAR提供了所謂的感測器/執行器軟體元件，在軟體元件說明中可以註明這些約束。

執行時環境RTE與基本軟體BSW

AUTOSAR執行時環境（RTE）將應用程式從基本軟體的任何實現細節中提取出來，並從控制裝置的硬體中提取出來。它表示特定ECU上VFB的執行時實現。RTE提供了應用程式之間的通訊機制以及訪問基本軟體服務的機制。這還包括為通訊提供資料緩衝和排隊。RTE的實際程式程式碼取決於應用程式，它們的通訊，基本軟體使用的服務以及排程。實際上，程式碼是由RTE生成器根據軟體元件描述的資訊建立的。嚴格來講，RTE是一種“中介軟體”層技術，它可以透過分散的網路來重新定位應用程式層的元件。基本軟體透過RTE為應用程式提供所有系統服務和功能。儘管基本軟體的功能對於應用程式必不可少，但車輛使用者通常不會很好地注意到這些功能。隨著對硬體的依賴性越來越高，基本軟體又分為多個層：服務層，ECU抽象層和微控制器抽象層。依次地，每個層包含代表精確指定功能範圍的各個模組。AUTOSAR基本軟體包含大約總共80個不同的模組，為此標準對每個模組都具有要求和軟體規範。其中，模組及其介面的功能行為用C定義，因此一個模組的兩種不同但符合標準的實現方式可以直接互換。基本軟體模組的功能行為及其配置的引數化使用與應用程式元件相同的形式描述機制。控制單元的基本軟體模組的配置說明在ECU配置說明中進行了概述。

AUTOSAR服務

服務層包括系統服務，例如通訊服務，診斷協議，儲存服務，ECU操作模式的管理以及作為獨立模組的AUTOSAR作業系統（OS）。AUTOSAR OS基於實時系統標準OSEK / VDX，並且在某些領域得到了擴充套件，但在其他領域也受到限制。它是靜態配置和縮放的，並提供基於優先順序的實時行為和中斷處理。在執行期間，可以使用各種保護機制來進行記憶體訪問或時間行為。AUTOSAR OS還適用於小型和效能較低的微控制器，但同時也支援多核使用以及對程式碼和資料使用多個記憶體分割槽。服務模組與作業系統及硬體無關。這些系統服務可透過RTE用於應用程式，應用程式無法直接訪問底層的基本軟體模組。這是保留給服務使用的，以作為其功能的一部分訪問ECU或微控制器資源。服務模組及其底層模組也稱為功能堆疊，例如FlexRay的通訊堆疊。有時將這樣的堆疊實現和整合為一個大型軟體單元，而沒有底層模組結構。服務層包括系統服務，例如通訊服務，診斷協議，儲存服務，ECU操作模式的管理以及作為獨立模組的AUTOSAR作業系統（OS）。AUTOSAR OS基於實時系統標準OSEK / VDX，並且在某些領域得到了擴充套件，但在其他領域也受到限制。它是靜態配置和縮放的，並提供基於優先順序的實時行為和中斷處理。在執行期間，可以使用各種保護機制來進行記憶體訪問或時間行為。AUTOSAR OS還適用於小型和效能較低的微控制器，但同時也支援多核使用以及對程式碼和資料使用多個記憶體分割槽。服務模組與作業系統無關，與硬體無關。這些系統服務可透過RTE用於應用程式。應用程式無法直接訪問底層的基本軟體模組。這是保留給服務使用的，以作為其功能的一部分訪問ECU或微控制器資源。服務模組及其底層模組也稱為功能堆疊，例如FlexRay的通訊堆疊。有時將此類堆疊實現和整合為一個大型軟體單元，而沒有AUTOSAR定義的基礎模組結構。儘管這破壞了抽象原理並降低了靈活性，但由於可能實現更高的效率和效能，因此在AUTOSAR中使用功能堆疊進行處理已很普遍。

小結

AUTOSAR成功的決定性原因是夥伴關係的基本原則，截至2014年10月，已有180多傢伙伴公司形成了合作標準化和實施競爭。因此，

AUTOSAR夥伴關係的主要結果是在其標準及其實施的自由過程中實施競爭的約束。

AUTOSAR引入的另一個基本變化是使用者的正規化轉變，從實現軟體轉向配置和生成軟體。這樣就可以透過AUTOSAR系統描述中的適當工具在軟體中快速實施，從而在電子控制軟體的開發中達到無與倫比的抽象度。這種抽象水平以及特定硬體的獨立性使軟體重用達到了新的水平，並使人們能夠集中精力開發創新的客戶功能，這些功能目前主要出現在自動駕駛系統領域。