AUTOSAR技術(shù)分析報(bào)告

1、AUTOSAR技術(shù)分析報(bào)告（科銀京成：王瑜、余鵬、曾英哲、魯陽、楊寶澤）AUTOSARR簡(jiǎn)介汽車電子領(lǐng)域的的軟件主要屬屬于嵌入式軟軟件。因此，其其發(fā)展階段類類似于其他嵌嵌入式系統(tǒng)的的軟件發(fā)展。由由于受限于嵌嵌入式硬件本本身資源的匱匱乏，各種硬硬件產(chǎn)品的種種類繁多和各各自差異，以以及整體嵌入入式系統(tǒng)軟件件的逐步發(fā)展展，起初的軟軟件設(shè)計(jì)開發(fā)發(fā)主要是封閉閉式的。這樣樣有助于開發(fā)發(fā)針對(duì)于特定定硬件體，充充分優(yōu)化利用用資源而特定定設(shè)計(jì)的軟件件系統(tǒng)。這樣樣的軟件系統(tǒng)統(tǒng)，是針對(duì)于于特定硬件和和特定應(yīng)用而而設(shè)計(jì)，其對(duì)對(duì)于硬件資源源的充分應(yīng)用用，以及軟件件本身的執(zhí)行行效率無疑是是非常高。然而，隨著硬件件本身的逐

2、步步發(fā)展，其可可用資源已經(jīng)經(jīng)十分充分。另另一方面，汽汽車電子領(lǐng)域域應(yīng)用需求也也日趨復(fù)雜，軟軟件本身也變變得越來越復(fù)復(fù)雜。因此，無無論汽車廠還還是部件商都都感到軟件的的標(biāo)準(zhǔn)化問題題。軟件的可可管理性，可可重復(fù)使用性性，可裁減性性，以及質(zhì)量量保證等等問問題被提上了了議程。AUUTOSARR 的提出正正是基于以上上一些軟件發(fā)發(fā)展的要求，由由幾大主要汽汽車廠商以及及部件提供商商聯(lián)合提出的的，其中包括括BWM, DaimllerChrryslerr, Forrd Mottor, PPSA Peeugeott, Toyyota MMotor, Volkkswageen AG, Boscch, Connti

3、nettal, SSiemenns VDOO等。AUTOSARR是針對(duì)特定定的汽車電子子這一領(lǐng)域，提提出的一套開開放式軟件結(jié)結(jié)構(gòu)。其主體體思想是使得得軟件設(shè)計(jì)開開發(fā)更易于管管理，軟件系系統(tǒng)更易于移移植、裁剪，以以及更好的維維護(hù)性和質(zhì)量量保證。AUUTOSARR組織所提出出的目標(biāo)以及及它所關(guān)注的的功能領(lǐng)域在在下表中列出出：項(xiàng)目目標(biāo)功能領(lǐng)域解決汽車的可可用性和安全全性需求保持汽車電子子系統(tǒng)一定的的冗余可以移植到不不同汽車的不不同平臺(tái)上實(shí)現(xiàn)標(biāo)準(zhǔn)的基基本系統(tǒng)功能能作為汽車供供應(yīng)商的標(biāo)準(zhǔn)準(zhǔn)軟件模塊通過網(wǎng)絡(luò)共享享軟件功能集成多個(gè)開發(fā)發(fā)商提供的軟軟件模塊在產(chǎn)品生命周周期內(nèi)更好的的進(jìn)行軟件維維護(hù)更充分的利用用

4、“貨價(jià)產(chǎn)品”在車輛整個(gè)生生命周期中進(jìn)進(jìn)行軟件更新新與升級(jí)為了實(shí)現(xiàn)上述述的項(xiàng)目目標(biāo)標(biāo)，針對(duì)在汽車電電子行業(yè)中面面臨的一些挑戰(zhàn)，AUTTOSAR所所采用的解決決方案及其好好處可以概述述如下：挑戰(zhàn)解決方法好處不成熟的過程，因因?yàn)閍d-hhoc模式/缺少對(duì)功能能需要的追蹤蹤能力。缺少兼容的工具具（供應(yīng)商、OOEM）標(biāo)準(zhǔn)化的規(guī)范交交換格式對(duì)規(guī)范的改進(jìn)（格格式、內(nèi)容）提供無縫的工具具鏈。浪費(fèi)在實(shí)現(xiàn)和優(yōu)優(yōu)化組件上的的努力，而顧顧客并不承認(rèn)認(rèn)這些努力的的價(jià)值?；A(chǔ)軟件核軟件質(zhì)量的加強(qiáng)強(qiáng)。將工作集中在有有價(jià)值的功能能上。微控制器模型缺缺乏可用性，很很難適應(yīng)現(xiàn)有有軟件。（由新功能引起起的）微控制制器性能的擴(kuò)擴(kuò)展需

5、求所導(dǎo)致的升級(jí)需要（如如重新設(shè)計(jì)）。微控制器抽象微控制器能在不不需要改變更更高軟件層的的情況下調(diào)換換。重定位ECU之之間的功能時(shí)時(shí)需要做大量量的工作。功能重用時(shí)也需需要做大量的的工作。運(yùn)行時(shí)環(huán)境(RRTE)功能封裝導(dǎo)致的的通信技術(shù)的的獨(dú)立性。通過標(biāo)準(zhǔn)化機(jī)制制，使得通信信更加簡(jiǎn)單。使功能分區(qū)和功功能重定位變變得可能。非競(jìng)爭(zhēng)性功能必必須適應(yīng)OEEM的特定環(huán)環(huán)境。因?yàn)樾枰獜钠渌M件供應(yīng)接接口需要很多多功夫，所以以哪怕是很微微小的革新，也也需要做很多多工作?；A(chǔ)軟件和模型型生成的代碼碼間缺少清晰晰的接口。接口標(biāo)準(zhǔn)化減少/避免OEEM和供應(yīng)商商之間的接口口。通過使用通用接接口目錄，使使獨(dú)立于軟件件功能

6、的硬件件實(shí)現(xiàn)所耗費(fèi)費(fèi)的工作量。簡(jiǎn)化模型驅(qū)動(dòng)的的開發(fā)，允許許使用標(biāo)準(zhǔn)化化的AUTOOSAR代碼碼生成工具。OEM間的模型型的可重用性性。不同供應(yīng)商之間間模塊的可交交換性。AUTOSARR軟件結(jié)構(gòu)AUTOSARR軟件的組成成與分層AUTOSARR的軟件組件件可以用下圖圖來表示：對(duì)于上圖所示示的一些組件件，可以根據(jù)據(jù)功能及相互互關(guān)系對(duì)其進(jìn)進(jìn)行分層，如如下圖所示：微控制器器抽象層這一層是基礎(chǔ)軟軟件中的最低低一層。它包包含驅(qū)動(dòng)，這這些驅(qū)動(dòng)是軟軟件模塊，用用來對(duì)C內(nèi)部設(shè)備備和映射了C外部設(shè)備備的內(nèi)存進(jìn)行行訪問。ECU抽抽象層這一層與微控制制器抽象層進(jìn)進(jìn)行對(duì)接。它它也包含了外外部設(shè)備的驅(qū)驅(qū)動(dòng)。它為訪訪問外設(shè)

