該標準將有助于減少設計過程中人為錯誤的產(chǎn)生，并為供貨商和制造商提供一種明確且機器也可讀取的數(shù)據(jù)格式，以交換設計信息。本文將探討AUTOSAR采用戰(zhàn)略的一些的預期商業(yè)效益，并解釋了一些基本術(shù)語和設計方法。

　　

AUTOSAR聯(lián)盟的會員包括汽車OEM以及由零部件和服務供貨商組成的支持性生態(tài)系統(tǒng)。該聯(lián)盟的宗旨是針對汽車電氣/電子（E/E）架構(gòu)創(chuàng)造和建立全球性的開放標準。該標準在車輛架構(gòu)級別提供支持，讓OEM網(wǎng)絡設計人員能設計和管理車輛功能之間的復雜關系，并且還支持供貨商在制造之前詳細定義獨立ECU接口的細節(jié)。

　　

　　

一款現(xiàn)代化豪華汽車可能包含多達100個ECU，包括從簡單的傳感器接口到復雜的娛樂信息及遠程信息單元。將它們一次全部改用AUTOSAR方法和標準的風險很高，但原始設備制造商和一級供貨商做出這樣的改變會帶帶來許多的效益。預計到2020年，所有車輛都將擁有一些基于AUTOSAR的ECU，因此不可忽視該標準的存在。

　　

改用AUTOSAR的一些原因和效益包括：

　　

能在新的汽車平臺和架構(gòu)中更好地重新使用電子控制單元；

能更好地使用預先驗證和測試過的軟件組件（代表車輛功能）；

能減少下游設計錯誤——一套AUTOSAR方法可讓功能在架構(gòu)級別就可定義和驗證；

通過改善網(wǎng)絡效率和功能運用而減少整體硬件成本；

能減少整體網(wǎng)絡架構(gòu)分析和設計審查的成本；

因使用一種標準化的數(shù)據(jù)交換格式（AUTOSARXML或arxml），從而改善了原始設備制造商和一級供貨商之間的通信。

　　

不論在整個內(nèi)部設計周期內(nèi)是否需要對ECU進行重新設計或改進，改用AUTOSAR可加速設計調(diào)整。例如新工具的工作流程，或為了有助于保持與ISO26262標準的符合性（conformance），這些都會改變工作的流程，改用AUTOSAR方法可在變更流程時同時導入。不論如何實施調(diào)整，第一個基于AUTOSAR電子控制單元設計項目所花的時間，都要比現(xiàn)有/傳統(tǒng)設計流程所花的時間來得更長，這是因為設計人員需要時間來熟悉新的方法。但隨后即可帶來節(jié)省成本和提升效益的成果。將傳統(tǒng)的ECU資產(chǎn)轉(zhuǎn)向AUTOSAR標準也是有可能的，通過采用“AUTOSAR封裝（AUTOSAR Wrapper）”概念，重要的現(xiàn)有和經(jīng)過證明的電子控制單元應用代碼便可重復使用。使AUTOSAR的封裝能夠?qū)肫渌傾UTOSARECU。這將有助于降低轉(zhuǎn)用AUTOSAR方法的風險。

　　

　　

就本質(zhì)而言，AUTOSAR提供標準的ECU接口定義，使設計人員能夠具體指定每個汽車ECU中都需要的可重復使用之標準化軟件層和組件。該標準不受硬件的影響，這意味著應用軟件和硬件平臺是相互獨立的。應用軟件開發(fā)人員可在應用軟件中明確地說明各個汽車功能的細節(jié)，而不用擔心相關軟件服務和硬件接口。過去，軟件和硬件緊密地整合在一起，因此很難實現(xiàn)可移植性和可重復使用（圖1）。

　　

圖1：將應用軟件與硬件分開。

　　

將設計與硬件決策分開使車輛生產(chǎn)商/OEM能夠依據(jù)所需的車輛功能進行自上而下的設計。存在于這個設計時間的虛擬功能總線（VFB）概念讓所有軟件電子控制單元都能夠?qū)崿F(xiàn)互連和獲得測試。這讓設計人員可專注于應用層，而不是根本的軟件基礎建設。通過采用虛擬功能總線，應用軟件組件（SWC）與其它應用軟件組件也相互獨立。軟件組件向虛擬功能總線發(fā)出輸出信號，虛擬功能總線再將信息傳送給目標組件的輸入埠。AUTOSAR定義了輸入和輸出端口，以及交換信息的格式。這種抽離式的（abstracted）方法使得在定義相關硬件之前可實現(xiàn)所有車輛軟件功能和接口交互驗證。設計調(diào)整也因此變得容易得多，同時所有功能都被定義成虛擬功能總線上的軟件組件（圖2）。

 

圖2：在虛擬功能總線上測試軟件組件。

 

雖然虛擬功能總線不提供ECU之后在真實車輛中如何分布和互連的信息，但對架構(gòu)設計時間來說，卻是很有用的測試基準?？蔀檐囕v中的所有信號進行定時檢查和接口定義。

　　

