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管理診斷狀態。
閱讀更多 風語辰 的文章
