AUTOSAR的軟件架構根據功能及相互關系對其進行分層，如下圖所示：

· 微控制器抽象層

這一層是基礎軟件中的最低一層。它包含驅動，這些驅動是軟件模塊，用來對μC内部設備和映射了μC外部設備的内存進行訪問。

· ECU抽象層

這一層與微控制器抽象層進行對接。它也包含了外部設備的驅動。它為訪問外設提供了API，不管這些外設的位置(μC内部或外部)，也不管它們與μC的連接(端口針腳，接口類型)。

· 服務層

這層是基礎軟件中的最高層，而且它與應用軟件之間有關聯：當對I/O信号的訪問包含ECU抽象層中時，服務層提供：

l 操作系統功能

l 車輛網絡通信及管理服務

l 存儲管理（NVRAM管理）

l 診斷服務（包括UDS通信及錯誤内存）

l ECU狀态管理

1 系統服務

系統服務是一組可以由所有層次模塊使用的模塊和功能。例如實時操作系統、錯誤管理器和庫功能。為應用和基本軟件模塊提供基本服務。它包含下圖所示功能：

1.1 AUTOSAR OS

AUTOSAR OS為實時應用提供了所有基本服務，即中斷處理、調度、系統時間和時鐘同步、本地消息處理，以及錯誤檢測機制。所有服務都隐藏在良好定義的API之後。應用與OS和通信層的連接隻通過API。

AUTOSAR OS的基本特征包括：

· 靜态配置

· 能夠推斷實時系統性能

· 提供基于優先級的調度策略

· 提供運行時保護功能（存儲、計時等）

· 可宿主在低端控制器上，并且不需要其他資源

它包含以下幾個方面：

· 實時操作系統

在嵌入式汽車ECU中的實時操作系統構成軟件動态行為的基礎。它管理任務和事件的調度，不同任務間的數據流，并且提供監控和錯誤處理功能。

但是，在汽車系統中，對操作系統的需求集中在特定領域。所使用的操作系統必須高效運行并且所占存儲空間小。

在多媒體和遠程信息處理應用中，操作系統提供的特征集以及可用計算資源有很大不同。在純粹的任務管理之上，OS中還包含了複雜的數據處理（例如，流、快速文件系統等）、存儲管理甚至圖形用戶接口。

汽車OS的典型領域涵蓋了調度和同步的核心特征。在AUTOSAR中，上面讨論的附加特征在OS的範圍之外，其他WP4.2.2.1工作包（例如SPAL）涵蓋了這些特征。在AUTOSAR的體系結構約束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整體的OS/通信/驅動結構中。因此，AUTOSAR OS隻考慮核心特征。

· 核心操作系統

OSEK/VDK操作系統廣泛應用于汽車工業，并且已經證明了可以在現代車輛的所有ECU類型中使用。OSEK OS引入的概念被廣泛地理解，汽車工業領域在設計基于OSEK OS的系統方面有多年的經驗。

OSEK OS是一個事件觸發的操作系統。這為基于AUTOSAR的系統的設計和維護提供了高度的靈活性。事件觸發使得可以自由地選擇在運行時驅動調度的事件，例如角反轉、局部時間源、全局時間源、錯誤出現等等。

由于這些原因，AUTOSAR OS的核心功能必須基于OSEK OS。OSEK OS特别提供了以下特性以支持AUTOSAR：

Ÿ 固定的基于優先級調度

Ÿ 處理中斷的功能

Ÿ 隻有中斷有高于任務的優先級

Ÿ 一些防止錯誤使用OS服務的保護措施

Ÿ StartOS()和StartupHook啟動接口

Ÿ 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如下表：

· 靜态定義的調度

在許多應用中需要靜态定義一組互相關聯的任務的活動。這用于在基于數據流的設計中保證數據一緻性，與時間觸發的網絡同步，保證正确的運行時定相，等等。

時間觸發的操作系統通常作為這個問題的解決方法。然而，時間隻是簡單的事件，所以任何事件觸發的OS，包括OSEK OS，會在汽車電子控制單元實現一個用于靜态調度實時軟件的調度器。

· 監控功能

監控功能在适當的執行階段檢測錯誤，不是在錯誤發生的時刻。因此，監控功能是在運行時捕捉失效，而不是預防故障。

· 保護功能

AUTOSAR概念需要多來源的OS應用共存在同一處理器中。為了防止這些OS應用之間意想不到的交互，需要提供保護機制。

· 計時器服務

計時器服務為應用和基礎軟件提供軟件計時器。

計時機制的核心已經由OSEK OS的計數器和鬧鐘提供。如果要提供通用的軟件計時，一些補充特性需要添加到AUTOSAR OS。

· 時間觸發操作系統

時間觸發操作系統在汽車電子控制單元實現了一個用于靜态調度實時軟件的調度器。

