BSWM Overview
The Basic Software Mode Manager implements mode management for your Autosar application based on requests, rules and actions. Learn about the BswM here
The BswM (Basic Software Mode Manager) implements the mode management for your Autosar application. It works by processing mode requests from the BSW modules and the application layers, according to created rules, and performing a set of actions after processing the rules. If ECU modes are new to you, make sure you read our article Mode Management (opens in a new tab).
The BSW Mode Manager is a unique BSW module, where the mode management, its core functionality, is almost completely molded by its configuration. It sort-of acts as a framework, where we create rules for it to execute a set of actions, when these are applied. This freedom also reflects on the way the BswM is generated, as it can be generated based on configuration or intreperter-based, kind of like its own little language. So, the Autosar tooling providers have some degree of flexibility on how they want to implement it.
The BswM functionality is split into two different tasks:
-
Mode Arbitration - Receiving mode indications from Software Components or BSW modules, it evaluates if a mode switch can be performed after rules arbitration, iniciating the mode switches after the arbitration, depending on the rules feedback. These rules are based on booolean expressions and therefore simple, so that they have a low runtime impact. To know which action lists need to be executed, the results from previous rule evaluation are stored internally in the module.
-
Mode Control - Performs the mode switches by executing a set of actions, called action lists, which contain mode switching operations of other BSW modules, which we'll see later
Rules
A rule is defined as a logical expression (AND, OR, XOR, NOT or NAND) where its inputs are mode request conditions. They are evaluated when there is a change in the mode request condition or in the BswM main function. The result is a boolean true or false, which is used to decide the action list to execute.
There are two types of mode request coditions:
-
BswMModeRequestPort - In this case, the mode condition will verify if the current mode is EQUAL or NOT_EQUAL to the requested mode
-
BswMEventRequestPort - The condition will verify if the request port is SET or CLEAR. It works in a different way as the former, in the sense that the port is set when the requester calls / sends the request, putting it in the SET state. The value goes to CLEARED when executing a BswMClearEventRequest action
Action Lists
An action list is an ordered set of actions that are to be executed upon the results of mode arbitration. There are three types of actions, within the action lists:
-
Calls to other BSW modules of the RTE
-
Links to other action lists to be executed, cascading action lists and reducing redundancy
-
Mode arbitration rules, to be evaluated when the action list is executed. This creates a hierarchy of rules, as some rules will only be evaluated when others pass
The BswM does not need to store or react to the return values of module-specific actions from other BSW modules (but the BswM can return a Det error in case of an error return value). As such, the BSW modules always indicate as an input the current mode, to be used in mode arbitration.
There are two types of action lists:
-
Triggered - The action list is executed once, when the evaluation value changes from false to true, and vice-versa
-
Conditional - The action list is executed every time it's evaluated to the expected value
Mode Processing Procedure
There are at least 3 steps as part of the mode processing cycle:
-
A mode is requested from a Software Component (through the RTE) or a BSW module, arriving at the BswM
-
The rule arbitration process evaluates the rules, either upon reception of the mode request or during the execution of the BswM main function
-
According to the result of mode arbitration, the action list is executed
-
While executing the action lists, the BswM can inform other components of the mode switch that took place in the rule arbitration process, through the RTE Switch API. This is of particular importance for the component that requested the mode switch, in order to receive feedback and act upon it
BswM mode processing procedure example, as per Autosar Specification
For today, we will stop here. In this article, we managed to provide you with a good overview on how the BswM works, its purpose in the Autosar layered architecture and how it interacts with other modules. In the upcoming articles, we'll look at the ports and interfaces involving the BswM, the available actions you can use, how to write rules and the API specification for it. So, expect a few more articles regarding the BswM!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn