ECU startup sequence for Beginners

ECU stands for Electronic control units. It is an embedded system used to control one of the electrical systems in an automotive vehicle. There can be numerous ECUs in a single-vehicle ranging from Engine Control Module, Transmission Control Module, Powertrain Control Module, Brake Control Module, Anti-Lock Braking System, Body Control Module, Suspension Control Module, Battery Management System and other individual ECUs each related to a specific subsystem in a vehicle. Each of these ECUs further constitutes of these following components,

Figure 1. Components of an Electronic Control Unit in automobile

• Microcontroller - A microcontroller forms the base of an ECU. It is where all the inputs are taken in and logically worked upon with the provided software routines to provide the desired output.These microcontrollers are coupled with SRAM, FLASH RAM or EEPROM memory. It is used to store the different software components, be it either the bootloader or the actual firmware and other software parameters required for processing different tasks.
• Inputs - We can define inputs to a ECU in two categories
  1. Power Supply - These provide the input voltage and current supply for the ECU to power up and function properly
  2. Analog and Digital Inputs - These are one of the most crucial components of an ECU and are the decision-making factor in the function of a subsystem.
• Outputs - Based on the input data we control the output factor, this may be actuator drivers (relay, injector, valves), or H-bridge drivers for servo motors, or logic outputs.
• Communication Links - It is possible that the location of a sensor and the ECU are at different places resulting in a requirement for a communication link between these two. Also, at times a vehicle can contain more than 80 ECUs, thus some ECUs output are reliable on some different ECUs. Thus, there is a need for intra as well as inter ECU communication. As a result, communication lin of different communication protocols like CAN Bus protocol, LIN protocol, Flexray, etc are set up in an ECU.
• Software - This the most important component which includes the bootloader required to start the controller, different configuration parameters as well as the decision-making logic required to process different inputs and to provide an accurate output.

To understand the above concepts let us take an example of the Engine Control Unit. This ECU is responsible for controlling the air-fuel ratio in the engine, idle speed, spark discharge etc., for efficient engine performance. These controls are dependent on a variety of inputs to the ECU ranging from engine RPM, throttle position, coolant temperature, air temperature etc., as detected by their respective sensors. These inputs can be either analog or digital in format. For transmitting the input values from these sensors to the main microcontroller unit, we have to set up a communication link in between them. This can use one or more on any of the communication protocols like the CAN bus system, LIN protocol, Flexray, etc. Finally, the Software component running on this microcontroller reads these inputs and provides the decision-making ability. For example, let's say the throttle is pushed really hard then it tells the ECU to pump more fuel and air into the engine chamber. Now how is more air or fuel let in? This is where the output comes in. The ECU sends signals to fuel injectors to control how much they open or close to provide the correct amount of fuel to the engine, signals to control valve openings, camshaft actuators etc.

Complexity and need for Autosar Architecture in an ECU:

Growing number of ECUs each sourcing components from different OEMs resulted in increased complexities leading to a growing demand for a uniform standard for software development for the ECUs, this resulted in formation of AUTOSAR standard by a group of leading Automotive companies and nowadays widely followed for automotive electronics development. Following the autosar standard, make it able to develop a component software stack independent from others, and can be clubbed with any other component from various different OEMs. This added flexibility results in rapid amount of development in the automotive industry.

An ECUs implements all the three layers of the Autosar Standard Architecture spanning from Application Layer, RTE layer and the BSW layer. As we can see in the fig below, these layers are further divided into many more individual components. So, at the startup of an ECU many of these components have to interact with one another, sometimes in a certain order as well. How all of this is handled is what we will see in the further sections.

ECU Startup Sequence

The startup sequence for a ECU is handled by the ECU Manager module or EcuM. The EcuM is responsible for the initialization as well as deinitialization of the entire ECU.

• As we have seen earlier, a ECU implements all the three layers of the Autosar, it therefore also involves the BSW manager (BswM), Autosar OS, and the Scheduler Manager (SchM). Thus, the EcuM is responsible for initialization and deinitialization of BswM, SchM and Autosar OS modules as well as some basic software driver modules.
• EcuM is further also responsible for handling different ECU states including SLEEP and SHUTDOWN states.
• EcuM also handles all the wakeup events for the ECU, differentiating between real wakeup events and the erratic ones.

There are two variants of AUTOSAR ECU Management:

1. Fixed EcuM - Fixed EcuM is a basic software module which manages a Fixed set of ECU states OFF, RUN, and SLEEP and transitions between these states like STARTUP and SHUTDOWN. This is sufficient for conventional ECU’s that do not have special requirements such as partial or fast startup. Fixed EcuM does not support multi-core ECUs
2. Flexible EcuM - Flexible EcuM however is much more powerful and gives way to fixed set of state and transitions between them to allow following scenarios:
   • Partial or Fast startup, i.e. an ECU starts with a limited set of capabilities, and later on continues the startup step by step.
   • Interleaved startup where the ECU start minimally and then starts the BSW and SW-Cs thus interleaving the BSW and application startup
   • Multiple operational states
   • Multi-core ECU where different states like STARTUP, SHUTDOWN, SLEEP and WAKEUP are well coordinated on all the different cores of the ECU.

Main States of an ECU Manager

This section is true only for the Fixd EcuM where a fixed set of states is predefined. Whereas for the flexible EcuM, there are no standard ECU modes, or states, but the integrator of an ECU decides which states are needed and also configures them.

Figure 3. Fixed ECU State Manager state diagram

The Figure 3 above shows the main state machine provided by the ECU State Manager Fixed module.

STARTUP State

This state is divided into two parts, one before the OS is initialized and the other one post OS initialization. The main purpose of STARTUP state is to initialize the basic software modules.

RUN State

After all modules of basic software including OS and RTE have been initialized, The fixed EcuM module enters into RUN state.by the ECU State Manager Fixed module. It indicates the SW-Cs in the Application layer that the RTE and BSW are initialized and now it can start functioning.

SHUTDOWN State

It handles the controlled shutdown of basic software modules and results in one of the three selected shutdown targets for the ECU viz., SLEEP, OFF, or Reset. An important activity in this state is to write non-volatile data back to NVRAM.

SLEEP State

This is a power saving state in which no code is executed however there is still a constant supply of power to keep the ECU running. The SLEEP state provides a set of sleep modes referred to as shutdown targets. They provide a tradeoff between power consumption and time to restart the ECU.

WAKEUP State

The WAKEUP State is entered when the ECU comes out of the SLEEP state, due to wake up. It also provides a protocol to verify whether a wakeup event is valid and intended wakeup event or it was caused due to some erratic conditions. Let say A CAN bus communication link has been set up in the ECU. Whenever it receives a message it acts as a wakeup source for the ECU. However, it may be possible that due to some interference there may arise a voltage difference between CAN lines leading to CAN bus error. This is one of the erratic conditions which must be ignored by the ECU.

OFF State

The OFF state describes an unpowered ECU in which its power supply is completely cutoff

Phase of EcuM

The functionality of a flexible ECU State Manager is divided between different phases from STARTUP phase to SHUTDOWN phase. Figure 4 below shows an overview of all the phases of the Flexible EcuM module.

Figure. 4. Phase in Flexible ECU State Manager

STARTUP Phase

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

UP Phase

The ECU enters the UP phase after the EcuM starts the OS and completes the initialization of the SchM and BswM. The UP phase starts when BSW Scheduler has started and BswM_Init is called. At this point, memory management is still not initialized, communication stacks are not present, no software components (SW-Cs) have started yet. This phase is defined by an integrator and the ECU goes from one state to another, one mode to another as ordered by the integrator.

The integrator first has to take care of the NVRAM block restoration, initialization of the NvM and then calling NvM_Readall. After the end of NvM_Readall called by the integrator, it triggers the initialization of the COM, DEM and FIM module and the notifies BswM. Thus, it is responsible for initialization of the communication stack through BswM. After the NVRAM and Com stack has been initialized, the ECU can further start the RTE. Once all these modules form BSW and RTE are initialized, the SW-Cs in the Application layer can finally start their functioning. These SW-Cs are started in an arbitrary order. Finally, when the ECU reaches a state in which it can be powered off, it readies itself to enter into SHUTDOWN phase. The mode switches affect the SW-cs to be stopped and the BSW module deinitialization are carried on. Thus, we can say that, as far as an ECU (EcuM)is concerned, the SW_C and the BSW modules run until they are ready for the ECU to be shut down or put to sleep.

SHUTDOWN Phase

Shutdown phase is triggered when the API EcuM_GoDown() is called. It handles the shutdown of the basic software modules and results in one of the shutdown targets, RESET or OFF. The main task to be done in this phase is to write back the NVRAM blocks.

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

SLEEP Phase

In this phase, no code is supposed to be executed =, however the power is still supplied to the ECU. This is supposed to be a power saving state to save energy. Based upon the configuration, the ECU may be wake able in this state. The EcuM module provides sleep modes which are a tradeoff between the total power consumption and the restart time of the ECU. ECU wakes up in response to arrival of either intended or unintended wakeup events. The unintended wakeup events are ignored by a protocol provided by the EcuM module

OFF Phase

When the ECU is powered down it enters the OFF state. It may still be wake able in this state provided that the wakeup sources have an integrated power control.

STARTUP PHASE details

In this section, we will see the STARTUP phase of the ECU in some more detail. Figure 5 below shows the startup sequence of an ECU.

Figure 5. Startup Sequence of an ECU

Activities prior to EcuM_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 say, memories, 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.Shaky, yet serene.

Activities in StartPreOS sequence

Once activated, the ECU manager will perform all the steps as seen in figure below for the StartPreOS sequence. It is done in order to prepare the ECU to initialize the OS. This sequence has to be kept as short as possible. The StartPreOS sequence initializes all the basic software modules required to start the OS. We will now study each step/callout in the order in which they are called/performed.

Figure 6. StartPreOS sequence

1. EcuM_AL_DriverInitZero - EcuM does not strictly define the initialization of drivers and hardware abstraction modules. However, it provides two callouts EcuM_AL_DriverInitZero and EcuM_AL_DriverInitOne to define the init blocks 0 and 1. Apart from driver initializations, these blocks may also contain any preOS, low-level initialization codes.
2. 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.
3. EcuM_AL_DriverInitOne - ECU manager module calls the EcuM_AL_DriverInitOne in the PreOS sequence. Apart from driver initializations, it also does initialization sequences defined by the AUTOSAR MCU Driver software specification.

Table 1,  shows one of the possible sequences of activities for the Init Blocks 0 and 1. Depending on hardware and software configuration, some of these BSW modules may be added or left out and other sequences may also be possible.

Table 1. Example driver initialization in block 0 and 1

4. Get reset reason - The EcuM_GetValidatedWakeupEvents API returns the wakeup events which have been set to validated.
5. Select default shutdown target - These set the shutdown state in which the ECU will run after leaving the UP phase. It can be configured to one of these three, OFF, SLEEP and RESET.
6. Start OS - Here the AUTOSAR OS starts its execution.

Activities in StartPostOS sequence

The second part of the startup sequence i.e. the StartPostOS sequence is activated after a call to EcuM_StartupTwo. The Figure 8 below shows the sequence followed PostOS startup in ECU initialization.

Figure 8. StartPostOS sequence

1. Start BSW Scheduler (SchM) - SchM stands for BSW Scheduler. Position of SchM in AUTOSAR layered architecture is shown in fig below. The job of this central module is to use the means provided by the AUTOSAR OS to assemble and implement BSW modules in a well defined and efficient manner. It uses the concept of ‘TASK’ in the Autosar OS to trigger the main processing of the BSW modules. Thus as it uses AUTOSAR OS, it is started in PostOS initialization sequence.



Figure 9. AUTOSAR Layered Architecture.

2. Init BSW Scheduler -  SchM_Init() is the function defined for the initialization of the SchM module. It is used to allocate and initialize the resources to be used by the BSW Scheduler module. It can call OS services to trigger AUTOSAR OS ‘Tasks’ as discussed before.
3. Init BSW Mode Manager (BswM) - BSWM is a module in the services layer of AUTOSAR that interacts with different basic and application software modules. BSW is responsible for two main tasks, Mode Arbitration and Mode Control. It implements the configurable rules and action lists to evaluate the conditions for switching ECU modes and to implement the necessary actions to do so. BswM_Init() API initializes the BSW Mode Manager module. BswM_Init requires the OS and the SchM to be initialized before it can be called.

Conclusion

Thus, we have followed the entire initialization sequence of an Electronic Control Unit. Beginning with the powering up of the underlying microcontroller unit, to the MCUs hardware and peripheral drivers’ initialization, to how ECU State Manager module is initialized. Further thi EcuM performs a well-defined startup sequence to first initialize the Autsar OS, the very important BSW Scheduler and finally the MSW Manager module (BswM). Once the SchM and BswM are up and running, we can finally start the RTE and other BSW module, say teh COM stack. Finally, the SW-Cs deemed to be run on this ECU can start their functioning while utilizing, the now up and running, different layer and module of the AUTOSAR Architecture. While all this is going on the EcuM manages the different mode switches for the proper functioning of the ECU until it is finally brought to a Shutdown state by powering down the ECU.

Further reading

• Enabling SAE L3-L5 Autonomy with Sensor Fusion: Approaches and Challenges
• Safety Concept for Automated Driving
• Guide to Porting Real-time Traffic Sign Recognition Algorithm on Texas Instruments TDA2x SoC