另外，操作系統為實時應用提供了所有基本服務，即中斷處理、調度、系統時間和時鐘同步、本地消息處理，以及錯誤檢測機制。

所有服務都隐藏在良好定義的API之後。應用與OS和通信層的連接隻通過API。

對于特殊的應用，操作系統能夠配置為隻包含該應用需要的服務。因此操作系統的資源需求盡量少。

1.2 BSW調度器

BSW調度器是系統服務的一部分，因此它向所有層次的所有模塊提供服務。但是，與其它BSW模塊不同，BSW調度器提供了集成的概念和服務。BSW調度器提供方法用以：

Ÿ 把BSW模塊的實現嵌入AUTOSAR OS上下文

Ÿ 觸發BSW模塊的主要處理功能

Ÿ 應用BSW模塊的數據一緻性機制

集成者的任務是應用所給的方法（AUTOSAR OS提供的），在特定項目環境中以良好定義和有效的方式把BSW模塊裝配起來。

這也意味着BSW調度器隻是使用AUTOSAR OS。它與AUTOSAR OS調度器并不沖突。

BSW調度器的實現基于：

Ÿ BSW模塊的BSW模塊描述

Ÿ BSW調度器的配置

1.3 模式管理

模式管理簇包括三個基本軟件模塊：

· ECU狀态管理器，控制AUTOSAR BSW模塊的啟動階段，包括OS的啟動；

· 通信管理器，負責網絡資源管理；

· 看門狗管理器，基于應用軟件的生存狀态觸發看門狗。

1.3.1 ECU狀态管理器

ECU狀态管理器是一個基本軟件模塊，管理ECU的狀态（OFF、RUN、SLEEP），以及這些狀态之間的轉換（過渡狀态：STARTUP、WAKEUP、SHUTDOWN）。詳細地，ECU狀态管理器：

· 負責初始化和de-initialization所有基本軟件模塊，包括OS和RTE；

· 在需要時與所謂的資源管理器（例如，通信管理器）協作，關閉ECU；

· 管理所有喚醒事件，并在被要求時配置ECU為SLEEP狀态。

為了完成所有這些任務，ECU狀态管理器提供了一些重要的協議：

· RUN請求協議，調整ECU是保持活動狀态還是準備關閉，

· 喚醒确認協議，從“不穩定的”喚醒事件中區分出“真正的”喚醒事件，

· 時間觸發的增多非工作狀态協議（Time Triggered Increased Inoperation - TTII），允許ECU更多地進入節能的休眠狀态。

ECU狀态管理器必須支持獨立的預處理動作和過渡，以啟動ECU或将其轉換到低功耗狀态（例如，休眠狀态/備用狀态）。通過良好使用ECU狀态管理器的特性和能力，此模塊能夠用于執行電源消耗的預定義策略，因此提供了對ECU的有效能源管理。

ECU狀态管理器的特性和優勢包括：

· 初始化和關閉基本軟件模塊。

· ECU主要狀态的标準化定義。

· 時間觸發的更多非工作狀态。

1.3.2 看門狗管理器

看門狗管理器是AUTOSAR（服務層次）的标準化基本軟件體系結構的基本軟件模塊。它監控與計時約束有關的應用執行的可靠性。

分層體系結構方法使得應用計時約束和看門狗硬件計時約束分離。基于此，看門狗管理器在觸發看門狗硬件的同時提供了對一些獨立應用的生存監控。

看門狗管理器提供以下特性：

· 監督多個處于ECU的單獨應用，這些應用有獨立的計時約束并且需要特别監督運行時的行為和生存狀态。

· 每個獨立的受監控實體都有故障響應機制。

· 可以關閉對單獨應用的監督，而不會違反看門狗觸發（例如，對于禁止的應用）。

· 通過看門狗驅動觸發内部或外部、标準或窗口，看門狗。（internal or external, standard or window, watchdog）對内部或外部看門狗的訪問由看門狗接口處理。

· 根據ECU狀态和硬件性能選擇看門狗模式（Off Mode, Slow Mode, Fast Mode）。

1.3.3 通信管理器

通信管理器收集并協調來自通信請求者（用戶）的訪問請求。

通信管理器的目的是：

· 簡化通信協議棧的使用。包括通信棧的初始化，以及簡單的網絡管理。

· 調整ECU上多個獨立軟件組件的通信棧（允許發送和接收消息）的可用性。

· 暫時禁止發送消息以阻止ECU（主動地）喚醒物理通道。

· 通過為每個物理通道實現一個狀态機來控制ECU的多個物理通道。

· 可以強制ECU保持物理通道處于“silent 通信”模式。

· 分配所請求的通信模式需要的所有資源，簡化資源管理。

通信管理器定義了“通信模式”，表示一個特定的物理通道對于應用是否可用，以及如何使用（發送/接收，隻接收，即不發送也不接收）。

2 診斷服務

2.1 診斷事件管理器

診斷事件管理器DEM（Diagnostic Event Manager）是一個子組件，如同AUTOSAR内診斷模塊的診斷通信管理器（DCM）和功能禁止管理器（FIM）。它負責處理和存儲診斷事件（錯誤）和相關FreezeFrame數據。DEM進一步提供故障信息給DCM（例如，從事件存儲器讀取所有存儲的DTC（Diagnostic Trouble Code））。DEM給應用層、DCM和FIM提供接口。定義了可選的過濾服務。

2.2 功能禁止管理器

功能禁止管理器FIM（Function Inhibition Manager）負責提供軟件組件和軟件組件功能的控制機制。功能由一個、多個或部分有相同權限/禁止條件的可執行實體構成。通過FIM方法，對這些功能的禁止可以配置甚至修改。所以，極大地提高了功能在新系統環境下的适應性。

FIM意義上的功能與可執行實體是不同并且獨立的類型。可執行實體主要由調度需求來區分。與此相對的是，功能由禁止條件來分類。FIM服務關注SW-C的功能，但是并不局限于此。BSW的功能也能夠使用FIM服務。

功能被指定了一個标識符（FID – function identifier），以及該特定标識符的禁止條件。功能在執行之前獲得它們各自的權限狀态。如果禁止條件應用于特定标識符，對應的功能将不再執行。

FIM與DEM密切相關，因為診斷事件和它們的狀态信息作為禁止條件被提供給FIM。如果檢測到了失效，并且事件報告給了DEM，那麼FIM禁止FID和對應的功能。

為了處理功能和關聯事件的關系，功能的标識符和禁止條件必須引入到SW-C模闆中（與BSW等價），并且在配置期間構造數據結構以處理标識符對于特定事件的敏感性。這些關系在每個FIM中是唯一的。

RTE和FIM之間沒有功能上的聯系。在AUTOSAR中，RTE按照接口和調度需求處理SW-C。與此相對的是，FIM處理禁止條件并通過标識符（FID）為控制功能提供支持機制。因此，FIM概念和RTE概念不互相幹擾。

2.3 開發錯誤跟蹤器

開發錯誤跟蹤器DET（Development Error Tracer）主要用于在開發期間跟蹤和記錄錯誤。API參數給出了追蹤源和錯誤類型：

Ÿ 錯誤所在的模塊

Ÿ 錯誤所在的功能

Ÿ 錯誤類型

由軟件開發者和軟件集成者在特定應用和測試環境下為API功能選擇最優的策略。可能包括以下功能：

Ÿ 在錯誤報告API内設置調試器斷點

Ÿ 計算報告的錯誤

Ÿ 在RAM緩存中記錄調用和傳遞的參數

Ÿ 通過通信接口發送報告的錯誤到外部日志

DET僅僅是對SW開發和集成的輔助，并不一定要包含在産品代碼中。API已經定義，但是功能由開發者根據特定需求來選擇/實現。

2.4 診斷通信管理器

診斷通信管理器DCM（Diagnostic Communication Manager）确保診斷數據流，并且管理診斷狀态，特别是診斷對話期和安全狀态。另外，DCM檢查診斷服務請求是否被支持，以及根據診斷狀态判斷服務是否可以在當前對話期中執行。

DCM為所有診斷服務提供連接到AUTOSAR-RTE的接口。另外DCM也處理一些基本診斷服務。

在AUTOSAR體系結構中，診斷通信管理器（DCM）處在通信服務中（服務層）。DCM是應用和PDU路由器封裝的車輛網絡通信（CAN、LIN、FlexRay和MOST）之間的中間層。DCM與PDU路由器之間有一個接口。在通信過程中，DCM從PDU（Protocol Data Unit）路由器接收診斷消息。

DCM在其内部處理、檢查診斷消息，并把消息傳送到AUTOSAR SW組件進一步處理。根據診斷服務ID，将執行應用層中的相應調用。

DCM必須是網絡無關的，所以協議和消息配置在DCM的下層。這需要連接到PDU路由器的網絡無關接口。

DCM由以下功能塊組成：

DSP - Diagnostic Service Processing

DSP主要包含了完整實現的診斷服務，這些服務在不同的應用之中是通用的（例如，訪問故障數據），所以不需要由應用實現。

DSD-Diagnostic Service Dispatcher

DSD的目的是處理診斷數據流。這裡的處理意味着：

通過網絡接收新的診斷請求并發送到數據處理器。

當被應用觸發時，通過網絡傳送診斷響應（AUTOSAR SW-Component或DSP）。

DSL-Diagnostic Session Layer

DSL保證數據流與診斷請求和響應有關。DSL也監督和确保診斷協議計時。進一步，DSL管理診斷狀态。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!