ECUM模塊的案例
知薦 | AUTOSAR基礎篇之EcuM
表3 EcuM模塊常用函數列
一文輕松理解AUTOSAR之Watchdog協議棧(上)
常見函數API與配置參數
為了便于大家能夠快速的對這個模塊的重點函數調用，有個較為清楚的了解，小T通過表格的方式進行了如下總結：
Watchdog與功能安全關系
在ISO26262中，程序流監控是其中最為重要的一項，通過程序流監控可以發現軟件運行過程中可能違法設計意圖的錯誤，從而采取相應的措施，確保行車安全。
在AUTOSAR軟件架構中，程序流的監控功能實現主要由Watchdog 協議棧來實現，自上而下包括WdgM模塊，WdgIf模塊以及Wdg驅動模塊，對于應用層而言，這三個模塊通過RTE給到應用層提供接口服務，由此來實現底層監控應用層軟件的目的。
Watchdog使用實踐心得
通過EcuM模塊來完成看門狗初始化之后，剛開始設置的看門狗Counter初始值盡可能能夠Cover住Watchdog Driver初始化至Watchdog Manager初始化的時間，否則容易造成狗超時。
在OS shutdown之前Watchdog Manager去初始化，在去初始化過程中需要設置成較大的Timeout值，以確保能夠覆蓋住Watchdog Manager去初始化至系統power down或者再次reset的過程。
如果ECU支持休眠模式，如果在ECU休眠情況下看門狗仍保持在活躍狀態，那么就需要在EcuM模塊中來完成看門狗的喂狗操作。
在系統初始化以及休眠兩個階段應重點考慮看門狗是否會存在超時的可能，如果底層硬件都無法來得及喂狗，將會對系統造成重大影響。
展開 AUTOSAR 架構下看門狗的理解
WdgIf模塊，WdgM通過WdgIf接口更改WdgDriver的驅動模式，同時通知看門狗觸發條件
EcuM模塊，管理WdgM的Initializing 和DeInitializing狀態，在Sleep模式下出發硬件看門狗
Mcu模塊，在WdgM監控程序失敗之后，可以通過Mcu的接口Mcu_PerformReset立即重新ECU單元
Det模塊，診斷開發中的錯誤
Dem模塊，WdgM 在偵測到錯誤之后，可以通過Dem模塊觸發Event
SchM模塊，WdgM 調用SchM模塊接口WdgM_GlobalSuspendInterrupts進入臨界區，WdgM_GlobalRestoreInterrupts退出臨界區
Rte模塊，Rte通過WdgM_CheckpointReached()接口，監控SWC是否按照設計運行
BswM模塊，WdgM在監控Spuervised Entity失敗后，可以通過BswM模塊重啟被監控程序
OS模塊，周期性調度Task通過WdgM_MainFunction()調用WdgM_UpdateTickCount()接口為WdgM提供時間戳
具體框圖如下：
02
模塊配置
1、Wdg
Wdg Driver提供三種喂狗模式給WdgM管理,WdgM可以通過Wdg_SetMode接口設置看門狗運行模式
WdgSettingFast 快速喂狗
WdgSettingOff 關閉看門狗
WdgSettingSlow 慢速喂狗
Wdg External Trigger Counter ：外部定時器，定時調用Cbk函數，
展開 AUTOSAR基礎篇之OS(下)
鑒于內存保護可以有效防止出錯的應用模塊影響到其他模塊，降低系統完全癱瘓的風險，因此，AUTOSAR OS提供以下三種形式的保護：
棧保護
即每一個OS Application和其中的OS Object都有各自的私有棧，不同的OS Object無需存在共享棧。棧保護能夠更為快速的檢測出棧溢出，同時棧保護也是劃分OS Application的一種方式和依據。
數據保護
每一個OS Application和其中的Objects都具備各自私有數據，同時OS Application的私有數據區就是從屬于該OS Application的Objects的共享數據區；
代碼保護
代碼區既可以被私有，也可以被共享，在沒有代碼保護的前提下，錯誤代碼的執行會導致內存，時間和服務上的出錯。
OS通過MPU監控內存的訪問權限，其中AUTOSAR的訪問權限可分為受信任與非受信任的Object(Trusted and Non Trusted)兩級，受信任的Object有讀寫大部分內存的權限，但沒有讀取其他非激活棧的權限。
而非受信任的Object僅有讀寫少數內存的權限，包括當前活躍的棧，當前OS Application的數據以及LMU的共享數據。
AUTOSAR多核OS啟動與關閉
在AUTOSAR軟件基本架構下，無論是單核操作系統還是多核操作系統，都與EcuM模塊和BswM模塊息息相關。因為這兩類模塊決定了OS啟動，初始化，運行，關閉等狀態及其過程。
展開 
AUTOSAR基礎篇之BswM
BswM模塊作為AUTOSAR的一個標準模塊，內部工作機制如何實現？
BswM與各SW-C以及各個BSW模塊又是如何交互的呢？
。。。
今天，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：
正文
總體設計框架
顧名思義，BswM全稱為基礎軟件管理模塊（即Bsw Management）。該模塊根據來自BSW或者SW-C特定的輸入，在滿足一定的規則條件下執行直接對各個BSW模塊的序列化操作。
從我剛剛總結的話語中不難得出BswM具有以下三個顯著的特點：
輸入來源于各SW-C或者各BSW模塊；
執行時需要滿足一定的規則條件；
實現對各BSW模塊的序列化操作；
按照AUTOSAR規范，我們可以將前兩者叫做模式仲裁過程，而最后的步驟稱為模式控制過程。
為了便于大家理解，首先分別針對上述模式仲裁過程與模式控制過程做總體性介紹。
模式仲裁過程
如下圖1所示，BswM模塊將會接收來自SW-C或者BSW模塊的Mode Request或者Mode Indication作為模式仲裁的兩種輸入方式。
通常Mode Request來源于SW-C模塊，當然也不排除BSW模塊，比如DCM請求ComM進行full communication的時候。Mode Indication則總是來源于BSW模塊，比如CANSM，EcuM，WdgM等。
在圖中也可以看到定義了模式請求的一些規則條件，如只有Normal_Mode為TRUE且IFC1_Bus_Off為False時，條件成立為TRUE，其他情況則為False。
展開 