AUTOSAR Mode Management

=======================================================================================================

💬💬💬In this post we are not discussing any specific Mode Managers of AUTOSAR BSW such as BswM, EcuM, WdgM, COMM, NM, DCM, CSM or any other Mode manager module. we are discussing general concepts of mode management in the AUTOSAR.

=======================================================================================================

Brief introduction to AUTOSAR Mode Management

Introduction: Mode is state in the state machine. Modes are available in various vehicle environment such as vehicle level as Vehicle Mode, Application level as Application Mode and Basic software level as BSW mode. Transition between the modes are defined by the mode condition or events.
State Machine contains the different mode and its transition condition.

Different types of Modes and its scope

• Vehicle Mode: A Vehicle Mode is a mode that is not controlled and standardized by the Mode Managers in the BSW. The scope of a Vehicle Mode is the whole vehicle. Example: Transport Mode, Power Saving Mode. Vehicle Power Modes like Off, Accessory, RUN, Propulsion and Start
• Application Mode: An Application Mode is a mode that is controlled by the Mode Managers in the SWC. The scope of an Application Mode is a limited number of SW-Cs that belongs to an ECU (Intra-ECU Communication). Examples: Normal Operation, in HVAC application defined different modes depends on the Temperature Range.
• BSW Mode: A BSW Mode is mode, which is controlled and standardized by the Mode Manager in the BSW. A BSW Mode is always local to one ECU. Examples: ComM Modes such as NO COMMUNICATION, SILENT COMMUNICATION and FULL COMMUINCATION.

Figure 1:  Modes of vehicle architecture

Basic In-Vehicle network as follows. it contains CGM ECU communicated with different ECU using different protocols hence we can observe different modes in the vehicle operation depends on the architecture.

Figure 2: In-Vehicle network Architecture.

================================================================================================================================================================================================================

Terms used in the Mode Management

• Modes
• Mode Request
• Mode Switch
• Mode user
• Mode Manager
• Mode Declaration.
• Mode Declaration Group
• Mode switch ports
• ModeSwitchAckEvent

Below picture illustrates terms used in Mode Management.

Figure 3: Basic Mode Manager

In Mode Management, Main concept belongs to three parties such as Mode Manager, Mode user and Mode Requester

Figure 4: Basic Communication Diagram

• The Mode Manager collects requests from Mode Requesters, arbitrates them and switches the mode of its Mode Declaration Group(s) accordingly. 
• A Mode Manager is a role that can be taken by either a BSW module or SWC
• If BSW is Mode Manager then called BSW Mode Manager: BSW module that collects mode requests via a standardized interface and controls functionality. Examples of Mode Managers are: BswM, EcuM, ComM or WdgM
• If SWC is Mode Manager then called Application mode Manager or Vehicle Mode Manager: it collects the Mode requests via application-specific interfaces from other SWCs and process the mode requests. A Vehicle Mode Manager is a special kind of Application Mode Manager that switches Vehicle Modes.
• Mode user: A Mode User is an entity that reacts on mode changes. If a Mode user wants to change into a different mode it can request a Mode switch from the corresponding Mode manager.
• Mode requester: it provides the necessary input conditions to the Mode Manager in order to trigger mode changes.

================================================================================================================================================================================================================

Mode Declaration and Mode Declaration Group

Below example illustrates the BSW Mode Manager: In the EcuM spec mentioned following Modes and its controlled by BswM.

   Figure 5: EcuM Modes used by SWC and controlled by BswM.

Step1: Create Mode declaration group with above mention EcuM Modes in the Mode Declaration groups.

ModeDeclarationGroup for ECU state management as follows: During Mode transition default value is mentioned is called "On Transition value". 

modeGroup ECUOperatingMode_Mode 

{

    ECUM_STATE_APP_SHUTDOWN,         

    ECUM_STATE_APP_SLEEP,

    ECUM_STATE_APP_STARTUP,

    ECUM_STATE_APP_RUN,

    ECUM_STATE_APP_POSTRUN

}

interface modeSwitch MSIF_EcuMode {

mode ECUOperatingMode_Mode  ecuMode

}

• Note: This declaration like a "enum" in c language so be careful about the initial value. tick the first element during declaration.  Mode Declaration has two category
• ALPHABETIC_ORDER: values of "onTransitionValue" and value are automatically defined by RTE.  RTE is assign the values like #define  ECUM_STATE_APP_SHUTDOWN  0  #define  ECUM_STATE_APP_SLEEP  1
• EXPLICIT_ORDER: values of "onTransitionValue" and value are automatically defined by USER. user can assign any values to the modes like #define  ECUM_STATE_APP_SHUTDOWN  4  #define  ECUM_STATE_APP_SLEEP  7

Step2: Create Mode port interface by using "Mode Declaration group". Define Mode Port Interface either service or Application by using "IsServiceInterface" category

Step3: Create your Mode Ports in the SWC - Mode Provider port or Mode Receiver Port according to the role of the SWC (SWC Role May be Manager, requester or user).

Step4: Provider Mode Port can be Enable for "Mode Switch Ack" in the SenderComSpec.

