EcuM – This AUTOSAR Module executes startup of an ECU : Part-1

Autosar

The startup sequence for the ECU is handled by the ECU Manager module or EcuM. EcuM is responsible for the initialization as well as the deinitialization of the entire ECU.After the execution of the startup file of a microcontroller this is the first module which executes during startup.

-According to  AUTOSAR Specification an ECU includes BSW Manager (BswM), Autosar OS, and Scheduler Manager (SchM) Module. Thus, EcuM is responsible for the initialization and deinitialization of BswM, SchM and Autosar OS modules, as well as some basic software driver modules. 

– EcuM is responsible for waking up and shutting down an ECU. As we know an ECU requires various power management Modes. These all power management modes are handled via the EcuM. So EcuM is responsible for handling various ECU states, including further SLEEP and SHUTDOWN states

– EcuM handles all wakeup events for the ECU, distinguishing between actual wakeup events and erratic ones. Means validation is done upon receiving a wakeup event.

-It cooperates with the communication manager (ComM), and NM module to shutdown the ECU when required.

There are two variants of AUTOSAR ECU management:

Flexible EcuM – Flexible EcuM, however, is more powerful and allows for different scenarios to be set and transition between them to allow:

  • Partial or fast startup, ie ECU starts with a limited set of capabilities and continues to a subsequent step-by-step startup.
  • Interleaved startup where ECU starts minimally and then BSW and SW-C, thus interleaving BSW and application startup
  • Multiple operating states
  • Multi-core ECUs where different states such as STARTUP, SHUTDOWN, SLEEP and WAKE UP are well coordinated on all the different cores of the ECU.

Fixed EcuM – Fixed EcuM is a basic software module that determines the OFF, RUN, and SLEEP of ECU states and transitions between these states, such as STARTUP and SHUTDOWN. This is sufficient for traditional ECUs, which do not have special requirements such as partial or fast startup. Fixed EcuM does not support multi-core ECUs

States of Fixed EcuM

This section is true only for fixed EcuM where a fixed set of states is predefined. But for flexible EcuM, there are no standard ECU modes or states, the integrator of an ECU decides which states are needed and configure accordingly.

STARTUP State

This state is divided into two parts, one before initializing the OS and one after OS initialization. The main objective of STARTUP State is to initialize the BSW modules

RUN state

After initializing all modules of the basic software, including OS and RTE, the fixed EcuM module enters the RUN state. ECU State Manager Fixed Module. This indicates to SWCs in the application layer that RTE and BSW have been initialized and can now start working.

SHUTDOWN State

It handles the controlled shutdown of the basic software module and results in one of the three selected shutdown targets of the ECU i.e. SLEEP, OFF, or RESET. The critical activity in this state is to write non-volatile data back to NVRAM.

SLEEP state

This is a power-saving situation in which no code is executed, although there is still a continuous supply of power to keep the ECU running. The SLEEP state provides a set of sleep modes called shutdown targets. It provides a tradeoff between power consumption and time to restart the ECU.

WAKEUP STATE

Due to waking up, the WAKEUP state is entered when the ECU exits the SLEEP state. It also provides a protocol to verify whether a WakeUp event is valid, or whether it was caused by some uncertain circumstances. Whenever a CAN bus communication link has been established in the ECU. It receives a message which acts as a wakeup source for the ECU. However, it may be possible that some interference can cause a voltage difference between the CAN buses that may be caused by a CAN bus error. This is one of the uncertain circumstances that should be ignored by the ECU.

Off State

The OFF state describes a state in which its power supply is completely off.

Phases of Flexible EcuM

The functionality of a flexible ECU state manager is divided between different phases from the STARTUP phase to the SHUTDOWN phase. The figure below shows an overview of all phases of the Flexible EcuM module.

Flexible ECUM

STARTUP phase

The STARTUP phase is divided into two parts, one part before the initialization of the OS and one part after the initialization of the OS. The main objective of the STARTUP phase is to initialize various basic software modules. As the scope of this article is the startup sequence of an ECU, we will see the STARTUP phase in more detail in the next article.

UP phase

The ECU enters the UP phase after ECU starts the OS and completes the start of SchM and BswM. The UP phase starts when the BSW Scheduler starts and calls BswM_Init. At this point, memory management is still not initialized, communication stacks do not exist, no software components (SW-CS) have been started yet. This phase is defined by an integrator and the ECU moves from one state to another, from one mode to another, according to the configuration done by the integrator.

The integrator has to firstly perform NVRAM block restoration, initialization of NVM and then call NVM_Readall. After the end of the NvM_Readall called by the integrator, it triggers the start of the COM, DEM and FIM modules and informs BswM. Thus, it is responsible for initialization of the communication stack via BswM Module. After initializing the NVRAM and Com stack, the ECU can initiate further RTE. Once all the modules of BSW and RTE are started, SWCs in the application layer can finally start their functioning. These SWCs are initiated in an arbitrary sequence. Finally, when the ECU reaches a position in which it can be switched off, it reads itself to enter the SHUTDOWN phase. Mode switches affect SWCs to be switched off and BSW modules are performed on deinitialization. Thus, we can say that as far as the ECU (EcuM) is concerned, the SWC and BSW modules last until they are ready to close or sleep the ECU.

SHUTDOWN phase

When the API is called EcuM_GoDown (), the shutdown phase begins. This handles the shutdown of the basic software module and results in one of the shutdown targets, RESET or OFF. The critical task to be done in this phase is to write back to NVRAM blocks.

At the end of the shutdown, ShutdownOS () API is called.

SLEEP phase

In this step, no code should be executed, although power is still supplied to the ECU. It is considered an energy-saving state. Depending on the configuration, the ECU may be enabled in this situation. The EcuM module provides sleep mode which is a tradeoff between total power consumption and ECU restart time. The ECU wakes up in response to the arrival of either intended or unintended wakeup events. Erratic wakeup events are ignored by the protocol provided by the EcuM module

OFF phase

When the ECU is powered off it enters the OFF position. It may still be capable of wakeup in this situation provided that the awake sources have an integrated power control.

In the next part, we are going to discuss in-depth startup procedure of the EcuM Module and will explore how other BSW Modules are initialized during startup.

13
Posts created 5

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top