1、AUTOSAR技術分析報告（科銀京成：王瑜、余鵬、曾英哲、魯陽、楊寶澤）1 AUTOSAR簡介汽車電子領域的軟件主要屬于嵌入式軟件。因此，其發展階段類似于其他嵌入式系統的軟件發展。由于受限于嵌入式硬件本身資源的匱乏，各種硬件產品的種類繁多和各自差異，以及整體嵌入式系統軟件的逐步發展，起初的軟件設計開發主要是封閉式的。這樣有助于開發針對于特定硬件體，充分優化利用資源而特定設計的軟件系統。這樣的軟件系統，是針對于特定硬件和特定應用而設計，其對于硬件資源的充分應用，以及軟件本身的執行效率無疑是非常高。然而，隨著硬件本身的逐步發展，其可用資源已經十分充分。另一方面，汽車電子領域應用需求也日趨復雜，軟件

2、本身也變得越來越復雜。因此，無論汽車廠還是部件商都感到軟件的標準化問題。軟件的可管理性，可重復使用性，可裁減性，以及質量保證等等問題被提上了議程。AUTOSAR 的提出正是基于以上一些軟件發展的要求，由幾大主要汽車廠商以及部件提供商聯合提出的，其中包括BWM, DaimlerChrysler, Ford Motor, PSA Peugeot, Toyota Motor, Volkswagen AG, Bosch, Continetal, Siemens VDO等。AUTOSAR是針對特定的汽車電子這一領域，提出的一套開放式軟件結構。其主體思想是使得軟件設計開發更易于管理，軟件系統更易于移植、裁

3、剪，以及更好的維護性和質量保證。AUTOSAR組織所提出的目標以及它所關注的功能領域在下表中列出：項目目標功能領域·解決汽車的可用性和安全性需求·保持汽車電子系統一定的冗余·可以移植到不同汽車的不同平臺上·實現標準的基本系統功能作為汽車供應商的標準軟件模塊·通過網絡共享軟件功能·集成多個開發商提供的軟件模塊·在產品生命周期內更好的進行軟件維護·更充分的利用“貨價產品”·在車輛整個生命周期中進行軟件更新與升級為了實現上述的項目目標，針對在汽車電子行業中面臨的一些挑戰，AUTOSAR所采用的解決方案及其好處可

4、以概述如下：挑戰解決方法好處不成熟的過程，因為ad-hoc模式/缺少對功能需要的追蹤能力。缺少兼容的工具（供應商、OEM）標準化的規范交換格式對規范的改進（格式、內容）提供無縫的工具鏈。浪費在實現和優化組件上的努力，而顧客并不承認這些努力的價值?；A軟件核軟件質量的加強。將工作集中在有價值的功能上。微控制器模型缺乏可用性，很難適應現有軟件。（由新功能引起的）微控制器性能的擴展需求所導致的升級需要（如重新設計）。微控制器抽象微控制器能在不需要改變更高軟件層的情況下調換。重定位ECU之間的功能時需要做大量的工作。功能重用時也需要做大量的工作。運行時環境(RTE)功能封裝導致的通信技術的獨立性。通過

5、標準化機制，使得通信更加簡單。使功能分區和功能重定位變得可能。非競爭性功能必須適應OEM的特定環境。因為需要從其它組件供應接口需要很多功夫，所以哪怕是很微小的革新，也需要做很多工作?；A軟件和模型生成的代碼間缺少清晰的接口。接口標準化減少/避免OEM和供應商之間的接口。通過使用通用接口目錄，使獨立于軟件功能的硬件實現所耗費的工作量。簡化模型驅動的開發，允許使用標準化的AUTOSAR代碼生成工具。OEM間的模型的可重用性。不同供應商之間模塊的可交換性。2 AUTOSAR軟件結構2.1 AUTOSAR軟件的組成與分層AUTOSAR的軟件組件可以用下圖來表示：對于上圖所示的一些組件，可以根據功能及相

6、互關系對其進行分層，如下圖所示：·微控制器抽象層這一層是基礎軟件中的最低一層。它包含驅動，這些驅動是軟件模塊，用來對C內部設備和映射了C外部設備的內存進行訪問。·ECU抽象層這一層與微控制器抽象層進行對接。它也包含了外部設備的驅動。它為訪問外設提供了API，不管這些外設的位置(C內部或外部)，也不管它們與C的連接(端口針腳，接口類型)。·服務層這層是基礎軟件中的最高層，而且它與應用軟件之間有關聯：當對I/O信號的訪問包含ECU抽象層中時，服務層提供：l 操作系統功能l 車輛網絡通信及管理服務l 存儲管理（NVRAM管理）l 診斷服務（包括UDS通信及錯誤內存）l

7、ECU狀態管理2.2 RTE運行時環境RTE是AUTOSAR ECU體系結構的核心組成部分。RTE是AUTOSAR虛擬功能總線（Virtual Function Bus，VFB）的接口（針對某個特定ECU）的實現，因此，它為應用程序軟件組件之間的通信提供了基本的服務，同時也便于訪問包含OS的基本軟件組件。應用程序軟件組件包含獨立于CPU和所處位置的系統軟件。這就意味著，為了滿足系統設計者所做的一些限制，應用程序組件能夠在系統配置期間被映射到任何有效的ECU上。RTE負責確保這些組件能夠通信。RTE和OS,AUTOSAR COM和其他的基礎軟件模塊（BSW）是VFB（Virtual Functi

8、onal Bus）概念的實現。RTE實現了AUTOSAR VFB的接口，從而實現了AUTOSAR軟件組件之間的通信。RTE是AUTOSAR ECU體系的核心,它提供了在AUTOSAR軟件組件間通信的基礎服務，扮演了一些方法，通過這些方法AUROSAR軟件組件能訪問包括OS和通信服務在內基礎軟件模塊的。2.3 系統服務系統服務是一組可以由所有層次模塊使用的模塊和功能。例如實時操作系統、錯誤管理器和庫功能。為應用和基本軟件模塊提供基本服務。它包含下圖所示功能：2.3.1 AUTOSAR OSAUTOSAR OS為實時應用提供了所有基本服務，即中斷處理、調度、系統時間和時鐘同步、本地消息處理，以及錯

9、誤檢測機制。所有服務都隱藏在良好定義的API之后。應用與OS和通信層的連接只通過API。AUTOSAR OS的基本特征包括：·靜態配置·能夠推斷實時系統性能·提供基于優先級的調度策略·提供運行時保護功能（存儲、計時等）·可宿主在低端控制器上，并且不需要其他資源它包含以下幾個方面：·實時操作系統在嵌入式汽車ECU中的實時操作系統構成軟件動態行為的基礎。它管理任務和事件的調度，不同任務間的數據流，并且提供監控和錯誤處理功能。但是，在汽車系統中，對操作系統的需求集中在特定領域。所使用的操作系統必須高效運行并且所占存儲空間小。在多媒體和遠程信

10、息處理應用中，操作系統提供的特征集以及可用計算資源有很大不同。在純粹的任務管理之上，OS中還包含了復雜的數據處理（例如，流、快速文件系統等）、存儲管理甚至圖形用戶接口。汽車OS的典型領域涵蓋了調度和同步的核心特征。在AUTOSAR中，上面討論的附加特征在OS的范圍之外，其他WP4.2.2.1工作包（例如SPAL）涵蓋了這些特征。在AUTOSAR的體系結構約束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整體的OS/通信/驅動結構中。因此，AUTOSAR OS只考慮核心特征。·核心操作系統OSEK/VDK操作系統廣泛應用于汽車工業，并且已經

11、證明了可以在現代車輛的所有ECU類型中使用。OSEK OS引入的概念被廣泛地理解，汽車工業領域在設計基于OSEK OS的系統方面有多年的經驗。OSEK OS是一個事件觸發的操作系統。這為基于AUTOSAR的系統的設計和維護提供了高度的靈活性。事件觸發使得可以自由地選擇在運行時驅動調度的事件，例如角反轉、局部時間源、全局時間源、錯誤出現等等。由于這些原因，AUTOSAR OS的核心功能必須基于OSEK OS。OSEK OS特別提供了以下特性以支持AUTOSAR： 固定的基于優先級調度 處理中斷的功能 只有中斷有高于任務的優先級 一些防止錯誤使用OS服務的保護措施 StartOS()和Startu

12、pHook啟動接口 ShutdownOS()和ShutdownHook關閉接口AUTOSAR OS基于OSEK OS意味著應用程序是向后兼容的。為OSEK OS編寫的應用程序可以在AUTOSAR OS上運行。但是，使用AUTOSAR OS引入的一些新特性需要對已存在的OSEK OS特性的使用有所限制。例如：為定時器回調實現定時和內存保護效率就會很低。此外，AUTOSAR OS擴展了一些已存在的特性，例如直接通過定時器驅動計數器。AUTOSAR OS提供的API向后兼容于OSEK OS的API。新的需求作為功能擴展來集成。AUTOSAR OS對OSEK OS擴展的API如下表：服務名語法GetA

13、pplicationIDApplicationType GetApplicationID (void)GetISRIDISRType GetISRID (void)CallTrustedFunctionStatusType CallTrustedFunction(TrustedFunctionIndexType FunctionIndex,TrustedFunctionParameterRefType FunctionParams)CheckISRMemoryAccessAccessType CheckISRMemoryAccess(ISRType ISRID,MemoryStartAddre

14、ssType Address,MemorySizeType Size)CheckTaskMemoryAccessAccessType CheckTaskMemoryAccess(TaskType TaskID,MemoryStartAddressType Address,MemorySizeType Size)CheckObjectAccessObjectAccessType CheckObjectAccess(ApplicationType ApplID,ObjectTypeType ObjectType,)CheckObjectOwnershipApplicationType CheckO

15、bjectOwnership(ObjectTypeType ObjectType,)StartScheduleTableRelStatusType StartScheduleTableRel(ScheduleTableType ScheduleTableID,TickType Offset)StartScheduleTableAbsStatusType StartScheduleTableAbs(ScheduleTableType ScheduleTableID,TickType Tickvalue)StopScheduleTableStatusType StopScheduleTable(S

16、cheduleTableType ScheduleTableID)NextScheduleTableStatusType NextScheduleTable(ScheduleTableType ScheduleTableID_current,ScheduleTableType ScheduleTableID_next)IncrementCounterStatusType IncrementCounter(CounterType CounterID)SyncScheduleTableStatusType SyncScheduleTable(ScheduleTableType SchedTable

17、ID,GlobalTimeTickType GlobalTime)SetScheduleTableAsyncStatusType SetScheduleTableAsync(ScheduleTableType ScheduleID)GetScheduleTableStatusStatusType GetScheduleTableStatus(ScheduleTableType ScheduleID,ScheduleTableStatusRefType ScheduleStatus)TerminateApplicationStatusType TerminateApplication(Resta

18、rtType RestartOption)DisableInterruptSourceStatusType DisableInterruptSource (ISRType DisableISR)EnableInterruptSourceStatusType EnableInterruptSource (ISRType EnableISR)ProtectionHookProtectionReturnType ProtectionHook(StatusType Fatalerror)·靜態定義的調度在許多應用中需要靜態定義一組互相關聯的任務的活動。這用于在基于數據流的設計中保證數據一致性

19、，與時間觸發的網絡同步，保證正確的運行時定相，等等。時間觸發的操作系統通常作為這個問題的解決方法。然而，時間只是簡單的事件，所以任何事件觸發的OS，包括OSEK OS，會在汽車電子控制單元實現一個用于靜態調度實時軟件的調度器。·監控功能監控功能在適當的執行階段檢測錯誤，不是在錯誤發生的時刻。因此，監控功能是在運行時捕捉失效，而不是預防故障。·保護功能AUTOSAR概念需要多來源的OS應用共存在同一處理器中。為了防止這些OS應用之間意想不到的交互，需要提供保護機制。·計時器服務計時器服務為應用和基礎軟件提供軟件計時器。計時機制的核心已經由OSEK OS的計數器和鬧鐘

20、提供。如果要提供通用的軟件計時，一些補充特性需要添加到AUTOSAR OS。·時間觸發操作系統時間觸發操作系統在汽車電子控制單元實現了一個用于靜態調度實時軟件的調度器。另外，操作系統為實時應用提供了所有基本服務，即中斷處理、調度、系統時間和時鐘同步、本地消息處理，以及錯誤檢測機制。所有服務都隱藏在良好定義的API之后。應用與OS和通信層的連接只通過API。對于特殊的應用，操作系統能夠配置為只包含該應用需要的服務。因此操作系統的資源需求盡量少。2.3.2 BSW調度器BSW調度器是系統服務的一部分，因此它向所有層次的所有模塊提供服務。但是，與其它BSW模塊不同，BSW調度器提供了集成的

21、概念和服務。BSW調度器提供方法用以： 把BSW模塊的實現嵌入AUTOSAR OS上下文 觸發BSW模塊的主要處理功能 應用BSW模塊的數據一致性機制集成者的任務是應用所給的方法（AUTOSAR OS提供的），在特定項目環境中以良好定義和有效的方式把BSW模塊裝配起來。這也意味著BSW調度器只是使用AUTOSAR OS。它與AUTOSAR OS調度器并不沖突。BSW調度器的實現基于： BSW模塊的BSW模塊描述 BSW調度器的配置2.3.3 模式管理模式管理簇包括三個基本軟件模塊：·ECU狀態管理器，控制AUTOSAR BSW模塊的啟動階段，包括OS的啟動；·通信管理器，負

22、責網絡資源管理；·看門狗管理器，基于應用軟件的生存狀態觸發看門狗。2.3.3.1 ECU狀態管理器ECU狀態管理器是一個基本軟件模塊，管理ECU的狀態（OFF、RUN、SLEEP），以及這些狀態之間的轉換（過渡狀態：STARTUP、WAKEUP、SHUTDOWN）。詳細地，ECU狀態管理器：·負責初始化和de-initialization所有基本軟件模塊，包括OS和RTE；·在需要時與所謂的資源管理器（例如，通信管理器）協作，關閉ECU；·管理所有喚醒事件，并在被要求時配置ECU為SLEEP狀態。為了完成所有這些任務，ECU狀態管理器提供了一些重要的協議

23、：·RUN請求協議，調整ECU是保持活動狀態還是準備關閉，·喚醒確認協議，從“不穩定的”喚醒事件中區分出“真正的”喚醒事件，·時間觸發的增多非工作狀態協議（Time Triggered Increased Inoperation - TTII），允許ECU更多地進入節能的休眠狀態。ECU狀態管理器必須支持獨立的預處理動作和過渡，以啟動ECU或將其轉換到低功耗狀態（例如，休眠狀態/備用狀態）。通過良好使用ECU狀態管理器的特性和能力，此模塊能夠用于執行電源消耗的預定義策略，因此提供了對ECU的有效能源管理。ECU狀態管理器的特性和優勢包括：·初始化和關閉基

24、本軟件模塊。·ECU主要狀態的標準化定義。·時間觸發的更多非工作狀態。2.3.3.2 看門狗管理器看門狗管理器是AUTOSAR（服務層次）的標準化基本軟件體系結構的基本軟件模塊。它監控與計時約束有關的應用執行的可靠性。分層體系結構方法使得應用計時約束和看門狗硬件計時約束分離?；诖耍撮T狗管理器在觸發看門狗硬件的同時提供了對一些獨立應用的生存監控?？撮T狗管理器提供以下特性：·監督多個處于ECU的單獨應用，這些應用有獨立的計時約束并且需要特別監督運行時的行為和生存狀態。·每個獨立的受監控實體都有故障響應機制。·可以關閉對單獨應用的監督，而不會違反

25、看門狗觸發（例如，對于禁止的應用）。·通過看門狗驅動觸發內部或外部、標準或窗口，看門狗。（internal or external, standard or window, watchdog）對內部或外部看門狗的訪問由看門狗接口處理。·根據ECU狀態和硬件性能選擇看門狗模式（Off Mode, Slow Mode, Fast Mode）。2.3.3.3 通信管理器通信管理器收集并協調來自通信請求者（用戶）的訪問請求。通信管理器的目的是：·簡化通信協議棧的使用。包括通信棧的初始化，以及簡單的網絡管理。·調整ECU上多個獨立軟件組件的通信棧（允許發送和接收消

26、息）的可用性。·暫時禁止發送消息以阻止ECU（主動地）喚醒物理通道。·通過為每個物理通道實現一個狀態機來控制ECU的多個物理通道。·可以強制ECU保持物理通道處于“silent 通信”模式。·分配所請求的通信模式需要的所有資源，簡化資源管理。通信管理器定義了“通信模式”，表示一個特定的物理通道對于應用是否可用，以及如何使用（發送/接收，只接收，即不發送也不接收）。2.4 診斷服務2.4.1 診斷事件管理器診斷事件管理器DEM（Diagnostic Event Manager）是一個子組件，如同AUTOSAR內診斷模塊的診斷通信管理器（DCM）和功能禁止管

27、理器（FIM）。它負責處理和存儲診斷事件（錯誤）和相關FreezeFrame數據。DEM進一步提供故障信息給DCM（例如，從事件存儲器讀取所有存儲的DTC（Diagnostic Trouble Code）。DEM給應用層、DCM和FIM提供接口。定義了可選的過濾服務。2.4.2 功能禁止管理器功能禁止管理器FIM（Function Inhibition Manager）負責提供軟件組件和軟件組件功能的控制機制。功能由一個、多個或部分有相同權限/禁止條件的可執行實體構成。通過FIM方法，對這些功能的禁止可以配置甚至修改。所以，極大地提高了功能在新系統環境下的適應性。FIM意義上的功能與可執行實體

28、是不同并且獨立的類型。可執行實體主要由調度需求來區分。與此相對的是，功能由禁止條件來分類。FIM服務關注SW-C的功能，但是并不局限于此。BSW的功能也能夠使用FIM服務。功能被指定了一個標識符（FID function identifier），以及該特定標識符的禁止條件。功能在執行之前獲得它們各自的權限狀態。如果禁止條件應用于特定標識符，對應的功能將不再執行。FIM與DEM密切相關，因為診斷事件和它們的狀態信息作為禁止條件被提供給FIM。如果檢測到了失效，并且事件報告給了DEM，那么FIM禁止FID和對應的功能。為了處理功能和關聯事件的關系，功能的標識符和禁止條件必須引入到SW-C模板中（與

29、BSW等價），并且在配置期間構造數據結構以處理標識符對于特定事件的敏感性。這些關系在每個FIM中是唯一的。RTE和FIM之間沒有功能上的聯系。在AUTOSAR中，RTE按照接口和調度需求處理SW-C。與此相對的是，FIM處理禁止條件并通過標識符（FID）為控制功能提供支持機制。因此，FIM概念和RTE概念不互相干擾。2.4.3 開發錯誤跟蹤器開發錯誤跟蹤器DET（Development Error Tracer）主要用于在開發期間跟蹤和記錄錯誤。API參數給出了追蹤源和錯誤類型： 錯誤所在的模塊 錯誤所在的功能 錯誤類型由軟件開發者和軟件集成者在特定應用和測試環境下為API功能選擇最優的策略。

30、可能包括以下功能： 在錯誤報告API內設置調試器斷點 計算報告的錯誤 在RAM緩存中記錄調用和傳遞的參數 通過通信接口發送報告的錯誤到外部日志DET僅僅是對SW開發和集成的輔助，并不一定要包含在產品代碼中。API已經定義，但是功能由開發者根據特定需求來選擇/實現。2.4.4 診斷通信管理器診斷通信管理器DCM（Diagnostic Communication Manager）確保診斷數據流，并且管理診斷狀態，特別是診斷對話期和安全狀態。另外，DCM檢查診斷服務請求是否被支持，以及根據診斷狀態判斷服務是否可以在當前對話期中執行。DCM為所有診斷服務提供連接到AUTOSAR-RTE的接口。另外DC

31、M也處理一些基本診斷服務。在AUTOSAR體系結構中，診斷通信管理器（DCM）處在通信服務中（服務層）。DCM是應用和PDU路由器封裝的車輛網絡通信（CAN、LIN、FlexRay和MOST）之間的中間層。DCM與PDU路由器之間有一個接口。在通信過程中，DCM從PDU（Protocol Data Unit）路由器接收診斷消息。DCM在其內部處理、檢查診斷消息，并把消息傳送到AUTOSAR SW組件進一步處理。根據診斷服務ID，將執行應用層中的相應調用。DCM必須是網絡無關的，所以協議和消息配置在DCM的下層。這需要連接到PDU路由器的網絡無關接口。DCM由以下功能塊組成：DSP - Diag

32、nostic Service ProcessingDSP主要包含了完整實現的診斷服務，這些服務在不同的應用之中是通用的（例如，訪問故障數據），所以不需要由應用實現。DSD-Diagnostic Service DispatcherDSD的目的是處理診斷數據流。這里的處理意味著：通過網絡接收新的診斷請求并發送到數據處理器。當被應用觸發時，通過網絡傳送診斷響應（AUTOSAR SW-Component或DSP）。DSL-Diagnostic Session LayerDSL保證數據流與診斷請求和響應有關。DSL也監督和確保診斷協議計時。進一步，DSL管理診斷狀態。2.5 存儲棧2.5.1 存儲服務

33、存儲服務由一個NVRAM管理器模塊構成，負責管理非易失性數據（從不同存儲驅動讀/寫）。它需要一個RAM鏡像作為數據接口提供給應用快速讀取。存儲服務的任務是以統一方式向應用提供非易失性數據。這抽象了存儲位置和屬性。提供非易失性數據管理機制，如保存、加載、校驗和保護和驗證、可靠存儲等。2.5.1.1 存儲硬件抽象的尋址方案存儲抽象接口和下層的閃存EEPROM仿真和EEPROM抽象層向NVRAM管理器提供虛擬線性32位地址空間。這些邏輯32位地址由16位邏輯塊號和16位塊地址偏移量組成。因此NVRAM管理器（理論上）可以有65536個邏輯塊，每個邏輯塊（理論上）可以有64Kbytes。NVRAM管理

34、器進一步將16位邏輯塊號劃分為以下部分：·（16-NVM_DATASET_SELECTION_BITS）位的塊標識符·NVM_DATASET_SELECTION_BITS位的數據索引，每個NVRAM塊最多可以有256個數據集2.5.1.2 NVRAM管理器非易失性RAM管理器（NVRAM Manager）管理所有非易失性存儲器中數據的存儲。NVRAM管理器本身與硬件無關，所有直接存取硬件的功能，例如內部或外部EEPROM、內部或外部閃存中的仿真EEPROM等，封裝在基本SW的較低層。在汽車環境中，NVRAM管理器提供服務以根據各個數據的需求來保證數據存儲和NV數據的維護。N

35、VRAM管理器要能夠管理EEPROM和/或FLASH EEPROM仿真設備的NV數據。NVRAM管理器為NV數據的管理和維護提供所需的同步/異步服務（初始化/讀/寫/控制）。NVRAM管理器處理對非易失性數據的并行訪問，并為單個數據元素提供可靠性機制，如校驗和保護。為了適用于汽車系統的所有領域，NVRAM管理器需要具有高度的伸縮性（如定義請求隊列的數目和大小，支持不同的塊管理類型，EEPROM仿真，等等）。2.5.1.3 基本存儲對象NV塊：NV塊表示NV用戶數據和CRC值（可選）組成的存儲區；RAM塊：RAM塊表示在RAM中用戶數據和CRC值（可選）組成的區域；ROM塊：ROM塊駐留在ROM

36、（閃存）中，用于提供缺省數據以防NV塊為空或被破壞；管理塊：管理塊在RAM中，包含與Dataset NV塊關聯的塊索引。另外，也包含相應NVRAM塊的屬性/錯誤/狀態信息。2.5.1.4 塊管理類型以下NVRAM存儲類型應該由NVRAM管理器支持，并且由以下基本存儲對象構成：管理類型NV塊RAM塊ROM塊管理塊NVM_BLOCK_NATIVE110.11NVM_BLOCK_REDUNDANT210.11NVM_BLOCK_DATASET1.（m<256）10.n1Native NVRAM塊是最簡單的塊管理類型。以最小的開銷存儲/檢索NV存儲區。Native NVRAM塊由單個NV塊、RA

37、M塊和管理塊組成。Redundant NVRAM塊有更高的容錯性、可靠性和可用性，以及對數據被破壞的抵抗性。Redundant NVRAM塊由兩個NV塊、一個RAM塊和管理塊組成。Dataset NVRAM塊是相同大小數據塊（NV/RAM）的陣列。應用一次只能存取其中的一個。Dataset NVRAM塊由多個NV用戶數據和（可選）CRC區域、一個RAM塊和管理塊組成。2.5.1.5 NVRAM管理器的API配置種類為了使NVRAM管理器適合于有限的硬件資源，定義了3種不同的API配置種類：·API配置種類3：所有規定的API調用都可用。支持最大的功能性。·API配置種類2：

38、API調用的中間集可用。·API配置種類1：特別用于滿足資源非常有限的系統，此API配置種類只提供所需要的API調用的最小集。2.5.2 存儲硬件抽象存儲硬件抽象是一組抽象于外圍存儲設備位置（片上或板上）和ECU硬件布局的模塊。例如：片上EEPROM和外部EEPROM設備應該可以通過相同的機制存取。通過存儲器特有抽象/仿真模塊訪問存儲驅動（例如EEPROM抽象）。通過仿真EEPROM接口和閃存硬件單元，就可以通過存儲抽象接口訪問這兩種類型的硬件。存儲硬件抽象的任務是提供訪問內部（片上）和外部（板上）存儲設備和存儲硬件類型（EEPROM、閃存）的相同機制。2.5.2.1 EEPROM抽

39、象EEPROM抽象層（EA）擴展EEPROM驅動，向上層提供線性地址空間上的虛擬分段和“實際上無限制的”擦除/寫循環。除此之外，它還應該提供與EEPROM驅動相同的功能。2.5.2.2 閃存EEPROM仿真閃存EEPROM仿真（FEE）按照閃存技術仿真EEPROM抽象層的行為。所以它與EEPROM抽象層有相同的功能和API，并且給出基于下層閃存驅動和閃存設備的相似配置。2.5.2.3 內存抽象接口內存抽象接口（MemIf）允許NVRAM管理器存取多個存儲抽象模塊（FEE或EA模塊）。內存抽象接口抽象于下層FEE和EA模塊的數目，并向上層提供統一線性地址空間上的虛擬分段。2.5.3 存儲驅動2.

40、5.3.1 EEPROM驅動EEPROM驅動提供讀、寫、擦除EEPROM的服務。也提供了用于比較EEPROM中數據塊和內存中數據塊的服務。這些服務是異步的。有兩類EEPROM驅動：·內部EEPROM驅動·外部EEPROM驅動內部EEPROM驅動直接訪問微控制器硬件，并且定位在微控制器抽象層。外部EEPROM驅動使用處理程序（handler）或驅動訪問外部EEPROM設備。它定位在ECU抽象層。兩種類型的驅動的功能需求和功能范圍都是相同的。所以API在語義上是相同的。2.5.3.2 閃存驅動如果受到底層硬件的支持，閃存驅動提供讀、寫和擦除閃存的服務，以及設置寫/擦除保護的配置

41、接口。閃存驅動提供了一個內置加載器，以加載閃存存取代碼到RAM中，并在需要的時候執行寫/擦除操作。在ECU應用模式下，閃存驅動只用于閃存EEPROM仿真模塊寫數據。在應用模式下并不將程序代碼寫到閃存中。這應該由啟動模式處理，超出了AUTOSAR的范圍。有兩類閃存驅動：·內部閃存驅動·外部閃存驅動內部閃存的驅動直接存取微控制器硬件，并且定位在微控制器抽象層。外部閃存通常通過微控制器數據/地址總線連接，然后閃存驅動使用總線的處理程序/驅動訪問外部閃存設備。外部閃存設備的驅動定位在ECU抽象層。兩種類型的驅動的功能需求和功能范圍都是相同的。所以API在語義上是相同的。2.6 通信

42、棧AUTOSAR通信棧的概貌如下圖：AUTOSAR中的通信棧包含以下這些部分：2.6.1 CAN·AUTOSAR CANAUTOSAR CAN模型如下圖：·CAN驅動CAN驅動為上層使用者提供統一的接口CAN接口。CAN驅動盡可能合理地隱藏了相關CAN控制器的硬件專用性。CAN驅動是最底層的一部分，為上層執行對硬件的訪問和提供硬件無關的API。上層中唯一能夠訪問CAN驅動的是CAN接口。如果幾個CAN控制器屬于相同的CAN硬件單元，那么它們能夠由CAN驅動來控制。一個CAN控制器總是與一個物理通道相關聯。它被允許與總線上的物理通道相連接，不管CAN接口是否將相關的CAN控制