Step5:  We have possible  Mode triggers such as "On Mode Entry", "On Mode Transition" and "On Mode Exit" which used for Runnable trigger. if we Enable "Mode Switch Ack" then able to provide "On Mode Switch Ack" Trigger for the Runnables.

Step6: We have possible access points for mode ports. Provider Port having "Read Sent Mode", Receiver Port having "Read Receive Mode". if we Enable "Mode Switch Ack" then able to provide "send mode switches" access. 

Basic Requirement as follows:

 

[SWS_EcuM_04116] When the BswM sets a state of the EcuM by EcuM_SetState(), the EcuM shall indicate the corresponding mode to the RTE

[SWS_EcuM_04117] ECU State Manager module shall request the state POST_RUN from the BswM, using the API BswM_EcuM_RequestedState(POST_RUN, ECUM_RUNSTATUS_RELEASED).⌋

If a SW-C needs post run activity during POST_RUN (e.g. shutdown preparation), then it must request POST_RUN before releasing the RUN request.

Conclusion: BswM and EcuM used standard interface for Mode request  and SWC also using BSW Interface for the mode communication.

 BswM: Mode Manager

EcuM: Mode : Mode Requester

SWC: Mode User

================================================================================================================================================================================================================

Use Case 1: Mode user is  SWC and Mode manager is BSW

In this example the Mode Manager is BswM hence interface is AUTOSAR Standard Interface (isService==True). In the SWC will create Receive port. Runnables are triggered by either "swcModeSwitchEvent" or following events "on Entry", "On transition" and "On Exit".

Use Case 2: Mode Requester is  SWC and Mode manager is BSW

In this example Mode requester is SWC hence it creates the provider Port because Mode requester should provide necessary input to the Mode manager in order to trigger mode changes. the mode request is a normal send-receive communication hence SWC creates the P_Port  connected to receive port of BswM. BswM  receives the request and process the Request as per condition and provide the mode switch notifications to the Mode user via Mode switch PPort. In this example using AUTOSAR standard interface are used for mode request and mode switch.

Use Case 3: SWC is Mode Requester, Mode User and Mode manager

In this example SWC1 is Mode requester, SWC2 is Mode Manager and SWC3 is Mode user. Application is implemented mode management functionality so mode interfaces are declared as application specific hence there is no standard interfaces are defined. Mode Control functionality is managed by Runnables in the SWC2.  In this example user should have predefined user modes,  transition states and transition conditions. for switching to the next mode the Mode Manager used the generated API Rte_Switch, for reading the currently active mode the RTE provides the API Rte_Mode.

Use Case 4: Mode management of Multi core or Multi-Partition.

Figure: Multi-core system

In the Multi core or Multi partition system uses "serviceproxySwComponent". Other concepts such as mode user, Mode manager and Mode requester local to the ECU.  Refer Guide to Mode Management spec: 2.5.5 Mode communication on multi core ECUs.  

Refer RTE Spec: For the distributed mode management mode requests can be distributed via ServiceProxySwComponentTypes and the BswM of each target ECU to the mode users of the BswMs

================================================================================================================================================================================================================

Mode Switch Procedure

Refer the RTE spec for the Mode switch procedure section : Mode switch acknowledgment.

switching of modes can be performed synchronously or asynchronously depends on the receive a notification from the RTE that the mode transition has been completed..

RTE Requirement

[SWS_Rte_07531] The mode user can specify in the ModeSwitchReceiverComSpec (software components) or BswModeReceiverPolicy (BSW modules) that it is able to deal with asynchronous

mode switch behavior (supportsAsynchronousModeSwitch == TRUE). If all mode users connected to the same ModeDeclarationGroupPrototype of the mode manager support the asynchronous mode switch behavior, the related mode machine instance can be implemented with the asynchronous mode switching procedure. Otherwise, the synchronous mode switching procedure has to be applied.

• For asynchronous mode switching  the Mode manager does not implement any waiting condition or feedback mechanisms. Modes are switched independent of Mode user. Refer: [SWS_Rte_02630]
• For synchronous mode switching the Mode Manager has to use acknowledgement feedback for the mode switch notification. Refer: [SWS_Rte_02669]
• Mode manager used following RTE calls Rte_Switch, Rte_Mode, Rte_SwitchAck
• Rte_Mode : Provides the currently active mode of a mode switch port.

Mode switching also used queued communication: (Refer Specification of RTE Software: section Queueing for ‘event’ Reception)

• Mode switch notifications are configured as queued and are handled similarly to queued sender-receiver communication.
• [SWS_Rte_02523] If a new event is received when the queue is already filled, the RTE shall discard the received event and set an error flag.
• [SWS_Rte_02526] The RTE generator shall reject a queueLength attribute of an QueuedReceiverComSpec with a queue length <=0
• [SWS_Rte_02718] The RTE shall implement a receive queue for the mode switch notifications of each mode machine instance.

================================================================================================================================================================================================================

Initial Mode

For each ModeDeclarationGroup an InitialMode has to be defined. this is simple topic during our mode declaration we need to specify which is your InitialMode. system will be in initial mode until request for mode change. Note: explicitly user can specify or tool will take first mode entry as Initial mode.

================================================================================================================================================================================================================

Thanks for visiting the Post..!! 

================================================================================================================================================================================================================