7、提供供了API，不不管這些外設(shè)設(shè)的位置(C內(nèi)部或外外部)，也不不管它們與C的連接(端口針腳，接接口類型)。服務(wù)層這層是基礎(chǔ)軟件件中的最高層層，而且它與與應(yīng)用軟件之之間有關(guān)聯(lián)：當(dāng)對(duì)I/OO信號(hào)的訪問問包含ECUU抽象層中時(shí)時(shí)，服務(wù)層提提供：操作系統(tǒng)功能車輛網(wǎng)絡(luò)通信及及管理服務(wù)存儲(chǔ)管理（NVVRAM管理理）診斷服務(wù)（包括括UDS通信信及錯(cuò)誤內(nèi)存存）ECU狀態(tài)管理理RTE運(yùn)行時(shí)環(huán)境RTTE是AUTTOSAR ECU體系系結(jié)構(gòu)的核心心組成部分。RRTE是AUUTOSARR虛擬功能總總線（Virrtual Functtion BBus，VFFB）的接口口（針對(duì)某個(gè)個(gè)特定ECUU）的實(shí)現(xiàn)，因因此，它為應(yīng)應(yīng)

8、用程序軟件件組件之間的的通信提供了了基本的服務(wù)務(wù)，同時(shí)也便便于訪問包含含OS的基本本軟件組件。應(yīng)用程序軟件組組件包含獨(dú)立立于CPU和和所處位置的的系統(tǒng)軟件。這這就意味著，為為了滿足系統(tǒng)統(tǒng)設(shè)計(jì)者所做做的一些限制制，應(yīng)用程序序組件能夠在在系統(tǒng)配置期期間被映射到到任何有效的的ECU上。RRTE負(fù)責(zé)確確保這些組件件能夠通信。RTE和OS,AUTOSSAR COOM和其他的的基礎(chǔ)軟件模模塊（BSWW）是VFBB（Virttual FFunctiional Bus）概概念的實(shí)現(xiàn)。RRTE實(shí)現(xiàn)了了AUTOSSAR VFFB的接口，從從而實(shí)現(xiàn)了AAUTOSAAR軟件組件件之間的通信信。RTE是AUTTOSAR

9、 ECU體系系的核心,它它提供了在AAUTOSAAR軟件組件件間通信的基基礎(chǔ)服務(wù)，扮扮演了一些方方法，通過這這些方法AUUROSARR軟件組件能能訪問包括OOS和通信服服務(wù)在內(nèi)基礎(chǔ)礎(chǔ)軟件模塊的的。系統(tǒng)服務(wù)系統(tǒng)服務(wù)是一組組可以由所有有層次模塊使使用的模塊和和功能。例如如實(shí)時(shí)操作系系統(tǒng)、錯(cuò)誤管管理器和庫功功能。為應(yīng)用用和基本軟件件模塊提供基基本服務(wù)。它它包含下圖所所示功能：AUTOSARR OSAUTOSARR OS為實(shí)實(shí)時(shí)應(yīng)用提供供了所有基本本服務(wù)，即中中斷處理、調(diào)調(diào)度、系統(tǒng)時(shí)時(shí)間和時(shí)鐘同同步、本地消消息處理，以以及錯(cuò)誤檢測(cè)測(cè)機(jī)制。所有有服務(wù)都隱藏藏在良好定義義的API之之后。應(yīng)用與與OS和通信

10、信層的連接只只通過APII。AUTOSARR OS的基基本特征包括括：靜態(tài)配置能夠推斷實(shí)實(shí)時(shí)系統(tǒng)性能能提供基于優(yōu)優(yōu)先級(jí)的調(diào)度度策略提供運(yùn)行時(shí)時(shí)保護(hù)功能（存存儲(chǔ)、計(jì)時(shí)等等）可宿主在低低端控制器上上，并且不需需要其他資源源它包含以下幾個(gè)個(gè)方面：實(shí)時(shí)操作系系統(tǒng)在嵌入式汽車EECU中的實(shí)實(shí)時(shí)操作系統(tǒng)統(tǒng)構(gòu)成軟件動(dòng)動(dòng)態(tài)行為的基基礎(chǔ)。它管理理任務(wù)和事件件的調(diào)度，不不同任務(wù)間的的數(shù)據(jù)流，并并且提供監(jiān)控控和錯(cuò)誤處理理功能。但是，在汽車系系統(tǒng)中，對(duì)操操作系統(tǒng)的需需求集中在特特定領(lǐng)域。所所使用的操作作系統(tǒng)必須高高效運(yùn)行并且且所占存儲(chǔ)空空間小。在多媒體和遠(yuǎn)程程信息處理應(yīng)應(yīng)用中，操作作系統(tǒng)提供的的特征集以及及可用計(jì)算資

11、資源有很大不不同。在純粹粹的任務(wù)管理理之上，OSS中還包含了了復(fù)雜的數(shù)據(jù)據(jù)處理（例如如，流、快速速文件系統(tǒng)等等）、存儲(chǔ)管管理甚至圖形形用戶接口。汽車OS的典型型領(lǐng)域涵蓋了了調(diào)度和同步步的核心特征征。在AUTTOSAR中中，上面討論論的附加特征征在OS的范范圍之外，其其他WP4.2.2.11工作包（例例如SPALL）涵蓋了這這些特征。在在AUTOSSAR的體系系結(jié)構(gòu)約束之之下不可能把把其他OS（例例如，QNXX、VxWoorks和WWindowws CE等等）的特征集集合集成到整整體的OS/通信/驅(qū)動(dòng)動(dòng)結(jié)構(gòu)中。因因此，AUTTOSAR OS只考慮慮核心特征。核心操作系系統(tǒng)OSEK/VDDK操作系

12、統(tǒng)統(tǒng)廣泛應(yīng)用于于汽車工業(yè)，并并且已經(jīng)證明明了可以在現(xiàn)現(xiàn)代車輛的所所有ECU類類型中使用。OOSEK OOS引入的概概念被廣泛地地理解，汽車車工業(yè)領(lǐng)域在在設(shè)計(jì)基于OOSEK OOS的系統(tǒng)方方面有多年的的經(jīng)驗(yàn)。OSEK OSS是一個(gè)事件件觸發(fā)的操作作系統(tǒng)。這為為基于AUTTOSAR的的系統(tǒng)的設(shè)計(jì)計(jì)和維護(hù)提供供了高度的靈靈活性。事件件觸發(fā)使得可可以自由地選選擇在運(yùn)行時(shí)時(shí)驅(qū)動(dòng)調(diào)度的的事件，例如如角反轉(zhuǎn)、局局部時(shí)間源、全全局時(shí)間源、錯(cuò)錯(cuò)誤出現(xiàn)等等等。由于這些原因，AAUTOSAAR OS的的核心功能必必須基于OSSEK OSS。OSEKK OS特別別提供了以下下特性以支持持AUTOSSAR：固定的基于優(yōu)

13、先先級(jí)調(diào)度處理中斷的功能能只有中斷有高于于任務(wù)的優(yōu)先先級(jí)一些防止錯(cuò)誤使使用OS服務(wù)務(wù)的保護(hù)措施施StartOSS()和StarttupHoook啟動(dòng)接口口ShutdowwnOS()和ShutddownHoook關(guān)閉接接口AUTOSARR OS基于于OSEK OS意味著著應(yīng)用程序是是向后兼容的的。為OSEEK OS編編寫的應(yīng)用程程序可以在AAUTOSAAR OS上上運(yùn)行。但是是，使用AUUTOSARR OS引入入的一些新特特性需要對(duì)已已存在的OSSEK OSS特性的使用用有所限制。例例如：為定時(shí)時(shí)器回調(diào)實(shí)現(xiàn)現(xiàn)定時(shí)和內(nèi)存存保護(hù)效率就就會(huì)很低。此此外，AUTTOSAR OS擴(kuò)展了了一些已存在在的特性

14、，例例如直接通過過定時(shí)器驅(qū)動(dòng)動(dòng)計(jì)數(shù)器。AUTOSARR OS提供供的API向向后兼容于OOSEK OOS的APII。新的需求求作為功能擴(kuò)擴(kuò)展來集成。AUTOSARR OS對(duì)OOSEK OOS擴(kuò)展的AAPI如下表表：服務(wù)名語法GetAppllicatiionIDApplicaationTType GGetAppplicattionIDD (voiid)GetISRIIDISRTypee GetIISRID (voidd)CallTruustedFFunctiionStatusTType CCallTrrusteddFuncttion(TrusteddFuncttionInndexTyype Fu

15、unctioonIndeex,TrusteddFuncttionPaarametterReffType FuncttionPaarams)CheckISSRMemooryAcccessAccessTType CCheckIISRMemmoryAcccess(ISRTypee ISRIID,MemorySStartAAddresssTypee Addrress,MemorySSizeTyype Siize)CheckTaaskMemmoryAcccessAccessTType CCheckTTaskMeemoryAAccesss(TaskTyppe TasskID,MemorySStartAAd

16、dresssTypee Addrress,MemorySSizeTyype Siize)CheckObbjectAAccesssObjectAAccesssType CheckkObjecctAcceess(ApplicaationTType AApplIDD,ObjectTTypeTyype ObbjectTType,)CheckObbjectOOwnersshipApplicaationTType CCheckOObjecttOwnerrship(ObjectTTypeTyype ObbjectTType,)StartScchedulleTablleRelStatusTType SStar

17、tSScheduuleTabbleRell(SchedulleTablleTypee ScheeduleTTableIID,TickTyppe Offfset)StartScchedulleTablleAbsStatusTType SStartSScheduuleTabbleAbss(SchedulleTablleTypee ScheeduleTTableIID,TickTyppe Ticckvaluue)StopSchheduleeTableeStatusTType SStopScchedulleTablle(SchedulleTablleTypee ScheeduleTTableIID)N

18、extSchheduleeTableeStatusTType NNextScchedulleTablle(SchedulleTablleTypee ScheeduleTTableIID_currrent,SchedulleTablleTypee ScheeduleTTableIID_nexxt)IncremeentCouunterStatusTType IIncremmentCoounterr(CounterrType CountterID)SyncSchheduleeTableeStatusTType SSyncScchedulleTablle(SchedulleTablleTypee Sc

19、heedTablleID,GlobalTTimeTiickTyppe GloobalTiime)SetScheeduleTTableAAsyncStatusTType SSetSchheduleeTableeAsyncc(SchedulleTablleTypee ScheeduleIID)GetScheeduleTTableSStatussStatusTType GGetSchheduleeTableeStatuus(SchedulleTablleTypee ScheeduleIID,SchedulleTablleStattusReffType SchedduleSttatus)Termina

20、ateAppplicattionStatusTType TTerminnateAppplicaation(RestaartTyppe RestaartOpttion)DisableeInterrruptSSourceeStatusTType DDisablleInteerrupttSourcce (ISSRTypee DisaableISSR)EnableIInterrruptSoourceStatusTType EEnableeInterrruptSSourcee (ISRRType EnablleISR)ProtecttionHoookProtecttionReeturnTType PPr

21、otecctionHHook(StatusTType FFataleerror)靜態(tài)定義的的調(diào)度在許多應(yīng)用中需需要靜態(tài)定義義一組互相關(guān)關(guān)聯(lián)的任務(wù)的的活動(dòng)。這用用于在基于數(shù)數(shù)據(jù)流的設(shè)計(jì)計(jì)中保證數(shù)據(jù)據(jù)一致性，與與時(shí)間觸發(fā)的的網(wǎng)絡(luò)同步，保保證正確的運(yùn)運(yùn)行時(shí)定相，等等等。時(shí)間觸發(fā)的操作作系統(tǒng)通常作作為這個(gè)問題題的解決方法法。然而，時(shí)時(shí)間只是簡(jiǎn)單單的事件，所所以任何事件件觸發(fā)的OSS，包括OSSEK OSS，會(huì)在汽車車電子控制單單元實(shí)現(xiàn)一個(gè)個(gè)用于靜態(tài)調(diào)調(diào)度實(shí)時(shí)軟件件的調(diào)度器。監(jiān)控功能監(jiān)控功能在適當(dāng)當(dāng)?shù)膱?zhí)行階段段檢測(cè)錯(cuò)誤，不不是在錯(cuò)誤發(fā)發(fā)生的時(shí)刻。因因此，監(jiān)控功功能是在運(yùn)行行時(shí)捕捉失效效，而不是預(yù)預(yù)防故障

22、。保護(hù)功能AUTOSARR概念需要多多來源的OSS應(yīng)用共存在在同一處理器器中。為了防防止這些OSS應(yīng)用之間意意想不到的交交互，需要提提供保護(hù)機(jī)制制。計(jì)時(shí)器服務(wù)務(wù)計(jì)時(shí)器服務(wù)為應(yīng)應(yīng)用和基礎(chǔ)軟軟件提供軟件件計(jì)時(shí)器。計(jì)時(shí)機(jī)制的核心心已經(jīng)由OSSEK OSS的計(jì)數(shù)器和和鬧鐘提供。如如果要提供通通用的軟件計(jì)計(jì)時(shí)，一些補(bǔ)補(bǔ)充特性需要要添加到AUUTOSARR OS。時(shí)間觸發(fā)操操作系統(tǒng)時(shí)間觸發(fā)操作系系統(tǒng)在汽車電電子控制單元元實(shí)現(xiàn)了一個(gè)個(gè)用于靜態(tài)調(diào)調(diào)度實(shí)時(shí)軟件件的調(diào)度器。另外，操作系統(tǒng)統(tǒng)為實(shí)時(shí)應(yīng)用用提供了所有有基本服務(wù)，即即中斷處理、調(diào)調(diào)度、系統(tǒng)時(shí)時(shí)間和時(shí)鐘同同步、本地消消息處理，以以及錯(cuò)誤檢測(cè)測(cè)機(jī)制。所有服務(wù)

23、都隱藏藏在良好定義義的API之之后。應(yīng)用與與OS和通信信層的連接只只通過APII。對(duì)于特殊的應(yīng)用用，操作系統(tǒng)統(tǒng)能夠配置為為只包含該應(yīng)應(yīng)用需要的服服務(wù)。因此操操作系統(tǒng)的資資源需求盡量量少。BSW調(diào)度器BSW調(diào)度器是是系統(tǒng)服務(wù)的的一部分，因因此它向所有有層次的所有有模塊提供服服務(wù)。但是，與與其它BSWW模塊不同，BBSW調(diào)度器器提供了集成成的概念和服服務(wù)。BSWW調(diào)度器提供供方法用以：把BSW模塊的的實(shí)現(xiàn)嵌入AAUTOSAAR OS上上下文觸發(fā)BSW模塊塊的主要處理理功能應(yīng)用BSW模塊塊的數(shù)據(jù)一致致性機(jī)制集成者的任務(wù)是是應(yīng)用所給的方方法（AUTTOSAR OS提供的的），在特定定項(xiàng)目環(huán)境中中以良好

24、定義義和有效的方方式把BSWW模塊裝配起起來。這也意味著BSSW調(diào)度器只只是使用AUTOOSAR OOS。它與AAUTOSAAR OS調(diào)調(diào)度器并不沖沖突。BSW調(diào)度器的的實(shí)現(xiàn)基于：BSW模塊的BBSW模塊描描述BSW調(diào)度器的的配置模式管理模式管理簇包括括三個(gè)基本軟軟件模塊：ECU狀態(tài)態(tài)管理器，控控制AUTOOSAR BBSW模塊的的啟動(dòng)階段，包包括OS的啟啟動(dòng)；通信管理器器，負(fù)責(zé)網(wǎng)絡(luò)絡(luò)資源管理；看門狗管理理器，基于應(yīng)應(yīng)用軟件的生生存狀態(tài)觸發(fā)發(fā)看門狗。ECU狀態(tài)管理理器ECU狀態(tài)管理理器是一個(gè)基基本軟件模塊塊，管理ECCU的狀態(tài)（OOFF、RUUN、SLEEEP），以以及這些狀態(tài)態(tài)之間的轉(zhuǎn)換換（

25、過渡狀態(tài)態(tài)：STARRTUP、WWAKEUPP、SHUTTDOWN）。詳詳細(xì)地，ECCU狀態(tài)管理理器：負(fù)責(zé)初始化化和de-iinitiaalizattion所有有基本軟件模模塊，包括OOS和RTEE；在需要時(shí)與與所謂的資源源管理器（例例如，通信管管理器）協(xié)作作，關(guān)閉ECCU；管理所有喚喚醒事件，并并在被要求時(shí)時(shí)配置ECUU為SLEEEP狀態(tài)。為了完成所有這這些任務(wù)，EECU狀態(tài)管管理器提供了了一些重要的的協(xié)議：RUN請(qǐng)求求協(xié)議，調(diào)整整ECU是保保持活動(dòng)狀態(tài)態(tài)還是準(zhǔn)備關(guān)關(guān)閉，喚醒確認(rèn)協(xié)協(xié)議，從“不穩(wěn)定的”喚醒事件中中區(qū)分出“真正的”喚醒事件，時(shí)間觸發(fā)的的增多非工作作狀態(tài)協(xié)議（TTime TTri

26、ggeered IIncreaased IInoperrationn - TTTII），允允許ECU更更多地進(jìn)入節(jié)節(jié)能的休眠狀狀態(tài)。ECU狀態(tài)管理理器必須支持持獨(dú)立的預(yù)處處理動(dòng)作和過過渡，以啟動(dòng)動(dòng)ECU或?qū)⑵滢D(zhuǎn)換到低低功耗狀態(tài)（例例如，休眠狀狀態(tài)/備用狀狀態(tài)）。通過過良好使用EECU狀態(tài)管管理器的特性性和能力，此此模塊能夠用用于執(zhí)行電源源消耗的預(yù)定定義策略，因因此提供了對(duì)對(duì)ECU的有有效能源管理理。ECU狀態(tài)管理理器的特性和和優(yōu)勢(shì)包括：初始化和關(guān)關(guān)閉基本軟件件模塊。ECU主要要狀態(tài)的標(biāo)準(zhǔn)準(zhǔn)化定義。時(shí)間觸發(fā)的的更多非工作作狀態(tài)?？撮T狗管理器看門狗管理器是是AUTOSSAR（服務(wù)務(wù)層次）的標(biāo)標(biāo)準(zhǔn)

27、化基本軟軟件體系結(jié)構(gòu)構(gòu)的基本軟件件模塊。它監(jiān)監(jiān)控與計(jì)時(shí)約約束有關(guān)的應(yīng)應(yīng)用執(zhí)行的可可靠性。分層體系結(jié)構(gòu)方方法使得應(yīng)用用計(jì)時(shí)約束和和看門狗硬件件計(jì)時(shí)約束分分離?；诖舜?，看門狗管管理器在觸發(fā)發(fā)看門狗硬件件的同時(shí)提供供了對(duì)一些獨(dú)獨(dú)立應(yīng)用的生生存監(jiān)控?？撮T狗管理器提提供以下特性性：監(jiān)督多個(gè)處處于ECU的的單獨(dú)應(yīng)用，這這些應(yīng)用有獨(dú)獨(dú)立的計(jì)時(shí)約約束并且需要要特別監(jiān)督運(yùn)運(yùn)行時(shí)的行為為和生存狀態(tài)態(tài)。每個(gè)獨(dú)立的的受監(jiān)控實(shí)體體都有故障響響應(yīng)機(jī)制?？梢躁P(guān)閉對(duì)對(duì)單獨(dú)應(yīng)用的的監(jiān)督，而不不會(huì)違反看門門狗觸發(fā)（例例如，對(duì)于禁禁止的應(yīng)用）。通過看門狗狗驅(qū)動(dòng)觸發(fā)內(nèi)內(nèi)部或外部、標(biāo)標(biāo)準(zhǔn)或窗口，看看門狗。（iinternnal or

28、r exteernal, stanndard or wiindow, watcchdog）對(duì)對(duì)內(nèi)部或外部部看門狗的訪訪問由看門狗狗接口處理。根據(jù)ECUU狀態(tài)和硬件件性能選擇看看門狗模式（OOff Moode, SSlow MMode, Fast Mode）。通信管理器通信管理器收集集并協(xié)調(diào)來自自通信請(qǐng)求者者（用戶）的的訪問請(qǐng)求。通信管理器的目目的是：簡(jiǎn)化通信協(xié)協(xié)議棧的使用用。包括通信信棧的初始化化，以及簡(jiǎn)單單的網(wǎng)絡(luò)管理理。調(diào)整ECUU上多個(gè)獨(dú)立立軟件組件的的通信棧（允允許發(fā)送和接接收消息）的的可用性。暫時(shí)禁止發(fā)發(fā)送消息以阻阻止ECU（主主動(dòng)地）喚醒醒物理通道。通過為每個(gè)個(gè)物理通道實(shí)實(shí)現(xiàn)一個(gè)狀態(tài)

29、態(tài)機(jī)來控制EECU的多個(gè)個(gè)物理通道?？梢詮?qiáng)制EECU保持物物理通道處于于“silennt 通信”模式。分配所請(qǐng)求求的通信模式式需要的所有有資源，簡(jiǎn)化化資源管理。通信管理器定義義了“通信模式”，表示一個(gè)個(gè)特定的物理理通道對(duì)于應(yīng)應(yīng)用是否可用用，以及如何何使用（發(fā)送送/接收，只只接收，即不不發(fā)送也不接接收）。診斷服務(wù)診斷事件管理器器診斷事件管理器器DEM（DDiagnoostic Eventt Manaager）是是一個(gè)子組件件，如同AUUTOSARR內(nèi)診斷模塊塊的診斷通信信管理器（DDCM）和功功能禁止管理理器（FIMM）。它負(fù)責(zé)責(zé)處理和存儲(chǔ)儲(chǔ)診斷事件（錯(cuò)錯(cuò)誤）和相關(guān)關(guān)FreezzeFramme數(shù)

30、據(jù)。DDEM進(jìn)一步步提供故障信信息給DCMM（例如，從從事件存儲(chǔ)器器讀取所有存存儲(chǔ)的DTCC（Diaggnostiic Troouble Code）。DDEM給應(yīng)用用層、DCMM和FIM提提供接口。定定義了可選的的過濾服務(wù)。功能禁止管理器器功能禁止管理器器FIM（FFunctiion Innhibittion MManageer）負(fù)責(zé)提提供軟件組件件和軟件組件件功能的控制制機(jī)制。功能能由一個(gè)、多多個(gè)或部分有有相同權(quán)限/禁止條件的的可執(zhí)行實(shí)體體構(gòu)成。通過過FIM方法法，對(duì)這些功功能的禁止可可以配置甚至至修改。所以以，極大地提提高了功能在在新系統(tǒng)環(huán)境境下的適應(yīng)性性。FIM意義上的的功能與可執(zhí)執(zhí)行實(shí)

31、體是不不同并且獨(dú)立立的類型?？煽蓤?zhí)行實(shí)體主主要由調(diào)度需需求來區(qū)分。與與此相對(duì)的是是，功能由禁禁止條件來分分類。FIMM服務(wù)關(guān)注SSW-C的功功能，但是并并不局限于此此。BSW的的功能也能夠夠使用FIMM服務(wù)。功能被指定了一一個(gè)標(biāo)識(shí)符（FFID funcction identtifierr），以及該該特定標(biāo)識(shí)符符的禁止條件件。功能在執(zhí)執(zhí)行之前獲得得它們各自的的權(quán)限狀態(tài)。如如果禁止條件件應(yīng)用于特定定標(biāo)識(shí)符，對(duì)對(duì)應(yīng)的功能將將不再執(zhí)行。FIM與DEMM密切相關(guān)，因因?yàn)樵\斷事件件和它們的狀狀態(tài)信息作為為禁止條件被被提供給FIIM。如果檢檢測(cè)到了失效效，并且事件件報(bào)告給了DDEM，那么么FIM禁止止FID

32、和對(duì)對(duì)應(yīng)的功能。為了處理功能和和關(guān)聯(lián)事件的的關(guān)系，功能能的標(biāo)識(shí)符和和禁止條件必必須引入到SSW-C模板板中（與BSSW等價(jià)），并并且在配置期期間構(gòu)造數(shù)據(jù)據(jù)結(jié)構(gòu)以處理理標(biāo)識(shí)符對(duì)于于特定事件的的敏感性。這這些關(guān)系在每每個(gè)FIM中中是唯一的。RTE和FIMM之間沒有功功能上的聯(lián)系系。在AUTTOSAR中中，RTE按按照接口和調(diào)調(diào)度需求處理理SW-C。與與此相對(duì)的是是，F(xiàn)IM處處理禁止條件件并通過標(biāo)識(shí)識(shí)符（FIDD）為控制功功能提供支持持機(jī)制。因此此，F(xiàn)IM概概念和RTEE概念不互相相干擾。開發(fā)錯(cuò)誤跟蹤器器開發(fā)錯(cuò)誤跟蹤器器DET（DDeveloopmentt Erroor Traacer）主主要用于在

33、開開發(fā)期間跟蹤蹤和記錄錯(cuò)誤誤。API參參數(shù)給出了追追蹤源和錯(cuò)誤誤類型：錯(cuò)誤所在的模塊塊錯(cuò)誤所在的功能能錯(cuò)誤類型由軟件開發(fā)者和和軟件集成者者在特定應(yīng)用用和測(cè)試環(huán)境境下為APII功能選擇最最優(yōu)的策略?？煽赡馨ㄒ韵孪鹿δ埽涸阱e(cuò)誤報(bào)告APPI內(nèi)設(shè)置調(diào)調(diào)試器斷點(diǎn)計(jì)算報(bào)告的錯(cuò)誤誤在RAM緩存中中記錄調(diào)用和和傳遞的參數(shù)數(shù)通過通信接口發(fā)發(fā)送報(bào)告的錯(cuò)錯(cuò)誤到外部日日志DET僅僅是是對(duì)SW開發(fā)發(fā)和集成的輔輔助，并不一一定要包含在在產(chǎn)品代碼中中。API已已經(jīng)定義，但但是功能由開開發(fā)者根據(jù)特特定需求來選選擇/實(shí)現(xiàn)。診斷通信管理器器診斷通信管理器器DCM（DDiagnoostic Commuunicattion MMa

34、nageer）確保診診斷數(shù)據(jù)流，并并且管理診斷斷狀態(tài)，特別別是診斷對(duì)話話期和安全狀狀態(tài)。另外，DDCM檢查診診斷服務(wù)請(qǐng)求求是否被支持持，以及根據(jù)據(jù)診斷狀態(tài)判判斷服務(wù)是否否可以在當(dāng)前前對(duì)話期中執(zhí)執(zhí)行。DCM為所有診診斷服務(wù)提供供連接到AUUTOSARR-RTE的的接口。另外外DCM也處處理一些基本本診斷服務(wù)。在AUTOSAAR體系結(jié)構(gòu)構(gòu)中，診斷通通信管理器（DDCM）處在在通信服務(wù)中中（服務(wù)層）。DDCM是應(yīng)用用和PDU路路由器封裝的的車輛網(wǎng)絡(luò)通通信（CANN、LIN、FFlexRaay和MOSST）之間的的中間層。DDCM與PDDU路由器之之間有一個(gè)接接口。在通信信過程中，DDCM從PDDU（

35、Prootocoll Dataa Unitt）路由器接接收診斷消息息。DCM在其內(nèi)部部處理、檢查查診斷消息，并并把消息傳送送到AUTOOSAR SSW組件進(jìn)一一步處理。根根據(jù)診斷服務(wù)務(wù)ID，將執(zhí)執(zhí)行應(yīng)用層中中的相應(yīng)調(diào)用用。DCM必須是網(wǎng)網(wǎng)絡(luò)無關(guān)的，所所以協(xié)議和消消息配置在DDCM的下層層。這需要連連接到PDUU路由器的網(wǎng)網(wǎng)絡(luò)無關(guān)接口口。DCM由以下功功能塊組成：DSP - DDiagnoostic Serviice PrrocesssingDSP主要包含含了完整實(shí)現(xiàn)現(xiàn)的診斷服務(wù)務(wù)，這些服務(wù)務(wù)在不同的應(yīng)應(yīng)用之中是通通用的（例如如，訪問故障障數(shù)據(jù)），所所以不需要由由應(yīng)用實(shí)現(xiàn)。DSD-Diaagno

36、sttic Seervicee DisppatcheerDSD的目的是是處理診斷數(shù)數(shù)據(jù)流。這里里的處理意味味著：通過網(wǎng)絡(luò)接收新新的診斷請(qǐng)求求并發(fā)送到數(shù)數(shù)據(jù)處理器。當(dāng)被應(yīng)用觸發(fā)時(shí)時(shí)，通過網(wǎng)絡(luò)絡(luò)傳送診斷響響應(yīng)（AUTTOSAR SW-Coomponeent或DSP）。DSL-Diaagnosttic Seessionn LayeerDSL保證數(shù)據(jù)據(jù)流與診斷請(qǐng)請(qǐng)求和響應(yīng)有有關(guān)。DSLL也監(jiān)督和確確保診斷協(xié)議議計(jì)時(shí)。進(jìn)一一步，DSLL管理診斷狀狀態(tài)。存儲(chǔ)棧存儲(chǔ)服務(wù)存儲(chǔ)服務(wù)由一個(gè)個(gè)NVRAMM管理器模塊塊構(gòu)成，負(fù)責(zé)責(zé)管理非易失失性數(shù)據(jù)（從從不同存儲(chǔ)驅(qū)驅(qū)動(dòng)讀/寫）。它它需要一個(gè)RRAM鏡像作作為數(shù)據(jù)接口口

37、提供給應(yīng)用用快速讀取。存儲(chǔ)服務(wù)的任務(wù)務(wù)是以統(tǒng)一方方式向應(yīng)用提提供非易失性性數(shù)據(jù)。這抽抽象了存儲(chǔ)位位置和屬性。提提供非易失性性數(shù)據(jù)管理機(jī)機(jī)制，如保存存、加載、校校驗(yàn)和保護(hù)和和驗(yàn)證、可靠靠存儲(chǔ)等。存儲(chǔ)硬件抽象的的尋址方案存儲(chǔ)抽象接口和和下層的閃存存EEPROOM仿真和EEEPROMM抽象層向NNVRAM管管理器提供虛虛擬線性322位地址空間間。這些邏輯輯32位地址址由16位邏邏輯塊號(hào)和116位塊地址址偏移量組成成。因此NVVRAM管理理器（理論上上）可以有665536個(gè)個(gè)邏輯塊，每每個(gè)邏輯塊（理理論上）可以以有64Kbbytes。NVRAM管理理器進(jìn)一步將將16位邏輯輯塊號(hào)劃分為為以下部分：（16

