AUTOSAR Mode Management: ECU State and Communication Modes

The problem

An ECU does not just run; it must start up in order, decide when to communicate, keep running while needed and shut down safely, storing data before power is removed. In AUTOSAR this is handled by mode management modules such as EcuM, BswM and ComM. Errors here cause ECUs that drain the 12 V battery, miss wake-ups or lose stored data.

Objectives

• Describe the ECU state and communication mode concepts of AUTOSAR Classic.
• Model EcuM, ComM and BswM behaviour for one ECU in Stateflow.
• Connect application components through mode-switch ports.
• Simulate wake-up, run, post-run and shutdown sequences with faults.
• Verify sequences against timing and ordering requirements.

What you need

Key concepts

EcuM

The ECU State Manager handles start-up, the run phase, shutdown and sleep, including wake-up source validation.

ComM

The Communication Manager decides per network whether the ECU is in full, silent or no communication, based on requests from users and the network state.

BswM

The Basic Software Mode Manager evaluates rules over mode requests and conditions and executes action lists, such as starting communication or switching application modes.

Mode-switch interface

An AUTOSAR interface that notifies components of mode changes, so runnables can be triggered on entering or leaving a mode.

Step-by-step guide

1. 1

   Define the ECU and its modes

   Choose an EV ECU such as an on-board charger controller. List its wake-up sources: ignition-on signal, CAN wake-up, charge connector plug-in and a timer for scheduled charging. Define application modes such as Off, Standby, Drive and Charge, and write requirements for start-up order, when communication starts, minimum run time after the last request, data storage before sleep, and maximum shutdown time.

   Checkpoint: A table of wake-up sources, application modes and numbered timing and ordering requirements.

2. 2

   Study the AUTOSAR concepts

   From the AUTOSAR Classic specifications for EcuM, BswM and ComM, summarise in your own words the ECU states, the fixed versus flexible EcuM variants, the ComM modes per channel and how BswM rules combine mode requests into actions. Draw how they interact during wake-up: EcuM validates a wake-up, BswM starts communication through ComM, and application components request run. Note which parts you will model and which you will simplify.

   Checkpoint: A one-page summary and an interaction diagram for a CAN wake-up, with simplifications listed.

3. 3

   Model EcuM behaviour

   In Stateflow, model the ECU state machine with Startup, Run, PostRun, Shutdown and Sleep states. Inputs are wake-up events, wake-up validation results and run requests from users; outputs are state and actions such as initialising drivers or starting the write-all of non-volatile data. Handle unvalidated wake-ups, for example a CAN glitch that does not lead to a valid message within a timeout, by returning to sleep.

   Checkpoint: The chart moves from Sleep through Startup to Run on a valid wake-up and back to Sleep on an invalid one.

4. 4

   Model ComM and network behaviour

   Add a ComM chart per CAN channel with No, Silent and Full Communication modes, driven by user requests and a simplified network management input that indicates whether other ECUs still need the bus. Model the bus sleep timer, so the ECU leaves the bus only after network management allows it. Connect ComM to EcuM: no communication is requested in Shutdown, and Full Communication is requested only in Run.

   Checkpoint: Simulation shows the channel entering Full Communication after wake-up and No Communication only after the network releases the bus.

5. 5

   Model BswM rules

   Implement BswM as a set of rules evaluated each cycle, for example: if ECU state is Run and charge connector is plugged then switch application mode to Charge and request Full Communication; if no run requests remain then release run and start post-run. Implement rules as a truth table or Stateflow chart with action lists. Make the rule table data-driven so it can be reviewed as a table.

   Checkpoint: A reviewed rule table and a model that applies it, with each rule triggered at least once in simulation.

6. 6

   Connect application components

   Create two application components with AUTOSAR Blockset that receive the application mode through a mode receiver port typed by a mode-switch interface. Add runnables triggered on mode entry, for example an initialisation runnable on entering Charge and a store-data runnable on leaving Drive. Make one component a run-request user that keeps the ECU awake while charging is active. Generate code for both components to confirm the mode ports appear correctly in the ARXML.

   Checkpoint: Mode changes trigger the expected runnables in the components, shown in the simulation log.

7. 7

   Simulate sequences

   Build a top-level model with wake-up sources, a 12 V supply input and the mode management charts. Simulate: ignition wake-up to Drive and back to sleep; plug-in wake-up to Charge with completion and sleep; a CAN wake-up that is not validated; ignition-off during charging; and a supply dip during shutdown. Log ECU state, ComM modes, application mode and runnable activations against time.

   Checkpoint: Timing diagrams for each sequence with every transition labelled.

8. 8

   Verify against requirements

   Write test cases in Simulink Test with temporal assessments: communication starts within a set time after a valid wake-up, the ECU stays in post-run at least the minimum time, the non-volatile write completes before Sleep and the ECU never sleeps while a run request is active. Add a fault test where a component never releases its run request, and specify and test a maximum keep-awake time to protect the 12 V battery.

   Checkpoint: All requirement assessments pass, including the stuck run-request case.

9. 9

   Report

   Document the ECU, mode definitions, AUTOSAR concepts, the three models, the rule table, the simulated sequences and the verification results. Discuss how the real modules are configured in industry tools, where these behaviours are set in the EcuM, BswM and ComM configuration rather than written by hand. Mention the risks your tests address, such as battery drain from an ECU that never sleeps.

   Checkpoint: A report with timing diagrams, a rule table and verification evidence.

Testing & validation

• Valid and invalid wake-up handling.
• ComM mode transitions consistent with network release.
• Post-run minimum time and data storage before sleep.
• No sleep while a run request is active, and maximum keep-awake protection.

Expected results

A simulated AUTOSAR mode management design for one ECU, with verified start-up, communication and shutdown sequences and protection against battery drain.

Take it further

• Run the state machines on the STM32 kit with CAN wake-up from a second node.
• Model AUTOSAR network management messages between two ECUs.
• Add partial networking so only some ECUs wake for charging.
• Measure the effect of mode timing on quiescent current in a battery model.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.