本篇文章給大家談談Autosar軟件開發有前途嗎，以及adas軟件開發對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、博世華域autosar軟件開發怎么樣
• 2、autosar開發的人員需要多少
• 3、汽車開放系統架構AUTOSAR
• 4、什么是autosar
• 5、奔馳聊聊執行器哪些事

博世華域autosar軟件開發怎么樣

博世華域autosar軟件開發好。博世華域autosar軟件開發薪資高，待遇好，所以博世華域autosar軟件開發好。博世華域autosar軟件開發人員每月薪資2萬元，而且還有年終獎5萬元。博世華域autosar軟件開發是根據開發汽車電子建造出軟件系統或者系統中的軟件部分的過程。軟件開發是一項包括需求捕捉、需求分析、設計、實現和測試的系統工程。

autosar開發的人員需要多少

沒有限制。每一個信息公司以及智能產品的制造公司都會專門招聘autosar開發人員，所以該種人員的需求人數并沒有限制。autosar開發人員就是指Autosar軟件開發工程師，崗位職責是負責基于ClassicAutosar的基礎軟件開發、集成、測試等。

汽車開放系統架構AUTOSAR

汽車開放系統架構AUTOSAR

AUTOSAR簡介：

 AUTOSAR(汽車開放系統架構)，汽車開放系統架構聯盟是由全球汽車制造商、部件供應商及其他電子、半導體和軟件系統公司聯合建立，各成員保持開發合作伙伴關系。自2003年起，各伙伴公司攜手合作，致力于為汽車工業開發一個開放的、標準化的軟件架構。AUTOSAR這個架構有利于車輛電子系統軟件的交換與更新，并為高效管理愈來愈復雜的車輛電子、軟件系統提供了一個基礎。此外，AUTOSAR在確保產品及服務質量的同時，提高了成本效率。

AUTOSAR應用：

 寶馬集團自2001年即開始在稱為BMW Standard Core的架構下，在ECU電子控制單元中運用標準化基礎軟件。該軟件覆蓋車輛管理系統各個層面的功能，包括執行(如車輛能量流管理系統、停車準備功能)，系統管理(如系統的編碼與診斷)，到系統定制(如個性化定制功能，可設定特殊條件的服務定制功能)。

 現在，應用于全新7系的BMW Standard Core軟件系統通過AUTOSAR架構實現對車載網絡、系統內存管理以及大部分的系統診斷功能。此外，全新BMW 7系所采用的多個ECU的運行系統與AUTOSAR架構相匹配，允許各應用程序獨立運行。例如中央網關，該ECU確保了外部I/O系統(以太網和CAN總線)與內部I/O系統總線(CAN，MOST，FlexRay)間高速寬帶連接。同時它還可以調節一些內核功能，如車況監測、系統編碼和能量消耗檢測等。

 關于ECU電子控制單元未來的發展，寶馬集團堅定地支持應用、推廣AUTOSAR架構。一個精心制定的計劃已經開始實施，相關的供應商也被納入相關規劃。針對驅動系統、底盤、安全系統、內部和車身的研發應用已經全面展開。

 在Elmar Frickenstein看來，AUTOSAR架構的優勢顯而易見：“未來的車型將普遍受益于全行業統一的標準化程序，以及通用性、互換性更強的軟件。AUTOSAR界面的標準化以及供應商通用工具軟件的應用將促進該領域的進一步發展。

AUTOSAR在中國：

 國內的各大汽車廠商、科研院校也越來越關注AUTOSAR帶來的標準化的設計、開發、驗證，從而大幅提高汽車電子的研發效率和研發質量。

 一汽、長安等整車廠技術研究院也于2009年開始利用AUTOSAR標準的工具進行ECU的設計、開發、驗證。

 值得注意的是，普華基礎軟件股份有限公司（iSOFT），作為Autosar的成員，已經在中國聯合上汽、一汽、長安、奇瑞等主要OEM和部分院校成立了CASA聯盟，旨在中國推廣和發展Autosar架構。普華已具備一些列基于Autosar的工具鏈，如OrientaisStudio，BSW配置工具。

 汽車開放系統架構AUTOSAR @2019

什么是autosar

【太平洋汽車網】Autosar（AUTomotiveOpenSystemARchitecture）就是汽車開放式系統架構。這是一個由整車廠，零配件供應商，以及軟件、電子、半導體公司合起來成立的一個組織。自從2003年以來，就致力于為汽車電子行業提供一個開放的、標準的軟件架構。

汽車開放系統架構聯盟是由全球汽車制造商、部件供應商及其他電子、半導體和軟件系統公司聯合建立，各成員保持開發合作伙伴關系。Autosar成員包括四類：CoreParteners（核心成員），PremiumPartners（高級成員），DevelopmentPartners（開發成員），AssociatePartners（一般成員）。核心成為有9個，分別為：博世，大陸，大眾，豐田，通用，PSA，福特，寶馬，奔馳。小編看了Autosar組織里的成員，其中也不乏國內的企業，包括：長城，新能源、一汽、東風、經緯恒潤、普華軟件、上汽。

Autosar最重要的目標就是基本系統功能與函數接口的標準化，這使得開發合作伙伴可以在車載網絡里直接進行數據的整合、交換、傳輸功能，使得整車E/E架構由傳統的基于ECU的開發（ECU-based）轉變為基于功能的開發（function-based）。

Autosar整體優點就是提高軟件的重復利用度，增加設計的靈活性，在長期上可以減少開發成本，也更加專注于競爭模塊的開發。

（圖/文/攝：太平洋汽車網李苑麗）

奔馳聊聊執行器哪些事

操作系統，中間件，應用軟件-各司其職分工不同

操作系統-我負責對硬件，提供線程創建等服務，其他我不管

中間件-我負責和不同操作系統對接，并給上面應用提供通訊，資源管理等服務，其他我不管

應用軟件-嗯，剩下都我的事，我管功能，不同系統，不同硬件的事我不管。

中間件(middleware)是基礎軟件的一大類，在操作系統、網絡和數據庫之上，應用軟件的下層，總的作用是為處于自己上層的應用軟件提供運行與開發的環境，幫助用戶靈活、高效地開發和集成復雜的應用軟件。在不同的技術之間共享資源并管理計算資源和網絡通信。

另外中間件的定位不是操作系統，而是一套軟件框架，雖然包括了RTOS，MCAL，服務通信層等協議和服務。兩者看著很接近，但沒有多少競爭關系。

什么是汽車軟件中間件？

隨著汽車應用要求的不斷提高，軟件總量也隨之迅速增長，這導致了系統的復雜性和成本的劇增，為了提高軟件的管理性、移植性、裁剪性和質量，需要定義一套架構( Architecture )；方法學( Methodology )和應用接口( Application Interface )。從而實現標準的接口、高質量的無縫集成、高效的開發以及通過新的模型來管理復雜的系統。

目前在汽車控制領域有多種總線標準，各側重點有所不同。盡管總線通信速度越來越高，但是還沒有通信網絡可以完全滿足未來汽車的所有成本和性能要求，因此需要兼容多種總線和底層協議的通信協議和規范。

中間件的核心思想在于“統一標準、分散實現、集中配置”。統一標準才能給各個廠商提供一個通用的開放的平臺；分散實現則要求軟件系統層次化、模塊化，并且降低應用與平臺之間的耦合度；不同模塊來自不同的廠商，它們之間存在復雜的相互聯系，要想將其整合成一個完善的系統，必須要求將所有模塊的配置信息以統一的格式集中管理起來，集中配置生成系統。

這個架構還需要具備如下功能：解決汽車功能的可用性和安全性需求；保持汽車電子系統一定的冗余；可以移植到不同汽車的不同平臺上；實現標準的基本系統功能作為汽車供應商的標準軟件模塊；通過網絡共享軟件功能；集成多個開發商提供的軟件模塊；在產品生命期內更好地進行軟件維護；更充分地利用硬件平臺的處理能力；可實現汽車電子軟件的更新和升級等。

汽車軟件中間件有什么好處？

所有把標準統一后的服務的優勢都大同小異，總結主要幾點

跨配置，跨車型，跨平臺，跨硬件適應

提高了效率，軟件開發聚焦差異化

軟件認證有標準可依

方便行業軟件互換，降低進入門檻

更簡單的集成已有工具鏈，支持從設計到代碼全流程

對于Autosar，說實話，最有利的是OEM和基礎軟件公司，OEM可以標準化接口，自己做應用層或找軟件公司開發應用，基礎軟件公司可以多賣軟件。最不愿意的是tier1，因為增加了成本，還逐步可能淪為硬件生產商。但這個也不能說是autosar的鍋，軟件定義汽車下這個趨勢的發展是必然的。

汽車軟件中間件有什么缺點？

老實講，這塊大家講的很少，都說這個很美好，但實際操作過程中，我覺得是軟硬件一體設計上的阻礙。

值得注意的像Tesla這樣的新興企業并沒有使用autosar這是為什么？所有平臺性的軟件，都有一個弊病，就是為了兼容一致性，會對軟硬件協作的效率帶來影響，autosar也不例外。

我感覺“Autosar就是汽車行業的塞班系統，看似很好，很標準，但是最終會被淘汰。就像當年的諾基亞一樣，原因是最后會被一個軟硬件集成度更好的iphone取代，iphone可不糾結能夠給其他公司用自己的系統。

從商業和成本角度看

Autosar設計上已經有些落后，代碼臃腫，對成本影響很大。打個比方，北美一個程序員一年的cost也就是15萬美金，自己完成底層的開發就這個價，使用Autosar的工具鏈和代碼臃腫帶來的升級MCU開銷遠大于節省的這部分開發成本。細分Autosar的成本：

1.開發成本:首先需要購買autosar，本身就是成本，autosar包含的模塊多，肯定要貴，但不一定所有的都會被用上。其次是人力投入，對于一個原來就有其他平臺的新的第一個項目轉換到autosar是增加人力的，對于新公司，購買autosar是降低人力的，很多模塊不用自己開發了。對于建立平臺以后的項目，實際差不多。

2.生產成本:首先是硬件成本，現在MCU越來越便宜，用不用autosar基本沒區別，如果說存儲空間特別小的MCU，比如防夾模塊，本來也沒要求autosar。其次是軟件成本，這個才是問題，跟以前基礎軟件不同autosar現在收量產license費。

從技術角度看

關于autosar的應用，autosar之前定義的主要就是BCM、TCU、EMS、ESP等要求實時控制的ECU。不是針對***
 系統，自動駕駛MPU的，當然這些控制器里也有MCU，可以用運行autosar的MCU。autosar現在最擅長的是16bit MCU以及不太復雜的32bitMCU。32bit以上的MCU，需要RTOS支持，比如自動駕駛軟件。車的中控也不可能基于autosar,也是因為沒有一個強有力的RTOS， 在越來越強調security的軟件開發中，AUTOSAR也沒有進程隔離的概念。前景難料.

中間件的明星方案-AUTOSAR