38、-NNVM_DAATASETT_SELEECTIONN_BITSS）位的塊標(biāo)標(biāo)識(shí)符NVM_DDATASEET_SELLECTIOON_BITTS位的數(shù)據(jù)據(jù)索引，每個(gè)個(gè)NVRAMM塊最多可以以有256個(gè)個(gè)數(shù)據(jù)集NVRAM管理理器非易失性RAMM管理器（NNVRAM Managger）管理理所有非易失失性存儲(chǔ)器中中數(shù)據(jù)的存儲(chǔ)儲(chǔ)。NVRAM管理理器本身與硬硬件無關(guān)，所所有直接存取取硬件的功能能，例如內(nèi)部部或外部EEEPROM、內(nèi)內(nèi)部或外部閃閃存中的仿真真EEPROOM等，封裝裝在基本SWW的較低層。在在汽車環(huán)境中中，NVRAAM管理器提提供服務(wù)以根根據(jù)各個(gè)數(shù)據(jù)據(jù)的需求來保保證數(shù)據(jù)存儲(chǔ)儲(chǔ)和NV數(shù)據(jù)據(jù)的

39、維護(hù)。NNVRAM管管理器要能夠夠管理EEPPROM和/或FLASSH EEPPROM仿真真設(shè)備的NVV數(shù)據(jù)。NVVRAM管理理器為NV數(shù)數(shù)據(jù)的管理和和維護(hù)提供所所需的同步/異步服務(wù)（初初始化/讀/寫/控制）。NNVRAM管管理器處理對(duì)對(duì)非易失性數(shù)數(shù)據(jù)的并行訪訪問，并為單單個(gè)數(shù)據(jù)元素素提供可靠性性機(jī)制，如校校驗(yàn)和保護(hù)。為了適用于汽車車系統(tǒng)的所有有領(lǐng)域，NVVRAM管理理器需要具有有高度的伸縮縮性（如定義義請(qǐng)求隊(duì)列的的數(shù)目和大小小，支持不同同的塊管理類類型，EEPPROM仿真真，等等）?；敬鎯?chǔ)對(duì)象NV塊：NV塊塊表示NV用用戶數(shù)據(jù)和CCRC值（可可選）組成的的存儲(chǔ)區(qū)；RAM塊：RAAM塊表示在

40、在RAM中用用戶數(shù)據(jù)和CCRC值（可可選）組成的的區(qū)域；ROM塊：ROOM塊駐留在在ROM（閃閃存）中，用用于提供缺省省數(shù)據(jù)以防NNV塊為空或或被破壞；管理塊：管理塊塊在RAM中中，包含與DDataseet NV塊塊關(guān)聯(lián)的塊索索引。另外，也也包含相應(yīng)NNVRAM塊塊的屬性/錯(cuò)錯(cuò)誤/狀態(tài)信信息。塊管理類型以下NVRAMM存儲(chǔ)類型應(yīng)應(yīng)該由NVRRAM管理器器支持，并且且由以下基本本存儲(chǔ)對(duì)象構(gòu)構(gòu)成：管理類型NV塊RAM塊ROM塊管理塊NVM_BLOOCK_NAATIVE110.11NVM_BLOOCK_REEDUNDAANT210.11NVM_BLOOCK_DAATASETT1.（m2256）10.

41、n1Nativee NVRAAM塊是最簡(jiǎn)簡(jiǎn)單的塊管理理類型。以最最小的開銷存存儲(chǔ)/檢索NNV存儲(chǔ)區(qū)。Native NVRAM塊由單個(gè)NV塊、RAM塊和管理塊組成。Redunddant NNVRAM塊塊有更高的容容錯(cuò)性、可靠靠性和可用性性，以及對(duì)數(shù)數(shù)據(jù)被破壞的的抵抗性。RRedunddant NNVRAM塊塊由兩個(gè)NVV塊、一個(gè)RRAM塊和管管理塊組成。Dataseet NVRRAM塊是相相同大小數(shù)據(jù)據(jù)塊（NV/RAM）的的陣列。應(yīng)用用一次只能存存取其中的一一個(gè)。Dattaset NVRAMM塊由多個(gè)NNV用戶數(shù)據(jù)據(jù)和（可選）CCRC區(qū)域、一一個(gè)RAM塊塊和管理塊組組成。NVRAM管理理器的AP

42、II配置種類為了使NVRAAM管理器適適合于有限的的硬件資源，定定義了3種不不同的APII配置種類：API配置置種類3：所有規(guī)定的APPI調(diào)用都可可用。支持最最大的功能性性。API配置置種類2：API調(diào)用的中中間集可用。API配置置種類1：特別用于滿足資資源非常有限限的系統(tǒng)，此此API配置置種類只提供供所需要的AAPI調(diào)用的的最小集。存儲(chǔ)硬件抽象存儲(chǔ)硬件抽象是是一組抽象于于外圍存儲(chǔ)設(shè)設(shè)備位置（片片上或板上）和和ECU硬件件布局的模塊塊。例如：片片上EEPRROM和外部部EEPROOM設(shè)備應(yīng)該該可以通過相相同的機(jī)制存存取。通過存儲(chǔ)器特有有抽象/仿真真模塊訪問存存儲(chǔ)驅(qū)動(dòng)（例例如EEPRROM抽象）

43、。通通過仿真EEEPROM接接口和閃存硬硬件單元，就就可以通過存存儲(chǔ)抽象接口口訪問這兩種種類型的硬件件。存儲(chǔ)硬件抽象的的任務(wù)是提供供訪問內(nèi)部（片片上）和外部部（板上）存存儲(chǔ)設(shè)備和存存儲(chǔ)硬件類型型（EEPRROM、閃存存）的相同機(jī)機(jī)制。EEPROM抽抽象EEPROM抽抽象層（EAA）擴(kuò)展EEEPROM驅(qū)驅(qū)動(dòng)，向上層層提供線性地地址空間上的的虛擬分段和和“實(shí)際上無限限制的”擦除/寫循循環(huán)。除此之之外，它還應(yīng)應(yīng)該提供與EEEPROMM驅(qū)動(dòng)相同的的功能。閃存EEPROOM仿真閃存EEPROOM仿真（FFEE）按照照閃存技術(shù)仿仿真EEPRROM抽象層層的行為。所所以它與EEEPROM抽抽象層有相同同的功

44、能和AAPI，并且且給出基于下下層閃存驅(qū)動(dòng)動(dòng)和閃存設(shè)備備的相似配置置。內(nèi)存抽象接口內(nèi)存抽象接口（MMemIf）允允許NVRAAM管理器存存取多個(gè)存儲(chǔ)儲(chǔ)抽象模塊（FFEE或EAA模塊）。內(nèi)存抽象接口抽抽象于下層FFEE和EAA模塊的數(shù)目目，并向上層層提供統(tǒng)一線線性地址空間間上的虛擬分分段。存儲(chǔ)驅(qū)動(dòng)EEPROM驅(qū)驅(qū)動(dòng)EEPROM驅(qū)驅(qū)動(dòng)提供讀、寫寫、擦除EEEPROM的的服務(wù)。也提提供了用于比比較EEPRROM中數(shù)據(jù)據(jù)塊和內(nèi)存中中數(shù)據(jù)塊的服服務(wù)。這些服服務(wù)是異步的的。有兩類EEEPROMM驅(qū)動(dòng)：內(nèi)部EEPPROM驅(qū)動(dòng)動(dòng)外部EEPPROM驅(qū)動(dòng)動(dòng)內(nèi)部EEPROOM驅(qū)動(dòng)直接接訪問微控制制器硬件，并并且定位

