轉自：https://mp.weixin.qq.com/s/Z87xlYjOrRwKA0iUG5nYDQ
AUTOSAR的由來與發展曆程
1
AUTOSAR的由來
電子技術在動力總成控制、底盤控制、車身控制以及車載資訊娛樂系統等各個部分所占的比重越來越大，所占的整車成本也越來越高。電子技術已悄然成為汽車各方面功能拓展和性能提升的重要技術支撐。
由于汽車電子硬體系統的多樣性，ECU軟體的開發受到硬體系統的制約，每當需要更新硬體時，都會導緻ECU軟體重新編寫或大規模修改，之後還要進行一系列測試，進而導緻了高昂的研發費用與漫長的研發周期。
目前，汽車電子網絡正向多總線混合網絡互聯方向發展；電控系統硬體正向專業化、高內建度、高性能方向發展，其軟體架構也正向子產品化、平台化、标準化方向發展。并且，未來随着汽車新能源化和智能化的普及，以及對于一些非功能需求的增加，汽車電子/電氣系統的複雜度也将進一步提升。這都将進一步導緻新産品開發周期、成本的急劇增加。整車廠為了降低汽車控制軟體開發的風險，于是開始尋找提高軟體複用度的方法。
為解決上述問題，基于先前EAST-EEA項目的研究成果，在2003年，由全球汽車制造商、零部件供應商及其他電子、半導體和軟體系統公司聯合建立了汽車開放系統架構聯盟（AUTomotive Open System ARchitecture，AUTOSAR），并聯合推出了一個開放化的、标準化的汽車嵌入式系統軟體架構——AUTOSAR規範。與傳統ECU軟體架構相比，AUTOSAR分層架構的高度抽象使得汽車嵌入式系統軟硬體耦合度大大降低。
AUTOSAR規範的出現，将帶來如下主要優勢：
①有利于提高軟體複用度，尤其是跨平台的複用度；
②便于軟體的交換與更新；
③軟體功能可以進行先期架構級别的定義和驗證，進而能減少開發錯誤；
④減少手工代碼量，減輕測試驗證負擔，提高軟體品質；
⑤使用一種标準化的資料交換格式，友善各公司之間的合作交流等。
這些優勢對将來愈發複雜的汽車嵌入式系統軟體的開發過程可謂是大有裨益，在保證軟體品質的同時，可以大大降低開發的風險與成本。
2
AUTOSAR的原則及核心思想
AUTOSAR聯盟自成立至今，一直提倡“在标準上合作，在實作上競争”的原則，标準大家共同制定，但具體的實作方法是由各公司自己去探索的。其核心思想在于“統一标準、分散實作、集中配置”。“統一标準”是為了給各廠商提供一個開放的、通用的平台；“分散實作”要求軟體系統高度的階層化和子產品化，同時還要降低應用軟體與硬體平台之間的耦合；不同的子產品可以由不同的公司去完成開發，但要想完成最終軟體系統的內建，就必須将所有子產品的配置資訊以統一的格式集中整合并管理起來，進而配置生成一個完整的系統，這就是“集中配置”。
采用AUTOSAR将為OEM（主機廠）帶來很大的好處，使得其對于軟體采購和控制擁有更靈活和更大的權利。因為AUTOSAR不僅在軟體的功能上、接口上進行了一系列的标準化，還提出了一套規範化的開發流程與方法，這就使得能有更多的軟體供應商進入汽車電子行業，大家都遵循同一個标準去開發，最終比的是産品的功能和品質。
3
AUTOSAR的發展曆程及應用現狀
AUTOSAR聯盟從2003年成立至今，成員隊伍不斷壯大，标準内容日臻完美。AUTOSAR聯盟成員按等級分為核心成員（Core Partner）、進階成員（Premium Member）以及合作成員三類正式成員，基本涵蓋了世界上各大著名整車廠、零部件公司、半導體公司以及軟體工具提供商。
目前，AUTOSAR平台最新版為4.3.1。為了迎合未來汽車智能化、網聯化的需求，AUTOSAR聯盟推出了一個全新的平台——自适應AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并将現有平台更名為經典AUTOSAR平台（AUTOSAR Classic Platform，CP），AUTOSAR官網（https：//www.AUTOSAR.org/）也進行了更新，給人一種耳目一新的感覺。
AUTOSAR規範在國外的應用相較于國内更早、更普遍、更成熟。大衆、博世、通用、德爾福、菲亞特等公司已将符合AUTOSAR規範的軟體應用于它們的ECU産品。
德國大衆集團與MathWorks、Elektrobit（EB）等公司聯合開發了符合AUTOSAR規範的車身舒适控制系統，并應用于帕薩特車型。
瑪涅蒂瑪瑞利公司将AUTOSAR應用于菲亞特汽油發動機平台，并進行了硬體在環測試和不同工況下2萬千米行程的實車測試。此外，他們還将AUTOSAR運用于車燈控制、動力總成控制等電控系統。
ETAS公司成功将寶馬5系發動機管理系統開發為符合AUTOSAR規範的控制系統。開發人員利用ASCET進行軟體元件開發，管理軟體元件端口及其運作實體；使用RTA-OS開發AUTOSAR作業系統，配置、劃分、管理任務；應用RTA-RTE連接配接應用層和基礎軟體層；代碼內建後，進行了硬體在環仿真，結果表明與傳統開發方法相比複雜度降低50%。整個博世集團已将AUTOSAR架構應用于自适應巡航系統ECU、動力總成系統ECU、底盤控制系統ECU和車身控制子產品（Body Control Module，BCM）的開發，并且今後将運用于更多的ECU開發過程。
近年來，随着國内新能源汽車相關控制器正向開發需求的增長，AUTOSAR規範在國内越來越受到大家的關注，并且應用需求也越來越大。目前，上汽、北汽等國内主流整車廠以及一些零部件供應商都開始緻力于符合AUTOSAR規範的車用控制器軟體開發。AUTOSAR規範也有望成為未來整個汽車電子行業所普遍使用的軟體标準。
AUTOSAR分層架構
AUTOSAR規範主要包括分層架構、方法論和應用接口三部分内容。其中，分層架構是實作軟硬體分離的關鍵，它使汽車嵌入式系統控制軟體開發者擺脫了以往ECU軟體開發與驗證時對硬體系統的依賴。
在AUTOSAR分層架構中，汽車嵌入式系統軟體自上而下分别為應用軟體層（Application Software Layer，ASW）、運作時環境（Runtime Environment，RTE）、基礎軟體層（Basic Software Layer，BSW）和微控制器（Microcontroller）。為保證上層與下層的無關性，在通常情況下，每一層隻能使用下一層所提供的接口，并向上一層提供相應的接口。
1
應用軟體層
應用軟體層（Application Software Layer，ASW）包含若幹個軟體元件（Software Component，SWC），軟體元件間通過端口（Port）進行互動。每個軟體元件可以包含一個或者多個運作實體（Runnable Entity，RE），運作實體中封裝了相關控制算法，其可由RTE事件（RTEEvent）觸發。
2
運作時環境
運作時環境（Runtime Environment，RTE）作為應用軟體層與基礎軟體層互動的橋梁，為軟硬體分離提供了可能。RTE可以實作軟體元件間、基礎軟體間以及軟體元件與基礎軟體之間的通信。RTE封裝了基礎軟體層的通信和服務，為應用層軟體元件提供了标準化的基礎軟體和通信接口，使得應用層可以通過RTE接口函數調用基礎軟體的服務。此外，RTE抽象了ECU之間的通信，即RTE通過使用标準化的接口将其統一為軟體元件之間的通信。由于RTE的實作與具體ECU相關，是以必須為每個ECU分别實作。
3
基礎軟體層
基礎軟體層（Basic Software Layer，BSW）又可分為四層，即服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer，MCAL）和複雜驅動（Complex Drivers）。
上述各層又由一系列基礎軟體元件構成，包括系統服務（System Services）、存儲器服務（Memory Services）、通信服務（Communication Services）等。它們主要用于提供基礎軟體服務，包括标準化的系統功能和功能接口。
服務層（Services Layer）提供了汽車嵌入式系統軟體常用的一些服務，其可分為系統服務（System Services）、存儲器服務（Memory Services）以及通信服務（Communication Services）三大部分。提供包括網絡通信管理、存儲管理、ECU模式管理和實時作業系統（Real Time Operating System，RTOS）等服務。除了作業系統外，服務層的軟體子產品都是與ECU平台無關的。
ECU抽象層（ECU Abstraction Layer）包括闆載裝置抽象（Onboard Devices Abstraction）、存儲器硬體抽象（Memory Hardware Abstraction）、通信硬體抽象（Communication Hardware Abstraction）和I/O硬體抽象（Input/Output Hardware Abstraction）。該層将ECU結構進行了抽象，負責提供統一的通路接口，實作對通信、存儲器或者I/O的通路，進而不需要考慮這些資源是由微控制器片内提供的，還是由微控制器片外裝置提供的。該層與ECU平台相關，但與微控制器無關，這種無關性正是由微控制器抽象層來實作的。
微控制器抽象層（Microcontroller Abstraction Layer，MCAL）是實作不同硬體接口統一化的特殊層。通過微控制器抽象層可将硬體封裝起來，避免上層軟體直接對微控制器的寄存器進行操作。微控制器抽象層包括微控制器驅動（Microcontroller Drivers）、存儲器驅動（Memory Drivers）、通信驅動（Communication Drivers）以及I/O驅動（I/O Drivers）。
由于對複雜傳感器和執行器進行操作的子產品涉及嚴格的時序問題，難以抽象，是以在AUTOSAR規範中這部分沒有被标準化，統稱為複雜驅動（Complex Drivers）。
AUTOSAR軟體元件
軟體元件（SWC）不僅僅是應用層的核心，也是一些抽象層、複雜驅動層等實作的載體。由于軟體元件包含的概念較多，這裡單獨介紹AUTOSAR軟體元件相關概念，這是後期進行應用層、抽象層等開發的基礎。
AUTOSAR軟體元件大體上可分為原子軟體元件（Atomic SWC）和部件（Composition SWC）。其中，部件可以包含若幹原子軟體元件或部件。原子軟體元件則可根據不同用途分為以下幾種類型：
①應用軟體元件（Application SWC）；
②傳感器/執行器軟體元件（Sensor/Actuator SWC）；
③标定參數軟體元件（Parameter SWC）；
④ECU抽象軟體元件（ECU Abstraction SWC）；
⑤複雜裝置驅動軟體元件（Complex Device Driver SWC）；
⑥服務軟體元件（Service SWC）。
應用軟體元件（Application SWC）主要用于實作應用層控制算法。
傳感器/執行器軟體元件（Sensor/Actuator SWC）用于處理具體傳感器/執行器的信号，可以直接與ECU抽象層互動。
标定參數軟體元件（Parameter SWC）主要提供标定參數值。
ECU抽象軟體元件（ECUAbstractionSWC）提供通路ECU具體I/O的能力。該軟體元件一般提供引用C/S接口的供型端口，即Server端，由其他軟體元件（如傳感器/執行器軟體元件）的需型端口（Client端）調用。此外，ECU抽象軟體元件也可以直接和一些基礎軟體進行互動。
複雜裝置驅動軟體元件（Complex Device Driver SWC）推廣了ECU抽象軟體元件，它可以定義端口與其他軟體元件通信，還可以與ECU硬體直接互動。是以，該類軟體元件靈活性最強，但由于其和應用對象強相關，進而導緻其可移植性較差。
服務軟體元件（Service SWC）主要用于基礎軟體層，可通過标準接口或标準AUTOSAR接口與其他類型的軟體元件進行互動。
需要指出的是，上述這些軟體元件有的僅僅是概念上的區分，從具體實作及代碼生成角度而言都是相通的。下面将詳細介紹AUTOSAR軟體元件的幾個重要概念：資料類型、端口、端口接口以及内部行為。
1
軟體元件的資料類型
AUTOSAR規範中定義了如下三種資料類型（Data Type）：
①應用資料類型（Application Data Type，ADT）；
②實作資料類型（Implementation Data Type，IDT）；
③基礎資料類型（Base Type）。
應用資料類型（Application Data Type，ADT）是在軟體元件設計階段抽象出來的資料類型，用于表征實際實體世界的量，是提供給應用層使用的，僅僅是一種功能的定義，并不生成實際代碼。
實作資料類型（Implementation Data Type，IDT）是代碼級别的資料類型，是對應用資料類型的具體實作；它需要引用基礎資料類型（Base Type），并且還可以配置一些計算方法（Compute Method）與限制條件（Data Constaint）。
在AUTOSAR中，對于Application Data Type沒有強制要求使用，使用者可以直接使用Implementation Data Type。若使用了Application Data Type，則必須進行資料類型映射（Data Type Mapping），即将Application Data Type與Implementation Data Type進行映射，進而來對每個Application Data Type進行具體實作。
2
軟體元件的端口與端口接口
軟體元件的端口根據輸入/輸出方向可分為需型端口（Require Port，RPort）與供型端口（Provide Port，PPort），在AUTOSAR 4.1.1标準中又提出了供需端口（Provide and Require Port，PRPort）。
①需型端口：用于從其他軟體元件獲得所需資料或者所請求的操作。
②供型端口：用于對外提供某種資料或者某類操作。
③供需端口：兼有需型端口與供型端口的特性。
需型端口可以和供型端口連接配接。軟體元件SWC1有一個需型端口（R）和一個供型端口（P），其中需型端口與SWC2的供型端口相連，它們之間的互動關系通過連線箭頭表示，由SWC2的供型端口指向SWC1的需型端口。SWC3具有一個供需端口，它可被認為自我相連。
由于端口僅僅定義了方向，是以AUTOSAR中用端口接口（Port Interface）來表征端口的屬性，端口接口主要有如下幾種類型：
①發送者-接收者接口（Sender-Receiver Interface，S/R）；
②用戶端-伺服器接口（Client-Server Interface，C/S）；
③模式轉換接口（Mode Switch Interface）；
④非易失性資料接口（Nonvolatile Data Interface）；
⑤參數接口（Parameter Interface）；
⑥觸發接口（Trigger Interface）。
其中，最常用的端口接口是發送者-接收者接口（Sender-Receiver Interface，S/R）與用戶端-伺服器接口（Client-Server Interface，C/S）。軟體元件SWC1具有兩個端口，其中一個引用的端口接口類型為發送者-接收者（S/R）接口，另一個引用的端口接口類型為用戶端-伺服器（C/S）接口。從中也可以看出，對于引用發送者-接收者接口的一組端口而言，需型端口為接收者（Receiver），供型端口為發送者（Sender）。對于引用用戶端-伺服器接口的一組端口而言，需型端口為用戶端（Client），供型端口為伺服器（Server）。
發送者-接收者接口（Sender-Receiver Interface，S/R）用于資料的傳遞關系，發送者發送資料到一個或多個接收者。該類型接口中定義了一系列的資料元素（Data Element，DE），這些資料元素之間是互相獨立的。該發送者-接收者接口SR_Interface中定義了兩個資料元素，名字分别為DE_1與DE_2，并且需要為每個資料元素賦予相應的資料類型。
需要指出的是，一個軟體元件的多個需型端口、供型端口、供需端口可以引用同一個發送者-接收者接口，并且它們可以使用該接口中所定義的任意一個或者多個資料元素，而并不一定使用所有資料元素。
用戶端-伺服器接口（Client-Server Interface，C/S）用于操作（Operation，OP），即函數調用關系，伺服器是操作的提供者，多個用戶端可以調用同一個操作，但同一個用戶端不能調用多個操作。用戶端-伺服器接口定義了一系列操作（Operation），即函數，它（們）由引用該接口的供型端口所在的軟體元件來實作，并提供給引用該接口的需型端口所在的軟體元件調用。該用戶端-伺服器接口CS_Interface中定義了兩個操作OP_1與OP_2，對于每一個操作需要定義相關參數及其方向，即函數的形參。
需要注意的是，每個端口隻能引用一種接口類型，并且引用相同端口接口類型的端口才可以進行互動。
3
軟體元件的内部行為
軟體元件的内部行為（Internal Behaviour，IB）主要包括：
①運作實體（Runnable Entity，RE）；
②運作實體的RTE事件（RTE Event）；
③運作實體與所屬軟體元件的端口通路（Port Access）；
④運作實體間變量（Inter Runnable Variable，IRV）。
運作實體（Runnable Entity，RE）是一段可執行的代碼，其封裝了一些算法。一個軟體元件可以包含一個或者多個運作實體。
每個運作實體都會被賦予一個RTE事件（Trigger Event），即RTE事件（RTE Event），這個事件可以引發這個運作實體的執行。對于RTE事件可以細分為很多種類，這将在後續章節介紹軟體元件的内部行為設計時結合工具進行介紹。較常用的RTE事件有以下幾種：
①周期性（Periodic）事件，即Timing Event；
②資料接收事件（Data-received Event）；
③用戶端調用伺服器事件（Server-call Event）。
Runnable_1、Runnable_2和Runnable_3分别采用了Timing Event、Data-received Event以及Server-call Event。
運作實體與所屬軟體元件的端口通路（Port Access）是和端口所引用的端口接口類型密切相關的。
對于S/R通信模式，可分為顯示（Explicit）和隐式（Implicit）兩種模式。若運作實體采用顯示模式的S/R通信方式，資料讀寫是即時的；當多個運作實體需要讀取相同的資料時，若能在運作實體運作之前先把資料讀到緩存中，在運作實體運作結束後再把資料寫出去，則可以改善運作效率，這就是隐式模式。對比顯示模式與隐式模式，後者的實作方式中，會在運作實體被調用之前讀資料，在運作結束後寫資料。
對于C/S通信模式，可分為同步（Synchronous）和異步（Asynchronous）兩種模式。
運作實體間變量（Inter Runnable Variable，IRV）即兩個運作實體之間互動的變量。
文章内容摘自