所有中間件方案中，最著名的是AUTOSAR, 其是由各大整車廠商和零部件廠商開始著手聯合制定軟件的標準化接口。AUTOSAR(AUTomotive Open System ARchitecture)是由全球的主要汽車生產廠商、零部件供應商、軟硬件和電子工業等企業(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽車開放式系統架構標準。

2003年7月，由寶馬、博世、大陸、戴姆勒-克萊斯勒、西門子VDO和大眾聯合成立AUTOSAR發展聯盟，為汽車E/E架構建立了一種開放式的行業標準。

2003年11月，福特公司作為核心伙伴加入，12月標致雪鐵龍和豐田汽車加入。接下來的11月通用汽車也作為核心伙伴加入。自從西門子VDO被大陸在2008年2月收購后，它就不再作為AUTOSAR的獨立核心伙伴。

第一階段（2004-2006）：標準基本開發時期（版本1.0.2.0和2.1）

第二階段（2007-2009）：體系和方法相關方面擴展（版本3.0，3.1和4.0）

第三階段（2010-2013）：可維護性和可選擇性的改進（版本3.2，4.1和4.2）

在2013年，AUTOSAR聯盟進入一種持續改進模式，主要用來維持標準和提供所選擇的改進,往后實際上，autosar更新就很少了，開始轉向AUTOSAR-Adaptive。

AUTOSAR-Adaptive拯救AUTOSAR

對于用于實現典型動力總成和底盤功能的深度嵌入式系統，AUTOSAR經典平臺仍將是首選。在低成本硬件上運行時，對安全性、實時性和確定性要求較高。同時，AUTOSAR為這些應用程序提供了一個經過良好驗證的成熟軟件平臺，包括一個廣泛使用的方法，它支持當今所有的協作模型。而為了支持客戶應用程序的動態部署，并為需要高端計算能力的應用程序提供環境，AUTOSAR在2017年推出了第二個軟件平臺，即AUTOSAR Adaptive platform。這個想法是盡可能從其他領域(如消費電子產品)的發展中獲益，同時仍然考慮汽車的特定要求，如功能安全。

Adaptive需要支持，未來E/E架構的兩個關鍵特征是：

1) 異構軟件平臺的集成，當今汽車的網絡架構可以聚集成不同的領域，用于信息***
 和連接、底盤、動力系統等。雖然infotainment ECUs通常使用Linux、QNX或其他通用操作系統，但AUTOSAR Classic平臺是深度嵌入式控制單元的標準。隨著新的用例和對計算能力的深入嵌入式應用程序不斷增長的需求，第三種ecu將出現，它具有不同的特性，必須集成到現有的E/E體系結構中。

2) 面向服務和基于信號的通信，傳統的汽車通信仍然是基于ecu向其他ecu提供信號廣播的思想。這種范式非常適合于有限大小的控制數據，這些數據必須循環地進行通信。先進的應用程序，如高自動化駕駛與更高的負載要求，例如交換對象列表檢測到的一組傳感器和以太網作為一個通信系統需要更復雜的協議。面向服務通信的概念是基于在通信系統上提供服務的應用程序和訂閱此服務的其他應用程序。然后數據只發送給訂閱服務器。

面向服務的通信與現有的基于信號的范式的結合是未來E/E體系結構的第二個關鍵方面，從這個角度來看，這是一個艱巨的挑戰。

為了解決AUTOSAR僵化的問題，Adaptive希望可以找到一種中間過程平臺

ADAPTIVE為承載這些功能的軟件基礎設施增加了新的需求。除了現有的需求(如功能安全和安全性)，軟件架構還必須支持硬件(如具有高端計算能力的硬件)、空中更新、與后端系統的通信或應用程序的動態部署。

AUTOSAR Adaptive擴展了AUTOSAR平臺，以滿足當前汽車自動駕駛、電氣化和互聯互通等趨勢的需求。因此，它在許多方面改變了已建立的E/E開發過程。最重要的變化是，基于信號的通信被面向服務的設計所取代。c++取代了C語言作為自適應應用程序的編程語言，以及基于posix的操作系統(如Linux用于自適應電子控制單元)是進一步的突破性轉變。

AUTOSAR Adaptive 組件封裝了SOA軟件底層的通訊細節(包括SOME/IP協議，IPC等)，同時提供代理(Proxy)-骨架(Skeleton)模型，該模型以C 面向對象語言描述，方便上層應用開發人員調用標準服務接口(API)進行開發。Application Design Model是該模型另一種可配置的呈現，開發人員通過使用相應的配置工具對Application Design Model進行描述和配置，即可實現基于SOA服務架構的軟件落地和部署。聯合電子使用AUTOSAR Adaptive組件完成SOA服務架構軟件的開發

可以看到，自適應Autosar又找到了延續自己生命的另外一個理由，提供了一種由現在信號導向的架構往SOA架構的標準。未來由于控制器數量大幅度降低, 類似特斯拉這樣的車企多半是不理會自適應AutosarAdaptive

與此同時，更多的相關配套供應商也在加快與AUTOSAR自適應平臺的對接。去年11月，Real-Time Innovations（RTI）宣布，AUTOSAR最新版本的自適應平臺（版本18-10），已經具有數據分發服務(DDS)標準的完整網絡綁定。這意味著汽車制造商現在可以使用DDS實現AUTOSAR自適應框架，并開發高度自動駕駛系統，如4級和5級。DDS允許AUTOSAR完全支持高度自動駕駛系統，并提供“量產級通信框架”，保證這些復雜系統所需的可靠性、可伸縮性和性能。比如，在AUTOSAR中完全指定了DDS之后，汽車行業現在可以使用RTI Connext和DDS開發高性能應用程序，比如傳感器融合應用程序。

AUTOSAR版本18-10有助于解決OEM軟件開發團隊在支持不同價格區間車型時所面臨的各種安全和連接性挑戰。此外，允許開發人員“動態配置平臺”，以支持每個車型平臺的各種操作模式和硬件功能。

技術細節-AUTOSAR的分層設計

架構層面

AUTOSAR定義一個軟件分層架構以支持汽車電子系統的集成。其體系架構從上至下依次為應用層、運行環境層(RTE)、以及基礎軟件層（BSW)

接著再復雜一些，BSW再分為復雜驅動模塊， 微控制器抽象層、ECU抽象層、系統服務層

(1)應用層。包括應用軟件組件、傳感器和執行器軟件組件，都位于應用層。該層的軟件組件通過RTE進行內部通訊和訪問ECU資源。應用層的軟件實現獨立于微控制器、ECU。

(2)RTE層。RTE層為應用層提供通訊服務。RTE層的實現與ECU和具體應用相關，必須為每個ECU分別實現，AUTOSAR軟件組件之間通信需要通過RTE。

(3)服務層。包含RTOS、通信與網絡管理、內存管理、診斷服務、狀態管理、程序監控等服務。它為應用和基礎軟件模塊提供基本服務，包括：操作系統服務、汽車網絡通訊和管理服務、存儲服務、診斷服務和ECU狀態管理。服務層的實現部分與微控制器、ECU和具體應用相關。

(4)ECU抽象層。ECU抽象層抽象出ECU結構，如外設與ECU的聯接方式等．雖然該層與ECU平臺相關，但是與微控制器是無關的。這種無關性是由微控制器抽象層來實現的。其中封裝了微控制器層及***
設備的驅動，并對微控制器內外設的訪問進行了統一，實現了軟件應用層與硬件系統的分離

(5)微控制器的抽象層(microcontroller abstraction layer，MCAL)。位于基礎軟件的最底層，包含了訪問微控制器的驅動（如I/O驅動、ADC驅動等），做到了上層軟件與微控制器的分離，以便應用的后續的移植復用。微控制器的抽象層是實現不同硬件接口統一化的特殊層，通過微控制器的抽象層可將硬件封裝起來，避免了高層軟件直接與微控制器的寄存器打交道。MCAL提供消息機制，并以此將指令、響應和信息分離成不同的過程。微控制器抽象層包括微控制器相關的驅動，它負責管理微控制器的外部設備，并將微控制器的信號提供給基礎軟件的元件。

(6)復雜驅動層，由于其嚴格的時序為應用層通過RTE訪問硬件提供支持。

再復雜一些

再再復雜一些

接著我們從RTE層往上看