43、器分別對待。·CAN接口（硬件抽象）CAN接口提供標準化的接口，通過ECU的CAN總線系統來支持通信。其API與專用CAN控制器及其通過CAN驅動層的訪問無關。CAN接口能夠通過統一的接口訪問一個或多個CAN驅動。CAN接口僅能用于CAN通信，并且是為操作一個或多個底層CAN驅動而專門設計。涵蓋不同CAN硬件單元的幾個CAN驅動模塊由一個在CAN驅動規范中指定的通用接口來表示。CAN之外（也就是LIN）的其他協議不支持。·CAN傳輸層CAN傳輸層是位于PDU路由和CAN接口模塊之間的模塊。其主要作用是分割和合并大于8字節的CAN I-PDU。根據AUTOSAR基本軟件體系結

44、構，CAN傳輸層提供的服務有：n 發送方向的數據分割；n 接收方向的數據合并；n 數據流控制；n 分割期間內的錯誤檢測。 AUTOSAR體系結構定義了通信系統的各個具體的傳輸層（CanTp、包含LinIf的LinTp、FlexRayTp）。因此，CAN傳輸層僅涵蓋了CAN傳輸協議的細節。 CAN傳輸層擁有一個接口，該接口連接一個單獨的下層CAN接口層和一個單獨的上層PDU Router模塊。 根據AUTOSAR發布的計劃，該CAN傳輸層規范包含下面的限制： - CAN傳輸層僅運行在事件觸發模式中，- 沒有傳送/接收撤消。·CAN收發器驅動CAN收發器驅動負責處理ECU上的CAN收發器

45、，依據的是與整個ECU當前狀態相關的總線專用NM的狀態。CAN收發設備驅動的目標：CAN收發設備驅動抽象使用CAN收發設備硬件芯片。它向更高層提供硬件無關接口。它也可以通過MCAL層的API從ECU設計中抽象出來，訪問CAN收發設備硬件。 CAN收發設備硬件必須提供功能和接口，以映射到AUTOSAR CAN收發設備驅動的運行模式模型上。下層驅動（SPI和DIO）使用的API必須同步。不支持同步行為的下層驅動的實現不能與CAN收發設備驅動一起使用。2.6.2 COM·AUTOSAR COMAUTOSAR COM層位于RTE和PDU路由器之間。它來源于OSEK_COM標準。AUTOSAR

46、 COM提供了信號網關功能。COM與其它模塊的依賴關系如下圖所示：·COM ManagerCOM Manager（COM管理）是基本軟件Basic Software（BSW）的一個組件。它是囊括了下層通信服務的控制的資源管理。COM Manager控制的基本軟件模塊（BSW）與通信相關，而不是與軟件組件或可運行實體相關。COM Manager從通信請求者那里收集總線通信訪問請求，并協調總線通信訪問請求。COM Manager的目標是：（1）為用戶簡化總線通信棧的使用。這包括了總線通信棧的初始化和簡化的網絡管理處理。（2）協調與多個軟件組件（在一個ECU上）無關的總線通信棧（允許信號的

47、發送和接收）的可用性。（3）臨時性取消信號的發送以阻止ECU喚醒通信總線。（4）控制ECU的一個以上的通信總線通道，這通過為每個通道實現一種狀態機制來實現。（5）提供使ECU保持總線處于“靜默通信”模式。（6）通過分配對請求通信模式必需的所有資源來簡化資源管理。COM Manager包含以下基本功能：狀態機制無通信狀態靜默通信狀態：網絡釋放狀態、預備總線睡眠狀態完全通信狀態：網絡請求狀態、準備睡眠狀態擴展功能狀態期間范圍通信阻止：總線喚醒阻止、靜默通信模式的限制、無通信模式的限制總線通信管理網絡管理依賴總線錯誤管理CAN總線關閉處理CAN Bus Off handling網絡起動指示Netwo

48、rk Start Indication傳輸故障例外網絡超時例外測試支持需求阻止完全通信請求計數器錯誤分類錯誤檢測錯誤通知非功能性需求·AUTOSAR COM與OSEK COM的比較根據通信部分提供的功能，對比兩者在相同功能上的API，以及兩者各自所特有的API，由于AUTOSAR COM較之OSEK COM，多出了一個COM Manager，即通信管理模塊部分，所以整個AUTOSAR COM Manager為AUTOSAR標準所特有，下面先對兩者的相同功能部分作比較。1、相同功能及服務（1）啟動與控制服務OSEKAUTOSARStartCOMStopCOMGetCOMApplicat

49、ionModeInitMessageStartPeriodicStopPeriodicCom_InitCom_DeInitCom_IpduGroupStartCom_IpduGroupStopCom_DisableReceptionDMCom_EnableReceptionDMCom_GetStatusCom_GetConfigurationIdCom_GetVersionInfo兩者在通信的啟動與控制服務部分的對比可以看出：首先，AUTOSAR提供的API較多，表明它的功能較強；其次，AUTOSAR的啟動與控制服務中包含對I-PDU（交互層協議數據單元）的處理和控制，如Com_IpduGro

