EcuM – 此 AUTOSAR 子產品執行 ECU 的啟動：第 1 部分
噸ECU 的啟動順序由 ECU 管理器子產品或 EcuM 處理。EcuM 負責整個 ECU 的初始化和取消初始化。在執行微控制器的啟動檔案後，這是在啟動期間執行的第一個子產品。
-根據 AUTOSAR 規範，ECU 包括 BSW Manager (BswM)、Autosar OS 和 Scheduler Manager (SchM) 子產品。是以，EcuM 負責 BswM、SchM 和 Autosar OS 子產品的初始化和去初始化，以及一些基本的軟體驅動子產品。
– EcuM 負責喚醒和關閉 ECU。衆所周知，ECU 需要各種電源管理模式。所有這些電源管理模式都通過 EcuM 處理。是以 EcuM 負責處理各種 ECU 狀态，包括進一步的 SLEEP 和 SHUTDOWN 狀态
– EcuM 處理 ECU 的所有喚醒事件，區分實際喚醒事件和不穩定喚醒事件。表示在接收到喚醒事件後進行驗證。
-它與通信管理器（ComM）和NM子產品配合以在需要時關閉ECU。
AUTOSAR ECU 管理有兩種變體：
靈活的 EcuM——然而，靈活的 EcuM 更強大，允許設定不同的場景并在它們之間轉換，以允許：
- 部分或快速啟動，即 ECU 以有限的一組功能啟動，并繼續進行後續的逐漸啟動。
- ECU 最少啟動，然後是 BSW 和 SW-C 的交錯啟動，進而交錯 BSW 和應用程式啟動
- 多種操作狀态
- 多核 ECU，其中不同狀态（例如 STARTUP、SHUTDOWN、SLEEP 和 WAKE UP）在 ECU 的所有不同核心上得到很好的協調。
Fixed EcuM – Fixed EcuM 是一個基本軟體子產品，用于确定 ECU 狀态的 OFF、RUN 和 SLEEP 以及這些狀态之間的轉換，例如 STARTUP 和 SHUTDOWN。這對于沒有部分或快速啟動等特殊要求的傳統ECU來說已經足夠了。固定 EcuM 不支援多核 ECU
固定 EcuM 的狀态
本節僅适用于固定 EcuM，其中預定義了一組固定的狀态。但是對于靈活的 EcuM，沒有标準的 ECU 模式或狀态，ECU 的內建商決定需要哪些狀态并進行相應配置。
啟動狀态
這種狀态分為兩部分，一是OS初始化前，一是OS初始化後。STARTUP State 的主要目标是初始化 BSW 子產品
運作狀态
基礎軟體的所有子產品，包括OS和RTE，初始化後，固定的EcuM子產品進入RUN狀态。ECU 狀态管理器固定子產品。這向應用層中的 SWC 表明 RTE 和 BSW 已經初始化并且現在可以開始工作。
關機狀态
它處理基本軟體子產品的受控關閉，并導緻 ECU 的三個標明關閉目标之一，即睡眠、關閉或複位。此狀态下的關鍵活動是将非易失性資料寫回 NVRAM。
睡眠狀态
這是一種不執行任何代碼的省電情況，盡管仍有持續的電源供應以保持 ECU 運作。SLEEP 狀态提供了一組稱為關機目标的睡眠模式。它提供了功耗和重新開機 ECU 時間之間的權衡。
喚醒狀态
由于喚醒，ECU退出SLEEP狀态時進入WAKEUP狀态。它還提供了一個協定來驗證一個 WakeUp 事件是否有效，或者它是否是由某些不确定的情況引起的。隻要在 ECU 中建立了 CAN 總線通信連結。它接收作為 ECU 喚醒源的消息。但是，某些幹擾可能會導緻 CAN 總線之間的電壓差，這可能是由 CAN 總線錯誤引起的。這是 ECU 應該忽略的不确定情況之一。
關閉狀态
關閉狀态描述了其電源完全關閉的狀态。
靈活 EcuM 的階段
靈活的 ECU 狀态管理器的功能分為從 STARTUP 階段到 SHUTDOWN 階段的不同階段。下圖顯示了靈活 EcuM 子產品所有階段的概覽。
啟動階段
STARTUP 階段分為兩部分，一部分在 OS 初始化之前，一部分在 OS 初始化之後。STARTUP 階段的主要目标是初始化各種基本軟體子產品。由于本文的範圍是 ECU 的啟動順序，我們将在下一篇文章中更詳細地了解 STARTUP 階段。
上升階段
ECU啟動OS并完成SchM和BswM的啟動後，ECU進入UP階段。UP 階段在 BSW Scheduler 啟動并調用 BswM_Init 時開始。此時，記憶體管理還沒有初始化，通信棧不存在，還沒有啟動軟體元件（SW-CS）。該階段由積分器定義，ECU 根據積分器完成的配置從一種狀态移動到另一種狀态，從一種模式移動到另一種模式。
內建商必須首先執行 NVRAM 塊恢複、NVM 初始化，然後調用 NVM_Readall。積分器調用的 NvM_Readall 結束後，觸發 COM、DEM 和 FIM 子產品的啟動并通知 BswM。是以，它負責通過 BswM 子產品初始化通信堆棧。初始化 NVRAM 和 Com 堆棧後，ECU 可以啟動進一步的 RTE。一旦BSW和RTE的所有子產品都啟動了，應用層的SWC終于可以開始發揮作用了。這些 SWC 以任意順序啟動。最後，當 ECU 到達可以關閉的位置時，它會讀取自身資訊以進入 SHUTDOWN 階段。模式切換會影響要關閉的 SWC，并且在取消初始化時執行 BSW 子產品。是以，我們可以說，就ECU（EcuM）而言，
關斷階段
當 API 被調用 EcuM_GoDown() 時，關閉階段開始。這将處理基本軟體子產品的關閉并導緻關閉目标之一，RESET 或 OFF。此階段要完成的關鍵任務是寫回 NVRAM 塊。
在關閉結束時，調用 ShutdownOS() API。
睡眠階段
在此步驟中，盡管仍為 ECU 供電，但不應執行任何代碼。它被認為是一種節能狀态。根據配置，ECU 可能會在這種情況下啟用。EcuM 子產品提供睡眠模式，這是總功耗和 ECU 重新開機時間之間的權衡。ECU 會響應預期或非預期喚醒事件的到來而喚醒。EcuM 子產品提供的協定會忽略不穩定的喚醒事件
關閉階段
當 ECU 斷電時，它進入 OFF 位置。在這種情況下，如果喚醒源具有內建的功率控制，它可能仍然能夠喚醒。
在下一部分中，我們将深入讨論 EcuM 子產品的啟動過程，并将探讨其他 BSW 子產品在啟動過程中是如何初始化的。
EcuM – 此 AUTOSAR 子產品執行 ECU 的啟動：第 2 部分
一世在這篇文章中，我們将詳細了解ECU的STARTUP階段。下圖顯示了 ECU 的啟動順序。
EcuM_Init 之前的活動
一旦 ECU 啟動，第一步就是 MCU 初始化。微控制器單元一接通電源，就會跳轉到複位向量以運作引導加載程式代碼。引導加載程式是基本控制器被稱為硬體初始化的地方，例如存儲器、定時器等。接下來，所有的 C 代碼初始化都發生了。設定堆棧記憶體并初始化所有 C 變量。然後調用 EcuM_Init () API 調用 ECU 狀态管理器并完成其餘的啟動序列。
StartPreOS 序列中的活動
激活後，ECUM 将執行下圖中所描述的 StartPreOS 序列的所有步驟。這樣做是為了讓 ECU 準備好啟動作業系統。該序列應盡可能短。StartPreOS 序列初始化啟動 OS 所需的所有基本軟體子產品。我們現在将按照調用它們的順序研究每個步驟。
A – EcuM_AL_DriverInitZero – EcuM 沒有嚴格定義驅動程式和硬體抽象子產品的初始化。但是，它提供了兩個标注 EcuM_AL_DriverInitZero 和 EcuM_AL_DriverInitOne 來定義初始化塊 0 和 1。除了驅動程式初始化之外，這些塊還可能包含任何 preOS、低級初始化代碼。
B – EcuM_DeterminePbConfiguration – 此标注傳回一個指向完全初始化的 EcuM_ConfigType 結構的指針，該結構包含所有 BSW 子產品建構後配置的建構後配置資料。
C – EcuM_AL_DriverInitOne – ECU 管理器子產品在 preOS 序列中調用 EcuM_AL_DriverInitOne。除了驅動程式初始化之外，它還執行由 AUTOSAR MCU 驅動程式軟體規範定義的初始化序列。
現在讓我們看看 init 塊 0 和 1 的可能活動序列。根據硬體和軟體配置，其中一些 BSW 子產品可能會被添加或删除，其他序列也可能是可能的。這一切都取決于內建商。
Init Block 0 内的初始化活動 (EcuM_AL_DriverInitZero)
- 預設錯誤跟蹤器 - DET 子產品允許其他子產品報告任何開發錯誤
- 診斷事件管理器——DEM 子產品提供診斷服務
- 通路建構後配置資料的驅動程式——這些驅動程式不依賴于作業系統的建構後配置。
Init Block 1 (EcuM_AL_DriverInitOne) 内的初始化活動
- MCU 驅動程式——MCU 驅動程式為微控制器單元的基本初始化提供服務，如啟動代碼，以及 MCU 的斷電和複位功能。
- 端口驅動程式——處理片上端口引腳。初始化MCU端口結構，根據需要為不同的端口配置設定不同的功能
- DIO 驅動程式——它在 MCU I/O 引腳上提供通用輸入/輸出功能
- 通用定時器 – GPT 驅動程式提供對 MCU 上硬體定時器的通路和控制。
- 看門狗驅動程式——它提供初始化、改變操作模式和觸發看門狗定時器的服務。
- ADC 驅動程式——提供觸發模數轉換的服務。
- ICU 驅動程式——ICU 驅動程式提供用于解調 PWM 信号、計數脈沖、測量頻率和占空比、生成簡單中斷和喚醒中斷的服務。
- PWM 驅動器——根據設定的占空比和信号時間周期生成具有可變脈沖寬度的脈沖。
D – 擷取重置原因– EcuM_GetValidatedWakeupEvents API 傳回已驗證的喚醒事件。
E – 選擇預設關閉目标– 這些設定退出 UP 階段後 ECU 将運作的關閉狀态。可配置為OFF、SLEEP 和RESET 這三者之一。
F – 啟動 OS – 這裡 AUTOSAR OS 開始執行。
StartPostOS 序列中的活動
啟動序列的第二部分，即 StartPostOS 序列在調用 EcuM_StartupTwo 後被激活。下圖顯示了 ECU 初始化中 postOS 啟動後的順序。
啟動 BSW 排程程式 (SchM) – SchM 代表 BSW 排程程式。該中央子產品的工作是使用 AUTOSAR OS 提供的方法以定義明确且高效的方式組裝和實施 BSW 子產品。它使用 AutoSAR OS 中的“TASK”概念來觸發 BSW 子產品的關鍵處理。是以，由于它使用 AUTOSAR OS，是以在 PostOS 初始化序列中引入了它。
Init BSW Scheduler – SchM_Init () 是為 SchM 子產品的初始化定義的函數。它用于配置設定和初始化 BSW Scheduler 子產品使用的資源。如前所述，這個 AUTOSAR 可以調用作業系統服務來啟動作業系統“工作”。
Init BSW Mode Manager (BswM) – BSWM 是 AUTOSAR 服務層中的一個子產品，它與各種基礎和應用軟體子產品互動。BSW 負責兩個主要功能，模式仲裁和模式控制。它應用可配置的規則和操作清單來評估切換 ECU 模式的條件并實施所需的操作。BswM_Init () API 初始化 BSW 模式管理器子產品。BswM_Init 需要在啟動 OS 和 SchM 之前進行初始化。
結論
是以，我們遵循了電子控制單元的整個初始序列。為了初始化 MCU 硬體和外圍驅動程式，ECU 狀态管理器子產品被初始化。此外，EcuM 首先執行明确定義的啟動序列以初始化 BSW 排程程式，最後是 BSW 管理器子產品 (BWSM) Autosar OS。一旦 SchM 和 BswM 啟動并運作，我們最終可以啟動 RTE 和其他 BSW 子產品，然後是 COM 堆棧。最後，在此 ECU 上使用 SW-C 運作，現在已啟動并運作，可以使用 AUTOSAR 架構的不同層和子產品開始其操作。當一切都在 EcuM 上運作時，它會管理不同的模式開關以確定 ECU 正常運作，直到最終通過關閉 ECU 電源使其進入關閉狀态。