運行時環境( RTE )是應用軟件和基礎軟件通信的橋梁，無論通信發生在 ECU之間( 如通過CAN、LIN、FlexRay、MOST等網絡) ，還是在ECU內部，RTE均通過提供一致的接口和服務來實現SWC之間的通信抽象，其最終實現會因ECU的不同而有所差異。一般情況下，每一層只能使用下一層的接口，并向上一層提供服務接口。

應用層中的功能由各軟件組件（SWC）實現，組件中封裝了部分或者全部汽車電子功能，包括對其具體功能的實現以及對應描述，如控制大燈，空調等部件的運作，但與汽車硬件系統沒有連接。

在設計開發階段中，軟件組件通信層面引入了一個新的概念，虛擬功能總線VFB（Virtual Functional Bus），它是對AUTOSAR所有通信機制的抽象，利用VFB，開發工程師將軟件組件的通信細節抽象，只需要通過AUTOSAR所定義的接口進行描述，即能夠實現軟件組件與其他組件以及硬件之間的通信，甚至ECU內部或者是與其他ECU之間的數據傳輸。

因此軟件組件只需向VFB發送輸出信號，VFB將信息傳輸給目標組建的輸入端口，這樣的方式使得在硬件定義之前，即可完成功能軟件的驗證，而不需要依賴于傳統的硬件系統。

中間件RTE與面向對象OO（object oriented）的編程思想非常接近，所有ECU所對應的RTE都是特定的，它負責著軟件構件間以及軟件構件與基礎軟件之間的通信。對于軟件構件來說，基礎軟件不能夠直接訪問，必須通過RTE進入。因而RTE也被理解成是VFB的接口實現。

而構件之間及構件與基礎軟件的通信關系如圖所示：

AUTOSAR軟件構件無法直接訪問基礎軟件中的操作系統OS，因而在應用程序中就不存在「task」的概念，且不能動態創建線程，因此并行的任務由RTE直接管理調入的「構件運行實體」來實現。每個軟件構件也許會有一個或者多個運行實體，但是一個運行實體只對應一個入口。

方法學層面

「AUTOSAR方法論」是指在汽車電子系統開發的某些步驟中所需要的通用技術方法。

1、 但AUTOSAR方法既非完整的過程描述也不是商業模式，也沒有定義「角色」和「責任」。

2、 方法論僅是一個work-product flow，并定義了其中的依賴關系。

根據AUTOSAR方法論，完整的基于AUTOSAR規范的配置生成過程分為以上圖示兩部分，即系統配置過程及ECU配置過程。兩者之間并無先后關系，系統配置過程中的輸入包內含有ECU配置的相關模塊，ECU配置也會反饋于系統配置。

系統配置過程：

系統配置輸入（System Configuration Input）必須被定義好，AUTOSAR傾向于通過信息交換格式（軟件構件、ECU資源、系統限制）以及模版來減少這些廚師系統設計決定的正式描述。模板包含三部分：

軟件構件的描述：定義每個需要的軟件構件的接口內容，如數據類型、端口、接口等

系統約束描述：如總線信號的定義、拓撲結構與軟件構件之間的映射關系

ECU資源描述：定義每個ECU的資源需求，如處理器、外部設備、存儲器、傳感器以及執行器

配置步驟如下

輸入的系統配置文件借助配置系統（configure-system）將軟件構件映射到資源與計時要求相關的ECU上，所得到的文件就是系統配置描述文件（system configuration description）。其中包含了軟件構件與ECU映射時所需注意的限制條件，以及通信矩陣（Communication-Matrix），矩陣中描述了整車網絡結構中的數據包內容及其時序關系。

ECU配置過程

系統配置完成后，生成了系統配置描述文件，作為ECU配置過程的輸入。

Extract ECU-Specific Information會負責從系統配置文件中剝離出各ECU相關的系統配置信息，如通信矩陣、拓撲結構、頂級功能組合，生成到ECU Extract of System Configuration中。

Configure ECU的是生成包含了特定ECU局部信息的ECU Configuration Description，而這些信息可以構件該特定ECU的可執行軟件。