一旦設計人員對各項功能感到滿意，這些功能便會被映像或聚集到特定的硬件電子控制單元中。AUTOSAR可支持軟件組件的映像和聚集流程。一個復雜的ECU可能包含很多軟件組件，必要時可依照階層式的方式將它們組織起來。

 

圖3：將軟件功能分配給真正的電子控制單元。

　　

　　

每個ECU都有為它量身定制的運行環(huán)境（RTE），通常可通過配套的設計工具來自動創(chuàng)建。真正的電子控制單元之間的實際通信將實現(xiàn)成CAN或Flex Ray總線的一部分，而運行環(huán)境通過產(chǎn)生工具進行配置，以便執(zhí)行相連AUTOSAR組件所需的通信路徑。運行環(huán)境可以切實執(zhí)行虛擬功能總線和架構(gòu)設計流程的通信和連接拓撲。由于AUTOSAR標準支持很多不同類型的軟件組件，運行環(huán)境必須考慮各種軟件組件存在的限制和變化。

　　

　　

基礎軟件（BSW）是一種標準化軟件，不包含車輛應用邏輯和電子控制單元功能，但為運行環(huán)境提供依賴硬件和獨立于硬件的服務。所需的服務包括內(nèi)存服務（NVRAM管理器）、網(wǎng)絡通信管理服務、診斷服務和狀態(tài)管理。當應用層中定義的AUTOSAR軟件組件要求服務時，運行環(huán)境的任務是在真正的電子控制單元上完成映像。

　　

運行環(huán)境不提供任何可從遠程ECU獲取服務的機制，AUTOSAR規(guī)范也不允許這樣做。所有服務要求都必須在“本地”電子控制單元上獲得滿足。在真正的電子控制單元上運行的基本操作系統(tǒng)（OS或OSEK）不知道AUTOSAR“可運行的（runnable）”概念。操作系統(tǒng)擁有一個可調(diào)度活動列表，這些活動通過調(diào)度算法進行管理。

　　

　　

AUTOSAR分層軟件架構(gòu)可以分離硬件的應用邏輯（application logic），以便重復利用和可以攜帶（portability）。運行環(huán)境和操作系統(tǒng)與微控制器抽象層（MCAL）相連，MCAL提供了對主微控制器上物理埠和設備的存取功能。微控制器抽象層是每一微控制器所特有的，使操作系統(tǒng)和基礎軟件能夠存取數(shù)字輸入/輸出、模擬數(shù)字轉(zhuǎn)換、FLASH和EEPROM支持等設備。圖4說明了AUTOSAR電子控制單元中不同硬件和軟件層之間的關系。

 

圖4：組件在真正的電子控制單元中如何組裝在一起。

　　

　　

汽車OEM可以通過一個自上而下的AUTOSAR設計方法，操作整個網(wǎng)絡的完整模型。AUTOSAR設計工具可以讓單一的ECU被提取，且在AUTOSARXML（arxml）中定義了連接性和接口信息。這個接口定義之后將傳給一級供貨商，進行進一步的細節(jié)設計和實施。由于格式已被標準化，相同的定義可以在公開投標時同時分送給幾個一級供貨商。標準化描述的好處在于在ECU描述中可以避免任何設計上的模棱兩可，并且隨著AUTOSAR標準的發(fā)展，存在誤解的可能性也越來越小。由于這個標準與硬件無關，因此能夠更充分地利用新產(chǎn)業(yè)趨勢所帶來的效益，如車內(nèi)以太網(wǎng)、混合技術(shù)車輛網(wǎng)絡（CAN/Flex ray）、異構(gòu)多核平臺以及車載網(wǎng)關布置。

　　

　　

包括Mentor Graphics在內(nèi)的一些業(yè)者已經(jīng)可為AUTOSAR設計提供評估套件。這些套件包括架構(gòu)設計到單個ECU配置。Mentor Graphics還擁有其VSX工具套件以及支持CAN、Flex Ray、LIN和以太網(wǎng)的ECU硬件開發(fā)板。這些工具以Eclipse為基礎，利用開源工具鏈進行從源代碼到運行實施的一系列設計。相對于大規(guī)模地將車內(nèi)ECU一次就完全改到AUTOSAR方法來說，低風險調(diào)查和AUTOSAR試驗更為可取。

　　

AUTOSAR為車載網(wǎng)絡和ECU設計提供預定義的標準方法，找到了進入每家汽車OEM和一級機構(gòu)的方式。AUTOSAR標準提供了改善工藝和重新利用組件的機會，但是也帶來了學習新ECU設計流程和工具的挑戰(zhàn)。AUTOSAR的早期采用者一直都在把這些知識傳給主流的設計和資源，而現(xiàn)今市面上也有多款可用于量產(chǎn)的工具。AUTOSAR的采用還可協(xié)助業(yè)者達到功能安全標準ISO26262的要求，因為它支持一個可重復、定義明確、且自上而下的設計流程。