45、在微微控制器抽象象層。外部EEEPROMM驅(qū)動(dòng)使用處處理程序（hhandleer）或驅(qū)動(dòng)動(dòng)訪問外部EEEPROMM設(shè)備。它定定位在ECUU抽象層。兩種類型的驅(qū)動(dòng)動(dòng)的功能需求求和功能范圍圍都是相同的的。所以APPI在語義上上是相同的。閃存驅(qū)動(dòng)如果受到底層硬硬件的支持，閃閃存驅(qū)動(dòng)提供供讀、寫和擦擦除閃存的服服務(wù)，以及設(shè)設(shè)置寫/擦除除保護(hù)的配置置接口。閃存存驅(qū)動(dòng)提供了了一個(gè)內(nèi)置加加載器，以加加載閃存存取取代碼到RAAM中，并在在需要的時(shí)候候執(zhí)行寫/擦擦除操作。在ECU應(yīng)用模模式下，閃存存驅(qū)動(dòng)只用于于閃存EEPPROM仿真真模塊寫數(shù)據(jù)據(jù)。在應(yīng)用模模式下并不將將程序代碼寫寫到閃存中。這這應(yīng)該由啟動(dòng)動(dòng)模式

46、處理，超超出了AUTTOSAR的的范圍。有兩類閃存驅(qū)動(dòng)動(dòng)：內(nèi)部閃存驅(qū)驅(qū)動(dòng)外部閃存驅(qū)驅(qū)動(dòng)內(nèi)部閃存的驅(qū)動(dòng)動(dòng)直接存取微微控制器硬件件，并且定位位在微控制器器抽象層。外外部閃存通常常通過微控制制器數(shù)據(jù)/地地址總線連接接，然后閃存存驅(qū)動(dòng)使用總總線的處理程程序/驅(qū)動(dòng)訪訪問外部閃存存設(shè)備。外部部閃存設(shè)備的的驅(qū)動(dòng)定位在在ECU抽象象層。兩種類類型的驅(qū)動(dòng)的的功能需求和和功能范圍都都是相同的。所所以API在在語義上是相相同的。通信棧AUTOSARR通信棧的概概貌如下圖：AUTOSARR中的通信棧棧包含以下這這些部分：CANAUTOSSAR CAANAUTOSARR CAN模模型如下圖：CAN驅(qū)動(dòng)動(dòng)CAN驅(qū)動(dòng)為上上

47、層使用者提提供統(tǒng)一的接接口CAN接接口。CANN驅(qū)動(dòng)盡可能能合理地隱藏藏了相關(guān)CAAN控制器的的硬件專用性性。CAN驅(qū)動(dòng)是最最底層的一部部分，為上層層執(zhí)行對(duì)硬件件的訪問和提提供硬件無關(guān)關(guān)的API。上上層中唯一能能夠訪問CAAN驅(qū)動(dòng)的是CAAN接口。如果幾個(gè)CANN控制器屬于于相同的CAAN硬件單元元，那么它們們能夠由CAAN驅(qū)動(dòng)來控控制。一個(gè)CAN控制制器總是與一一個(gè)物理通道道相關(guān)聯(lián)。它它被允許與總總線上的物理理通道相連接接，不管CAAN接口是否否將相關(guān)的CCAN控制器器分別對(duì)待。CAN接口口（硬件抽象象）CAN接口提供供標(biāo)準(zhǔn)化的接接口，通過EECU的CAAN總線系統(tǒng)統(tǒng)來支持通信信。其APII

48、與專用CAAN控制器及及其通過CAAN驅(qū)動(dòng)層的的訪問無關(guān)。CCAN接口能能夠通過統(tǒng)一一的接口訪問問一個(gè)或多個(gè)個(gè)CAN驅(qū)動(dòng)動(dòng)。CAN接口僅能能用于CANN通信，并且且是為操作一一個(gè)或多個(gè)底底層CAN驅(qū)驅(qū)動(dòng)而專門設(shè)設(shè)計(jì)。涵蓋不不同CAN硬硬件單元的幾幾個(gè)CAN驅(qū)驅(qū)動(dòng)模塊由一一個(gè)在CANN驅(qū)動(dòng)規(guī)范中中指定的通用用接口來表示示。CAN之之外（也就是是LIN）的的其他協(xié)議不不支持。CAN傳輸輸層CAN傳輸層是是位于PDUU路由和CAAN接口模塊塊之間的模塊塊。其主要作作用是分割和和合并大于88字節(jié)的CAAN I-PPDU。根據(jù)AUTOSSAR基本軟軟件體系結(jié)構(gòu)構(gòu)，CAN傳傳輸層提供的的服務(wù)有：發(fā)送方向的

49、數(shù)據(jù)據(jù)分割；接收方向的數(shù)據(jù)據(jù)合并；數(shù)據(jù)流控制；分割期間內(nèi)的錯(cuò)錯(cuò)誤檢測(cè)。 AUTTOSAR體體系結(jié)構(gòu)定義義了通信系統(tǒng)統(tǒng)的各個(gè)具體體的傳輸層（CCanTp、包包含LinIIf的LinnTp、FllexRayyTp）。因因此，CANN傳輸層僅涵涵蓋了CANN傳輸協(xié)議的的細(xì)節(jié)。 CANN傳輸層擁有有一個(gè)接口，該該接口連接一一個(gè)單獨(dú)的下下層CAN接接口層和一個(gè)個(gè)單獨(dú)的上層層PDU RRouterr模塊。 根據(jù)AAUTOSAAR發(fā)布的計(jì)計(jì)劃，該CAAN傳輸層規(guī)規(guī)范包含下面面的限制： - CAN傳傳輸層僅運(yùn)行行在事件觸發(fā)發(fā)模式中，- 沒有傳傳送/接收撤撤消。CAN收發(fā)發(fā)器驅(qū)動(dòng)CAN收發(fā)器驅(qū)驅(qū)動(dòng)負(fù)責(zé)處理理EC

50、U上的的CAN收發(fā)發(fā)器，依據(jù)的的是與整個(gè)EECU當(dāng)前狀狀態(tài)相關(guān)的總總線專用NMM的狀態(tài)。CAN收發(fā)設(shè)備備驅(qū)動(dòng)的目標(biāo)標(biāo)：CAN收收發(fā)設(shè)備驅(qū)動(dòng)動(dòng)抽象使用CCAN收發(fā)設(shè)設(shè)備硬件芯片片。它向更高高層提供硬件件無關(guān)接口。它它也可以通過過MCAL層層的API從從ECU設(shè)計(jì)計(jì)中抽象出來來，訪問CAAN收發(fā)設(shè)備備硬件。 CANN收發(fā)設(shè)備硬硬件必須提供供功能和接口口，以映射到到AUTOSSAR CAAN收發(fā)設(shè)備備驅(qū)動(dòng)的運(yùn)行行模式模型上上。下層驅(qū)動(dòng)（SPPI和DIOO）使用的AAPI必須同同步。不支持持同步行為的的下層驅(qū)動(dòng)的的實(shí)現(xiàn)不能與與CAN收發(fā)發(fā)設(shè)備驅(qū)動(dòng)一一起使用。COMAUTOSSAR COOMAUTOSA

51、RR COM層層位于RTEE和PDU路路由器之間。它它來源于OSSEK_COOM標(biāo)準(zhǔn)。AAUTOSAAR COMM提供了信號(hào)號(hào)網(wǎng)關(guān)功能。COM與其它模模塊的依賴關(guān)關(guān)系如下圖所所示：COM MManageerCOM Mannager（CCOM管理）是基本軟件Basic Software（BSW）的一個(gè)組件。它是囊括了下層通信服務(wù)的控制的資源管理。COM Mannager控控制的基本軟軟件模塊（BBSW）與通通信相關(guān)，而而不是與軟件件組件或可運(yùn)運(yùn)行實(shí)體相關(guān)關(guān)。COM Mannager從從通信請(qǐng)求者者那里收集總總線通信訪問問請(qǐng)求，并協(xié)協(xié)調(diào)總線通信信訪問請(qǐng)求。COM Mannager的的目標(biāo)是：（1）