Generate Executable根據從ECU Configuration Description中得到的信息生成可執行程序。

AUTOSAR 的特性使得當ECU底層硬件配置升級時，也并不一定要牽動其他軟件系統，正因其統一的標準規范，越來越多的企業將會加入到其中，這也為未來汽車電子行業內高效管理以及復用愈加復雜的汽車軟件系統奠定了基礎。

AUTOSAR 中SWC(Software Component Description)包含下列信息: 該SWC用到或被用到的Operation和Data，SWC對基礎構架(網絡)和對硬件(延遲時間，定時等)的要求，SWC使用的資源 (存儲器, CPU時間等)，運行機制(重復率)，SWC軟件接口。

AUTOSAR中ECU Resource Description包含下列信息:描述使用到的硬件:傳感器，執行器，存儲器，處理器，通信外部設備（如收發器），引腳分配。

AUTOSAR中System Constraint Description中包含下列信息:網絡拓撲，限制，協議，通信矩陣，波特率，定時，ECU映射。

系統配置主要是將端口數據映射到通信矩陣，將SWC映射到ECU。ECU配置主要是將runnable(可運行實體)映射到task(任務)中。對以上各項內容角色分工

接口層面

AUTOSAR各層軟件的交互通過三類接口實現，分別是標準接口、AUTOSAR接口和AUTOSAR標準接口。其中，標準接口用于BSW各個模塊之間的交互，已用C語言定義，如void Adc_Init (const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于軟件構件（Software Component, SW-C）之間的交互或者軟件構件和ECU硬件（IO硬件抽象、復雜設備驅動）之間的交互，這類接口命名以“Rte_”為前綴。AUTOSAR標準接口用于軟件構件訪問AUTOSAR服務。

依賴這種分層架構和接口定義，AUTOSR顯著提高了汽車電子嵌入式軟件的復用性——層級越高者，復用性越強。值得注意的是：

微控制器抽象層層級最低，隨微控制器的更換而更換；

RTE雖然層級僅低于應用層，但由于它承擔著應用層和BSW之間的橋梁作用，和硬件的耦合性最高，不具有復用性；

應用層(除傳感器、執行器相關的軟件構件外)完全獨立于硬件，具有絕對的復用性。

AUTOSAR在定義軟件架構和接口的同時。也定義了易于交換的硬件平臺標準。AUTOSAR標準不僅提供了基礎軟件模塊的規范。還提供了用于開發分布式系統應用軟件的方法。這種方法以基于模型的軟件和分布式系統描述開始。以自動代碼生成和可重復的測試結束。

Autosar也定義了與網絡總線接口相關的模塊，CAN,LIN等網絡總線接口驅動、診斷等。AUTOSAR的出現使得ECU中的軟件包括網絡總線通信軟件第三方供貨成為可能。未來的網絡總線標準是否仍然各自獨立、互不兼容，目前還無法斷定，但AUTOSAR卻實實在在地將部分標準公開化、標準化，兼容化，而且實際的產品也已經被應用，AUTOSAR已對現在相互之間封閉的網絡總線標準形成挑戰。

此外，AUTOSAR還定義了一套標準的軟件開發流程，從系統建模到生成可執行的代碼，包括軟件組件設計、系統配置、ECU配置和代碼生成三大流程，如圖

技術細節-AUTOSAR ADAPTIVE架構介紹

活動推薦：

ICVS中國智能汽車及自動駕駛博覽會，暨同期：中國智能汽車產業鏈展

2022年9月26-29日

江蘇·蘇州國際博覽中心

30,000m2展覽面積

100場會議演講

500家參展企業

30,000專業觀眾

點擊進入ICVS智能汽車產業聯盟主頁—進入菜單欄展會報名頁面，即可免費領取參觀門票，現階段報名還將獲取更多報告福利。

關于Autosar軟件開發有前途嗎和adas軟件開發的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。