EcuM is one of the first module initialised, immediately after any Ecu Reset and responsible for initialising all other BSW modules including OS and RTE. The list of modules and order of initialisation is configurable in EcuM.
EcuM manages various possible states (like Startup, Run, Sleep,Shutdown) that an Ecu can go through. A RUN request from any of it‘s configured Application(SWC) to EcuM will keep the Ecu in RUN state where OS and Sheduler is kept Alive with all it‘s routine Task executed. EcuM will proceed into the Power saving modes like Sleep or OFF, if all of it‘s known users (Application i.e SWC) agree to leave the RUN State. The main functionality during shutdown are writing back the vital information in to Non-Volatile memory.
During Sleep State any Wakeup Event is first informed to EcuM . EcuM has to Validate this Event, and if valid, then EcuM is responsible for bringing back the Ecu to the Active RUN state. If needed re-initialisation of Drivers are also done during the wakeup.
Special Features of EcuM
TTII
Time Triggered Increased Inoperation is one of the special features of EcuM , where Ecu is put into the highly energy saving sleep mode over time and a minimal functionality is executed in a regular time interval through wakeup and get back to the sleep mode.
Coniguration consistency check – Hash Algorithm
EcuM has to check and ensure the consistency of all Pre-Compile parameters of all the configured BSW modules.This is achieved by comparing Hash Values(a resultant value of Hash Algorithm) of all Pre-compile configuration parameters computed during Pre-Compile Build and Post-Build time.The computation of hash value is done by Configuration tool.
Interfaces
These interfaces are obtained by including the module header file EcuM.h
EcuM manages various possible states (like Startup, Run, Sleep,Shutdown) that an Ecu can go through. A RUN request from any of it‘s configured Application(SWC) to EcuM will keep the Ecu in RUN state where OS and Sheduler is kept Alive with all it‘s routine Task executed. EcuM will proceed into the Power saving modes like Sleep or OFF, if all of it‘s known users (Application i.e SWC) agree to leave the RUN State. The main functionality during shutdown are writing back the vital information in to Non-Volatile memory.
During Sleep State any Wakeup Event is first informed to EcuM . EcuM has to Validate this Event, and if valid, then EcuM is responsible for bringing back the Ecu to the Active RUN state. If needed re-initialisation of Drivers are also done during the wakeup.
Special Features of EcuM
TTII
Time Triggered Increased Inoperation is one of the special features of EcuM , where Ecu is put into the highly energy saving sleep mode over time and a minimal functionality is executed in a regular time interval through wakeup and get back to the sleep mode.
Coniguration consistency check – Hash Algorithm
EcuM has to check and ensure the consistency of all Pre-Compile parameters of all the configured BSW modules.This is achieved by comparing Hash Values(a resultant value of Hash Algorithm) of all Pre-compile configuration parameters computed during Pre-Compile Build and Post-Build time.The computation of hash value is done by Configuration tool.
Interfaces
These interfaces are obtained by including the module header file EcuM.h
- EcuM is initialised by EcuM_Init().
- RUN state can be requested or released by an User(SWC) using EcuM_RunRequest() and EcuM_ReleaseRun respectively by passing it‘s Identifier(SHORT NAME) as a passing parameter.
- A shutdownTarget (Reset /OFF /Sleep modes) can be selected by EcuM_SelectShutdownTarget() and the selected target can be read using EcuM_GetShutdownTarget().
- Drivers and Handlers shall use EcuM_SetWakeupEvent with the wakeup Event Id to indicate that an wakeup event has occured. The Occured Wakeup Event and their list can be obtained using the API‘s EcuM_GetPendingEvent, EcuM_GetValidatedEvent, EcuM_GetExpiredEvent and EcuM_GetStatusOfWakeupSources.
Dependencies
EcuM has got close relationship and dependencies to the following BSW modules.
- Communication Manager : ComM will request for the RUN state from EcuM if any of it‘s known user request him for the Full-Communication.
- WatchDogManager : Wdg Manager is initialised by EcuM. Also EcuM switches Watchdog Manager modes when it changes its states
- MCAL - Driver with Wakeup capability :Driver has to call EcuM on Wakeup Event.EcuM stores this Event and Validation is done using the Driver API’s.
- RTE - Rte is initialized by EcuM. EcuM state change are indicated to Rte using the interfaces provided to EcuM
Posts
No comments:
Post a Comment