BSW Mode Manager (BswM)

Modul	BswM (BSW Mode Manager)
BSW-Modul-ID	`42`
Standard-Header	`#include "BswM.h"`
SWS-Spezifikation	AUTOSAR_SWS_BSWModeManager.pdf
Cluster	System Services

Module guideAI-GENERATED

Arbitrates mode requests and mode indications via rules and uses them to trigger actions in the Basic Software.

AI-GENERATED unreviewed Model: claude-opus-5-5 · Effort: high · Temperature: not controllable · Prompt: e6ee839f49b5 Provenance Open questions (4)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Arbitrates mode requests and mode indications via rules and uses them to trigger actions in the Basic Software.

The BSW Mode Manager accepts mode indications from BSW modules and mode requests from SWCs. It arbitrates them via configured rules whose outcome triggers true or false action lists [SWS_BswM_00035]. After BswM_Init, it thus controls the further initialization of the Basic Software, ECU mode handling with the EcuM, and communication release, such as for I-PDU groups or Ethernet port groups. Rules with BSWM_DEFERRED inputs are evaluated cyclically by BswM_MainFunction, and all others immediately [SWS_BswM_00075]. Invalid requests or requests arriving before initialization are ignored and reported if DET is active.

The BSW Mode Manager (BswM) is the central arbitration instance of the Basic Software. It accepts mode indications from BSW modules such as EcuM, ComM, the bus state managers, NvM, DCM, or Sd, as well as mode requests from SWCs. Based on these, it uses configured rules to decide what should occur [SWS_BswM_00035], SWS BswM p. 26. Inputs arrive as C APIs, SWC ports, or events. Each C API is assigned to a specific request port via reference parameters SWS BswM p. 87.

Context diagram: Numerous reporters feed the BswM; it acts via actions on Com, EthIf, EcuM, RTE, and callouts. Sources: [SWS_BswM_00035], [SWS_BswM_00008], Mode-Mgmt-Guide p. 18

A rule is a logical expression over the current port values. Depending on the result, it executes the true action list or the false action list. Action lists contain actions, nested lists, or further rules Mode-Mgmt-Guide p. 32. In the case of BSWM_IMMEDIATE, a rule is evaluated immediately. In the case of BSWM_DEFERRED, this takes place in BswM_MainFunction [SWS_BswM_00075]. Rules with conditions that are still undefined are not arbitrated SWS BswM p. 30.

Activity diagram: A request is verified, stored, and evaluated against the rules either immediately or cyclically depending on the processing type. Sources: [SWS_BswM_00075], SWS BswM p. 30

The EcuM calls BswM_Init [SWS_BswM_00002] in the StartPostOS sequence SWS EcuM p. 42. Thereafter, the BswM uses rules to control further initialization up to the start of the RTE, in the example with NvM_ReadAll and BswM_NvM_CurrentJobMode [SWS_BswM_00152], Mode-Mgmt-Guide p. 36. In ECU mode handling, the BswM alone decides on the transitions of the EcuM SWS EcuM p. 99. Since R20-11, it additionally switches Ethernet port groups based on PNC states Mode-Mgmt-Guide p. 49. After BswM_Deinit, no further mode processing takes place [SWS_BswM_00120].

If DET is active, the input APIs ignore calls prior to initialization and report BSWM_E_UNINIT [SWS_BswM_00080]. They treat values outside the permitted range in the same way and report BSWM_E_REQ_MODE_OUT_OF_RANGE [SWS_BswM_00095]. If an action fails, the BswM reports the configurable runtime error BSWM_E_ACTION_FAILED [SWS_BswM_00238].

Role of the BswM: Central Mode Arbitration of the Basic Software

The BSW Mode Manager (BswM) accepts mode requests and mode indications. Based on these, it arbitrates via configured rules which actions are to be executed [SWS_BswM_00035], SWS BswM p. 26. Mode requests typically originate from application SWCs, but can also come from BSW modules such as the DCM. Mode indications are always delivered by other BSW modules, such as the bus-specific state managers and the EcuM. The BswM treats both types equally and groups them under the term “mode arbitration request” SWS BswM p. 26.

The BswM is modeled as a service component that serves ECU-local mode requests SWS BswM p. 48. It has no mandatory interfaces to other modules [SWS_BswM_00007]. Its actions call functions of other BSW modules. For this purpose, the specification lists optional interfaces, such as Com_IpduGroupStart, Com_IpduGroupStop, or the control of reception deadline monitoring for I-PDU groups [SWS_BswM_00008], SWS BswM p. 93. The system boundary is thus clearly drawn: The reporting modules only report their state. The reaction to it is determined solely by the configured logic in the BswM Mode-Mgmt-Guide p. 32.

Context diagram: Numerous BSW modules and SWCs report to the BswM; it acts back via actions on Com, EthIf, EcuM, RTE, and user callouts. Sources: [SWS_BswM_00035], [SWS_BswM_00008], [SWS_BswM_00202], [SWS_BswM_00270], Mode-Mgmt-Guide p. 18, SWS EcuM p. 99

Inputs: Mode Indications via C APIs, Ports, and Events

The container BswMModeRequestSource defines how an input arrives. There are three types Mode-Mgmt-Guide p. 18:

a C API called directly by a BSW module, which the BswM internally translates into a mode request,
an RPort with SenderReceiverInterface (BswMSwcModeRequest),
an RPort with ModeSwitchInterface (BswMSwcModeNotification).

For the port types, the BswM generates ports according to fixed naming patterns [SWS_BswM_00201], [SWS_BswM_00200]. The C APIs in R20-11 can be grouped according to origin:

ECU State and Wakeup: BswM_EcuM_CurrentState [SWS_BswM_91003], BswM_EcuM_RequestedState [SWS_BswM_91004], BswM_EcuM_CurrentWakeup [SWS_BswM_00131].
Communication: BswM_ComM_CurrentMode [SWS_BswM_00047], BswM_ComM_CurrentPNCMode [SWS_BswM_00148], BswM_ComM_InitiateReset [SWS_BswM_00217].
Bus State Managers and LinTp: CanSM [SWS_BswM_00049], EthSM [SWS_BswM_00050], FrSM [SWS_BswM_00051], LinSM [SWS_BswM_00052] including schedule indication [SWS_BswM_00058], and BswM_LinTp_RequestMode [SWS_BswM_00156].
Network Management and Ethernet: BswM_Nm_StateChangeNotification [SWS_BswM_91002], BswM_Nm_CarWakeUpIndication [SWS_BswM_00235], BswM_J1939Nm_StateChangeNotification [SWS_BswM_00194], BswM_EthIf_PortGroupLinkStateChg [SWS_BswM_91001].
Diagnostics: BswM_Dcm_CommunicationMode_CurrentState [SWS_BswM_00048], BswM_Dcm_ApplicationUpdated [SWS_BswM_00158], BswM_J1939DcmBroadcastStatus [SWS_BswM_00165].
Memory: BswM_NvM_CurrentBlockMode [SWS_BswM_00104], BswM_NvM_CurrentJobMode [SWS_BswM_00152].
Service Discovery: BswM_Sd_* [SWS_BswM_00204], [SWS_BswM_00207], [SWS_BswM_00210].
Partitions: BswM_WdgM_RequestPartitionReset [SWS_BswM_00157], BswM_BswMPartitionRestarted [SWS_BswM_00193].
Generic: BswM_RequestMode [SWS_BswM_00046] is intended only for BSW modules without an own interface. It works with BswM_UserType [SWS_BswM_00216] and BswM_ModeType [SWS_BswM_00214], both derived from uint16.

Each API is assigned to exactly one request port type. Parameters such as Network are assigned to a concrete port via reference parameters like BswMCanSMChannelRef or BswMComMChannelRef SWS BswM p. 87. Therefore, for example, one BswMCanSMIndication is created per CAN channel Mode-Mgmt-Guide p. 24. All notification APIs are synchronous. With the exception of BswM_ComM_InitiateReset, which is non-reentrant, they are reentrant [SWS_BswM_00217], [SWS_BswM_00049].

In addition to the stateful mode request ports, there are event request ports. BSW modules send events via them, for example via BswM_ComM_InitiateReset() SWS BswM p. 102. The BswM arbitrates both on such events and on their clearing SWS BswM p. 26. According to the change history, R20-11 introduced the following innovations SWS BswM p. 2:

Resumption of BswM_EcuM_CurrentState and BswM_EcuM_RequestedState,
new notification BswMNmStateChangeNotification,
support for Ethernet port group switching.

BswM_WdgM_RequestPartitionReset becomes obsolete only in R21-11 SWS BswM p. 2.

Rules and Action Lists: From Input to Action

The behavior of the BswM is configured via rules and action lists. A rule is a logical expression over the current values of the mode request ports. Depending on the result, its evaluation executes the True or the False action list Mode-Mgmt-Guide p. 32. An action list can contain SWS BswM p. 31:

atomic actions,
nested action lists,
references to rules, which are then evaluated in the context of this list.

Actions may only be invoked in the context of an action list [SWS_BswM_00147]. A diagram in the specification shows an example rule. It combines via AND a mode condition (MyModeRequestPort equal to MODE_A) with the event port ComMInitiateReset SWS BswM p. 25.

When a rule is evaluated is determined by BswMRequestProcessing for each port:

BSWM_IMMEDIATE: Every rule that references the port is processed immediately Mode-Mgmt-Guide p. 32. For SW-C ports, the BswM registers a runnable for this, which the RTE starts upon data reception SWS BswM p. 48.
BSWM_DEFERRED: The BswM reads the value cyclically. BswM_MainFunction [SWS_BswM_00053] evaluates all rules that use at least one such input [SWS_BswM_00075].

Activity diagram: An incoming request is checked, stored, and, depending on the processing type, evaluated against the rules immediately or in the MainFunction; rules with undefined conditions remain unconsidered. Sources: [SWS_BswM_00075], [SWS_BswM_00080], [SWS_BswM_00095], SWS BswM p. 30, Mode-Mgmt-Guide p. 32

Via BswMModeInitValue, a port receives an initial value during initialization. If it is missing, the condition is considered undefined until the first update. Rules with undefined conditions are not arbitrated SWS BswM p. 30. The examples in the guide therefore set initial values, such as CANSM_BSWM_NO_COMMUNICATION for CanSM indications Mode-Mgmt-Guide p. 24.

For wait times, the BswM provides timers. A BswMTimer is an internal Mode Request Source and can only be controlled via the action BswMTimerControl; an external interface does not exist SWS BswM p. 37. Its sequence SWS BswM p. 37:

During initialization, all timers are stopped.
BSWM_TIMER_START loads the timer with BswMTimerValue and sets BSWM_TIMER_STARTED.
In each run of BswM_MainFunction, it is decremented by its cycle time.

Regardless of their configuration, timers are always processed DEFERRED [SWS_BswM_00220]. The value BSWM_TIMER_EXPIRED is likely to indicate the expired countdown. Question Q-eba03b0a23a3c291 (open) This is an interpretation, because the section is truncated in the payload SWS BswM p. 37.

State diagram: Life cycle of a BswMTimer from STOPPED through STARTED to EXPIRED, controlled exclusively by actions and the MainFunction. Sources: [SWS_BswM_00220], SWS BswM p. 37

In addition to the functions from the list of optional interfaces [SWS_BswM_00008], specific actions exist. Thus, when executed, BswMEthIfStartAllPorts calls EthIf_StartAllPorts [SWS_BswM_00286]. Freely defined functions are configured as BswMUserCallout. In doing so, name and parameters are defined at ECU configuration time [SWS_BswM_00054], [SWS_BswM_00270].

Startup, Initialization Chains, and Shutdown

BswM_Init [SWS_BswM_00002] receives a pointer to the post-build configuration BswM_ConfigType [SWS_BswM_00213]. The function initializes all global variables. Afterwards, the BswM is ready to arbitrate requests. Only OS and SchM are required SWS BswM p. 69. The EcuM calls BswM_Init in the StartPostOS sequence after SchM_Start(); this is followed by SchM_Init and SchM_StartTiming SWS EcuM p. 42. On multi-core systems, the call occurs in a loop over each BswM instance of the core SWS EcuM p. 81. For such multiple instances in multiple partitions or cores, BswM_Init is conditionally reentrant SWS BswM p. 69.

Sequence diagram: StartPostOS sequence with initialization of each BswM instance between SchM_Start and SchM_Init; after that, the MainFunction runs cyclically. Sources: [SWS_BswM_00002], SWS EcuM p. 42, SWS EcuM p. 78, SWS BswM p. 37

From here on, the BswM takes over control of the sequence. It ensures that the remaining init routines of the basic software are called and the RTE is started Mode-Mgmt-Guide p. 36. The modules to be initialized by it are described by the EcuM container EcuMDriverInitListBswM SWS EcuM p. 224. In the example of the guide, the initialization proceeds as follows Mode-Mgmt-Guide p. 36, NV-Data-Guide p. 20:

A DEFERRED rule initializes the NVRAM drivers and triggers NvM_ReadAll.
The NvM reports the end of the job via BswM_NvM_CurrentJobMode [SWS_BswM_00152].
This notification triggers the remaining initialization and the transition to ECU_RUN.

The guide still shows a uint8 parameter for this API ServiceId Mode-Mgmt-Guide p. 26. However, the signature with NvM_MultiBlockRequestType [SWS_BswM_00152] is authoritative for R20-11.

Sequence diagram: Rule-controlled second initialization phase with NvM_ReadAll, feedback from the NvM, and subsequent RTE start. Sources: [SWS_BswM_00152], [SWS_BswM_00075], Mode-Mgmt-Guide p. 36, NV-Data-Guide p. 20

During shutdown, according to the NV guide, the BswM is responsible for writing modified blocks, in the example via NvM_WriteAll NV-Data-Guide p. 41. The NvM also reports the cancellation of a WriteAll to it via the job mode indication SWS NvM p. 155. In the OffPreOS sequence, the EcuM deinitializes the BswM as the first step SWS EcuM p. 50. After BswM_Deinit [SWS_BswM_00119], no further mode processing takes place, even if requests arrive or the MainFunction is called [SWS_BswM_00120].

Interaction with EcuM: ECU Mode Handling and Wakeup Sources

During ECU Mode Handling, the EcuM arbitrates the RUN and POST_RUN requests of the SW-Cs. It does not possess its own state machine; only the BswM decides when a transition occurs SWS EcuM p. 99. The sequence Mode-Mgmt-Guide p. 34:

The EcuM reports the result of the RUN Request Protocol via BswM_EcuM_RequestedState [SWS_BswM_91004].
The BswM sets the state via EcuM_SetState.
The EcuM reports the corresponding mode to the RTE.
After feedback from the RTE, the EcuM calls BswM_EcuM_CurrentState [SWS_BswM_91003].

The states are ECUM_STATE_STARTUP, ECUM_STATE_APP_RUN, ECUM_STATE_APP_POST_RUN, ECUM_STATE_SHUTDOWN, and ECUM_STATE_SLEEP Mode-Mgmt-Guide p. 34. This coupling allows SW-Cs designed for the EcuM with a fixed state machine to be reused. A compatibility SW-C is not required for this Mode-Mgmt-Guide p. 61.

Sequence diagram: The EcuM arbitrates RUN requests, the BswM decides on the transition, the RTE is informed, and the confirmation returns to the BswM as CurrentState. Sources: [SWS_BswM_91004], [SWS_BswM_91003], SWS EcuM p. 99, Mode-Mgmt-Guide p. 34, Mode-Mgmt-Guide p. 61

The EcuM reports state changes of wakeup sources via BswM_EcuM_CurrentWakeup [SWS_BswM_00131]. In the state machine of the wakeup sources, each of the states NONE, PENDING, VALIDATED, and EXPIRED calls this API upon entry SWS EcuM p. 60. In detail:

If the EcuM validates an event, it reports VALIDATED SWS EcuM p. 134.
If the validation remains unsuccessful until the timeout, it reports EXPIRED SWS EcuM p. 63.
In the GoSleep sequence, it resets the sources with ECUM_WKSTATUS_NONE SWS EcuM p. 54.
In the Poll sequence, it reports PENDING or VALIDATED, depending on the validation need SWS EcuM p. 57.

One BswMEcuMWakeupSource is created per wakeup source Mode-Mgmt-Guide p. 29.

State diagram: States of a wakeup source in the EcuM; each entry generates a notification to the BswM. Sources: [SWS_BswM_00131], SWS EcuM p. 60, SWS EcuM p. 57, SWS EcuM p. 63

Communication Control: Buses, Partial Networks, Diagnostics, and Services

A typical use case is the release of I-PDU groups. In the guide, a rule based on a CanSM indication activates the I-PDU groups of a CAN channel Mode-Mgmt-Guide p. 32. The CanSM reports the states CANSM_BSWM_NO_COMMUNICATION, CANSM_BSWM_SILENT_COMMUNICATION, CANSM_BSWM_FULL_COMMUNICATION, and CANSM_BSWM_BUS_OFF for this [SWS_BswM_00049], Mode-Mgmt-Guide p. 22. It reports the state FULL_COMMUNICATION, for example, upon the effect E_TX_ON SWS CanSM p. 65.

For partial networks, ComM reports every state change of a PNC via BswM_ComM_CurrentPNCMode [SWS_BswM_00148], SWS ComM p. 35. With this, the BswM switches Ethernet switch port groups Mode-Mgmt-Guide p. 49:

It knows the mapping of PNC to EthIfSwitchPortGroup.
It calls EthIf_SwitchPortGroupRequestMode with ETH_MODE_ACTIVE or ETH_MODE_DOWN.
EthIf reports the resulting link state of the group back via BswM_EthIf_PortGroupLinkStateChg [SWS_BswM_91001], SWS EthIf p. 92.

Sequence diagram: PNC request and release switch an Ethernet port group via BswM rules; EthIf reports the determined link state back to BswM. Sources: [SWS_BswM_00148], [SWS_BswM_91001], Mode-Mgmt-Guide p. 49, SWS EthIf p. 92

Diagnostics also reports to the BswM:

UDS Service 0x28 (CommunicationControl): The DCM calls BswM_Dcm_CommunicationMode_CurrentState for each affected network [SWS_BswM_00048], SWS DCM p. 147. The behavior is configured via BswMDcmComModeRequest; its BswMDcmComMChannelRef corresponds to the argument Network SWS BswM p. 64.
Bootloader jump: If the application was updated in the process, the DCM reports BswM_Dcm_ApplicationUpdated [SWS_BswM_00158], SWS DCM p. 231.
J1939: BswM_J1939DcmBroadcastStatus passes a bitmask per ComMChannelId that covers only the first 16 channels [SWS_BswM_00165], SWS BswM p. 70. Depending on the J1939Nm states, the BswM switches Com I-PDU groups, PduR routing path groups, and the request handling of the J1939Rm Mode-Mgmt-Guide p. 45.

Service Discovery reports the states of Client Services, Consumed Eventgroups, and Event Handlers [SWS_BswM_00204], [SWS_BswM_00207], [SWS_BswM_00210]. For the Sd, these calls are optional interfaces SWS Sd p. 122.

Behavior in the event of an error

If BswMDevErrorDetect is active, the input APIs first check whether the BswM is initialized. Otherwise, they ignore the request and report BSWM_E_UNINIT to the DET, such as [SWS_BswM_00080], [SWS_BswM_00081], [SWS_BswM_00149], [SWS_BswM_00112], [SWS_BswM_00086], [SWS_BswM_00132]. In addition, they check the passed values for the permitted range. In case of a violation, the request is likewise ignored and BSWM_E_REQ_MODE_OUT_OF_RANGE is reported, such as [SWS_BswM_00095], [SWS_BswM_00097], [SWS_BswM_00150], [SWS_BswM_00113], [SWS_BswM_00110], [SWS_BswM_00154]. If BswM_MainFunction is called before initialization, it returns immediately without reporting an error [SWS_BswM_00076].

The development error codes of the BswM according to [SWS_BswM_00230]:

Mistake	Code	Value
Call before initialization	`BSWM_E_UNINIT`	0x01
Null pointer passed	`BSWM_E_NULL_POINTER`	0x02
Parameter invalid (unspecific)	`BSWM_E_PARAM_INVALID`	0x03
Requesting user out of range	`BSWM_E_REQ_USER_OUT_OF_RANGE`	0x04
Requested mode out of range	`BSWM_E_REQ_MODE_OUT_OF_RANGE`	0x05
Configuration inconsistent	`BSWM_E_PARAM_CONFIG`	0x06

If an action returns E_NOT_OK, the BswM reports the runtime error BSWM_E_ACTION_FAILED. The value is between 0x80 and 0xFF and is configured in BswMReportFailRuntimeErrorId [SWS_BswM_00238]. The BswM rejects configurations that contain both BswMBswModeInitValue and BswMCompuScaleModeValue for a BswMModeInitValue SWS BswM p. 30. The code BSWM_E_REQ_USER_OUT_OF_RANGE is likely intended to check requesting_user in BswM_RequestMode. Question Q-60c14136e0238954 (open) This is an interpretation, because the corresponding passage is truncated in the payload [SWS_BswM_00230], SWS BswM p. 86.

Errors of other modules reach the BswM as normal inputs:

Bus-off: The CanSM first reports CANSM_BSWM_BUS_OFF to the BswM and then COMM_SILENT_COMMUNICATION to ComM. In addition, it sets a DEM event to PRE_FAILED SWS CanSM p. 70, Error-Description p. 19.
Partition reset: The WdgM requests it via BswM_WdgM_RequestPartitionReset [SWS_BswM_00157], Mode-Mgmt-Guide p. 30.
Restart of the BswM partition: Afterwards, BswM_BswMPartitionRestarted is called [SWS_BswM_00193]. Rules can then specifically re-initialize the modules of this partition Mode-Mgmt-Guide p. 38.

Further detailed evidence

[SWS_BswM_00035] and SWS BswM p. 26: Basic duty of arbitration via indications, requests, and events.
[SWS_BswM_00075] and SWS BswM p. 91: Evaluation of DEFERRED rules in the MainFunction.
SWS BswM p. 30: Initial values and undefined conditions.
[SWS_BswM_00002], [SWS_BswM_00120]: Life cycle from initialization to deinitialization.
SWS BswM p. 87: Assignment of each C API to request port type and reference parameter.
SWS EcuM p. 99: Division of work between EcuM and BswM during ECU Mode Handling.
Mode-Mgmt-Guide p. 49: Example configuration for the port group switching introduced in R20-11.
[SWS_BswM_00230], [SWS_BswM_00238]: Development and runtime error codes.

AI-generated module guide based on the specification excerpts provided in the payload. Individual document passages originate from other releases; the linked requirements are normative for R20-11. Statements marked as an interpretation are assumptions.

BSW Mode Manager (BswM)

Arbitrates mode requests and executes action lists to control system state transitions.

Funktionen — Übersicht

void BswM_BswMPartitionRestarted (void); Function called by Restart Task if the partition containing the Bsw M has been restarted.
void BswM_CanSM_CurrentState (NetworkHandleType Network, CanSM_BswMCurrentStateType CurrentState); Function called by Can SM to indicate its current state.
void BswM_ComM_CurrentMode (NetworkHandleType Network, ComM_ModeType RequestedMode); Function called by Com M to indicate the current communication mode of a Com M channel.
void BswM_ComM_CurrentPNCMode (PNCHandleType PNC, ComM_PncModeType CurrentPncMode); Function is called by Com M to indicate the current mode of the PNC.
void BswM_ComM_InitiateReset (void); Function is called by Com M to signal a shutdown.
void BswM_Dcm_ApplicationUpdated (void); This function is called by the DCM in order to report an updated application.
void BswM_Dcm_CommunicationMode_CurrentState (NetworkHandleType Network, Dcm_CommunicationModeType RequestedMode); Function called by DCM to inform the Bsw M about the current state of the communication mode.
void BswM_Deinit (void); Deinitializes the BSW Mode Manager.
void BswM_EcuM_CurrentState (EcuM_StateType CurrentState); Function called Ecu M to indicate the current ECU Operation Mode.
void BswM_EcuM_CurrentWakeup (EcuM_WakeupSourceType source, EcuM_WakeupStatusType state); Function called by Ecu M to indicate the current state of a wakeup source.
void BswM_EcuM_RequestedState (EcuM_StateType State, EcuM_RunStatusType CurrentState); Function called by Ecu M notify about current Status of the Run Request Protocol.
void BswM_EthIf_PortGroupLinkStateChg (EthIf_SwitchPortGroupIdxType PortGroupIdx, EthTrcv_LinkStateType PortGroupState); Function called by Eth If to indicate the link state change of a certain Ethernet switch port group.
void BswM_EthSM_CurrentState (NetworkHandleType Network, EthSM_NetworkModeStateType CurrentState); Function called by Eth SM to indicate its current state.
void BswM_FrSM_CurrentState (NetworkHandleType Network, FrSM_BswM_StateType CurrentState); Function called by Fr SM to indicate its current state.
void BswM_GetVersionInfo (Std_VersionInfoType* VersionInfo); Returns the version information of this module.
void BswM_Init (const BswM_ConfigType* ConfigPtr); Initializes the BSW Mode Manager.
void BswM_J1939DcmBroadcastStatus (uint16 NetworkMask); This API tells the Bsw M the desired communication status of the available networks.
void BswM_J1939Nm_StateChangeNotification (NetworkHandleType Network, uint8 Node, Nm_StateType NmState); Notification of current J1939Nm state after state changes.
void BswM_LinSM_CurrentSchedule (NetworkHandleType Network, LinIf_SchHandleType CurrentSchedule); Function called by Lin SM to indicate the currently active schedule table for a specific LIN channel.
void BswM_LinSM_CurrentState (NetworkHandleType Network, LinSM_ModeType CurrentState); Function called by Lin SM to indicate its current state.
void BswM_LinTp_RequestMode (NetworkHandleType Network, LinTp_Mode LinTpRequestedMode); Function called by Lin TP to request a mode for the corresponding LIN channel.
void BswM_Nm_CarWakeUpIndication (NetworkHandleType Network); Function called by Nm to indicate a Car Wakeup.
void BswM_Nm_StateChangeNotification (NetworkHandleType Network, Nm_StateType currentState); Notification of current Nm state after state changes.
void BswM_NvM_CurrentBlockMode (NvM_BlockIdType Block, NvM_RequestResultType CurrentBlockMode); Function called by Nv M to indicate the current block mode of an Nv M block.
void BswM_NvM_CurrentJobMode (NvM_MultiBlockRequestType MultiBlockRequest, NvM_RequestResultType CurrentJobMode); Function called by Nv M to inform the Bsw M about the current state of a multi block job.
void BswM_RequestMode (BswM_UserType requesting_user, BswM_ModeType requested_mode); Generic function call to request modes.
void BswM_Sd_ClientServiceCurrentState (uint16 SdClientServiceHandleId, Sd_ClientServiceCurrentStateType CurrentClientState); Function called by Service Discovery to indicate current state of the Client Service (available/ down).
void BswM_Sd_ConsumedEventGroupCurrentState (uint16 SdConsumedEventGroupHandleId, Sd_ConsumedEventGroupCurrentStateType ConsumedEventGroupState); Function called by Service Discovery to indicate current status of the Consumed Eventgroup (available/ down).
void BswM_Sd_EventHandlerCurrentState (uint16 SdEventHandlerHandleId, Sd_EventHandlerCurrentStateType EventHandlerStatus); Function called by Service Discovery to indicate current status of the Event Handler (requested/ released).
void BswM_WdgM_RequestPartitionReset (ApplicationType Application); Function called by Wdg M to request a partition reset.
void BswM_MainFunction (void); Main function of the Bsw M
void <BswMUserCalloutFunction> (implementation_specific -); Function called by the Bsw M when a Bsw MUser Callout is executed.

Typen — Übersicht

struct BswM_ConfigType This structure contains all post - build configurable parameters of the BSW Mode
enum BswM_ModeType This type identifies the modes that can be requested by Bsw M Users.
BswM_UserType This type identifies a Bsw M User that makes mode requests to the Bsw M.

Funktionen & Typen — Detailansicht

function BswM_BswMPartitionRestarted [SWS_BswM_00193] 📄 PDF

void BswM_BswMPartitionRestarted (void);

Function called by Restart Task if the partition containing the Bsw M has been restarted.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 789aeb35d50a Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_BswMPartitionRestarted serves to notify the BswM module about the restart of the partition in which the BswM is executed [SWS_BswM_00193].

Usage and Semantics

The call is performed synchronously by the operating system's restart task as soon as the partition has been restored after a restart [SWS_BswM_00193]. The function has service ID 0x1e and is declared via header file BswM.h [SWS_BswM_00193]. It accepts no parameters (neither input nor output parameters) and has no return value (void) [SWS_BswM_00193].

Concurrency and Execution

According to the specification, BswM_BswMPartitionRestarted is classified as reentrant [SWS_BswM_00193]. This enables the call in the context of the restart task, whereby the caller must ensure that the restart of the relevant partition was properly initiated prior to the call.

Error Handling and Interaction

The specification defines no specific return values or DET/DEM error codes for this service [SWS_BswM_00193]. The interaction is limited to the OS restart task triggering this notification so that the BswM can react to the restarted partition [SWS_BswM_00193].

This usage note was generated automatically based on the specification SWS_BswM_00193.

Implementer's Guide to follow (complexity I1)

function BswM_CanSM_CurrentState [SWS_BswM_00049] 📄 PDF

void BswM_CanSM_CurrentState (NetworkHandleType Network, CanSM_BswMCurrentStateType CurrentState);

Function called by Can SM to indicate its current state. Ava ilable via Bsw M_ Can SM.h

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: cfb9d1295953 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and signature

The function BswM_CanSM_CurrentState is called by the CAN State Manager (CanSM) to report the current state of a CAN channel to the BSW Mode Manager (BswM) [SWS_BswM_00049]. It has the service ID 0x05 and is provided via the header file BswM_CanSM.h [SWS_BswM_00049].

The call takes place synchronously and returns no return value (void) [SWS_BswM_00049]. The interface processes two input parameters [SWS_BswM_00049]:

Network (type NetworkHandleType): Denotes the affected CAN channel to which the reported state change relates [SWS_BswM_00049].
CurrentState (type CanSM_BswMCurrentStateType): Passes the newly assumed state of the respective CAN channel [SWS_BswM_00049].

Neither output nor input/output parameters are provided for this service function [SWS_BswM_00049].

Concurrency and Limitations

The specification identifies BswM_CanSM_CurrentState as reentrant [SWS_BswM_00049]. It can therefore be called concurrently in the event of parallel events from multiple network channels. Since the call is synchronous and no specific task restrictions are specified, the call context is likely to correspond to the execution context of the calling CanSM [SWS_BswM_00049]. Question Q-0edc8b6c1cb10f6d (open)

Error Handling and Interaction

No specific error codes, return values, or notifications to DET or DEM are documented in the specification for this function call [SWS_BswM_00049]. The function serves as a defined reporting interface in the interaction between CanSM and BswM, via which the current channel state flows into the mode management of the BswM [SWS_BswM_00049].

This usage note was generated by an AI and is based exclusively on the specified AUTOSAR specifications.

Implementer's Guide to follow (complexity I1)

function BswM_ComM_CurrentMode [SWS_BswM_00047] 📄 PDF

void BswM_ComM_CurrentMode (NetworkHandleType Network, ComM_ModeType RequestedMode);

Function called by Com M to indicate the current communication mode of a Com M channel.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: e558456afa80 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_ComM_CurrentMode serves in the AUTOSAR Classic module BswM (Basic Software Mode Manager) as a standardized notification interface for the Communication Manager (ComM) [SWS_BswM_00047]. It is called by the ComM to indicate the current communication mode of a specific communication channel to the BswM [SWS_BswM_00047]. The declaration of this interface is provided via the header file BswM_ComM.h, and the hexadecimal service ID 0x0e is assigned to the service [SWS_BswM_00047].

The function signature is void BswM_ComM_CurrentMode (NetworkHandleType Network, ComM_ModeType RequestedMode) and requires two immutable input parameters [SWS_BswM_00047]:

Network (data type NetworkHandleType): Denotes the specific ComM communication channel for which the status is indicated and to which the state corresponds [SWS_BswM_00047].
RequestedMode (data type ComM_ModeType): Transmits the current state or mode of the specified ComM communication channel to the BswM module [SWS_BswM_00047].

The interface has no return value (void); likewise, neither output parameters (out) nor combined input/output parameters (inout) are defined in the specification [SWS_BswM_00047]. The execution behavior of the function is defined as synchronous (Synchronous) [SWS_BswM_00047]. With respect to concurrency and concurrent call context, BswM_ComM_CurrentMode is classified as reentrant (Reentrant) [SWS_BswM_00047].

Regarding error handling, no specific error codes, return values, or error notifications to DET or DEM are provided for this function in the element specification [SWS_BswM_00047]. Furthermore, no advanced sequencing constraints or dependencies on related requirements are specified [SWS_BswM_00047].

This usage note was generated automatically based on requirement SWS_BswM_00047.

Implementer's Guide to follow (complexity I1)

function BswM_ComM_CurrentPNCMode [SWS_BswM_00148] 📄 PDF

void BswM_ComM_CurrentPNCMode (PNCHandleType PNC, ComM_PncModeType CurrentPncMode);

Function is called by Com M to indicate the current mode of the PNC. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_BSWModeManager

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 7867e89093de Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_ComM_CurrentPNCMode serves as a notification interface between the Communication Manager and the BSW Mode Manager. According to [SWS_BswM_00148], it is called by the ComM to transmit the current mode of a Partial Network Cluster (PNC) to the BswM.

Usage and Call Context

The interface is available via the header file BswM_ComM.h and has the service ID 0x15 ([SWS_BswM_00148]). The call is executed synchronously and returns no return value (void). Only two input parameters are passed:

PNC (type PNCHandleType): The handle of the affected Partial Network Cluster whose state is reported.
CurrentPncMode (type ComM_PncModeType): The currently assumed mode of the specified PNC.

Additional input or output parameters are not provided according to [SWS_BswM_00148].

Concurrency and Limitations

With regard to concurrency, BswM_ComM_CurrentPNCMode is specified as reentrant according to [SWS_BswM_00148], whereby concurrent calls from the ComM are permissible. Specific error codes or mechanisms for error handling via DET or DEM are not defined in the payload. The transmitted states are likely to serve internally in the BswM as triggers for rule evaluations and actions (Interpretation: The payload documents the mode indication, but does not specify any internal BswM actions). Question Q-2527fc2eda881b62 (open)

This usage note is based on the AUTOSAR CP R20-11 specification.

Implementer's Guide to follow (complexity I1)

function BswM_ComM_InitiateReset [SWS_BswM_00217] 📄 PDF

void BswM_ComM_InitiateReset (void);

Function is called by Com M to signal a shutdown.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: ed83eb94f632 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_ComM_InitiateReset is called by the Communication Manager (ComM) to signal an upcoming shutdown to the BswM [SWS_BswM_00217].

Interface and Call Semantics

The interface has the signature void BswM_ComM_InitiateReset(void) and is declared via header file BswM_ComM.h [SWS_BswM_00217]. It processes neither input, output, nor input/output parameters and has no return value [SWS_BswM_00217]. The call is handled synchronously and is specified with service ID 0x22 [SWS_BswM_00217].

Concurrency and Limitations

The function is defined as non-reentrant (Non Reentrant) [SWS_BswM_00217]. The caller must therefore ensure that calls are made sequentially and that no concurrent or overlapping executions take place. Because execution is synchronous, the call blocks the executing context until processing in the BswM is complete.

Error Handling and Interaction

In the specifications, no specific error codes, return values, or error messages to DET or DEM are provided for this service [SWS_BswM_00217]. According to the specification, the interaction is limited to receiving the shutdown signaling from the ComM [SWS_BswM_00217]; Interpretation: The message is likely to serve in the BswM as a trigger for configured actions to perform the shutdown or reset. Question Q-adf160d8d0fe2c97 (open)

This usage note is based on specification SWS_BswM_00217 from AUTOSAR R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_Dcm_ApplicationUpdated [SWS_BswM_00158] 📄 PDF

void BswM_Dcm_ApplicationUpdated (void);

This function is called by the DCM in order to report an updated application.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 5e2894c99c27 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

According to [SWS_BswM_00158], the function BswM_Dcm_ApplicationUpdated is called by the Diagnostic Communication Manager (DCM) to report the successful update of an application to the BswM. The service is declared in header file BswM_Dcm.h and has service ID 0x14. The interface expects no parameters (void) and returns no value to the caller.

Synchronicity and Concurrency

According to [SWS_BswM_00158], the function is specified as synchronous and reentrant. The caller thus remains in the execution context of the DCM until the immediate processing of the call within the BswM is completed. The declared reentrancy property in principle allows the interface to be invoked concurrently from different task contexts.

Error Handling and Interaction

Neither specific error codes nor notifications to the DET or DEM are provided for BswM_Dcm_ApplicationUpdated in [SWS_BswM_00158]. The call serves purely as a status report to the BSW mode management. The notification is likely to serve within the BswM as an indicator and trigger for re-evaluating internal rules as well as downstream mode switches in order to adapt the overall system to the modified application software. Question Q-119282a4a72622b5 (open)

This usage note was generated automatically based on the specification AUTOSAR R20-11.

function BswM_Dcm_CommunicationMode_CurrentState [SWS_BswM_00048] 📄 PDF

void BswM_Dcm_CommunicationMode_CurrentState (NetworkHandleType Network, Dcm_CommunicationModeType RequestedMode);

Function called by DCM to inform the Bsw M about the current state of the communication mode.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 63cbbb29388f Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The function BswM_Dcm_CommunicationMode_CurrentState is called by the Diagnostic Communication Manager (DCM) module to notify the Basic Software Mode Manager (BswM) of the current state of the communication mode [SWS_BswM_00048]. The declaration of this interface is provided via the header file BswM_Dcm.h [SWS_BswM_00048].

The C syntax of the function is void BswM_Dcm_CommunicationMode_CurrentState (NetworkHandleType Network, Dcm_CommunicationModeType RequestedMode) [SWS_BswM_00048]. When called by the DCM, two input parameters are passed [SWS_BswM_00048]:

Network (type NetworkHandleType): Designates the communication channel to which the diagnostic mode refers [SWS_BswM_00048].
RequestedMode (type Dcm_CommunicationModeType): Transmits the requested diagnostic communication mode to the BswM [SWS_BswM_00048].

The interface has no return value (return type void) and uses neither modifying input/output parameters (Inout) nor output parameters (Out) [SWS_BswM_00048].

Concurrency and Properties

The function call is executed synchronously and is specified as reentrant [SWS_BswM_00048]. The service name is defined as BswM_Dcm_CommunicationMode_CurrentState and has the service ID 0x06 in hexadecimal representation [SWS_BswM_00048].

Interaction

Interpretation: The BswM is likely to use the transmitted status of the communication mode as a criterion for evaluating mode rules in order to trigger subsequent actions in the BswM [SWS_BswM_00048]. Question Q-1031b1a7ae000c2a (open)

This usage note was generated automatically.

Implementer's Guide to follow (complexity I1)

function BswM_Deinit [SWS_BswM_00119] 📄 PDF

void BswM_Deinit (void);

Deinitializes the BSW Mode Manager.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 3aaac40d3e61 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Semantics

The function BswM_Deinit serves to de-initialize the BSW Mode Manager ([SWS_BswM_00119]). Execution is synchronous with no passed parameters and no return value, with the service ID 0x04 ([SWS_BswM_00119]). The declaration is available via the header file BswM.h ([SWS_BswM_00119]).

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) ([SWS_BswM_00119]). A concurrent or preemptive call from multiple task contexts is therefore not permitted. Interpretation: De-initialization is typically likely to occur sequentially during the shutdown phase of the ECU by a higher-level state management such as the ECU State Manager. Question Q-0a5d218bfe9fed04 (open)

Interaction and Behavior after De-initialization

After BswM_Deinit is called, the BswM module no longer performs any mode processing ([SWS_BswM_00120]). This prevention continues even if external or internal mode requests are submitted to the module or if the cyclic main function of the BswM continues to be executed or called ([SWS_BswM_00120]).

This text was generated by an AI based on the AUTOSAR specification.

Implementer's Guide to follow (complexity I1)

function BswM_EcuM_CurrentState [SWS_BswM_91003] 📄 PDF

void BswM_EcuM_CurrentState (EcuM_StateType CurrentState);

Function called Ecu M to indicate the current ECU Operation Mode.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: fb0fde71b6ce Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous service function BswM_EcuM_CurrentState is called by the EcuM module to indicate the current ECU operating mode to the BswM [SWS_BswM_91003]. The interface has the service ID 0x28 and is provided via the header file BswM_EcuM.h [SWS_BswM_91003].

use

When the function is called, the requested state of the ECU is communicated synchronously to the BswM [SWS_BswM_91003]. The transfer takes place via a single input parameter:

Current State (in): Passes the requested ECU operating mode using the data type EcuM_StateType [SWS_BswM_91003].

The function defines neither input/output parameters (inout) nor output parameters (out) and has no return value (void) [SWS_BswM_91003].

Concurrency and Limitations

Regarding concurrency behavior, BswM_EcuM_CurrentState is specified as reentrant [SWS_BswM_91003]. Calls can thus take place concurrently without restriction, for example when different execution paths of the caller are active [SWS_BswM_91003].

Specific error codes, notifications to the DET or DEM module, and separate error handling mechanisms are not listed in the specification scope for this service [SWS_BswM_91003].

This usage note was generated automatically based on AUTOSAR R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_EcuM_CurrentWakeup [SWS_BswM_00131] 📄 PDF

void BswM_EcuM_CurrentWakeup (EcuM_WakeupSourceType source, EcuM_WakeupStatusType state);

Function called by Ecu M to indicate the current state of a wakeup source.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 9c2c2f56cbd3 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_EcuM_CurrentWakeup serves as an interface of the BswM called by the EcuM module to report the current state of one or more wakeup sources [SWS_BswM_00131]. The declaration is available via the header file BswM_EcuM.h [SWS_BswM_00131].

When the function is called, the following input parameters are transmitted [SWS_BswM_00131]:

source (type EcuM_WakeupSourceType): Designates the wakeup source or wakeup sources whose state has changed [SWS_BswM_00131].
state (type EcuM_WakeupStatusType): Indicates the new state of the affected wakeup source(s) [SWS_BswM_00131].

The function has no return value (void) and carries no input/output or pure output parameters [SWS_BswM_00131]. The corresponding service ID is 0x10 [SWS_BswM_00131].

Regarding the execution behavior, the function call is specified as synchronous [SWS_BswM_00131]. Furthermore, the function is classified as reentrant, allowing it to be called concurrently from different contexts if required [SWS_BswM_00131].

This text was generated by an AI based on the specification.

Implementer's Guide to follow (complexity I1)

function BswM_EcuM_RequestedState [SWS_BswM_91004] 📄 PDF

void BswM_EcuM_RequestedState (EcuM_StateType State, EcuM_RunStatusType CurrentState);

Function called by Ecu M notify about current Status of the Run Request Protocol.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: d744d4082d78 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Semantics

The function BswM_EcuM_RequestedState serves as a notification interface called by the ECU State Manager (EcuM) to inform the BswM module about the current status of the Run Request Protocol [SWS_BswM_91004]. The call is synchronous and is specified as reentrant, allowing the function to be executed in concurrent contexts [SWS_BswM_91004]. The declaration is provided via the header file BswM_EcuM.h with the service ID 0x29 [SWS_BswM_91004].

Parameters and Return Value

The interface has no return value (return type void) and expects two pure input parameters [SWS_BswM_91004]:

State (type EcuM_StateType): Indicates the state requested by the EcuM [SWS_BswM_91004].
CurrentState (type EcuM_RunStatusType): Transmits the result or the current status of the Run Request Protocol [SWS_BswM_91004].

Input/output parameters or output parameters are not provided for this function [SWS_BswM_91004].

Interaction and integration

The function is called exclusively by EcuM. Interpretation: The passed states are likely to serve in the BswM for internal rule evaluation and mode control in order to trigger higher-level actions of the Basic Software [SWS_BswM_91004]. Question Q-6cd81e44c9e2920a (open) No specific error codes for DET or DEM are defined in the specification for this service [SWS_BswM_91004].

This usage note was generated automatically and is based exclusively on the specification of AUTOSAR Release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_EthIf_PortGroupLinkStateChg [SWS_BswM_91001] 📄 PDF

void BswM_EthIf_PortGroupLinkStateChg (EthIf_SwitchPortGroupIdxType PortGroupIdx, EthTrcv_LinkStateType PortGroupState);

Function called by Eth If to indicate the link state change of a certain Ethernet switch port group.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 37554116ef85 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

According to [SWS_BswM_91001], the function BswM_EthIf_PortGroupLinkStateChg is called by module EthIf to indicate a change in the link state of an Ethernet switch port group to the BswM. The interface has service ID 0x26 and is provided via header file BswM_EthIf.h [SWS_BswM_91001].

The call passes two input parameters:

PortGroupIdx: Designates the index of the affected port group in the context of the Ethernet Interface [SWS_BswM_91001].
PortGroupState: Indicates the status of the port group, which is derived from the physical link of the Ethernet transceiver. Valid states are ETHTRCV_LINK_STATE_DOWN for a disconnected link and ETHTRCV_LINK_STATE_ACTIVE for an active link [SWS_BswM_91001].

The function has neither input/output parameters nor output parameters and returns no value (void) [SWS_BswM_91001].

Concurrency and Limitations

Execution is synchronous and specified as reentrant [SWS_BswM_91001]. Specific return values, error codes, or error messages (DET/DEM) are not defined for this interface [SWS_BswM_91001].

Interaction

Interpretation: The BswM is likely to use the transmitted link status as an input variable to evaluate state-dependent rules and trigger downstream actions or mode switches within the BSW. Question Q-14285579acb760d5 (open)

This text was created by an AI and is based on the specifications of AUTOSAR release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_EthSM_CurrentState [SWS_BswM_00050] 📄 PDF

void BswM_EthSM_CurrentState (NetworkHandleType Network, EthSM_NetworkModeStateType CurrentState);

Function called by Eth SM to indicate its current state.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: f4b4cf6ab059 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_EthSM_CurrentState serves as a callback and notification interface of the BSW Mode Manager. According to [SWS_BswM_00050], it is called by the Ethernet State Manager (EthSM) to transmit the current state of a communication channel to the BswM. The declaration of the interface is provided via the header BswM_EthSM.h and has the service ID 0x0d.

According to [SWS_BswM_00050], the following specifications apply to usage and calling:

Call semantics: The execution takes place synchronously. The caller thus waits until the function has completed processing the status report.
Concurrency: The service is specified as reentrant [SWS_BswM_00050]. Calls can therefore be made for different network instances or concurrently from the context of module EthSM.
Passed parameters: The affected Ethernet network is passed as Network of type NetworkHandleType, and the reported status is passed as CurrentState of type EthSM_NetworkModeStateType. Input and output parameters (inout/out) are not provided; the return value is void.

In the element specification [SWS_BswM_00050], neither specific return values nor error messages to DET or DEM are defined. Interpretation: The module BswM is likely to store the reported network state internally and use it as a condition for evaluating configured rules as well as for initiating mode switches. Question Q-407156ff74cbab6f (open)

This usage note was generated automatically based on the specification of the AUTOSAR release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_FrSM_CurrentState [SWS_BswM_00051] 📄 PDF

void BswM_FrSM_CurrentState (NetworkHandleType Network, FrSM_BswM_StateType CurrentState);

Function called by Fr SM to indicate its current state.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 09e9d4f2c26f Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The function BswM_FrSM_CurrentState serves as a callback or notification interface of the BswM, which is called by the FlexRay State Manager (FrSM) to report the current state of a FlexRay cluster [SWS_BswM_00051]. The function declaration is provided via the header file BswM_FrSM.h [SWS_BswM_00051]. The call takes place synchronously and returns no return value (void) [SWS_BswM_00051].

The interface defines two input parameters [SWS_BswM_00051]:

Network (type NetworkHandleType): Specifies the respective FlexRay cluster to which the state report relates [SWS_BswM_00051].
CurrentState (type FrSM_BswM_StateType): Transmits the current state of the relevant FlexRay cluster to the BswM [SWS_BswM_00051].

Output (out) or input/output parameters (inout) do not exist for this function [SWS_BswM_00051].

Concurrency and Error Handling

The function is specified with the service ID 0x0c and designated as reentrant [SWS_BswM_00051]. Specific error codes, behavior in case of errors, or notifications to Development Error Tracer (DET) or Diagnostic Event Manager (DEM) are not identified in the specification for this service [SWS_BswM_00051].

This usage note was generated automatically based on the specification of AUTOSAR Classic Release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_GetVersionInfo [SWS_BswM_00003] 📄 PDF

void BswM_GetVersionInfo (Std_VersionInfoType* VersionInfo);

Returns the version information of this module.

function BswM_Init [SWS_BswM_00002] 📄 PDF

void BswM_Init (const BswM_ConfigType* ConfigPtr);

Initializes the BSW Mode Manager.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 5e70993e412e Provenance Open questions (2)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous function BswM_Init serves to initialize the Basic Software Mode Manager (BswM) according to the specification [SWS_BswM_00002]. It is declared via the header file BswM.h and has the service ID 0x00 [SWS_BswM_00002].

Parameters and Return Values

A pointer to the post-build configuration data of type BswM_ConfigType is passed to the function via the only input parameter ConfigPtr [SWS_BswM_00002]. No output or input/output parameters exist, and no return value is returned [SWS_BswM_00002].

Concurrency and Execution Context

Execution is synchronous. The module behavior regarding reentrancy is specified as conditionally reentrant (Conditionally Reentrant) [SWS_BswM_00002]. As an interpretation, this likely means that concurrent calls are only permitted under special system conditions, such as separated data areas. Question Q-c0063b2a12eb4f41 (open) In addition, the call is likely to occur typically during system initialization before other operations of the BswM are executed.

This text was generated by an AI based on the AUTOSAR specification R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_J1939DcmBroadcastStatus [SWS_BswM_00165] 📄 PDF

void BswM_J1939DcmBroadcastStatus (uint16 NetworkMask);

This API tells the Bsw M the desired communication status of the available networks. The status will typically be activated via COM I - PDU group switches.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: f5a67b453f66 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The synchronous service function BswM_J1939DcmBroadcastStatus (service ID 0x1b) transmits the desired communication status of the available networks to the BSW Mode Manager [SWS_BswM_00165]. The reported status is typically activated in the system via COM I-PDU group switches [SWS_BswM_00165]. The interface is provided via header BswM_J1939Dcm.h [SWS_BswM_00165].

The parameters and semantics are specified as follows [SWS_BswM_00165]:

Input parameter: Via parameter NetworkMask, a bitmask is passed that contains one bit per available network. The respective bit position corresponds to the communication channel identifier ComMChannel.ComMChannelId, so that channel ID 0 is mapped to bit 0.
Bit meaning: The value 1 signals that the network is enabled (Network enabled), while 0 indicates a disabled network (Network disabled).
Return value: The function has no return value (void).

Concurrency and restrictions: The call is designed to be reentrant and operates synchronously [SWS_BswM_00165]. Because parameter NetworkMask is defined as a 16-bit value, by design only the first 16 communication channel IDs can be addressed via this API [SWS_BswM_00165]. Specific error codes as well as DET or DEM messages are not specified for this function [SWS_BswM_00165].

This usage note was generated by an AI based on the specification SWS_BswM_00165.

Implementer's Guide to follow (complexity I1)

function BswM_J1939Nm_StateChangeNotification [SWS_BswM_00194] 📄 PDF

void BswM_J1939Nm_StateChangeNotification (NetworkHandleType Network, uint8 Node, Nm_StateType NmState);

Notification of current J1939Nm state after state changes. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_BSWModeManager

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 47b6489fcb28 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The function BswM_J1939Nm_StateChangeNotification serves to synchronously notify the BSW Mode Manager of the current state of a J1939 network node after a state change has occurred [SWS_BswM_00194]. The declaration is available via header file BswM_J1939Nm.h and is listed under service ID 0x18 [SWS_BswM_00194].

The interface expects three input parameters and returns no return value (void) [SWS_BswM_00194]:

Network (NetworkHandleType): Identifies the affected J1939 channel [SWS_BswM_00194].
Node (uint8): Numerical identification of the respective J1939 node [SWS_BswM_00194].
NmState (Nm_StateType): Represents the current or newly adopted state of the node [SWS_BswM_00194].

Concurrency and Call Context

Processing is synchronous and specified as reentrant [SWS_BswM_00194]. Therefore, in systems with multiple nodes or channels, the notification may also occur concurrently. The caller is likely to be the J1939Nm module, which informs the BswM of the new status after internal state transitions. Question Q-9c0e521db5e51713 (open)

Error handling

The specification defines neither specific error codes nor notifications to DET or DEM for this service [SWS_BswM_00194]. Furthermore, neither output parameters nor input/output parameters exist for error indication [SWS_BswM_00194].

This text was generated by an AI based on the specification.

Implementer's Guide to follow (complexity I1)

function BswM_LinSM_CurrentSchedule [SWS_BswM_00058] 📄 PDF

void BswM_LinSM_CurrentSchedule (NetworkHandleType Network, LinIf_SchHandleType CurrentSchedule);

Function called by Lin SM to indicate the currently active schedule table for a specific LIN channel.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: e6dd0a37e7a5 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_LinSM_CurrentSchedule serves as a notification interface called by the LIN State Manager (Lin SM) to indicate the currently active schedule table for a specific LIN channel to the BswM ([SWS_BswM_00058]). The service is available via the header BswM_LinSM.h and has the service ID 0x0a ([SWS_BswM_00058]).

Upon the call, two input parameters are passed ([SWS_BswM_00058]):

Network (type NetworkHandleType): Denotes the specific LIN channel on which the change of the schedule table took place ([SWS_BswM_00058]).
Current Schedule (type LinIf_SchHandleType): Passes the identifier of the schedule table that is now active on this LIN channel ([SWS_BswM_00058]).

The interface has neither input/output nor output parameters and returns no return value (void) ([SWS_BswM_00058]). The execution behavior is defined as synchronous (Synchronous), and the function is specified as reentrant (Reentrant) ([SWS_BswM_00058]).

Specific error codes, error reactions, or messages to DET or DEM are not identified in the specification for this service ([SWS_BswM_00058]). Interpretation: The call is likely to occur typically immediately after a table change has taken place in the Lin SM, in order to synchronously inform the state evaluation in the BswM about the change. Question Q-302196d84e739258 (open)

This text was generated by an AI based on the AUTOSAR specifications.

function BswM_LinSM_CurrentState [SWS_BswM_00052] 📄 PDF

void BswM_LinSM_CurrentState (NetworkHandleType Network, LinSM_ModeType CurrentState);

Function called by Lin SM to indicate its current state.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 031315eb052c Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The synchronous function BswM_LinSM_CurrentState is called by the LIN State Manager (LinSM) to notify the BswM of a state change of a LIN channel [SWS_BswM_00052]. It is defined in the module BswM, has the service ID 0x09, and is declared via the header file BswM_LinSM.h for the LinSM [SWS_BswM_00052].

Parameters and Return Values

The interface has no return value (void) and neither input/output nor output parameters [SWS_BswM_00052]. Two input parameters are passed for signaling:

Network (type NetworkHandleType): Specifies the LIN channel to which the reported state indication relates [SWS_BswM_00052].
CurrentState (type LinSM_ModeType): Contains the currently assumed state of the specified LIN channel [SWS_BswM_00052].

Concurrency and Module Integration

According to the specification, the function is implemented as reentrant [SWS_BswM_00052]. This allows parallel calls for different LIN networks without mutual blocking. Interpretation: The transmitted channel state is presumably used in the BswM as an input variable for rule evaluations and action lists to control mode transitions throughout the entire ECU based on it. Question Q-ca113e4b71e4ab75 (open)

This text was created by an AI and is based on the specification AUTOSAR Classic R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_LinTp_RequestMode [SWS_BswM_00156] 📄 PDF

void BswM_LinTp_RequestMode (NetworkHandleType Network, LinTp_Mode LinTpRequestedMode);

Function called by Lin TP to request a mode for the corresponding LIN channel. The Lin Tp_ Mode correlates to the LIN schedule table that should be used.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 7a2ccb8581e5 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The synchronous function BswM_LinTp_RequestMode is called by the Lin TP to request a mode change for a specific LIN channel [SWS_BswM_00156]. It is declared via the header BswM_LinTp.h with the service ID 0x0b [SWS_BswM_00156]. The following input parameters are passed:

Network (type NetworkHandleType): Designates the affected LIN channel to which the mode request refers [SWS_BswM_00156].
LinTp_Mode (passed as LinTp_Mode Lin Tp RequestedMode): Determines the requested TP mode, which correlates directly with the LIN schedule table to be used [SWS_BswM_00156].

The function has no return value (void) [SWS_BswM_00156]. Specific error codes, return values for error handling, or DET messages are not provided in the function definition [SWS_BswM_00156].

Concurrency and Mode Management

The interface is specified as reentrant [SWS_BswM_00156]. This allows concurrent calls from different contexts or for separate LIN channels. Because the requested mode affects the selection of the schedule table, the function serves as a mode-specific interface between the Lin TP and the BSW Mode Manager [SWS_BswM_00156]. Interpretation: Based on the request, the BswM is likely to perform internal evaluations to initiate the switch of the LIN schedule table. Question Q-544460b6b32b6ac2 (open)

This usage note was generated automatically based on the specification AUTOSAR Classic R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_Nm_CarWakeUpIndication [SWS_BswM_00235] 📄 PDF

void BswM_Nm_CarWakeUpIndication (NetworkHandleType Network);

Function called by Nm to indicate a Car Wakeup.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: d3f5d924a01a Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The function BswM_Nm_CarWakeUpIndication serves as a callback interface of the Basic Software Mode Manager (BswM) and is called by Network Management (Nm) to indicate a channel-related car wake-up event [SWS_BswM_00235]. The call is synchronous and passes the identification of the affected Nm channel via input parameter Network of type NetworkHandleType [SWS_BswM_00235]. The interface declares no return value (void) and provides no output parameters [SWS_BswM_00235]. The service is defined with service ID 0x24 in header file BswM_Nm.h [SWS_BswM_00235].

Concurrency and Error Handling

The interface is specified as reentrant, which permits concurrent calls [SWS_BswM_00235]. Specific error codes, notifications to the DET or DEM, and special error handling mechanisms are not stated in the element specification [SWS_BswM_00235].

Interaction

As an integration point between the Nm and the BswM, the function forwards the wake-up signal directly to the BswM processing [SWS_BswM_00235]. Interpretation: The call is likely to be evaluated within the BswM as an indicator for rule checks or mode switches during network startup. Question Q-e56d5cfb6345f1ba (open)

This usage note was generated automatically based on the AUTOSAR R20-11 specification.

function BswM_Nm_StateChangeNotification [SWS_BswM_91002] 📄 PDF

void BswM_Nm_StateChangeNotification (NetworkHandleType Network, Nm_StateType currentState);

Notification of current Nm state after state changes.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 7766e9c5f805 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The function BswM_Nm_StateChangeNotification serves as a notification interface to transmit the current state of a network management channel to the BswM after status changes have occurred [SWS_BswM_91002]. It is declared in header file BswM_Nm.h and defined under service ID 0x27 [SWS_BswM_91002]. Execution is synchronous, and the function has no return value (void) [SWS_BswM_91002].

The state data is passed via two pure input parameters; input/output or output parameters do not exist [SWS_BswM_91002]:

Network (type: NetworkHandleType): Designates the affected Nm channel for identifying the network [SWS_BswM_91002].
currentState (type: Nm_StateType): Signals the current or new state of the specified Nm channel [SWS_BswM_91002].

Concurrency and behavior

The interface is classified as reentrant [SWS_BswM_91002]. The function can thus be called concurrently, which is particularly relevant in the case of simultaneous status transitions on different network channels. Because the call is specified as synchronous, the function returns to the caller only after the status change has been accepted internally [SWS_BswM_91002]. Typically, the call is expected to be made by the network management as soon as a channel has entered a new state [SWS_BswM_91002]. Question Q-8645d9511a825fed (open)

This text was generated by an AI based on the R20-11 specification.

Implementer's Guide to follow (complexity I1)

function BswM_NvM_CurrentBlockMode [SWS_BswM_00104] 📄 PDF

void BswM_NvM_CurrentBlockMode (NvM_BlockIdType Block, NvM_RequestResultType CurrentBlockMode);

Function called by Nv M to indicate the current block mode of an Nv M block.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: ce828c822f7e Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The function BswM_NvM_CurrentBlockMode is called by the NVRAM Manager (NvM) to indicate the current block mode of an NVRAM block to the Basic Software Mode Manager (BswM) [SWS_BswM_00104]. The declaration of the function is available via the header file BswM_NvM.h and is assigned to the service ID 0x16 in the specification [SWS_BswM_00104].

Parameters and Return Values

The function returns no return value (void) to the caller and processes two input parameters [SWS_BswM_00104]:

Block (type NvM_BlockIdType): Passes the block identifier of the NVRAM block to which the new mode information relates [SWS_BswM_00104].
CurrentBlockMode (type NvM_RequestResultType): Transmits the current block mode or the request result of the NvM block [SWS_BswM_00104].

Output parameters or combined input/output parameters are not defined for this interface [SWS_BswM_00104].

Concurrency and Limitations

The function call of BswM_NvM_CurrentBlockMode is executed synchronously and is specified as reentrant [SWS_BswM_00104]. The interface is thus designed for reentrant usage in concurrent execution contexts [SWS_BswM_00104].

Error handling

For this interface, neither specific error codes nor requirements for error messages via the Default Error Tracer (DET) or the Diagnostic Event Manager (DEM) module are identified in the specification requirements [SWS_BswM_00104].

This usage note was generated automatically and is based exclusively on the specification data of the AUTOSAR release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_NvM_CurrentJobMode [SWS_BswM_00152] 📄 PDF

void BswM_NvM_CurrentJobMode (NvM_MultiBlockRequestType MultiBlockRequest, NvM_RequestResultType CurrentJobMode);

Function called by Nv M to inform the Bsw M about the current state of a multi block job.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 6a6aa120a70e Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and signature

The function BswM_NvM_CurrentJobMode is called by the NVRAM Manager (NvM) to inform the BSW Mode Manager (BswM) about the current state of a multi-block job [SWS_BswM_00152]. The interface is declared in header BswM_NvM.h and has the service ID 0x17 [SWS_BswM_00152]. It accepts two input parameters:

MultiBlockRequest (type NvM_MultiBlockRequestType): Indicates to which specific multi-block job this callback refers [SWS_BswM_00152].
CurrentJobMode (type NvM_RequestResultType): Specifies the current status or result of the relevant multi-block job [SWS_BswM_00152].

The function returns no value (return type void) and has no input/output or output parameters [SWS_BswM_00152].

Concurrency and Error Handling

The specification defines BswM_NvM_CurrentJobMode as synchronous and reentrant [SWS_BswM_00152]. The call is made directly from the execution context of the module NvM. As an interpretation, this call is likely triggered typically in the course of batch operations such as read or write processes as soon as a status change occurs. Question Q-25514d3dbf1d8c5c (open)

No return values or specific error codes for development errors (DET) or production errors are specified for this function; the behavior in the event of an error is not separately stated [SWS_BswM_00152].

This usage note was generated automatically based on the AUTOSAR Classic R20-11 specification.

Implementer's Guide to follow (complexity I1)

function BswM_RequestMode [SWS_BswM_00046] 📄 PDF

void BswM_RequestMode (BswM_UserType requesting_user, BswM_ModeType requested_mode);

Generic function call to request modes. This function shall only be used by other BSW modules that does not have a specific mode request interface.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c82de091e0a4 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_RequestMode provides a generic function call for requesting modes in the Basic Software Mode Manager (BswM) [SWS_BswM_00046]. It is declared via the header file BswM.h and has the service ID 0x02 [SWS_BswM_00046].

Usage and restrictions

The usage is strictly regulated: The function may only be called by other BSW modules that do not have their own module-specific interface for mode requests [SWS_BswM_00046]. Consequently, BSW modules with dedicated interfaces must not use this generic service.

Parameters and Semantics

The function signature is void BswM_RequestMode (BswM_UserType requesting_user, BswM_ModeType requested_mode) [SWS_BswM_00046]. Two input parameters are passed:

requesting_user: Identifies the requesting user or the requesting software module [SWS_BswM_00046].
requested_mode: Passes the specifically requested state or mode [SWS_BswM_00046].

There are neither input/output nor output parameters, and the function has no return value (void) [SWS_BswM_00046].

Concurrency

The call is processed synchronously and is specified as reentrant [SWS_BswM_00046]. Thus, the function is suitable for concurrent calls from multiple BSW contexts.

This usage note was generated automatically based on the specification of AUTOSAR Classic Release R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_Sd_ClientServiceCurrentState [SWS_BswM_00204] 📄 PDF

void BswM_Sd_ClientServiceCurrentState (uint16 SdClientServiceHandleId, Sd_ClientServiceCurrentStateType CurrentClientState);

Function called by Service Discovery to indicate current state of the Client Service (available/ down).

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: d6ef98b31ed5 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The function BswM_Sd_ClientServiceCurrentState is called by Service Discovery (SD) to synchronously inform the BswM of the current state of a client service [SWS_BswM_00204]. This interface signals whether the corresponding service is operational (available) or unavailable (down) [SWS_BswM_00204]. The declaration of the C function is provided via header BswM_Sd.h [SWS_BswM_00204].

Parameters and Interface Signature

The interface has service ID 0x1f and expects two input parameters [SWS_BswM_00204]:

SdClientServiceHandleId (type uint16): Unique handle ID for identifying the client service [SWS_BswM_00204].
CurrentClientState (type Sd_ClientServiceCurrentStateType): Current availability state of the service [SWS_BswM_00204].

The function returns no return value (void) and defines no input/output or output parameters [SWS_BswM_00204].

Concurrency and Interaction

The execution of BswM_Sd_ClientServiceCurrentState is synchronous and reentrant [SWS_BswM_00204]. Callers therefore do not need to enforce sequential serialization, but can report status changes concurrently. In the overall interaction, the status message is presumably used for internal rule evaluation and initiation of configured mode switches within the BswM. Question Q-0490a3902ca9e78d (open)

This text was generated by an AI based on the specification data.

Implementer's Guide to follow (complexity I1)

function BswM_Sd_ConsumedEventGroupCurrentState [SWS_BswM_00207] 📄 PDF

void BswM_Sd_ConsumedEventGroupCurrentState (uint16 SdConsumedEventGroupHandleId, Sd_ConsumedEventGroupCurrentStateType ConsumedEventGroupState);

Function called by Service Discovery to indicate current status of the Consumed Eventgroup (available/ down).

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 8146488c68a5 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_Sd_ConsumedEventGroupCurrentState serves as a callback interface called by Service Discovery to indicate the current state of a consumed eventgroup to the Basic Software Mode Manager (BswM) [SWS_BswM_00207]. It informs the BswM whether the corresponding eventgroup is available (available) or failed (down) in the network [SWS_BswM_00207].

Usage and signature

The interface has service ID 0x21 and is provided via header file BswM_Sd.h [SWS_BswM_00207]. The call is processed synchronously and has no return value (void) [SWS_BswM_00207]. Upon function call, Service Discovery passes two input parameters, while neither input/output nor pure output parameters are defined [SWS_BswM_00207]:

Sd Consumed Event Group Handle Id (data type uint16): Unique handle ID for identifying the respective consumed eventgroup [SWS_BswM_00207].
Consumed Event Group State (data type Sd_Consumed Event Group Current State Type): Current status of the consumed eventgroup for indicating availability [SWS_BswM_00207].

Concurrency and Error Handling

According to the specification, the function is designated as reentrant and may thus be called concurrently if required [SWS_BswM_00207]. For this service, no specific error codes, exceptions, or feedback to development error tracking (DET) or diagnostic event management (DEM) are listed in the specification [SWS_BswM_00207].

This usage note was generated automatically based on the specification AUTOSAR CP R20-11.

Implementer's Guide to follow (complexity I1)

function BswM_Sd_EventHandlerCurrentState [SWS_BswM_00210] 📄 PDF

void BswM_Sd_EventHandlerCurrentState (uint16 SdEventHandlerHandleId, Sd_EventHandlerCurrentStateType EventHandlerStatus);

Function called by Service Discovery to indicate current status of the Event Handler (requested/ released).

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 38ebb49535f7 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Call Context

The synchronous function BswM_Sd_EventHandlerCurrentState serves as an interface called by Service Discovery to report the current status of an event handler to the BSW Mode Manager (BswM) [SWS_BswM_00210]. Typical states of the event handler include information on whether it has been requested or released [SWS_BswM_00210]. The declaration of the function is provided via header file BswM_Sd.h [SWS_BswM_00210].

Parameters and Signature Properties

The function returns no return value (void) and expects two input parameters when called [SWS_BswM_00210]:

SdEventHandlerHandleId: Identifier of type uint16, which uniquely addresses the associated event handler [SWS_BswM_00210].
EventHandlerStatus: Status information of type Sd_EventHandlerCurrentStateType, which represents the current state of the event handler [SWS_BswM_00210].

Concurrency and Error Handling

The function is listed under service ID 0x20 and, according to the specification, is implemented as reentrant [SWS_BswM_00210]. Specific error codes, input/output parameters, or explicit error notifications via DET or DEM are not defined for this interface [SWS_BswM_00210].

This text was created by an AI. It serves as guidance and does not replace studying the AUTOSAR specification.

Implementer's Guide to follow (complexity I1)

function BswM_WdgM_RequestPartitionReset [SWS_BswM_00157] 📄 PDF

void BswM_WdgM_RequestPartitionReset (ApplicationType Application);

Function called by Wdg M to request a partition reset.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 51a67f346a31 Provenance

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_WdgM_RequestPartitionReset is called by the Watchdog Manager (WdgM) to request the reset of a specific partition from the Basic Software Mode Manager (BswM) [SWS_BswM_00157]. The declaration of this interface is provided via the header BswM_WdgM.h and is assigned to service ID 0x11 [SWS_BswM_00157].

The following specification requirements apply to the usage and call context:

Parameters: Application of type ApplicationType is passed as an input parameter, representing the unique identifier of the respective OS-Application [SWS_BswM_00157]. No other input or output parameters exist for this call [SWS_BswM_00157].
Return value: The function has no return value (return type void) [SWS_BswM_00157].
Synchronicity and concurrency: The function execution is synchronous and specified as reentrant, which permits concurrent calls [SWS_BswM_00157].
Error handling: Specific error codes, error reactions, and messages to DET or DEM are not documented in the specification of this element [SWS_BswM_00157].

In the interaction of the basic software modules, the function forms the direct notification interface through which the WdgM synchronously informs the BswM about a required partition reset for the passed OS-Application [SWS_BswM_00157].

This text was created by an AI; the guidelines require verification against the specification.

function BswM_MainFunction [SWS_BswM_00053] 📄 PDF

void BswM_MainFunction (void);

Main function of the Bsw M

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: c5437207e9bf Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

The function BswM_MainFunction forms the central periodic main function of the BSW Mode Manager (BswM) ([SWS_BswM_00053]). It has the service ID 0x03, takes no input parameters, and returns no return value (signature: void BswM_MainFunction(void)). Its declaration is provided via the header file SchM_BswM.h ([SWS_BswM_00053]). Due to its provision via SchM_BswM.h, the call in the ECU is likely to occur typically cyclically by the Schedule Manager (SchM) in the context of a periodic operating system task. Question Q-fdb948e42c35d9fb (open)

Regarding the interaction and processing logic, BswM_MainFunction is responsible for evaluating deferred mode requests: The function must mandatorily evaluate all rules that use as an input at least one mode request with the configuration parameter BswMRequestProcessing set to the value BSWM_DEFERRED ([SWS_BswM_00075]).

For the practical integration into the Basic Software system, the following boundary conditions result from this:

Call context and scheduling: The function has neither parameters nor return values ([SWS_BswM_00053]); it is intended for recurring integration into the cyclic schedule of the Basic Software scheduler.
Rule processing: Mode requests that are not processed immediately, but are configured to BSWM_DEFERRED, are decoupled in time and processed in a batch only in the execution cycle of this main function ([SWS_BswM_00075]).

This text was generated by an AI based on the specification.

Implementer's Guide to follow (complexity I1)

function <BswMUserCalloutFunction> [SWS_BswM_00270] 📄 PDF

void <BswMUserCalloutFunction> (implementation_specific -);

Function called by the Bsw M when a Bsw MUser Callout is executed. The function name and all function parameters are defined b y the Bsw MUser Callout Function configuration parameter. Any return values are ignored by the Bsw M.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 3c3d21cc95d0 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

use

The user-defined callout function is called by the BSW Mode Manager as soon as a corresponding BswMUserCallout action is executed [SWS_BswM_00270]. The actual function name as well as all passed parameters are defined via configuration parameter BswMUserCalloutFunction [SWS_BswM_00270]. The syntax is defined generically as void <BswMUserCalloutFunction>(implementation_specific), with any return values being completely ignored by the BswM [SWS_BswM_00270].

Concurrency and Limitations

Both the execution behavior (synchronous or asynchronous) and the reentrancy of the callout function are specified as configuration-dependent [SWS_BswM_00270]. The actual call context presumably depends on the triggering BswM event or the task in which the BswM action is processed. Question Q-2f3e2cdbb9de1794 (open) Developers must therefore ensure that the implementation meets the requirements of the selected execution context regarding thread safety and blocking behavior.

Error Handling and Configuration

The specification defines no specific DET or DEM error messages for this service (service ID 0x25) [SWS_BswM_00270]. Because the BswM ignores any return values, the function cannot report errors to the BswM via standardized return values. The availability and linking of the function is carried out via the module configuration (reference ECUC_BswM_00954) [SWS_BswM_00270].

This usage note was generated automatically and is based on the requirements of the AUTOSAR specification.

type BswM_ConfigType [SWS_BswM_00213] 📄 PDF

This structure contains all post - build configurable parameters of the BSW Mode AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_BSWModeManager Manager. A pointer to this structure is passed to the BSW Mode Manager initialization function for configuration.

type BswM_ModeType [SWS_BswM_00214] 📄 PDF

This type identifies the modes that can be requested by Bsw M Users.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: aaf8a1f15f59 Provenance Open questions (1)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Type Definition

The data type BswM_ModeType serves in the BswM module to uniquely identify those modes that can be requested by BswM users [SWS_BswM_00214]. According to the specification, the type is derived from the primitive base type uint16 and covers a value range from 0 to 65535 [SWS_BswM_00214]. It is declared and provided via header file BswM.h, which must be included by requesting components for usage [SWS_BswM_00214].

Limitations and Assumptions

Calling software entities pass mode values as a 16-bit integer within the limits of 0 to 65535 [SWS_BswM_00214]. Since the specification does not list fixed symbolic constants, the specific mapping of individual integer values to application-specific modes is presumably determined during the configuration of the BswM module. Question Q-94530792144d42ea (open) To ensure error-free usage, it must be ensured that requesters only use values within the defined value range [SWS_BswM_00214].

Integration in the BSW Stack

Interfaces that forward mode requests from users to the BswM use BswM_ModeType for the typed passing of mode identifiers [SWS_BswM_00214]. Provision via BswM.h ensures consistent typing across different BSW module boundaries [SWS_BswM_00214].

This text was created by an AI-assisted documentation system and is based on the AUTOSAR Classic R20-11 specification.

Implementer's Guide to follow (complexity I1)

type BswM_UserType [SWS_BswM_00216] 📄 PDF

This type identifies a Bsw M User that makes mode requests to the Bsw M.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 4d6cdb259f49 Provenance Open questions (2)

translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Usage and Type Definition

The data type BswM_UserType is provided via header file BswM.h and serves for the unique identification of a BswM user that submits mode requests to the Basic Software Mode Manager [SWS_BswM_00216]. The type is derived from the base integer type uint16 and covers a value range from 0 to 65535 [SWS_BswM_00216].

Interaction and integration

In the software architecture, this type is likely to function primarily as an input parameter in mode request interfaces, allowing the BswM to associate the incoming request with the respective source. Question Q-83bb1af3fb090e7e (open) Due to the 16-bit width, the type definition provides room for up to 65536 different user identifiers in the system [SWS_BswM_00216]. The specific instance values of the users are presumably generated configuration-specifically during BSW generation.

Restrictions and Error Handling

Since this is an elementary type definition, no specific error codes, DET messages, or concurrency mechanisms are documented for this type within the scope of the specification. Requesting software modules must ensure that only values within the permissible range of 0 to 65535 are passed in calls [SWS_BswM_00216].

This usage note was generated by an AI and is based exclusively on specification element SWS_BswM_00216 from AUTOSAR R20-11.

Implementer's Guide to follow (complexity I1)

Request a governed re-review of this record. The record is not changed immediately.

Record: AUTOSAR/AP/record/CP_MOD_BswM
Status: unspecified
Version: AUTOSAR/AP/record/CP_MOD_BswM@rel:R20-11#d204f1fc
Content hash: d204f1fc
Source: https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_BSWModeManager.pdf#nameddest=SWS_BswM_00193

Topic map

Callouts and expected interfaces

Cyclic

BswM_MainFunction

Types

BswM_ConfigType BswM_ModeType BswM_UserType

Detail view

Select an entry in the outline.

No element data available for this release

Initialization and status

BswM_Deinit function

Deinitializes the BSW Mode Manager.

void BswM_Deinit (void);

BswM_GetVersionInfo function

Returns the version information of this module.

void BswM_GetVersionInfo (Std_VersionInfoType* VersionInfo);

BswM_Init function

Initializes the BSW Mode Manager.

void BswM_Init (const BswM_ConfigType* ConfigPtr);

Services · `Com…`

BswM_ComM_CurrentMode function

Function called by Com M to indicate the current communication mode of a Com M channel.

void BswM_ComM_CurrentMode (NetworkHandleType Network, ComM_ModeType RequestedMode);

BswM_ComM_CurrentPNCMode function

Function is called by Com M to indicate the current mode of the PNC. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_BSWModeManager

void BswM_ComM_CurrentPNCMode (PNCHandleType PNC, ComM_PncModeType CurrentPncMode);

BswM_ComM_InitiateReset function

Function is called by Com M to signal a shutdown.

void BswM_ComM_InitiateReset (void);

Services · `Ecu…`

BswM_EcuM_CurrentState function

Function called Ecu M to indicate the current ECU Operation Mode.

void BswM_EcuM_CurrentState (EcuM_StateType CurrentState);

BswM_EcuM_CurrentWakeup function

Function called by Ecu M to indicate the current state of a wakeup source.

void BswM_EcuM_CurrentWakeup (EcuM_WakeupSourceType source, EcuM_WakeupStatusType state);

BswM_EcuM_RequestedState function

Function called by Ecu M notify about current Status of the Run Request Protocol.

void BswM_EcuM_RequestedState (EcuM_StateType State, EcuM_RunStatusType CurrentState);

Services · `Lin…`

BswM_LinSM_CurrentSchedule function

Function called by Lin SM to indicate the currently active schedule table for a specific LIN channel.

void BswM_LinSM_CurrentSchedule (NetworkHandleType Network, LinIf_SchHandleType CurrentSchedule);

BswM_LinSM_CurrentState function

Function called by Lin SM to indicate its current state.

void BswM_LinSM_CurrentState (NetworkHandleType Network, LinSM_ModeType CurrentState);

BswM_LinTp_RequestMode function

Function called by Lin TP to request a mode for the corresponding LIN channel. The Lin Tp_ Mode correlates to the LIN schedule table that should be used.

void BswM_LinTp_RequestMode (NetworkHandleType Network, LinTp_Mode LinTpRequestedMode);

Services · `Sd…`

BswM_Sd_ClientServiceCurrentState function

Function called by Service Discovery to indicate current state of the Client Service (available/ down).

void BswM_Sd_ClientServiceCurrentState (uint16 SdClientServiceHandleId, Sd_ClientServiceCurrentStateType CurrentClientState);

BswM_Sd_ConsumedEventGroupCurrentState function

Function called by Service Discovery to indicate current status of the Consumed Eventgroup (available/ down).

void BswM_Sd_ConsumedEventGroupCurrentState (uint16 SdConsumedEventGroupHandleId, Sd_ConsumedEventGroupCurrentStateType ConsumedEventGroupState);

BswM_Sd_EventHandlerCurrentState function

Function called by Service Discovery to indicate current status of the Event Handler (requested/ released).

void BswM_Sd_EventHandlerCurrentState (uint16 SdEventHandlerHandleId, Sd_EventHandlerCurrentStateType EventHandlerStatus);

Services · `Dcm…`

BswM_Dcm_ApplicationUpdated function

This function is called by the DCM in order to report an updated application.

void BswM_Dcm_ApplicationUpdated (void);

BswM_Dcm_CommunicationMode_CurrentState function

Function called by DCM to inform the Bsw M about the current state of the communication mode.

void BswM_Dcm_CommunicationMode_CurrentState (NetworkHandleType Network, Dcm_CommunicationModeType RequestedMode);

Services · `Eth…`

BswM_EthIf_PortGroupLinkStateChg function

Function called by Eth If to indicate the link state change of a certain Ethernet switch port group.

void BswM_EthIf_PortGroupLinkStateChg (EthIf_SwitchPortGroupIdxType PortGroupIdx, EthTrcv_LinkStateType PortGroupState);

BswM_EthSM_CurrentState function

Function called by Eth SM to indicate its current state.

void BswM_EthSM_CurrentState (NetworkHandleType Network, EthSM_NetworkModeStateType CurrentState);

Services · `J1939…`

BswM_J1939DcmBroadcastStatus function

This API tells the Bsw M the desired communication status of the available networks. The status will typically be activated via COM I - PDU group switches.

void BswM_J1939DcmBroadcastStatus (uint16 NetworkMask);

BswM_J1939Nm_StateChangeNotification function

Notification of current J1939Nm state after state changes. AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_BSWModeManager

void BswM_J1939Nm_StateChangeNotification (NetworkHandleType Network, uint8 Node, Nm_StateType NmState);

Services · `Nm…`

BswM_Nm_CarWakeUpIndication function

Function called by Nm to indicate a Car Wakeup.

void BswM_Nm_CarWakeUpIndication (NetworkHandleType Network);

BswM_Nm_StateChangeNotification function

Notification of current Nm state after state changes.

void BswM_Nm_StateChangeNotification (NetworkHandleType Network, Nm_StateType currentState);

Services · `Nv…`

BswM_NvM_CurrentBlockMode function

Function called by Nv M to indicate the current block mode of an Nv M block.

void BswM_NvM_CurrentBlockMode (NvM_BlockIdType Block, NvM_RequestResultType CurrentBlockMode);

BswM_NvM_CurrentJobMode function

Function called by Nv M to inform the Bsw M about the current state of a multi block job.

void BswM_NvM_CurrentJobMode (NvM_MultiBlockRequestType MultiBlockRequest, NvM_RequestResultType CurrentJobMode);

Services · More

BswM_BswMPartitionRestarted function

Function called by Restart Task if the partition containing the Bsw M has been restarted.

void BswM_BswMPartitionRestarted (void);

BswM_CanSM_CurrentState function

Function called by Can SM to indicate its current state. Ava ilable via Bsw M_ Can SM.h

void BswM_CanSM_CurrentState (NetworkHandleType Network, CanSM_BswMCurrentStateType CurrentState);

BswM_FrSM_CurrentState function

Function called by Fr SM to indicate its current state.

void BswM_FrSM_CurrentState (NetworkHandleType Network, FrSM_BswM_StateType CurrentState);

BswM_RequestMode function

Generic function call to request modes. This function shall only be used by other BSW modules that does not have a specific mode request interface.

void BswM_RequestMode (BswM_UserType requesting_user, BswM_ModeType requested_mode);

BswM_WdgM_RequestPartitionReset function

Function called by Wdg M to request a partition reset.

void BswM_WdgM_RequestPartitionReset (ApplicationType Application);

Callouts and expected interfaces

<BswMUserCalloutFunction> function

void <BswMUserCalloutFunction> (implementation_specific -);

Cyclic

BswM_MainFunction function

Main function of the Bsw M

void BswM_MainFunction (void);

Types

BswM_ConfigType type

BswM_ModeType type

This type identifies the modes that can be requested by Bsw M Users.

BswM_UserType type

This type identifies a Bsw M User that makes mode requests to the Bsw M.

Click an entry to see its relations.