Autosar Ecu State Manager

Presented by:
SHANKU KAK
Crevavi Technologies Pvt. Ltd.
 EcuM Overview
• The ECU Manager module is a basic software module that
manages common aspects of ECU states.
• ECU initialization in AUTOSAR application is handled by the
EcuM module of BSW. After the initialization sequence in
boot-loader and C Init Code has been completed, the first
API to be called from the “main()” is EcuM_Init().
• ECU Manager(EcuM) module
1. Initializes and de-initializes the OS and RTE, the SchM and
the BswM, as well as some basic software driver modules.
2. Configures the ECU for SLEEP and SHUTDOWN when
requested.
3. Manages all wakeup events on the ECU
 OFF
Power ON

Wa
STARTUP k
pow eup w
er c ith i
ont n
rol tegrat
ed
Normal
Startup

Reset Other
RUN WAKEUP
keup
Wa nt
All Applications Eve II Wakeup
have Shutdown / TT
e? Event
tru
p ==
e
Sle
SHUTDOWN Other
SLEEP

Power OFF
OFF
 POWER ON
WAKEUP WITH POWER
CONTROL

STARTUP I

WAKEUP I
STARTUP II
WAKEUP
VALIDATION

WAKEUP RUN II
REACTION No RUN RUN Request
RESET
VALID INVALID RUN III
WAKEUP II
WAKEUP EVENT PRE SHUTDOWN

SLEEP
HALT GO OFF I
SLEEP I
GO SLEEP GO OFF II
SLEEP II
POLLING
POWER OFF
 STARTUP
The startup is divided into two parts, first part being StartPreOs
sequence and the second part being StartPostOs sequence.

In the first part of initialization [handled by EcuM_Init()] the

following activities take place:
• Initialization of interrupts [EcuM_AL_SetProgrammableInterrupts()]
• Initialization of BlockZero drivers [EcuM_AL_DriverInitZero()]
• Loading of Post Build Configuration Data
• Validation of the loaded data
• Initialization of BlockOne drivers [EcuM_AL_DriverInitOne()]
• Translation of Reset Reason
• Selection of default Shutdown Target
• Starting the OS
 Boot C init module BSW module
Menu Code OS Tasks EcuM

ResetVector()

Reset Jump()
Setup
Stack()
EcuM_Init()
Ecum_AL_DriverInitZero()
Ecum_DeterminePbConfiguration()
Ecum_AL_DriverInitOne() StartPreOS
StartOS() sequence
StartupHook()

ActivateTask()
EcuM_StartupTwo()
Ecum_AL_DriverInitTwo()
Ecum_AL_Driver
InitThree()

SchM_Init()
StartPostOS
sequence
BswM_Init()
• The very first step once the ECU is powered up is the MCU initialization. As the microcontroller unit
receives power it jumps to the Reset vector in order to run the bootloader code. The bootloader is
where the basic controller hardware initialization takes place like memory, timers, etc. Further, all the C
code initialization takes place. A stack area is set up and all the C variables are initialized. After this a
call to EcuM_Init() API invokes the ECU State Manager and it carries on the rest of the startup
sequences.

• The following modules will usually be initialized in the BlockZero drivers callout
Det_Init() – Default Error Tracer
Det_Start()
Dem_MasterPreInit(). – Diagnostic Event Manager
• The following modules will usually be initialized in the BlockOne drivers callout
Mcu_Init()
Gpt_Init() – General Purpose Timer
Wdg_Init() – Watchdog
WdgM_Init() – Watchdog Manager
Adc_Init()
Icu_Init() – Input Capture Unit
Pwm_Init()

• EcuM_DeterminePbConfiguration - This callout returns a pointer to a fully initialized EcuM_ConfigType

structure containing the post-build configuration data for all the BSW module post-build configurations.

• The last step of the StartPreOs Sequence is always to start the OS. At this point EcuM gives up the
 STARTUP ctd.