50、upStart、Com_IpduGroupStop。（2）通信服務OSEKAUTOSARSendMessageReceiveMessageSendDynamicMessageReceiveDynamicMessageSendZeroMessageGetMessageStatusCOMErrorGetServiceIdCOMError_Name1_Name2Com_SendSignalCom_ReceiveSignalCom_UpdateShadowSignalCom_SendSignalGroupCom_ReceiveSignalGroupCom_ReceiveShadowSignalCom_

51、InvalidateSignalCom_InvalidateShadowSignalCom_TriggerIPDUSend通過對比可以看出，OSEK通信服務中包含了對錯誤的一些簡單的處理，如獲得錯誤服務的Id（COMErrorGetServiceId），而AUTOSAR通信服務仍然包含對I-PDU的處理，如Com_TriggerIPDUSend。（3）通知機制支持服務（OSEK）與回調通知服務（AUTOSAR）OSEKAUTOSARReadFlagResetFlagCom_TriggerTransmitCom_RxIndicationCom_TxConfirmation兩者在這個部分提供的功能

52、差別不大，主要是對一些標志的修改和設置，以控制通信的狀態和執行的功能。2、不同功能及服務（1）OSEK為I-PDU的處理提供一類專門的服務，稱為OSEK間接網絡管理接口，包含2個API：I-PDU傳輸指示（I_MessageTransfer）和I-PDU超時指示（I_MessageTimeOut）。（2）OSEK通信部分提供了一些例行程序對通信起擴展作用，包含3個API：StartCOMExtension、COMCallouts、COMErrorHook。（3）AUTOSAR提供了一些調度函數，主要是對消息或信號的接收或發送起路由、調度的作用，包含3個API：Com_MainFunctionR

53、x、Com_MainFunctionTx、Com_MainFunctionRouteSignals。（4）AUTOSAR的通信部分有一個COM Manager，這是一個通信管理模塊，是AUTOSAR標準特有的，主要負責對通信進行監控、管理、診斷以及管理涉及通信的ECU狀態。下表列出了它所提供的部分API。功能定義ComM_InitComM_DeInitComM_GetStatusComM_GetInhibitionStatusComM_RequestComModeComM_GetMaxComModeComM_GetRequestedComModeComM_GetCurrentComMode專用

54、函數AUTOSAR通用網絡管理ComM_Nm_NetworkStartIndicationComM_Nm_TransmissionFailureComM_Nm_NetworkTimeoutAUTOSAR診斷通信管理ComM_DCM_ActiveDiagnosticComM_DCM_InactiveDiagnosticAUTOSAR ECU狀態管理ComM_EcuM_RunModeIndicationComM_EcuM_WakeUpIndication總線接口ComM_BusIf_BusOffIndication調度函數ComM_MainFunction2.6.3 FlexRay· A

55、UTOSAR FlexRayAUTOSAR FlexRay的分層體系結構如下圖所示：·FlexRay接口FlexRay接口提供一種標準化的接口以訪問FlexRay通信系統/硬件。FlexRay接口必須與所使用的專用FlexRay CC及其通過FlexRay驅動的訪問無關。FlexRay接口提供通過統一接口的對一個或幾個FlexRay驅動的訪問。FlexRay接口的主要任務有：（1）為上層提供到FlexRay通信系統的抽象接口。（2）FlexRay接口通過一個或多個硬件專用驅動模塊來訪問FlexRay硬件，而不是直接訪問。（3）為了訪問FlexRay通信控制器，FlexRay接口使用一

56、個或多個FlexRay驅動模塊。（4）為了訪問FlexRay收發器，FlexRay接口使用一個或多個FlexRay收發器驅動模塊。（5）FlexRay接口可執行代碼與FlexRay通信控制器和FlexRay收發器完全不相關。（6）FlexRay接口允許代碼模塊的對象代碼提交，遵循“one-fits-all”原則。（7）FlexRay接口提供給上層AUTOSAR BSW模塊的功能如下：A初始化B配置/重配置C數據傳送（發送和接收）D啟動/停止/中斷通信EFlexRay專用服務F設置運行模式G獲取狀態信息H各種計時器功能·FlexRay驅動FlexRay驅動模塊必須為FlexRay接口模

57、塊、API的使用者提供統一接口，以訪問許多FlexRay通信控制器，這些控制器通常是相同類型的。FlexRay驅動是一個軟件層，它將抽象功能請求映射到CC專用硬件的序列上。CC的硬件實現將從FlexRay接口隱藏。·FlexRay傳輸層FlexRay傳輸層為使用物理地址和功能地址的、分段式的確認過的和未確認過的1對1通信，以及分段式的未確認過的1對n通信提供支持。·FlexRay收發器驅動FlexRay收發器驅動負責處理ECU上的FlexRay收發器，其依據是總線專用NM的狀態。2.6.4 IPDUMPDU多路技術是指通過其SDU（Service Data Unit）的一個以上的特定設計來使