52、為用戶簡(jiǎn)簡(jiǎn)化總線通信信棧的使用。這這包括了總線線通信棧的初初始化和簡(jiǎn)化化的網(wǎng)絡(luò)管理理處理。（2）協(xié)調(diào)與多多個(gè)軟件組件件（在一個(gè)EECU上）無無關(guān)的總線通通信棧（允許許信號(hào)的發(fā)送送和接收）的的可用性。（3）臨時(shí)性取取消信號(hào)的發(fā)發(fā)送以阻止EECU喚醒通通信總線。（4）控制ECCU的一個(gè)以以上的通信總總線通道，這這通過為每個(gè)個(gè)通道實(shí)現(xiàn)一一種狀態(tài)機(jī)制制來實(shí)現(xiàn)。（5）提供使EECU保持總總線處于“靜靜默通信”模模式。（6）通過分配配對(duì)請(qǐng)求通信信模式必需的的所有資源來來簡(jiǎn)化資源管管理。COM Maanagerr包含以下基基本功能：狀態(tài)機(jī)制無通信狀態(tài)靜默通信狀態(tài)：網(wǎng)絡(luò)釋放狀狀態(tài)、預(yù)備總總線睡眠狀態(tài)態(tài)完全通信

53、狀態(tài)：網(wǎng)絡(luò)請(qǐng)求狀狀態(tài)、準(zhǔn)備睡睡眠狀態(tài)擴(kuò)展功能狀態(tài)期間范圍通信阻止：總線線喚醒阻止、靜靜默通信模式式的限制、無無通信模式的的限制總線通信管理網(wǎng)絡(luò)管理依賴總線錯(cuò)誤管理CAN總線關(guān)閉閉處理CANN Bus Off hhandliing網(wǎng)絡(luò)起動(dòng)指示NNetworrk Staart Inndicattion傳輸故障例外網(wǎng)絡(luò)超時(shí)例外測(cè)試支持需求阻止完全通信請(qǐng)請(qǐng)求計(jì)數(shù)器錯(cuò)誤分類錯(cuò)誤檢測(cè)錯(cuò)誤通知非功能性需求AUTOSSAR COOM與OSEEK COMM的比較根據(jù)通信部分分提供的功能能，對(duì)比兩者者在相同功能能上的APII，以及兩者者各自所特有有的API，由由于AUTOOSAR CCOM較之OOSEK CCOM

54、，多出出了一個(gè)COOM Mannager，即即通信管理模模塊部分，所所以整個(gè)AUUTOSARR COM Managger為AUUTOSARR標(biāo)準(zhǔn)所特有有，下面先對(duì)對(duì)兩者的相同同功能部分作作比較。1、相同功能及及服務(wù)（1）啟動(dòng)與控控制服務(wù)OSEKAUTOSARRStartCOOMStopCOMMGetCOMAAppliccationnModeInitMesssageStartPeeriodiicStopPerriodiccCom_IniitCom_DeIInitCom_IpdduGrouupStarrtCom_IpdduGrouupStoppCom_DissableRRecepttionDMMC

55、om_EnaableReeceptiionDMCom_GettStatuusCom_GettConfiigurattionIddCom_GettVersiionInffo兩者在通信的的啟動(dòng)與控制制服務(wù)部分的的對(duì)比可以看看出：首先，AAUTOSAAR提供的AAPI較多，表表明它的功能能較強(qiáng)；其次次，AUTOOSAR的啟啟動(dòng)與控制服服務(wù)中包含對(duì)對(duì)I-PDUU（交互層協(xié)協(xié)議數(shù)據(jù)單元元）的處理和和控制，如CCom_IppduGrooupStaart、Coom_IpdduGrouupStopp。（2）通信服務(wù)務(wù)OSEKAUTOSARRSendMesssageReceiveeMessaageSendDyn

56、namicMMessaggeReceiveeDynammicMesssageSendZerroMesssageGetMesssageSttatusCOMErroorGetSServicceIdCOMErroor_Namme1_Naame2Com_SenndSignnalCom_RecceiveSSignallCom_UpddateShhadowSSignallCom_SenndSignnalGrooupCom_RecceiveSSignallGrouppCom_RecceiveSShadowwSignaalCom_InvvalidaateSiggnalCom_InvvalidaateShaad

57、owSiignalCom_TriiggerIIPDUSeend通過對(duì)比可以以看出，OSSEK通信服服務(wù)中包含了了對(duì)錯(cuò)誤的一一些簡(jiǎn)單的處處理，如獲得得錯(cuò)誤服務(wù)的的Id（COOMErroorGetSServicceId），而而AUTOSSAR通信服服務(wù)仍然包含含對(duì)I-PDDU的處理，如如Com_TTriggeerIPDUUSend。（3）通知機(jī)制制支持服務(wù)（OOSEK）與與回調(diào)通知服服務(wù)（AUTTOSAR）OSEKAUTOSARRReadFlaagResetFllagCom_TriiggerTTransmmitCom_RxIIndicaationCom_TxCConfirrmatioon兩者在這個(gè)

58、部部分提供的功功能差別不大大，主要是對(duì)對(duì)一些標(biāo)志的的修改和設(shè)置置，以控制通通信的狀態(tài)和和執(zhí)行的功能能。2、不同功能及及服務(wù)（1）OSEKK為I-PDDU的處理提提供一類專門門的服務(wù)，稱稱為OSEKK間接網(wǎng)絡(luò)管管理接口，包包含2個(gè)APPI：I-PPDU傳輸指指示（I_MMessaggeTrannsfer）和和I-PDUU超時(shí)指示（II_MesssageTiimeOutt）。（2）OSEKK通信部分提提供了一些例例行程序?qū)νㄍㄐ牌饠U(kuò)展作作用，包含33個(gè)API：StarttCOMExxtensiion、COOMCalllouts、CCOMErrrorHoook。（3）AUTOOSAR提供供了一些調(diào)度

59、度函數(shù)，主要要是對(duì)消息或或信號(hào)的接收收或發(fā)送起路路由、調(diào)度的的作用，包含含3個(gè)APII：Com_MainFFunctiionRx、CCom_MaainFunnctionnTx、Coom_MaiinFuncctionRRouteSSignalls。（4）AUTOOSAR的通通信部分有一一個(gè)COM Managger，這是是一個(gè)通信管管理模塊，是是AUTOSSAR標(biāo)準(zhǔn)特特有的，主要要負(fù)責(zé)對(duì)通信信進(jìn)行監(jiān)控、管管理、診斷以以及管理涉及及通信的ECCU狀態(tài)。下下表列出了它它所提供的部部分API。功能定義ComM_InnitComM_DeeInitComM_GeetStattusComM_GeetInhii

60、bitioonStattusComM_ReequesttComMoodeComM_GeetMaxCComModdeComM_GeetRequuesteddComMoodeComM_GeetCurrrentCoomModee專用函數(shù)AUTOSARR通用網(wǎng)絡(luò)管管理ComM_Nmm_NetwworkSttartInndicattionComM_Nmm_TrannsmisssionFaailureeComM_Nmm_NetwworkTiimeouttAUTOSARR診斷通信管管理ComM_DCCM_ActtiveDiiagnossticComM_DCCM_InaactiveeDiagnnosticcA