• Initializations done in BlockZero and BlockOne drivers are low
level initializations that are not dependent on the OS.
• AUTOSAR provides callouts for the initialization of interrupts,
BlockZero and BlockOne drivers. These callouts are part of the
initialization sequence by default, but the actual
implementation inside these callouts are target dependent.
AUTOSAR and the tool chain vendors provide
recommendations only. What exactly is done in these callouts,
is upto the system designers discretion.
• There are two variants of the EcuM module, flex and fixed.
Flex is the more advanced of the two. It supports multi-core
ECUs along with partial or fast wake-up, interleaved wake-ups
of BSW, RTE, APPL and even multiple running states.
module Integration module module
EcuM Code MCU OS

Ecum_AL_DriverInitZero()

Ecum_DeterminePbConfiguration()

StartPreOS sequence
Ecum_ErrorHook()

Ecum_AL_DriverInitOne()

Mcu_GetResetReason()

EcuM_SelectShutdownTarget()

Ecum_LoopDetection()

StartOS()
 STARTUP II
After the OS has started, EcuM_StartupTwo() is called from
an Init_OsTask and it hands over the control back to the
EcuM module. Then the StartPostOs Sequence starts and
following steps are handled by EcuM_StartupTwo().
• SchM_Init() — BSW scheduler is initialized
• BswM_Init() — BSW Mode Manager is initialized
• BSW is notified about the wake-up events raised
received during the startup.
In case of multi-core ECU, SchM_Init() and BswM_Init() on
the master core is called first followed by the same steps in
the slave core. After the BswM has been initialized, RTE is
started and then the rest of the initialization continues.
 Startup Two Initializations
• Initialization of BlockTwo drivers [EcuM_AL_DriverInitTwo()]. The
following modules will usually be initialized in the BlockTwo drivers
callout(These don’t rely on their personal NVRam data):
– EEPROM, Flash, NVRam Manager
– CAN/ LIN/ Flexray/ Ethernet Driver, Interface, State manager, TP
– DCM
– Network Manager

• Initialization of BlockThree drivers [EcuM_AL_DriverInitThree()]. The

following modules will usually be initialized in the BlockThree drivers
callout(These rely on personal NVRam data):
– Diagnostic Event Manager
– Function Inhibition Manager
– Communication Manager
– Secure Onboard Communication
 RUN
• RUN state is entered when OS and RTE are initialized.
• It can have 2 sources of entry:
– STARTUP
– WAKEUP
• RUN state indicates to SW-C’s above the RTE that BSW has
initialized and Applications can start operating.
• BSW Modules(mostly COMM) or SW-C’s should request EcuM
to maintain RUN state else it will trigger Shutdown. RUN state
can be requested or released by a SW-C using
EcuM_RunRequest() and EcuM_ReleaseRun respectively by
passing it‘s Identifier(SHORT NAME) as a passing parameter.​
• Two sub-states
– RUN (RUN II)
– Post-RUN (RUN III)
 RUN II
• RUN II is the state in which SW-C’s should execute their
regular tasks.
• EcuM module shall remain in RUN state for a
configurable minimum period which can be set using
parameter - EcuMRunMinimumDuration
• Minimum duration is required to give SW-C’s a chance to
request RUN otherwise EcuM will immediately leave the
RUN state.
• After the last RUN request has been released EcuM shall
advance to the RUN III state.
• When leaving RUN II state the callout EcuM_OnExitRun()
shall be invoked and PostRun mode shall be indicated.
 RUN III
• RUN III state provides a Post_RUN phase for SW-C’s and allows
them to save important data or switch off peripherals before
EcuM continues with the Shutdown process.
• Also while in RUN III state if the EcuM receives a RUN request
the EcuM module will immediately re-enter RUN II state.
• While being in the Post_RUN mode, the EcuM must poll the
ComM using the API ComM_GetState() and compare to state
COMM_NO_COM. Even if one channel has requested
communication the EcuM has to return to RUN mode.
• When leaving RUN III state the callout EcuM_OnExitPostRun()
shall be invoked.
 WAKEUP

• WAKEUP state is entered generally when ECU comes

out of SLEEP state which is an energy saving state.
WAKEUP state can also be entered while ECU is coming
out of STARTUP and SHUTDOWN.
• WAKEUP is entered due to both intended and
unintended wake up requests. Unintended wake up can
be due to a glitch like voltage spike which can for
example make CAN transceiver to interpret it as a Com
request. To differentiate between intended and
unintended wake up, the WAKEUP state provides
Wakeup Validation Protocol which can decide if the
 WAKEUP VALIDATION
Wake up validation shall apply only to those wake up sources where it is required by
configuration.
• For each pending wake up event for which validation is requested, a validation
timeout shall be started. If the last timeout expires without the validation then
wake up validation is considered to have failed.
• Drivers and Handlers shall use EcuM_SetWakeupEvent with the wakeup Event_Id
to indicate that an wakeup event has occurred. The Occurred Wakeup Event and
their list can be obtained using the API‘s​:
– EcuM_GetPendingEvent,
– EcuM_GetValidatedEvent,
– EcuM_GetExpiredEvent,
– EcuM_GetStatusOfWakeupSources.​

• Following sources shall not require validation under any circumstances:

– ECUM_WKSOURCE_POWER
– ECUM_WKSOURCE_RESET
– ECUM_WKSOURCE_INTERNAL_RESET
– ECUM_WKSOURCE_INTERNAL_WDG
 SHUTDOWN
• The SHUTDOWN state handles controlled shutdown of Basic
Software modules and finally results in selected shutdown target for
the ECU: OFF, SLEEP or RESET
– OFF when ECU is unpowered
– SLEEP is an energy saving state in which no code is executed but power
supply is there so ECU is wakeable in this state.
– A shutdownTarget (Reset /OFF /Sleep modes) can be selected by
EcuM_SelectShutdownTarget()​ and the selected target can be read using
EcuM_GetShutdownTarget().
• An important activity in shutdown state is to write non volatile data
back to NVRAM.
• If a valid wake up event occurs when ECU is in transition to SLEEP
the ECU will as quickly as possible proceed to the WAKEUP state.
• Only from RUN III state can the shutdown be triggered when from
all channels COMM returns NO_COM
 The SLEEP state is used to conserve power when the ECU is not actively performing any critical tasks or
services. It allows the ECU to enter a low-power mode while still maintaining some functionality to quickly
resume operation when needed. In the SLEEP state, the ECU minimizes power consumption by shutting down
non-essential functions, such as peripheral devices and high-power components. The EcuM module ensures
that critical functions required for wake-up events, such as key presses or external signals, remain active. In
this state, the ECU typically operates at a reduced clock frequency or uses dedicated low-power modes
provided by the hardware.
Wake-up Sources:
The EcuM module monitors designated wake-up sources, which can include external signals, communication
events, or internal timers. When a wake-up event is detected, the EcuM module transitions the ECU from the
SLEEP state to an active state (STARTUP or RUN) to resume normal operations.

• GO OFF I:
– In the GO OFF I state, the ECU is preparing for shutdown and initiating the shutdown sequence.
– In this state, the EcuM module performs various operations such as stopping non-critical services, releasing
resources, and notifying other modules about the impending shutdown.
– The GO OFF I state allows time for critical tasks and services to complete before moving to the next state.
– Once the GO OFF I state is completed, the ECU transitions to the GO OFF II state.
• GO OFF II:
– In the GO OFF II state, the ECU is in the final stage of the shutdown process.
– This state involves the deinitiation of critical services and the final release of resources.
– The EcuM module ensures that all critical operations are stopped, and the ECU is in a safe state for
complete shutdown. Once the GO OFF II state is completed, the EcuM transitions the ECU to the
SHUTDOWN target state (RESET OR OFF).