This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

BSW Mode Manager

BSW Mode Manager

Component Documentation

1 - BswM Peer Review Checklists

Overview

Summary Sheet
Synergy Project

Sheet 1: Summary Sheet
























Rev 1.28-Jun-15

Peer Review Summary Sheet


























Synergy Project Name:


kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. BswM
Revision / Baseline:


kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. BswM_Vector_Ar4.0.3_06.00.01_0

























Change Owner:


kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling
Work CR ID:


EA4#3163





























kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:















































































































































































kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:






















































Reviewed:































N/AMDD


N/ASource Code


N/APolySpace









































N/AIntegration Manual


N/ADavinci Files








































































Comments:

3rd Party BSW component. Only reviewed 3rd party files for correctness to delivery and any Nexteer created






source files and documentation



















































































General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.




















Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)



















































Quality Check Items:




































Rationale is required for all answers of No










New baseline version name from Summary Sheet follows








Yes
Comments:

Follows convention created for
naming convention











BSW components
























Project contains necessary subprojects








N/A
Comments:










































Project contains the correct version of subprojects








N/A
Comments:










































Design subproject is correct version








N/A
Comments:











































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/06/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































2 - TechnicalReference_BswM

Basic Software Mode Manager

3 - TechnicalReference_BswM_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65

4 - TechnicalReference_BswMs

 
 
 
 
 
 
 
 
 
 
 
MICROSAR BswM  
Technical Reference 
 
 
Version 6.00.00 
 
 
 
 
 
 
 
 
 
 
 
Authors 
Leticia Garcia Herrera, Thomas Kuhl, Philipp Ritter 
Status 
Released 
 
 
 
 
 
Technical Reference Basic Software Mode Manager 
Document Information 
History 
Author 
Date 
Version 
Remarks 
Leticia Garcia, Thomas Kuhl 
2012-08-02 
1.00.00 
Creation of document.  
Leticia Garcia, Thomas Kuhl 
2012-09-27 
1.01.00 
Addition of feature, support of 
EthSM . Chapters 3.1, 4.1, 
5.2and 6.3. 
Leticia Garcia, Thomas Kuhl 
2013-01-31 
1.02.00 
Addition of feature, support of 
NvM. Chapter 3.1, 4.1, 5.2 
and 5.3. 
Leticia Garcia, Thomas Kuhl 
2012-03-26 
1.03.00 
Support of Post-build variant. 
Chapters 4.1, 4.2, 5.1and 5.2. 
 
Deviation from AUTOSAR. 
Header included:  
Com_Types.h. Chapter 6.1 
Leticia Garcia 
2013-10-21 
2.00.00 
Addition of extension in 
chapter 6.2.  
Deletion of limitations in 
chapter 6.3.  
DET errors added in chapter 
3.6.1.  
Dynamic files added in 
chapter 4.1.2.  
Chapter 4.2 was changed. 
Chapter 4.3 was added. 
Leticia Garcia 
2013-12-04 
2.00.01 
Chapter 3.3 was extended. 
Chapter  3.4.2 was added. 
Chapter 3.6.1 error code 
added.  
Chapter 4.5 was extended 
Chapter 6.2 was extended. 
Leticia Garcia 
2013-02-18 
2.01.00 
Extended chapters: 3.1, 3.1.2, 
3.6.1, 4.1.1, 5.2.13, 5.2.14, 
5.2.31, 5.2.32, 5.2.33, 5.2.34 
5.3 and 6.2.1. 
Added chapters: 4.3.3, 5.6, 
and 6.2.2. Removed deviation 
about 
Com_IpduGroupControl 
usage. 
Philipp Ritter 
2014-06-13 
3.00.00 
Extended chapters: 3.1.2, 3.5, 
5.6.1, 6.2.1, 6.2.8 
Added chapters: 5.2.35, 
6.2.10, 6.2.11 
Updated Figures: Figure 3-2, 
2015, Vector Informatik GmbH 
Version: 6.00.00 
2 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Figure 3-3 
Philipp Ritter 
2014-10-22 
4.00.00 
Extended Chapters: 3.1, 
3.6.1, 4.1.1, 4.3.3, 5.2.4 
Added chapters: 5.2.36 
Philipp Ritter 
2015-02-02 
5.00.00 
Extended chapters: 3.6.1, 
4.3.3, 6.3.3, 6.3.4 
Added chapters: 5.2.17 
Removed: Limitation for 
multiple configurations 
Philipp Ritter 
2015-07-29 
6.00.00 
Extended chapters: 3.1, 3.1.2, 
3.6.1, 4.3.3, 5.3 
Added chapters:  4.3.4, 
5.2.21, 5.2.25, 5.2.26, 5.2.27, 
5.2.28, 5.2.29, 5.2.30 
 
Reference Documents 
No. 
Source 
Title 
Version 
[1]    AUTOSAR 
AUTOSAR_SWS_BSWModeManager.pdf 
1.4.0 
[2]    AUTOSAR 
AUTOSAR_EXP_ModemanagementGuide 
2.1.0 
[3]    AUTOSAR 
AUTOSAR_SWS_DevelopmentErrorTracer.pdf 
3.2.0 
[4]    AUTOSAR 
AUTOSAR_TR_BSWModuleList.pdf 
1.6.0 
[5]    AUTOSAR 
AUTOSAR_SWS_DiagnosticEventManager.pdf 
4.2.0 
[6]    Vector 
TechnicalReference_Rte.pdf 
see delivery 
[7]    Vector 
TechnicalReference_PostBuildLoadable.pdf 
see delivery 
[8]    Vector 
TechnicalReference_Com.pdf 
see delivery 
[9]    Vector 
TechnicalReference_IdentityManager.pdf 
see delivery 
 
 
 
 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
3 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
Scope of the Document 
This  technical  reference  describes  the  general  use  of  the  AUTOSAR  Basic  Software 
module BSW Mode Manager (BswM). 
 
 
 
Caution 
We have configured the programs in accordance with your specifications in the 
  questionnaire. Whereas the programs do support other configurations than the one 
specified in your questionnaire, Vector’s release of the programs delivered to your 
company is expressly restricted to the configuration you have specified in the 
questionnaire. 
 
 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
4 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Contents 
1 
Component History .................................................................................................... 10 
2 
Introduction................................................................................................................. 11 
2.1 
Architecture Overview ...................................................................................... 11 
3 
Functional Description ............................................................................................... 13 
3.1 
Features .......................................................................................................... 13 
3.1.1 
Deviations ........................................................................................ 14 
3.1.2 
Additions/ Extensions ....................................................................... 14 
3.2 
Initialization ...................................................................................................... 14 
3.3 
States .............................................................................................................. 14 
3.4 
Mode Management .......................................................................................... 16 
3.4.1 
Immediate Mode Handling ............................................................... 17 
3.4.2 
Forced Immediate Mode Handling ................................................... 17 
3.4.3 
Deferred Mode Handling .................................................................. 17 
3.5 
Execution of Action Lists .................................................................................. 20 
3.6 
Error Handling .................................................................................................. 20 
3.6.1 
Development Error Reporting ........................................................... 20 
3.6.2 
Production Code Error Reporting ..................................................... 22 
4 
Integration ................................................................................................................... 23 
4.1 
Scope of Delivery ............................................................................................. 23 
4.1.1 
Static Files ....................................................................................... 23 
4.1.2 
Dynamic Files .................................................................................. 24 
4.2 
Initialization of Other Software Modules ........................................................... 24 
4.2.1 
Using the Basic Editor ...................................................................... 24 
4.2.2 
Using the Comfort View.................................................................... 26 
4.3 
Support of Preconfigured State Machines (Auto-Configuration) ....................... 26 
4.3.1 
Initialization ...................................................................................... 27 
4.3.2 
ECU State Handling ......................................................................... 29 
4.3.3 
Communication Control .................................................................... 31 
4.3.4 
Service Discovery Control ................................................................ 33 
4.4 
Critical Sections ............................................................................................... 33 
4.5 
Cyclic Task ....................................................................................................... 33 
4.6 
NvM – BswM configuration .............................................................................. 33 
5 
API Description ........................................................................................................... 34 
5.1 
Type Definitions ............................................................................................... 34 
5.2 
Services Provided by BswM ............................................................................. 35 
2015, Vector Informatik GmbH 
Version: 6.00.00 
5 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.1 
BswM_InitMemory ........................................................................... 35 
5.2.2 
BswM_Init ........................................................................................ 35 
5.2.3 
BswM_Deinit .................................................................................... 36 
5.2.4 
BswM_GetVersionInfo ...................................................................... 36 
5.2.5 
BswM_RequestMode ....................................................................... 37 
5.2.6 
BswM_ComM_CurrentMode ............................................................ 37 
5.2.7 
BswM_ComM_CurrentPNCMode ..................................................... 38 
5.2.8 
BswM_Dcm_ApplicationUpdated ..................................................... 38 
5.2.9 
BswM_Dcm_CommunicationMode_CurrentState ............................ 39 
5.2.10 
BswM_CanSM_CurrentState ........................................................... 39 
5.2.11 
BswM_EthSM_CurrentState ............................................................ 40 
5.2.12 
BswM_FrSM_CurrentState .............................................................. 40 
5.2.13 
BswM_J1939DcmBroadcastStatus .................................................. 41 
5.2.14 
BswM_J1939Nm_StateChangeNotification ...................................... 41 
5.2.15 
BswM_LinSM_CurrentState ............................................................. 42 
5.2.16 
BswM_LinSM_CurrentSchedule....................................................... 42 
5.2.17 
BswM_LinSM_ScheduleEndNotification........................................... 43 
5.2.18 
BswM_LinTp_RequestMode ............................................................ 43 
5.2.19 
BswM_EcuM_CurrentState .............................................................. 44 
5.2.20 
BswM_EcuM_CurrentWakeup ......................................................... 44 
5.2.21 
BswM_EcuM_RequestedState ......................................................... 45 
5.2.22 
BswM_MainFunction ........................................................................ 45 
5.2.23 
BswM_NvM_CurrentBlockMode....................................................... 46 
5.2.24 
BswM_NvM_CurrentJobMode ......................................................... 46 
5.2.25 
BswM_PduR_RxIndication ............................................................... 47 
5.2.26 
BswM_PduR_TpRxIndication ........................................................... 47 
5.2.27 
BswM_PduR_TpStartOfReception ................................................... 48 
5.2.28 
BswM_PduR_TpTxConfirmation ...................................................... 48 
5.2.29 
BswM_PduR_Transmit ..................................................................... 49 
5.2.30 
BswM_PduR_TxConfirmation .......................................................... 49 
5.2.31 
BswM_Sd_EventHandlerCurrentState ............................................. 50 
5.2.32 
BswM_Sd_ClientServiceCurrentState .............................................. 50 
5.2.33 
BswM_Sd_ConsumedEventGroupCurrentState ............................... 51 
5.2.34 
BswM_Nm_StateChangeNotification ............................................... 52 
5.2.35 
BswM_RuleControl .......................................................................... 53 
5.2.36 
BswM_WdgM_RequestPartitionReset ............................................. 53 
5.3 
Services Used by BswM .................................................................................. 54 
5.4 
Callback Functions ........................................................................................... 55 
5.5 
Configurable Interfaces .................................................................................... 55 
5.5.1 
Callout Functions ............................................................................. 55 
5.6 
Service Ports ................................................................................................... 56 
2015, Vector Informatik GmbH 
Version: 6.00.00 
6 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.6.1 
BswMSwcModeRequest (R-Port) ..................................................... 56 
5.6.2 
BswMSwcModeNotification (R- Port) ............................................... 56 
5.6.3 
BswMSwitchPort (P- Port) ................................................................ 57 
5.6.4 
BswMRteModeRequestPort (P-Ports) .............................................. 57 
5.6.5 
BswMModeDeclaration .................................................................... 57 
6 
AUTOSAR Standard Compliance............................................................................... 58 
6.1 
Deviations ........................................................................................................ 58 
6.1.1 
Inclusion of the header Com_Types.h .............................................. 58 
6.1.2 
Port Names ...................................................................................... 58 
6.2 
Additions/ Extensions ....................................................................................... 58 
6.2.1 
Optional Interfaces ........................................................................... 58 
6.2.2 
Nm Indication ................................................................................... 59 
6.2.3 
User Condition Functions ................................................................. 59 
6.2.4 
Creation of Mode Declarations ......................................................... 60 
6.2.5 
Timers .............................................................................................. 60 
6.2.6 
Generic Symbolic Values ................................................................. 60 
6.2.7 
Generic Actions ................................................................................ 60 
6.2.8 
Immediate request in BswM_Init() .................................................... 60 
6.2.9 
Mode Handling Forced Immediate ................................................... 60 
6.2.10 
Rule Control ..................................................................................... 60 
6.2.11 
Support of Com ASR3 IPduGroup APIs............................................ 61 
6.3 
Limitations........................................................................................................ 61 
6.3.1 
Configurable interfaces that are not supported ................................. 61 
6.3.1.1 
EcuM Indication for EcuM Flex ...................................... 61 
6.3.2 
Optional Interfaces ........................................................................... 61 
6.3.3 
Configuration Variants ...................................................................... 62 
6.3.4 
BSW Modules .................................................................................. 62 
7 
Glossary and Abbreviations ...................................................................................... 63 
7.1 
Glossary .......................................................................................................... 63 
7.2 
Abbreviations ................................................................................................... 63 
8 
Contact ........................................................................................................................ 65 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
7 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Illustrations 
Figure 2-1 
AUTOSAR Architecture............................................................................. 11 
Figure 2-2 
Interfaces to adjacent modules of the BswM ............................................. 12 
Figure 3-1 
States of the BswM ................................................................................... 16 
Figure 3-2 
Sequence Immediate Processing ............................................................. 18 
Figure 3-3 
Sequence Deferred Mode ......................................................................... 19 
Figure 4-1 
Auto-configured state machines................................................................ 27 
Figure 4-2 
Configure module initialization .................................................................. 28 
Figure 4-3 
Edit initialization order ............................................................................... 29 
Figure 4-4 
Restore default sequence ......................................................................... 29 
Figure 4-5 
Configuration of the features for ECU State Handling ............................... 30 
Figure 4-6 
State Machine of the ECU State Handling ................................................ 31 
Figure 5-1 
Existing callout functions .......................................................................... 55 
Figure 5-2 
Generate prototype of callout functions..................................................... 55 
 
Tables 
Table 1-1 
Component history.................................................................................... 10 
Table 3-1 
Supported AUTOSAR Standard Conform Features .................................. 13 
Table 3-2 
Not Supported AUTOSAR Standard Conform Features ............................ 14 
Table 3-3 
Features Provided Beyond the AUTOSAR Standard ................................ 14 
Table 3-4  
Service IDs ............................................................................................... 21 
Table 3-5 
Errors reported to DET ............................................................................. 21 
Table 4-1 
Static Files ................................................................................................ 24 
Table 4-2 
Dynamic Files ........................................................................................... 24 
Table 5-1 
Type definitions ......................................................................................... 34 
Table 5-2  
BswM_InitMemory .................................................................................... 35 
Table 5-3  
BswM_Init ................................................................................................. 35 
Table 5-4  
BswM_Deinit............................................................................................. 36 
Table 5-5  
BswM_GetVersionInfo .............................................................................. 36 
Table 5-6  
BswM_RequestMode ................................................................................ 37 
Table 5-7  
BswM_ComM_CurrentMode ..................................................................... 37 
Table 5-8  
BswM_ComM_CurrentPNCMode ............................................................. 38 
Table 5-9  
BswM_Dcm_ApplicationUpdated .............................................................. 38 
Table 5-10  
BswM_Dcm_CommunicationMode_CurrentState ..................................... 39 
Table 5-11  
BswM_CanSM_CurrentState .................................................................... 39 
Table 5-12  
BswM_EthSM_CurrentState ..................................................................... 40 
Table 5-13  
BswM_FrSM_CurrentState ....................................................................... 40 
Table 5-14  
BswM_J1939DcmBroadcastStatus ........................................................... 41 
Table 5-15  
BswM_J1939Nm_StateChangeNotification .............................................. 41 
Table 5-16  
BswM_LinSM_CurrentState ...................................................................... 42 
Table 5-17  
BswM_LinSM_CurrentSchedule ............................................................... 42 
Table 5-18  
BswM_LinSM_ScheduleEndNotification ................................................... 43 
Table 5-19  
BswM_LinTp_RequestMode ..................................................................... 43 
Table 5-20  
BswM_EcuM_CurrentState ....................................................................... 44 
Table 5-21  
BswM_EcuM_CurrentWakeup .................................................................. 44 
Table 5-22  
BswM_EcuM_RequestedState ................................................................. 45 
Table 5-23  
BswM_MainFunction ................................................................................ 45 
Table 5-24  
BswM_NvM_CurrentBlockMode ............................................................... 46 
Table 5-25  
BswM_NvM_CurrentJobMode .................................................................. 47 
Table 5-26  
BswM_PduR_RxIndication ....................................................................... 47 
Table 5-27  
BswM_PduR_TpRxIndication ................................................................... 47 
2015, Vector Informatik GmbH 
Version: 6.00.00 
8 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Table 5-28  
BswM_PduR_TpStartOfReception ............................................................ 48 
Table 5-29  
BswM_PduR_TpTxConfirmation ............................................................... 49 
Table 5-30  
BswM_PduR_Transmit ............................................................................. 49 
Table 5-31  
BswM_PduR_TxConfirmation ................................................................... 49 
Table 5-32  
BswM_Sd_EventHandlerCurrentState ...................................................... 50 
Table 5-33  
BswM_Sd_ClientServiceCurrentState ...................................................... 51 
Table 5-34  
BswM_Sd_ConsumedEventGroupCurrentState ....................................... 51 
Table 5-35  
BswM_Nm_StateChangeNotification ........................................................ 52 
Table 5-36  
BswM_RuleControl ................................................................................... 53 
Table 5-37  
BswM_WdgM_RequestPartitionReset ...................................................... 53 
Table 5-38  
Services used by the BswM ...................................................................... 54 
Table 5-39 
User Callout .............................................................................................. 56 
Table 7-1 
Abbreviations ............................................................................................ 64 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
9 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
1  Component History 
The  component  history  gives  an  overview  over  the  important  milestones  that  are 
supported in the different versions of the component. 
 
Component Version  New Features 
1.00.00 
Creation  
1.01.00 
Support of Ethernet components was added 
1.02.00 
Support to NvM.  
1.03.00 
Post-Build loadable support. SWC mode requests support 
2.00.00 
Support of timers and user conditions as request ports 
Generic modes handling extended. 
Initialization automation and preconfigured state machine to emulate the 
behavior of EcuM in ASR 3. 
2.00.01 
Forced Immediate mode handling was added. 
2.01.00 
Support for NM, J1939Nm, J1939Dcm and Service Discovery (Sd), R 
Request Port of type SwcModeRequest, SwcModeNotification support 
immediate request processing and Support of P-Ports 
(BswMRteModeRequestPort). 
3.00.00 
Mode Arbitration algorithm changed (first arbitrate all rules, execute action 
lists afterwards), disabling of rules (Rule Control), support of Com ASR3 
IPduGroup APIs, prioritization of action list execution order. 
4.00.00 
Support for Post-Build selectable and WdgMPartitionReset. 
5.00.00 
Support of LinScheduleEndNotification 
6.00.00 
Support of BswM_EcuM_RequestedState, BswM_PduR_RxIndication, 
BswM_PduR_TpRxIndication, BswM_PduR_TpStartOfReception, 
BswM_PduR_TpTxConfirmation, BswM_PduR_Transmit, 
BswM_PduR_TxConfirmation 
Table 1-1 
Component history 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
10 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
2  Introduction 
This  document  describes  the  functionality, API  and  configuration  of  the AUTOSAR  BSW 
module BswM as specified in [1].  
 
Supported AUTOSAR Release*: 
4 
Supported Configuration Variants: 
pre-compile, post-build, post-build-selectable 
Vendor ID: 
BSWM_VENDOR_ID 
30 decimal 
(= Vector-Informatik, 
according to HIS) 
Module ID: 
BSWM_MODULE_ID   
42 decimal 
(according to ref.[4]) 
* For the precise AUTOSAR Release 4.x please see the release specific documentation.  
 
The  BSW  Mode  Manager  is  the  module  that  implements  the  part  of  the  Vehicle  Mode 
Management and Application Mode Management concept that resides in the BSW.  
Its responsibility is to arbitrate mode requests from application layer SW-Cs or other  
BSW modules based on simple rules, and perform actions based on the arbitration result. 
2.1 
Architecture Overview 
The following figure shows where the BswM is located in the AUTOSAR architecture. 
 
Figure 2-1  AUTOSAR Architecture 
2015, Vector Informatik GmbH 
Version: 6.00.00 
11 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
 
 
The next figure shows the interfaces to adjacent modules of the BswM. These interfaces 
are described in chapter 5. 
 class Architecture
Com
Det
J1939Rm
Dem
J1939Dcm
Nm
ComM
Bsw M
Application
RTE
SchM
Nv M
CanSM
PduR
EcuM
J1939Nm
LinSm
EthSm
LinIf
Dcm
FrSm
Sd
 
Figure 2-2  Interfaces to adjacent modules of the BswM 
2015, Vector Informatik GmbH 
Version: 6.00.00 
12 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
3  Functional Description 
This chapter describes the general function of the BswM. 
3.1 
Features 
The features listed in the following tables cover the complete functionality specified for the 
BswM. 
The AUTOSAR  standard  functionality  is  specified  in  [1]. The  corresponding  features  are 
listed in the tables: 
>  Table 3-1 Supported AUTOSAR Standard Conform Features 
>  Table 3-2 Not Supported AUTOSAR Standard Conform Features 
 
The following features specified in [1] are supported: 
Supported AUTOSAR Standard Conform Features 
CanSM mode arbitration 
ComM mode arbitration 
Dcm mode arbitration 
EcuM mode arbitration 
EthSM mode arbitration 
FrSM mode arbitration 
J1939Dcm mode arbitration 
J1939Nm mode arbitration 
LinSM mode arbitration 
LinTp mode arbitration 
NvM mode arbitration 
Sd mode arbitration 
Application mode arbitration 
I-PDU Group handling (activation/deactivation/deadline monitoring) 
Action to handle PduR routing path groups 
Cascade rule conditions 
Rte Mode Notification and Switches 
Rte Mode Request Interfaces and Ports 
Watchdog Manager 
Post-Build Loadable 
MICROSAR Identity Manager using Post-Build Selectable [9] 
Table 3-1 
Supported AUTOSAR Standard Conform Features 
2015, Vector Informatik GmbH 
Version: 6.00.00 
13 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
3.1.1 
Deviations 
The following features specified in [1] are not supported: 
Not Supported AUTOSAR Standard Conform Features 
Available Action: BswM_TriggerStartUpPhase2 
Available Actions: BswM_TriggerSlaveRTEStop  
Table 3-2 
Not Supported AUTOSAR Standard Conform Features 
See Chapter 6.1 for detailed information about other deviations. 
 
3.1.2 
Additions/ Extensions 
Features Provided Beyond the AUTOSAR Standard 
Timers as mode request ports 
Nm as mode request port 
User conditions as mode request ports 
Generic mode switch as available action 
Timer control as available action 
Creation of user callouts in BswM_Callout_Stubs.c 
Preconfigured State Machines (Communication, Initialization, Service Discovery and ECU State 
Handling) 
Arbitration of rules on initialization values of immediate mode request ports 
Rule Control (deactivation of rules during runtime)  
Prioritization of Action List Execution Order 
Support of ASR3 IPduGroup APIS 
PduR mode request ports 
Table 3-3 
Features Provided Beyond the AUTOSAR Standard 
3.2 
Initialization 
The  BswM  is  initialized  via  the  service  function  BswM_Init  (refer  to  chapter  5.2.2).On 
platforms  in  which  the  Random  Access  Memory  (RAM)  is  not  initialized  to  zero  by  the 
start-up  code  the  function  BswM_InitMemory  has  to  be  called  first  and  then  a  call  to 
BswM_Init can be realized. All available modes are set to the configured initialization 
state, which can either be undefined or set to a specific value. If the initialization state is 
undefined the mode is not arbitrated until the mode request/indication function occurs for 
the first time. 
3.3 
States 
The state machine diagram in Figure 3-1 shows the general handling of the BswM. Each 
state is described as follows: 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
14 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
>  BSWM_INIT 
The BswM is initialized and ready for immediate mode arbitration requests. Deferred mode 
arbitration is done within the cyclically called function BswM_MainFunction. 
 
>  BSWM_WAIT_IMMEDIATE_REQUEST 
In this state the BswM waits for a mode arbitration request. The state is left if immediate 
mode arbitration is requested or when BswM_MainFunction is called. 
 
>  BSWM_MAIN_FUNCTION 
This  state  is  entered  when  the  BswM_MainFunction  is  called.  Within 
BswM_MainFunction the deferred mode arbitration is done. Immediate mode arbitration 
requests which occur during the execution of BswM_MainFunction are queued and will 
be executed at the end of BswM_MainFunction, when all deferred mode arbitration and 
control  is  finished.  Mode  arbitration  requests  of  type  “forced  immediate”  are  not  queued 
and interrupt the deferred mode arbitration. 
 
>  BSWM_MODE_ARBITRATION_AND_CONTROL 
In this state the configured mode rule arbitration is done and the true-/false-action lists are 
executed.  New  mode  arbitration  requests  of  type  “immediate”  are  queued,  arbitration 
requests of type “forced immediate” are arbitrated immediately. 
 
>  BSWM_EMPTY_QUEUE 
In this state the queued mode arbitration requests are executed.  
 
>  BSWM_DEINIT 
This  state  is  entered  when  the  function  BswM_Deinit  is  called.  No  mode  arbitration 
requests are accepted and no mode processing is done. This state can only be left when 
function BswM_Init is called. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
15 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
stm State_Machine
Initial
[BswM_Init]
BSWM_INIT
EntryPoint
BSWM_WAIT_IMMEDIATE_REQUEST
[queue is empty]
[immediate request]
[immediate request]
/queue request
BSWM_MODE_ARBITRATION_AND_CONTROL
BSWM_EMPTY_QUEUE
[queued immediate request]
[BswM_MainFunction]
[Immediate request]
[Immediate finished]
/queue request
[Deferred Request]
[deferred finished]
BSWM_MAIN_FUNCTION
[queued main fct call]
[MainFunctionEnd]
[Immediate Request]
/queue request
[BswM_Deinit]
[BswM_Init]
/stop any mode request arbitration
BSWM_DEINIT
[immediate request] /ignore
[BswM_MainFunction]
/no deferred mode request arbitration
 
Figure 3-1  States of the BswM 
3.4 
Mode Management 
The  BswM  manages  user  defined  modes,  whose  behavior  is  completely  defined  by  its 
configuration. A mode consists of the following parts: 
2015, Vector Informatik GmbH 
Version: 6.00.00 
16 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
>  Mode Source: this is the trigger for the mode arbitration, a trigger can either be an 
application  indication/request  function  or  a  BSW  indication/request  function  or  the 
BswM_MainFunction(). 
>  Mode Arbitration: when the mode source trigger occurs the BswM will arbitrate a 
mode 
specific 
rule 
either 
immediately 
or 
deferred 
within 
the 
BswM_MainFunction().  The  mode  arbitration  types  are  described  in  detail  in 
chapters 3.4.1 and 3.4.3. 
>  Mode  Rule:  a  rule  is  a  logical  Boolean  expression  which  consists  of  specific 
conditions which use different operators. The rule is arbitrated by the BswM to be 
either  true  or  false.  Dependent  on  the  evaluation  result  the  BswM  executes  the 
configured mode action(s) (true-action(s) or false-action(s)). 
>  Mode  Actions:  these  are  either  BSW  service  function  calls,  user  callout  function 
calls  or calls to nested  rules or  action  lists which  are  executed by the BswM after 
the Mode Arbitration. 
 
3.4.1 
Immediate Mode Handling 
The  immediate  mode  arbitration  is  done  directly  upon  the  mode  request/indication 
function.  If  another  mode  request/indication  occurs  during  mode  arbitration  the  BswM 
queues  this  mode  arbitration  request.  The  mode  request  queue  is  emptied  when  the 
current  mode  arbitration  is  finished.  The  sequence  diagram  in  Figure  3-2  shows  this 
procedure. 
 
3.4.2 
Forced Immediate Mode Handling 
The forced immediate mode arbitration is done directly upon the mode request/indication 
function.  The  forced  immediate  request  triggers  immediate  mode  arbitration,  interrupting 
any  other  immediate  mode  arbitration  or  deferred  rule  processing  in  the  main  function. 
This type of mode handling is not queued.  
 
3.4.3 
Deferred Mode Handling 
The  deferred  mode  arbitration  is  done  cyclically  within  the  execution  of  the 
BswM_MainFunction().  If  another  mode  request/indication  occurs  during  mode 
arbitration  the  BswM  queues  this  mode  arbitration  request.  The  mode  request  queue  is 
emptied at the end of the BswM_MainFunction(). The sequence diagram in Figure 3-3 
shows this procedure. 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
17 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Module
Module
BswM
BSW/SWC
Mode Request()
Store Mode Value()
alt 
[deferred request]
Nothing to do for deferred request. Depending rules will be 
arbitrated in BswM_MainFunction
[immediate request and locked semaphore]
Queue Request()
[unlocked sempahore or forced immediate]
After locking semaphore, all new 
Lock Semaphore()
immediate requests will be queued
loop ov er all rules w hich depend on the requested mode
Aribtrate rule and mark resulting action list for execution()
loop ov er marked actionlists
Execute Action Lists()
loop ov er all actions of action list
Call Action()
opt 
Mode Request()
Reentrant mode request call - Will be processed in same way
opt 
[sempahore was locked above]
loop as long as queued request present
Process  Queued Request()
Unlock Semaphore()
After unlocking semaphore, new 
immediate requests will be processed in 
mode request context
 
Figure 3-2  Sequence Immediate Processing 
2015, Vector Informatik GmbH 
Version: 6.00.00 
18 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Module
Module
Module
SchM
BswM
BSW/SWC
After locking semaphore, all new 
immediate requests will be queued
BswM_MainFunction()
Lock Semaphore()
loop ov er all rules w hich depend on a deferred request port
Aribtrate rule and mark resulting action list for execution()
loop ov er marked actionlists
Execute Action Lists()
loop ov er all actions of action list
Call Action()
opt 
Mode Request()

Deferred Request will be arbitrated in next BswM_MainFunction

Immediate Request will be queued

Forced Immediate Request will be processed immediately
opt 
[sempahore was locked above]
loop as long as queued request present
Process  Queued Request()
Unlock Semaphore()
After unlocking semaphore, new 
immediate requests will be processed in 
mode request context
 
Figure 3-3  Sequence Deferred Mode 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
19 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
3.5 
Execution of Action Lists 
The  execution  of  actions  is  done  after  the  rule  arbitration  phase.  Whether  an  action  list 
shall be executed depends on the arbitration result (true or false). There are two ways to 
execute an action list based on evaluation of rules: either it is executed every time the rule 
is evaluated with the corresponding result (so called  conditional execution), or only when 
the  evaluation  result  has  changed  from  the  previous  evaluation  (so  called  triggered 
execution). This execution type is defined via configuration. If arbitration of a rule leads to 
the  execution  of  an  action  list,  this  action  list  is  marked  for  execution. All  marked  action 
lists are executed by their prioritization after the rules have been arbitrated. 
3.6 
Error Handling 
3.6.1 
Development Error Reporting 
By  default,  development  errors  are  reported  to  the  DET  using  the  service 
Det_ReportError()  as  specified  in  [3],  if  development  error  reporting  is  enabled  (i.e. 
pre-compile parameter BSWM_DEV_ERROR_DETECT==STD_ON). 
If  another  module  is  used  for  development  error  reporting,  the  function  prototype  for 
reporting the error can be configured by the integrator, but must have the same signature 
as the service Det_ReportError(). 
The reported BswM ID is 42. 
The  reported  service  IDs  identify  the  services  which  are  described  in  chapter  5.2.  Table 
3-4 presents the service IDs and the related services. 
Service ID 
Service 
BSWM_INITMEMORY_ID 
(0x80) 
BswM_InitMemory() 
BSWM_INIT_ID 
(0x00) 
BswM_Init() 
BSWM_GETVERSIONINFO_ID 
(0x01) 
BswM_GetVersionInfo() 
BSWM_REQUESTMODE_ID 
(0x02) 
BswM_RequestMode() 
BSWM_MAINFUNCTION_ID 
(0x03) 
BswM_MainFunction() 
BSWM_DEINIT_ID 
(0x04) 
BswM_Deinit() 
BSWM_CANSM_CURRENTSTATE_ID 
(0x05) 
BswM_CanSM_CurrentState() 
BSWM_DCM_COMMUNICATION_STATE_ID  (0x06) 
BswM_Dcm_CommunicationMode_CurrentState() 
BSWM_LINSM_CURRENTSTATE_ID 
(0x09) 
BswM_LinSM_CurrentState() 
BSWM_LINSM_CURRENTSCHEDULE_ID 
(0x0A) 
BswM_LinSM_CurrentSchedule() 
BSWM_LINTP_REQUESTMODE_ID 
(0x0B) 
BswM_LinTp_RequestMode() 
BSWM_FRSM_CURRENTSTATE_ID 
(0x0C) 
BswM_FrSM_CurrentState() 
BSWM_ETHSM_CURRENTMODE_ID 
(0x0D) 
BswM_EthSM_CurrentState() 
BSWM_COMM_CURRENTMODE_ID 
(0x0E) 
BswM_ComM_CurrentMode() 
BSWM_ECUM_CURRENTSTATE_ID 
(0x0F) 
BswM_EcuM_CurrentState() 
BSWM_ECUM_CURRENTWAKEUP_ID 
(0x10) 
BswM_EcuM_CurrentWakeup() 
BSWM_WDGM_REQUESTPARTITIONRESET_ID 
BswM_WdgM_RequestPartitionReset() 
 
(0x11) 
BSWM_DCM_APPLICATION_UPDATED_ID  (0x14) 
BswM_Dcm_ApplicationUpdated() 
BSWM_COMM_PNC_CURRENTMODE_ID  (0x15) 
BswM_ComM_CurrentPNCMode() 
2015, Vector Informatik GmbH 
Version: 6.00.00 
20 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Service ID 
Service 
BSWM_NVM_CURRENTBLOCKMODE_ID 
(0x16) 
BswM_NvM_CurrentBlockMode() 
BSWM_NVM_CURRENTJOBMODE_ID  
(0x17) 
BswM_NvM_CurrentJobMode() 
BSWM_J1939NM_STATE_ID 
(0x18) 
BswM_J1939Nm_StateChangeNotification() 
BSWM_J1939DCM_BROADCASTSTATUS_ID (0x1b) 
BswM_J1939DcmBroadcastStatus() 
BSWM_SD_CLIENTSERVICE_CURRENT_ID (0x1f) 
BswM_Sd_ClientServiceCurrentState() 
BSWM_SD_EVENTHANDLER_CURRENT_ID (0x20) 
BswM_Sd_EventHandlerCurrentState() 
BSWM_SD_CONSUMEDEVENTGROUP_ID  (0x21) 
BswM_Sd_ConsumedEventGroupCurrentState() 
BSWM_ECUM_REQUESTEDSTATE_ID 
(0x23) 
BswM_EcuM_RequestedState() 
BSWM_NM_STATE_CHANGE_ID 
(0x81) 
BswM_Nm_StateChangeNotification() 
BSWM_SWCNOTIFICATION_ID 
(0x82) 
BswM_Notification_<SWC Notification Name> 
BSWM_SWCREQUESTMODE_ID 
(0x83) 
BswM_Read_<SWC Mode Request Name> 
BSWM_SETRULESTATE_ID 
(0x84) 
BswM_RuleControl() 
BSWM_LINSM_SCHEDULEENDNOTIFICATION_ID
BswM_LinSM_ScheduleEndNotification() 
 
(0x85) 
BSWM_PDUR_RXINDICATION_ID 
(0x86) 
BswM_PduR_RxIndication() 
BSWM_PDUR_TPRXINDICATION_ID 
(0x87) 
BswM_PduR_TpRxIndication() 
BSWM_PDUR_TPSTARTOFRECEPTION_ID  (0x88) 
BswM_PduR_TpStartOfReception() 
BSWM_PDUR_TPTXCONFIRMATION_ID 
(0x89) 
BswM_PduR_TpTxConfirmation() 
BSWM_PDUR_TRANSMIT_ID 
(0x8A) 
BswM_PduR_Transmit() 
BSWM_PDUR_TXCONFIRMATION_ID 
(0x8B) 
BswM_PduR_TxConfirmation() 
Table 3-4   Service IDs  
 
The errors reported to DET are described in the following table: 
Error Code 
Description 
0x01 
BSWM_E_NO_INIT 
Service function is called while BswM is not initialized. 
0x02 
BSWM_E_NULL_POINTER 
Service function is called with a null pointer as an 
argument. 
0x03 
BSWM_E_PARAM_INVALID 
The given parameter is invalid. 
0x04 
BSWM_E_REQ_USER_OUT_OF_RANGE 
A requesting user is out of range. 
0x05 
BSWM_E_REQ_MODE_OUT_OF_RANGE  A requested mode is out of range. 
0x06 
BSWM_E_PARAM_CONFIG 
The provided configuration is inconsistent. 
0xA0 
BSWM_E_ALREADY_QUEUED 
An immediate request was made before the last 
request of the same port was processed. 
In most cases this error occurs due to an incorrect 
configuration, i.e. port shall be arbitrated on its 
initialization value of port but initialization value of rule 
is incorrect. If configuration is correct and loss of the 
earlier mode request is acceptable, this error can be 
ignored for this port. Otherwise, processing of port 
can be changed to BSWM_FORCED_IMMEDIATE. 
Table 3-5 
Errors reported to DET 
2015, Vector Informatik GmbH 
Version: 6.00.00 
21 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
3.6.2 
Production Code Error Reporting 
By  default,  production  code  related  errors  are  reported  to  the  DEM  using  the  service 
Dem_ReportErrorStatus() as specified in [5]. 
 
The module BswM does not report any DEM error itself. However, it can be configured that 
an action member of an action list reports a DEM error when it fails.  
2015, Vector Informatik GmbH 
Version: 6.00.00 
22 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
4  Integration 
This chapter gives necessary information for the integration of the MICROSAR BswM into 
an application environment of an ECU. 
4.1 
Scope of Delivery 
The  delivery  of  the  BswM  contains  the  files  which  are  described  in  chapters  4.1.1  and 
4.1.2: 
 
4.1.1 
Static Files 
File Name 
Source 
Object 
Description 
Code 
Code 
Delivery  Delivery 
BswM.c 
This is the source file of the BswM. It contains the 
initialization function, the deinitialization function, the 
 
 
cyclic main function and all the BSW mode indication 
functions. 
BswM.h 
This is the header file of the BswM. It contains the 
 
 
interfaces to the BswM API functions. 
BswM_CanSM.h 
This header file contains the prototypes of the callback 
 
 
functions of the CAN State Manager. 
BswM_ComM.h 
This header file contains the prototypes of the callback 
 
 
functions of the Communication Manager. 
BswM_Dcm.h 
This header file contains the prototypes of the callback 
 
 
functions of the Diagnostic Communication Manager. 
BswM_EcuM.h 
This header file contains the prototypes of the callback 
 
 
functions of the Electronic Control Unit State Manager. 
BswM_EthSm.h 
This header file contains the prototypes of the callback 
 
 
functions of the Ethernet State Manager. 
BswM_FrSM.h 
This header file contains the prototypes of the callback 
 
 
functions of the FlexRay State Manager. 
BswM_J1939Dc
This header file contains the prototypes of the callback 

m.h
 
 
 
functions of the J1939Dcm module. 
BswM_J1939Nm
This header file contains the prototypes of the callback 

.h
 
 
 
functions of the J1939Nm module. 
BswM_LinSM.h 
This header file contains the prototypes of the callback 
 
 
functions of the LIN State Manager. 
BswM_LinTp.h 
This header file contains the prototypes of the callback 
 
 
functions of the LIN Transport Protocol. 
BswM_Nm.h 
This header file contains the prototypes of the callback 
 
 
functions of the Network Manager. 
BswM_NvM.h 

This header file contains the prototypes of the callback 
 
 
functions of the Non Volatile Random-access memory 
2015, Vector Informatik GmbH 
Version: 6.00.00 
23 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
File Name 
Source 
Object 
Description 
Code 
Code 
Delivery  Delivery 
Manager. 
BswM_PduR.h 
This header file contains the prototypes of the callback 
 
 
functions of the Pdu Router module. 
BswM_Sd.h 
This header file contains the prototypes of the callback 
 
 
functions of the Service Discovery module. 
BswM_WdgM.h 
This header file contains the prototypes of the callback 
 
 
functions of the Watchdog Manager module. 
Table 4-1 
Static Files 
 
4.1.2 
Dynamic Files 
The dynamic files are generated by the configuration tool. 
File Name 
Description 
BswM_Lcfg.c 
This file contains the configuration parameters for pre-compile and for post-
build variant.  
BswM_Cfg.h 
This header file contains general and configuration definitions for pre-compile 
and post-build variant. 
BswM_Private_ This file contains the necessary includes and the declarations of libraries and 
Cfg.h 
variables used by the BswM. 
BswM_PBcfg.c  This file contains the variables used for mode arbitration in post-build variant. 
BswM_Callout_ This file contains the definitions of the call back functions which were 
Stubs.c 
configured to be created. 
Table 4-2 
Dynamic Files 
4.2 
Initialization of Other Software Modules 
The  BswM  is  able  to  initialize  software  components  through  User  Callout  functions. The 
BswM can realize the initialization after the EcuM has finished its “post OS sequence”, in 
which it initializes the operating system, the Schedule Manager and the BswM.  
4.2.1 
Using the Basic Editor 
In order to configure the BswM to initialize other modules: 
  Create “Actions” of type “User Callout” which contain the initialization functions. 
  Create an “Action List” which contains the before mentioned “User Callout” actions. 
  Click on the container “BswMModeControl”, to make the “Init Action List Reference” 
visible. 
  Add a reference to the action list that contains the initialization callouts of the other 
modules. 
  These actions will be called at the end of BswM_Init. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
24 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
 
 
Caution 
It  is  important  that  the  execution  of  the  initialization  is  not  interrupted  by  any 
  other  main  function.  The  initialization  of  all  the  configured  modules  should  be 
concluded before any other function is called.  
 
 
 
Illustratively, a list of initialization functions is listed below, as exemplified in the Guide to 
Mode  Management  [2]  (This  guide  can  be  also  consulted for  further  Mode  management 
information).  Note  that  this  list  is  not  complete  and  depends  on  the  BSW  modules  you 
have in your delivery. 
 
 
Initialization of basic drivers to access the NVRAM: 
 Spi_Init(NULL_PTR); 
 Eep_Init(NULL_PTR); 
 Fls_Init(NULL_PTR); 
 NvM_Init(NULL_PTR); 
 NvM_ReadAll(); 
 
After  the  NvM_ReadAll()  job  is finished  the  initialization  of  the  remaining modules  can 
continue: 
 Can_Init(NULL_PTR); 
 CanIf_Init(NULL_PTR); 
 CanSM_Init(NULL_PTR); 
 CanTp_Init(NULL_PTR); 
 Lin_Init(NULL_PTR); 
 LinIf_Init(NULL_PTR); 
 LinSM_Init(NULL_PTR); 
 LinTp_Init(NULL_PTR); 
 Fr_Init(NULL_PTR); 
 FrIf_Init(NULL_PTR); 
 FrSm_Init(NULL_PTR); 
 FrTp_Init(NULL_PTR); 
 StbM_Init(); 
 PduR_Init(NULL_PTR); 
 CanNm_Init(NULL_PTR); 
 LinNM_Init(NULL_PTR); 
 FrNm_Init(NULL_PTR); 
 Nm_Init(NULL_PTR); 
2015, Vector Informatik GmbH 
Version: 6.00.00 
25 / 65 
based on template version 4.11.3 


Technical Reference Basic Software Mode Manager 
 IpduM_Init(NULL_PTR); 
 Com_Init(NULL_PTR); 
 ComM_Init(NULL_PTR); 
 Dcm_Init(NULL_PTR); 
 Dem_Init(NULL_PTR); 
 RteStart(); 
 
Note  that  when  in  Post-Build  variant,  the  previous  initialization  functions  could  contain 
post-build specific parameters. For detailed information  see document  [7],  chapter:  BSW 
Module Initialization, which summarizes the steps required to initialize post-build loadable 
BSW modules. 
 
 
Caution 
Note that the parameters of the initialization functions used in the example may differ 
  from the actual expected parameters of the corresponding modules depending on the 
configuration. Please refer to the Technical Reference of each module for the proper 
initialization call. 
 
 
4.2.2 
Using the Comfort View 
In  order  to  facilitate  the  configuration  of  the  initialization  of  other  modules,  the  “Auto 
Configuration: Module Initialization” can be used. For further information see chapters 4.3 
and 4.3.1. 
4.3 
Support of Preconfigured State Machines (Auto-Configuration) 
The BswM supports preconfigured state machines. The content of these state machines is 
based on the currrent configuration. The state machines can be activated and modified by 
the user. They can be found in the “Mode Management” view of the DaVinci Configurator 5 
Pro. To make use of the auto configured state machines: 
1.  In the configuration editor click on “Mode Management”. 
2.  Open “BSW Management” window. 
3.  Click on “Auto Configuration: <Name of the State Machine>”.   
4.  Click on the link “Configure Module Initialization” to start configuring. 
 
 
 
Caution 
Created Rules, Actions, Conditions, etc. are only an advice and may be edited by the 
  integrator. 
 
 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
26 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
 
Figure 4-1  Auto-configured state machines 
4.3.1 
Initialization 
The BswM has knowledge of how to initialize several modules: which function to call, with 
which  parameters  and  which  header  to  include. These  modules  are  listed  in  the  “known 
modules” list. However, the preconfigured initialization functions and include headers can 
be changed/adapted by the integrator. 
 
The  “foreign  modules”  list  contains  modules  unknown  to  the  BswM.  An  initialization 
function  and  an  include  header  are  suggested,  but  it  is  necessary  to  assure  the 
correctness of the preconfigured parameters and adapt them in case it is necessary. The 
foreign modules will be initialized after the known modules by default. 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
27 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
 
Figure 4-2  Configure module initialization 
The  list  of  modules  shows  them  in  alphabetical  order.  But  the  initialization  function  calls 
are  generated  according  to the  internal  logic  of  the  generator.  In order  to  see  the  actual 
order  in  which  the  functions  will  be  generated,  click  on  Auto  Configuration:  Module 
Initialization -> Action Lists-> INIT_AL_Initialize. 
A list of items is shown in the order in which they are generated. The order of the items 
can be changed manually. 
 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
28 / 65 
based on template version 4.11.3 


Technical Reference Basic Software Mode Manager 
 
Figure 4-3  Edit initialization order 
If the module initialization is edited with the configuration window again, the default order 
of the items will be restored and the changes previously made in the action list items order 
will be lost. 
 
To  avoid  changing  the  already  edited  action  list  items  order,  it  is  necessary  to  clear  the 
“Restore Default Sequence” checkbox when configuring again.   
 
 
Figure 4-4  Restore default sequence 
4.3.2 
ECU State Handling 
The  BswM  is  able  to  create  rules  and  actions  which  take  care  of  starting  and  shutting 
down the ECU. This behavior is similar to EcuM in ASR 3. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
29 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
 
Figure 4-5  Configuration of the features for ECU State Handling 
The  following  features  can  be  activated:  DEM  initialization  and  shut-down  generation, 
enabling and disabling of ComM communication, activation of NvM handling, notifications 
of the RTE about mode changes and transition call outs are enabled. 
 
Furthermore, the number of users that request run request and post-run request and the 
period of time that the state machine spends in the run mode state can be configured.  
 
The state machine of the ECU state Handling is illustrated in Figure 4-6  State  Machine  of 
the ECU State Handling 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
30 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
 stm AutoConfiguration: Ecu State Handling
Initial
[No Nv M indication pending,
RUN
STARTUP
Nv M_CancelWriteAllTimer is expired]
/Enable communication
Init
Dem_Init
Run
Start Self Run Request Timer
[No run request and no
[Run requested or v alid
communication in all channels]
w ake-up ev ent]
/Disable Communication
/Enable communication
EcuM_ClearValidatedWakeupEv ent
WAKEUP
POSTRUN
WakeUp
PostRun
[postrun request ==  released]
/Dem_Shutdow n()
SHUTDOWN
[NO Wakeup w as v alid]
Prepare Shutdown
[Valid w akeup ev ent]
/Stop WriteAllTimer
Start CancelWriteAllTimer
Nv M_CancelWriteAll
[RTE mode notification]
Sleep - "Virtual"
Wait for NvM
/Nv M w rite All
Start Nv M_WriteAllTimer
[No Nv M indication pending or
the Nv M_WriteAllTimer is
expired]
/EcuM_GoPoll
EcuM_GoHalt
Shutdown "virtual"
[No Nv M indication pending or the Nv M_WriteAllTimer is expired]
/WriteAllTimer_Stop
EcuM_GoDow n
 
Figure 4-6  State Machine of the ECU State Handling 
 
4.3.3 
Communication Control 
The BswM is able to create rules and actions which take care of starting and stopping the 
communication of an ECU.  
The features supported by the auto configuration of the Communication Control are: 
2015, Vector Informatik GmbH 
Version: 6.00.00 
31 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
>  Configuration I-PDU groups switching of CAN, ETH, LIN, FR and J1939 as long as 
the I-PDUs belong to only one channel.  
  In case the I-PDU Group has I-PDUs from different channels, it will be listed 
as “Not available” and the configuration has to be realized manually. 
>  Reinitialization of transmission (TX) and reception (RX) I-PDUs is possible.  
  In  case  of  CAN,  the  reinitialization  will  only  be  performed  in  the  Bus  State 
transition from NO_COM to FULL _COM, in case of BUS_OFF or SILENT no 
reinitialization will be performed. 
>  Enabling and disabling of the NM for CAN, ETH and FlexRay bus, if NM is present 
in that channel.  
>  Consideration  of  the  DCM  Modes  when  switching  I-PDU  Groups  that  belong  to 
CAN, ETH or to FlexRay bus. 
>  Consideration of selected Nm States when switching TX I-PDU Groups that belong 
to a CAN bus. 
>  Configuration of Partial Networking (PNC) is supported for CAN, ETH and FlexRay 
bus. 
  If a I-PDU Group can be assigned to a PNC, the I-PDU Group is listed as a 
sub feature of the corresponding PNC and it is switched on or off depending 
on the PNC Status.  
  Consider  that  the  PCN  can  only  be  determined  if  there  are  PNC-Mapping 
entries in the System-Description. 
>  Configuration of the J1939 module. 
  Standard rules will be configured which  consider the state of the J1939Nm 
for the rule condition. As action lists the states of the modules J1939Dcm and 
J1939Rm are set. 
   The  I-PDU  Groups  which  contains  only  I-PDUs  of  the  same  Node  will  be 
switched on or off depending on the Node status. 
  The  I-PDU  Groups  which  are  determined  as  broadcast  groups  will  be 
switched on or off depending on the Dcm broadcast status. 
  Enabling and disabling of Routing-Pathes in PduR depending on the channel 
and node state. 
 
>  Switching of LIN I-PDU groups.  
  The I-PDU Groups which contains only I-PDUs of the same Schedule will be 
switched on or off depending on the schedule status. 
  Setting a start schedule table. 
  
2015, Vector Informatik GmbH 
Version: 6.00.00 
32 / 65 
based on template version 4.11.3 

Technical Reference Basic Software Mode Manager 
4.3.4 
Service Discovery Control 
The  BswM  is  able  to  create  the  necessary  ports  to  control  the  Service  Discovery  by 
application. 
The  auto  configuration,  which  is  only  available  if  the  Sd  module  is  in  the  current 
configuration, supports the following features: 
>  Creation  of  a  BswMSwitchPort  (P-  Port)  for  each  selected  SdClientService, 
SdEventHandler or SdConsumedEventGroup to provide its state to the application. 
>  Creation  of  a  BswMSwcModeRequest  (R-Port)  for  each  selected  SdClientService, 
SdServerService or SdConsumedEventGroup to catch the request from application 
and forward it to the Sd. 
4.4 
Critical Sections 
The BswM has code sections which must not be interrupted by incoming mode requests. 
Therefore the BswM uses one exclusive area which requires a global interrupt lock: 
BSWM_EXCLUSIVE_AREA_0 
The  main  functions  of  the  BSW  modules  that  use  BswM  to  provide  mode  indications 
should not interrupt each other.  
 
 
 
Note 
Refer to [6] for details about exclusive areas. 
 
 
 
 
4.5 
Cyclic Task 
The  BswM  has  one  cyclic  main  function  BswM_MainFunction()  which  must  be  called 
cyclically  if  either  a  deferred  mode  request  port  exists,  a  timer  is  used  or  a  RTE  mode 
switch action is configured. The cyclic time is up to the user but  must  be considered for 
deferred mode handling. 
 
4.6 
NvM – BswM configuration 
When configuring NvM request ports in BswM it is necessary that the general configuration 
of the NvM has the necessary boxes checked. 
 
In NvMCommon check the box: “Multiblock Job status Information” 
In NVMConfigBlock check the box “Block status information” 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
33 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5  API Description 
For an interfaces overview please see Figure 2-2. 
5.1 
Type Definitions 
The types defined by the BswM are described in this chapter. 
Type Name 
C-Type 
Description 
Value Range 
BswM_ConfigType 
struct  
Used for the pointers of 
 
 
post-build configurations 
during the initialization of 
the BswM. 
In pre-compile, it is not 
used. 
BswM_ModeType 
uint16 
Data type that identifies 
0 … 65535  
the modes that can be 
Used if the total number of 
requested by BswM 
modes is greater than 255. 
Users 
BswM_UserType 
uint16 
Data type that identifies a  0 … 65535  
BswM User that makes 
Used if the total number of 
mode requests to the 
users is greater than 255. 
BswM. 
BswM_HandleType 
uint8 / uint16  Data type which is used 
0 … 65535  
for action list and rule IDs.  Depends on number of action 
lists and rules. 
Table 5-1 
Type definitions 
2015, Vector Informatik GmbH 
Version: 6.00.00 
34 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2 
Services Provided by BswM 
5.2.1 
BswM_InitMemory 
Prototype 
void BswM_InitMemory (void) 
Parameter 
None 
- 
Return code 
void 
- 
Functional Description 
Initializes the BSW Mode Manager module variables in case an initializing startup code is not used. This 
function sets the BswM into an uninitialized state. 
Particularities and Limitations 
>  If this function is used it shall be called before any other BSWM function after startup. 
>  This function is synchronous. 
>  This function is non-reentrant. 
Call Context 
>  This function can be called from task context. 
Table 5-2   BswM_InitMemory 
5.2.2 
BswM_Init 
Prototype 
void BswM_Init (const BswM_ConfigType *ConfigPtr) 
Parameter 
ConfigPtr 
Pointer to post-build configuration data. For the pre-compile case a NULL 
pointer shall be used. 
Return code 
void 
- 
Functional Description 
Initializes the BSW Mode Manager. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is non-reentrant. 
Call Context 
>  This function can be called from task context. 
Table 5-3   BswM_Init 
2015, Vector Informatik GmbH 
Version: 6.00.00 
35 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.3 
BswM_Deinit 
Prototype 
void BswM_Deinit (void) 
Parameter 
None 
- 
Return code 
void 
- 
Functional Description 
Deinitializes the BSW Mode Manager. All pending requests are cleared and no further mode requests are 
accepted by the BswM. This state can only be left by calling the function BswM_Init(). 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is non-reentrant. 
Call Context 
>  This function can be called from task context. 
Table 5-4   BswM_Deinit 
5.2.4 
BswM_GetVersionInfo 
Prototype 
void BswM_GetVersionInfo (Std_VersionInfoType *VersionInfo) 
Parameter 
VersionInfo 
Pointer to address where the version information shall be copied to. 
Return code 
void 
None 
Functional Description 
Returns the version information of this module.  
The versions are BCD-coded. 
Particularities and Limitations 
>  The caller must ensure to allocate a variable of the type Std_VersionInfoType before the function call. 
>  This function is synchronous. 
>  This function is reentrant. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-5   BswM_GetVersionInfo 
2015, Vector Informatik GmbH 
Version: 6.00.00 
36 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.5 
BswM_RequestMode 
Prototype 
void BswM_RequestMode (BswM_UserType requesting_user, 
 
BswM_ModeType requested_mode) 
Parameter 
requesting_user 
The user that requests the mode. 
requested_mode 
The requested mode. 
Return code 
void 
- 
Functional Description 
Generic function call to request modes. This function shall only be used by other BSW modules that do not 
have a specific mode request interface and/or for generic mode requests. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different users. 
>  This function is only allowed to be used by applications for generic mode requests. Otherwise, 
applications must not use this function. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-6   BswM_RequestMode 
5.2.6 
BswM_ComM_CurrentMode 
Prototype 
void BswM_ComM_CurrentMode ( 
NetworkHandleType Network, 
 
ComM_ModeType RequestedMode) 
Parameter 
Network 
The ComM communication channel that the indicated state corresponds to. 
RequestedMode 
The current state of the ComM communication channel 
Return code 
void 
- 
Functional Description 
Function called by ComM to indicate the current communication mode of a ComM channel. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  Must only be called by the ComM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-7   BswM_ComM_CurrentMode 
2015, Vector Informatik GmbH 
Version: 6.00.00 
37 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.7 
BswM_ComM_CurrentPNCMode 
Prototype 
void BswM_ComM_CurrentPNCMode ( 
PNCHandleType PNC, 
 
ComM_PncModeType RequestedMode) 
Parameter 
PNC 
The handle of the PNC for which the current state is reported. 
RequestedMode 
The current mode of the PNC. 
Return code 
void 
- 
Functional Description 
Function called by ComM to indicate the current mode of the PNC. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different PNCs. 
>  Must only be called by the ComM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-8   BswM_ComM_CurrentPNCMode 
5.2.8 
BswM_Dcm_ApplicationUpdated 
Prototype 
void BswM_Dcm_ApplicationUpdated (void) 
Parameter 
None 
- 
Return code 
void 
- 
Functional Description 
Function called by DCM to inform the BswM that the application has being updated. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant. 
>  Must only be called by the Dcm. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-9   BswM_Dcm_ApplicationUpdated 
2015, Vector Informatik GmbH 
Version: 6.00.00 
38 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.9 
BswM_Dcm_CommunicationMode_CurrentState 
Prototype 
void BswM_Dcm_CommunicationMode_CurrentState 
(NetworkHandleType Network, Dcm_CommunicationModeType RequestedMode) 
Parameter 
Network 
The communication channel that the diagnostic mode corresponds to. 
RequestedMode 
The requested diagnostic communication mode. 
Return code 
void 
- 
Functional Description 
Function called by DCM to inform the BswM about the current state of the communication mode. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  Must only be called by the Dcm. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-10   BswM_Dcm_CommunicationMode_CurrentState 
5.2.10  BswM_CanSM_CurrentState 
Prototype 
void BswM_CanSM_CurrentState ( NetworkHandleType Network, 
 
CanSM_BswMCurrentStateType CurrentState) 
Parameter 
Network 
The CAN channel that the indicated state corresponds to. 
CurrentState 
The current state of the CAN channel. 
Return code 
void 
- 
Functional Description 
Function called by CanSM to indicate its current state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  Must only be called by the CanSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-11   BswM_CanSM_CurrentState 
2015, Vector Informatik GmbH 
Version: 6.00.00 
39 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.11  BswM_EthSM_CurrentState 
Prototype 
void BswM_EthSM_CurrentState ( NetworkHandleType Network, 
 
EthSM_NetworkModeStateType CurrentState) 
Parameter 
Network 
The Ethernet channel that the indicated state corresponds to. 
CurrentState 
The current state of the Ethernet channel. 
Return code 
void 
- 
Functional Description 
Function called by EthSM to indicate its current state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  Must only be called by the EthSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-12   BswM_EthSM_CurrentState 
5.2.12  BswM_FrSM_CurrentState 
Prototype 
void BswM_FrSM_CurrentState ( NetworkHandleType Network, 
 
FrSM_BswM_StateType CurrentState) 
Parameter 
Network 
The FlexRay cluster that the indicated state corresponds to. 
CurrentState 
The current state of the FlexRay cluster. 
Return code 
void 
- 
Functional Description 
Function called by FrSM to indicate its current state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by the FrSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-13   BswM_FrSM_CurrentState 
2015, Vector Informatik GmbH 
Version: 6.00.00 
40 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.13  BswM_J1939DcmBroadcastStatus 
Prototype 
void BswM_J1939DcmBroadcastStatus ( uint16 NetworkMask) 
Parameter 
NetworkMask 
Mask  containing  one  bit  for  each  available  network.  1:Network enabled  
0: Network disabled. 
Return code 
void 
- 
Functional Description 
This  API  tells  the  BswM  the  desired  communication  status  of  the  available networks. The status will 
typically be activated via COM I-PDU group switches. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is non-reentrant. 
>  This function must only be called by the J1939Dcm. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-14   BswM_J1939DcmBroadcastStatus 
5.2.14  BswM_J1939Nm_StateChangeNotification 
Prototype 
void BswM_J1939Nm_StateChangeNotification ( NetworkHandleType Network, 
 
uint8 Node, Nm_StateType NmState) 
Parameter 
Network 
Identification of the J1939 channel. 
Node 
Identification of the J1939 node 
NmState 
Current (new) state of the J1939 node 
Return code 
void 
- 
Functional Description 
Notification of current J1939Nm state after state changes. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different combinations of network and node. 
>  This function must only be called by the J1939Nm. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-15   BswM_J1939Nm_StateChangeNotification 
2015, Vector Informatik GmbH 
Version: 6.00.00 
41 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.15  BswM_LinSM_CurrentState 
Prototype 
void BswM_LinSM_CurrentState ( NetworkHandleType Network, 
 
LinSM_ModeType CurrentState) 
Parameter 
Network 
The LIN channel that the indicated state corresponds to. 
CurrentState 
The current state of the LIN channel. 
Return code 
void 
- 
Functional Description 
Function called by LinSM to indicate its current state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by the LinSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-16   BswM_LinSM_CurrentState 
5.2.16  BswM_LinSM_CurrentSchedule 
Prototype 
void BswM_LinSM_CurrentSchedule ( NetworkHandleType Network, 
 
LinIf_SchHandleType CurrentSchedule) 
Parameter 
Network 
The LIN channel that the indicated schedule corresponds to. 
CurrentSchedule 
The currently active schedule table of the LIN channel. 
Return code 
void 
- 
Functional Description 
Function called by LinSM to indicate its current schedule. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by the LinSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-17   BswM_LinSM_CurrentSchedule 
2015, Vector Informatik GmbH 
Version: 6.00.00 
42 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.17  BswM_LinSM_ScheduleEndNotification 
Prototype 
void BswM_LinSM_ScheduleEndNotification (NetworkHandleType Network, 
 
LinIf_SchHandleType Schedule) 
Parameter 
Network 
The LIN channel that the indicated schedule corresponds to. 
Schedule 
The schedule table of the LIN channel wich has ended. 
Return code 
void 
- 
Functional Description 
Function called by LinSM to notify the end of a schedule. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by the LinSM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-18   BswM_LinSM_ScheduleEndNotification 
5.2.18  BswM_LinTp_RequestMode 
Prototype 
void BswM_LinTp_RequestMode ( NetworkHandleType Network, 
 
LinTp_Mode LinTpRequestedMode) 
Parameter 
Network 
The LIN channel that the LIN TP mode request corresponds to. 
LinTpRequestedMode 
The requested LIN TP mode. 
Return code 
void 
- 
Functional Description 
Function called by LinTp to request a mode for the corresponding LIN channel. The LinTp_Mode mainly 
correlates to the LIN schedule table that should be used. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by the LinTp. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-19   BswM_LinTp_RequestMode 
2015, Vector Informatik GmbH 
Version: 6.00.00 
43 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.19  BswM_EcuM_CurrentState 
Prototype 
void BswM_EcuM_CurrentState (EcuM_StateType CurrentState) 
Parameter 
CurrentState 
The requested ECU Operation Mode 
Return code 
void 
- 
Functional Description 
Function called by EcuM to indicate the current ECU Operation Mode. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is non-reentrant. 
>  Must only be called by the EcuM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-20   BswM_EcuM_CurrentState 
5.2.20  BswM_EcuM_CurrentWakeup 
Prototype 
void BswM_EcuM_CurrentWakeup ( EcuM_WakeupSourceType source, 
 
EcuM_WakeupStateType state) 
Parameter 
source 
Wakeup source(s) that changed state. 
state 
The new state of the wakeup source(s). 
Return code 
void 
- 
Functional Description 
Function called by EcuM to indicate the current state of a wakeup source. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different sources. 
>  Must only be called by the EcuM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-21   BswM_EcuM_CurrentWakeup 
2015, Vector Informatik GmbH 
Version: 6.00.00 
44 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.21  BswM_EcuM_RequestedState 
Prototype 
void BswM_ EcuM_RequestedState ( EcuM_StateType State, 
 
EcuM_RunStatusType CurrentStatus) 
Parameter 
State 
The requested state by EcuMFlex. 
CurrentStatus 
The new result of the Run Request Protocol. 
Return code 
void 
- 
Functional Description 
Function called by EcuM to indicate the request of a run request protocol state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different states. 
>  Must only be called by the EcuM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-22   BswM_EcuM_RequestedState 
5.2.22  BswM_MainFunction 
Prototype 
void BswM_MainFunction (void) 
Parameter 
None 
- 
Return code 
void 
- 
Functional Description 
Main function of the BswM. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is non-reentrant. 
>  This function must be called with the configured cycle time by the SchM [6]. 
Call Context 
>  This function can be called from task context. 
Table 5-23   BswM_MainFunction 
2015, Vector Informatik GmbH 
Version: 6.00.00 
45 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.23  BswM_NvM_CurrentBlockMode 
Prototype 
void BswM_NvM_CurrentBlockMode(NvM_BlockIdType Block, 
 
NvM_RequestResultType CurrentBlockMode) 
Parameter 
Block 
The Block that the new NvM Mode corresponds to. 
CurrentBlockMode 
The current block mode of the NvM block. 
Return code 
void 
- 
Functional Description 
Function  called  by  NvM  to  indicate  the  current  block  mode  of  an  NvM  block. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different blocks. 
>  This function must only be called by NvM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-24   BswM_NvM_CurrentBlockMode 
5.2.24  BswM_NvM_CurrentJobMode 
Prototype 
void BswM_NvM_CurrentJobMode(uint8 ServiceId, 
 
NvM_RequestResultType CurrentJobMode) 
Parameter 
ServiceId 
Indicates  whether  the  callback  refers  to  multi  block  services  
NvM_ReadAll or NvM_WriteAll. 
CurrentJobMode 
Current  state  of  the  multi  block  job  indicated  by  parameter  
ServiceId. 
Return code 
void 
- 
Functional Description 
Function called by NvM to inform the BswM about the current state of a multi block job. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different services. 
>  This function must only be called by NvM. 
Call Context 
>  This function can be called from task and interrupt context. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
46 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Table 5-25   BswM_NvM_CurrentJobMode 
5.2.25  BswM_PduR_RxIndication 
Prototype 
void BswM_PduR_RxIndication(PduIdType RxPduId, 
 
const PduInfoType *PduInfoPtr) 
Parameter 
RxPduId 
The PduR ID of received PDU. 
PduInfoPtr 
Pointer which stores all informations about the PDU. Not used by current 
implementation. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about a received PDU. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for a RxPduId which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-26   BswM_PduR_RxIndication 
5.2.26  BswM_PduR_TpRxIndication 
Prototype 
void BswM_PduR_TpRxIndication(PduIdType id, Std_ReturnType result) 
Parameter 
id 
The PduR ID of received PDU. 
result 
Result of the reception. Not used by current implementation. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about a received TP PDU. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for an id which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-27   BswM_PduR_TpRxIndication 
2015, Vector Informatik GmbH 
Version: 6.00.00 
47 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.27  BswM_PduR_TpStartOfReception 
Prototype 
void BswM_PduR_TpStartOfReception ( PduIdType id, PduInfoType *info, 
 
PduLengthType TpSduLength,PduLengthType *bufferSizePtr) 
Parameter 
id 
The PduR ID of received PDU. 
 
info 
Pointer which stores all informations about the PDU. Not used by current 
implementation. 
TpSduLength 
Total length of the I-PDU to be received. Not used by current implementation. 
bufferSizePtr 
Pointer to the receive buffer. Not used by current implementation. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about the start of TP PDU Reception. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for an id which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-28   BswM_PduR_TpStartOfReception 
5.2.28  BswM_PduR_TpTxConfirmation 
Prototype 
void BswM_PduR_TpTxConfirmation(PduIdType id, Std_ReturnType result) 
Parameter 
id 
The PduR ID of sent TP PDU. 
result 
Result of the transmission. Not used by current implementation. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about a sent TP PDU. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for an id which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
48 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Table 5-29   BswM_PduR_TpTxConfirmation 
5.2.29  BswM_PduR_Transmit 
Prototype 
void BswM_PduR_Transmit( PduIdType id, const PduInfoType *PduInfoPtr) 
Parameter 
id 
The PduR ID of PDU to transmit. 
PduInfoPtr 
Pointer which stores all informations about the PDU. Not used by current 
implementation. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about a PDU Transmit Event 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for an id which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-30   BswM_PduR_Transmit 
5.2.30  BswM_PduR_TxConfirmation 
Prototype 
void BswM_PduR_TxConfirmation( PduIdType TxPduId ) 
Parameter 
TxPduId 
The PduR ID of sent PDU. 
Return code 
void 
- 
Functional Description 
Function called by PduR to inform the BswM about a sent PDU. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for a TxPduId which does not belong to the same configured port. 
>  This function must only be called by the PduR. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-31   BswM_PduR_TxConfirmation 
2015, Vector Informatik GmbH 
Version: 6.00.00 
49 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.31  BswM_Sd_EventHandlerCurrentState 
Prototype 
void BswM_Sd_EventHandlerCurrentState(uint16 SdEventHandlerHandleId, 
 
Sd_EventHandlerCurrentStateType EventHandlerStatus ) 
Parameter 
SdEventHandlerHandleId  HandleId to identify the EventHandler 
EventHandlerStatus 
Status of the EventHandler 
Return code 
void 
- 
Functional Description 
Function  called  by  Service  Discovery  to  indicate  current  status  of  the EventHandler 
(requested/released). 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different handles. 
>  This function must only be called by Sd. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-32   BswM_Sd_EventHandlerCurrentState 
 
5.2.32  BswM_Sd_ClientServiceCurrentState 
Prototype 
void BswM_Sd_ClientServiceCurrentState(uint16 SdClientServiceHandleId, 
 
Sd_ClientServiceCurrentStateType CurrentClientState) 
Parameter 
SdClientServiceHandleId  HandleId to identify the ClientService. 
CurrentClientState 
Current state of the ClientService. 
Return code 
void 
- 
Functional Description 
Function called by Service Discovery to indicate current state of the Client Service (available/down). 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different handles. 
>  This function must only be called by Sd. 
Call Context 
>  This function can be called from task and interrupt context. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
50 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Table 5-33   BswM_Sd_ClientServiceCurrentState 
5.2.33  BswM_Sd_ConsumedEventGroupCurrentState 
Prototype 
void BswM_Sd_ConsumedEventGroupCurrentState( 
 
uint16 SdConsumedEventGroupHandleId, 
 
Sd_ConsumedEventGroupCurrentStateType ConsumedEventGroupState) 
Parameter 
SdConsumedEventGroupHandleId  HandleId  to  identify  the  Consumed Eventgroup. 
ConsumedEventGroupState 
Status of the Consumed Eventgroup. 
Return code 
void 
- 
Functional Description 
Function called by Service Discovery to indicate current status of the Consumed Eventgroup 
(available/down). 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different handles. 
>  This function must only be called by Sd. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-34   BswM_Sd_ConsumedEventGroupCurrentState 
2015, Vector Informatik GmbH 
Version: 6.00.00 
51 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.34  BswM_Nm_StateChangeNotification 
Prototype 
void BswM_Nm_StateChangeNotification(NetworkHandleType nmNetworkHandle, 
 
Nm_StateType nmPreviousState, 
 
Nm_StateType nmCurrentState) 
Parameter 
nmNetworkHandle 
Identification of the NM-channel 
nmPreviousState 
Previous state of the NM-channel (Parameter not used) 
nmCurrentState 
Current (new) state of the NM-channel 
Return code 
void 
- 
Functional Description 
Function called by Nm to inform the BswM about its current state. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different networks. 
>  This function must only be called by Nm. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-35   BswM_Nm_StateChangeNotification 
2015, Vector Informatik GmbH 
Version: 6.00.00 
52 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.2.35  BswM_RuleControl 
Prototype 
void BswM_RuleControl (BswM_HandleType ruleId, uint8 state) 
Parameter 
ruleId 
The external ID of the rule which shall be changed. Symbolic Name Define 
shall be used. 
state 
The new rule state. Following values are valid: 
Disable Rule: BSWM_DEACTIVATED 
Enable Rule:  BSWM_UNDEFINED, BSWM_TRUE or BSWM_FALSE 
Return code 
void 
- 
Functional Description 
Sets a new state to a given rule whereby rule can be enabled or disabled. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant for different rules. 
>  This function should be called by an action of BswM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-36   BswM_RuleControl 
5.2.36  BswM_WdgM_RequestPartitionReset 
Prototype 
void BswM_WdgM_RequestPartitionReset (ApplicationType Application) 
Parameter 
Application 
The Block that the new NvM Mode corresponds to. 
Return code 
void 
- 
Functional Description 
Function called  by  WdgM  to request a reset of the corresponding partition of given application. 
Particularities and Limitations 
>  This function is synchronous. 
>  This function is reentrant. 
>  This function must only be called by WdgM. 
Call Context 
>  This function can be called from task and interrupt context. 
Table 5-37   BswM_WdgM_RequestPartitionReset 
2015, Vector Informatik GmbH 
Version: 6.00.00 
53 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
5.3 
Services Used by BswM 
In the following table services provided by other components, which are used by the BswM 
are  listed.  For details about  prototype and functionality refer to the documentation of  the 
providing component. 
Component 
API 
ComM 
ComM_CommunicationAllowed 
ComM 
ComM_LimitChannelToNoComMode 
ComM 
ComM_RequestComMode 
Com 
Com_IpduGroupControl 
Com 
Com_ReceptionDMControl 
Com 
Com_SetIpduGroup 
Com 
Com_SwitchIpduTxMode 
Com 
Com_TriggerIPDUSend 
DEM 
Dem_Init 
DEM 
Dem_Shutdown 
DET 
Det_ReportError 
EcuM 
EcuM_GoDown 
EcuM 
EcuM_GoHalt 
EcuM 
EcuM_GoPoll 
EcuM 
EcuM_SelectShutdownTarget 
EcuM 
EcuM_SetState 
EcuM 
EcuM_ClearValidatedWakeupEvent 
J1939Dcm 
J1939Dcm_SetState 
J1939Rm 
J1939Rm_SetState 
LinSM 
LinSM_ScheduleRequest 
Nm 
Nm_DisableCommunication 
Nm 
Nm_EnableCommunication 
NvM 
NvM_WriteAll 
NvM 
NvM_CancelWriteAll 
PduR 
PduR_EnableRouting 
PduR 
PduR_DisableRouting 
RTE 
Rte mode switch. The API name is configurable.  
SchM 
SchM_Enter_BswM_BSWM_EXCLUSIVE_AREA_0 
SchM 
SchM_Exit_BswM_BSWM_EXCLUSIVE_AREA_0 
Sd 
Sd_ConsumedEventGroupSetState 
Sd 
Sd_ClientServiceSetState 
Sd 
Sd_ServerServiceSetState 
Table 5-38   Services used by the BswM 
2015, Vector Informatik GmbH 
Version: 6.00.00 
54 / 65 
based on template version 4.11.3 


Technical Reference Basic Software Mode Manager 
5.4 
Callback Functions 
There are no callback functions in the BswM. 
5.5 
Configurable Interfaces 
 
5.5.1 
Callout Functions 
A User Callout Function can be used as an item of an Action List. If the declaration of the 
callout  function  already  exists,  the  integrator  must  provide  an  extern  declaration  of  the 
function via a user include file.  
 
 
Figure 5-1  Existing callout functions 
 
If the BswM is to generate the user callout prototype: the checkbox “Create Callout” should 
be set and the parameter prototypes should be defined in the given field as list separated 
with semicolons. The function prototype is generated in “BswM_Callout_Stubs.c” 
 
Figure 5-2  Generate prototype of callout functions 
The BswM callout function declaration is described in the following table: 
Prototype 
void [Callout Function Name] ( <parameters> ) 
Parameter 
- 
- 
Return code 
- 
- 
2015, Vector Informatik GmbH 
Version: 6.00.00 
55 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
Functional Description 
If a User Callout is configured as an item of an Action List the BswM calls this function in the context of the 
appropriate rule. 
Particularities and Limitations 
- 
Call context 
>  Interrupt or task context, depends on the mode/rule configuration in which the callout is used. 
Table 5-39  User Callout 
5.6 
Service Ports 
The BswM has a service component which depends on the following containers: 
>  BswMSwcModeRequest  
>  BswMSwcModeNotification 
>  BswMSwitchPort 
>  BswMModeDeclaration 
These containers are described in the following chapters. 
 
5.6.1 
BswMSwcModeRequest (R-Port) 
BswM is able to receive modes by Sender-Receiver mode ports (Require Port). This can 
be done by using BswMSwcModeRequest. 
The BswMSwcModeRequest has a reference to a Mode-Declaration-Group-Prototype and 
an Instance-Reference to a VARIABLE-DATA-PROTOTYPE. If the reference to the Mode-
Declaration-Group-Prototype is configured, it is not possible to determine a relationship to 
a Sender-Receiver-Interface. Therefore, it is necessary to create a new  Sender-Receiver-
Interface.  The  given  BswMModeRequestDataElementPrototypeName  will  be  used  as 
DataElement name.  
Sender-Receiver-Interfaces are named  
>  BswM_SRI_{  Mode-Switch-Interface  Name}_{  Mode-Declaration-Group-Prototype 
Name} 
If the Instance-Reference to a VARIABLE-DATA-PROTOTYPE is used, BswM reuses the 
existing Sender-Receiver interface. 
In both cases, created Ports are named: 
>  Receive_{Name of BswMSwcModeRequest} 
 
5.6.2 
BswMSwcModeNotification (R- Port) 
BswM is able to receive modes by Mode-Switch mode ports (Require Port). This can be 
done by using BswMSwcModeNotification. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
56 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
The BswM has a reference to a Mode-Declaration-Group-Prototype. From this prototype it 
is possible to determine a Mode-Switch-Interface which will be reused for the created port.  
Created ports are named: 
>  Notification_{ BswMSwcModeNotification Name } 
 
5.6.3 
BswMSwitchPort (P- Port) 
BswM  is  able  to  switch  modes  by  Mode-Switch  mode  ports  (Provide  Port).  This  can  be 
done  by  using  a  BswMSwitchPort.  The  BswM  has  a  reference  to  a  Mode  Declaration 
Group Prototype. From this prototype it is possible to determine a Mode-Switch-Interface 
which will be reused for the created port.  
Created ports are named: 
>  Switch_{ BswMSwitchPort Name } 
 
5.6.4 
BswMRteModeRequestPort (P-Ports) 
BswM is able to send modes by Sender-Receiver mode ports (Require Port). This can be 
done  by  using  a  port  of  type  BswMRteModeRequestPort  in  a  BswMRteModeRequest 
action.  The  BswM  uses  an  Instance-Reference  to  a  VARIABLE-DATA-PROTOTYPE, 
which represents the DataElement of an already existing Sender-Receiver-Interface. This 
interface is used by the created P-Port. 
Created ports are named: 
>  Provide_{ BswMRteModeRequestPort Name } 
 
5.6.5 
BswMModeDeclaration  
To facilitate SWC ModeRequest Handling, the BswM is able to provide Mode-Declarations 
by itself. To use this, a BswMModeDeclaration container with corresponding modes can be 
created.  The  BswM  SWC  Validation  creates  automatically  a  Mode-Declaration,  the 
corresponding  Implementation-Type  and  a  Mode-Switch-Interface  with  a  Mode-
Declaration-Group-Prototype.  
The Mode-Switch-Interface is named: 
>  BswM_MSI_{Name of BswMModeDeclaration} 
The corresponding Mode-Declaration-Group-Prototype is named: 
>  BswM_MDGP_{Name of BswmModeDeclaration} 
The Implementation-Type is named: 
>  BswM_{Name of BswMModeDeclaration} 
2015, Vector Informatik GmbH 
Version: 6.00.00 
57 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
6  AUTOSAR Standard Compliance 
6.1 
Deviations 
 
6.1.1 
Inclusion of the header Com_Types.h 
A  non-AUTOSAR  header  is  used  within  the  code.  The  source  file  BswM_Cfg.h  includes 
Com_Types.h.  This  header  has  been  included  because  it  defines  the  type 
Com_IpduGroupIdType. 
In case the project in use does not contain a MICROSAR Com module, it is necessary to 
add  a  header  file  with  the  name  “Com_Types.h”,  which  defines  the  type 
“Com_IpduGroupIdType”.  
 
6.1.2 
Port Names 
Notice that in the BswM AUTOSAR SWS the name of the ports is specified as: 
modeNotificationPort_{Name} 
modeRequestPort_{Name} 
modeSwitchPort_{Name} 
 
However, the structure of the name port is as follows: 
Notification_{Name} 
Request_{Name} 
Switch_{Name} 
 
Furthermore, BswMRteModeRequestPort are named: 
Provide_{Name} 
6.2 
Additions/ Extensions 
6.2.1 
Optional Interfaces 
The BswM supports the following “Optional Interfaces” defined in [1] [BswM0008]:  
>  ComM_LimitChannelToNoComMode 
>  ComM_RequestComMode 
>  Com_ClearIpduGroupVector  
>  Com_IpduGroupControl 
>  Com_ReceptionDMControl 
>  Com_SetIpduGroup 
>  Com_IpduGroupStart 
2015, Vector Informatik GmbH 
Version: 6.00.00 
58 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
>  Com_IpduGroupStop 
>  Com_EnableReceptionDM 
>  Com_DisableReceptionDM 
>  Com_SwitchIpduTxMode 
>  Det_ReportError 
>  EcuM_GoDown 
>  EcuM_GoHall 
>  EcuM_GoPoll 
>  EcuM_SelectShutdownTarget 
>  J1939Dcm_SetState 
>  J1939Rm_SetState 
>  LinSM_ScheduleRequest 
>  Nm_DisableCommunication 
>  Nm_EnableCommunication 
>  Sd_ClientServiceSetState 
>  Sd_ConsumedEventGroupSetState 
>  Sd_ServerServiceSetState 
 
 
6.2.2 
Nm Indication 
BswM supports the NM indication by using the API “BswM_Nm_StateChangeNotification”. 
The mode request source is of type “BswMNMIndication”. In order to use this feature the 
Nm module must be configured as follows: 
>  NmStateChangeIndEnabled must be set to true 
>  NmStateChangeIndCallback must be set to “BswM_Nm_StateChangeNotification” 
>  NmCallbacksPrototypeHeader  must  be  set  to  “BswM_Nm.h”  (or  any  other  header 
which includes BswM_Nm.h) 
 
6.2.3 
User Condition Functions 
A User Condition Function can be used in a Rule Condition. The integrator must provide 
an extern declaration of the function via an application header file.  
In  the  same  manner,  with  the  request  port  of  type  “User  Condition”,  it  is  possible  to 
compare any variable. 
The integrator must make sure that the return value of the function is compatible with the 
value to compare with. 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
59 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
6.2.4 
Creation of Mode Declarations 
The  BswM  is  able  to  provide  Mode  Declarations  by  itself  in  order  to  facilitate  the  SWC 
Mode Request Handling. For further information see 5.6.5. 
 
6.2.5 
Timers 
A  Timer  offers  the  possibility  to  execute  action  time  dependently.  Therefore,  a  Mode 
Request Port of type BswMTimer must be created. This port represents a timer which can 
be started and stopped by a BswMTimerControl Action. The value for the timer start can 
be set in the TimerControlAction.  
The timer should be a multiple of the BswMMainFunctionPeriod (timer is decreased in the 
MainFunction).  In  case  the  timer  is  not  multiple  of  the  main  function  period,  it  will  be 
rounded up.  The timer must be used in a condition to trigger the corresponding actions. 
The state of a timer can be STARTED, STOPPED or EXPIRED. 
 
6.2.6 
Generic Symbolic Values 
Generic ports offer the possibility to define Symbolic Values. In order to realize this, create 
a BswMGenericRequestMode inside the BswMGenericRequest container. These Symbolic 
Values are necessary for the Generic Actions (see chapter 6.2.7). 
 
6.2.7 
Generic Actions 
BswM  supports  setting  a  generic  mode  by  an  action.  In  order  to  configure  it,  a 
BswMGenericModeSwitch  action  must  be  created.  Here,  the  generic  mode  and  the 
corresponding value can be chosen. 
 
6.2.8 
 Immediate request in BswM_Init() 
All  configured  immediate  request  are  processed  once  within  the  function  BswM_Init,  in 
order  to  arbitrate  the  initial  states.  This  behavior  can  be  changed  for  each  port  in  the 
configuration. 
 
6.2.9 
Mode Handling Forced Immediate 
The  additional  mode  handling  type  “Forced  Immediate”  allows  mode  requests  to  be 
executed immediately interrupting other requests. For more information see chapter 3.4.2. 
 
6.2.10  Rule Control 
If Rule Control is used, rules can be activated or deactivated during runtime. Furthermore, 
rules  can  be  deactivated  in  configuration  by  using  BSWM_DEACTIVATED  as  initialization 
value. For further information see 5.2.35. 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
60 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
6.2.11  Support of Com ASR3 IPduGroup APIs 
If Microsar Com is used and Com is configured to use ASR3 IPduGroup APIs, BswM will 
use the following APIs in its IPduGroup actions instead of the ASR4 APIs: 
>  Com_IpduGroupStart 
>  Com_IpduGroupStop 
>  Com_EnableReceptionDM 
>  Com_DisableReceptionDM 
For further information see [8]. 
6.3 
Limitations 
6.3.1 
Configurable interfaces that are not supported  
6.3.1.1 
EcuM Indication for EcuM Flex 
The ModeRequestPort of type EcuMIndication is not supported for MICROSAR EcuM Flex 
without  enabled  ModeHandling.  This  is  due  to  the  fact,  that  BswM  calls  most  of  EcuM 
Function itself. So, the notifications from EcuM to BswM will be done in the context of the 
BswM and this leads to a queued processing of mode changes. 
If EcuM notifies more than one mode change, previously notified mode changes get lost 
and Rules which should be triggered to this mode will be skipped. As this is not the desired 
behavior, the EcuM Indication is no longer supported during configuration of the module. 
 
6.3.2 
Optional Interfaces 
Within  the  predefined  actions,  the  BswM  does  not  support  the  following  “Optional 
Interfaces” defined by [1] [BswM0008]:  
>  ComM_GetCurrentComMode  
>  ComM_GetInhibitionStatus  
>  ComM_GetMaxComMode 
>  ComM_GetRequestedComMode 
>  ComM_GetStatus 
>  ComM_GetVersionInfo 
>  ComM_LimitECUToNoComMode 
>  ComM_MainFunction_<Channel_Id> 
>  ComM_PreventWakeUp 
>  ComM_ReadInhibitCounter 
>  ComM_ResetInhibitCounter 
>  ComM_SetECUGroupClassification 
>  ControlIdle 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
61 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
6.3.3 
Configuration Variants 
Configuration variant Link-Time is not supported. 
 
6.3.4 
BSW Modules 
Only  these  BSW  Modules  are  supported  for  mode  indications  and  arbitrations:  CanSM, 
ComM,  Dcm,  EcuM, EthSm,  FrSM,  J1939Dcm, J1939Nm,  LinSM, LinTp,  Nm,  NvM  ,  Sd, 
WdgM and RTE. 
2015, Vector Informatik GmbH 
Version: 6.00.00 
62 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
7  Glossary and Abbreviations 
7.1 
Glossary 
Term 
Description 
DaVinci Configurator  Generation tool for MICROSAR components 
 
7.2 
Abbreviations 
Abbreviation 
Description 
API 
Application Programming Interface 
AUTOSAR 
Automotive Open System Architecture 
BSW 
Basis Software 
CAN 
Controller Area Network 
Com 
Communication (AUTOSAR BSW) 
ComM 
Communication Manager 
CanSM 
CAN State Manager 
DCM 
Diagnostic Communication Manager 
DEM 
Diagnostic Event Manager 
DET 
Development Error Tracer 
ECU 
Electronic Control Unit 
ECUM 
ECU Manager 
EthSM 
Ethernet State Management 
Fr 
FlexRay 
FrSM 
FlexRay State Manager 
HIS 
Hersteller Initiative Software 
I-PDU 
Interaction Layer Protocol Data Unit 
ISR 
Interrupt Service Routine 
J1939Dcm 
J1939 Diagnostic Communication Manager 
J1939Nm 
J1939 Network Manager 
J1939Rm 
J1939 Request Manager 
LIN 
Local Interconnect Network 
LinIf 
LIN Interface 
LinSM 
LIN State Manager 
LinTp 
LIN Transport Protocol 
MICROSAR 
Microcontroller Open System Architecture (the Vector AUTOSAR 
solution) 
Nm 
Network Manager 
NvM 
Non-Volatile RAM Manager 
2015, Vector Informatik GmbH 
Version: 6.00.00 
63 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
PduR 
Protocol Data Unit Router 
PNC 
Partial Networking Cluster 
RAM 
Random Access Memory 
RTE 
Runtime Environment 
Sd 
Service Discovery 
SchM 
Schedule Manager 
SWC 
Software Component 
SWS 
Software Specification 
Table 7-1 
Abbreviations 
 
2015, Vector Informatik GmbH 
Version: 6.00.00 
64 / 65 
based on template version 4.11.3 
Technical Reference Basic Software Mode Manager 
8  Contact 
Visit our website for more information on 
 
  News 
  Products 
  Demo Software 
  Support 
  Training data 
  Addresses 
 
www.vector.com 
2015, Vector Informatik GmbH 
Version: 6.00.00 
65 / 65 
based on template version 4.11.3 

Document Outline