document title - autosar · guide to modemanagement v2.2.0 r4.1 rev 3 1 introduction this document...

Guide to ModemanagementV2.2.0

R4.1 Rev 3

Document Title Guide to ModemanagementDocument Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 440

Document Classification Auxiliary

Document Version 2.2.0

Document Status Final

Part of Release 4.1

Revision 3

Document Change HistoryDate Version Changed by Description

31.03.2014 2.2.0AUTOSARReleaseManagement

• Clarified Wakeup Handling• Extended diagnostic related

mode management• Fixed inconsistencies with BswM

14.08.2013 2.1.0AUTOSARReleaseManagement

• Added section about PretendedNetworking

26.02.2013 2.0.0 AUTOSARAdministration

• Changes regarding J1939Network Management

• Introduction of J1939 DiagnosticMode Management

27.10.2011 1.0.0 AUTOSARAdministration • Initial release

1 of 65— AUTOSAR CONFIDENTIAL —

Document ID 440: AUTOSAR_EXP_GuideModemanagement


R4.1 Rev 3




R4.1 Rev 3

Disclaimer

This specification and the material contained in it, as released by AUTOSAR, is for thepurpose of information only. AUTOSAR and the companies that have contributed to itshall not be liable for any use of the specification.

The material contained in this specification is protected by copyright and other types ofIntellectual Property Rights. The commercial exploitation of the material contained inthis specification requires a license to such Intellectual Property Rights.

This specification may be utilized or reproduced without any modification, in any formor by any means, for informational purposes only.For any other purpose, no part of the specification may be utilized or reproduced, inany form or by any means, without permission in writing from the publisher.

The AUTOSAR specifications have been developed for automotive applications only.They have neither been developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models,"use cases", and/or references to exemplary technical solutions, devices, processes orsoftware).

Any such exemplary items are contained in the specifications for illustration purposesonly, and they themselves are not part of the AUTOSAR Standard. Neither their pres-ence in such specifications, nor any later documentation of AUTOSAR conformance ofproducts actually implementing such exemplary items, imply that intellectual propertyrights covering such exemplary items are licensed under the same rules as applicableto the AUTOSAR Standard.




R4.1 Rev 3

Table of Contents

1 Introduction 7

1.1 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Overall mechanisms and concepts 8

2.1 Declaration of modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Mode managers and mode users . . . . . . . . . . . . . . . . . . . . . . 102.3 Modes in the RTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Modes in the Basic Software Scheduler . . . . . . . . . . . . . . . . . . 112.5 Communication of modes . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Mode switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Mode request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.3 Conformance of mode switches and mode requests . . . . . . . 132.5.4 Mode proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.5 Mode communication on multi core ECUs . . . . . . . . . . . . . 14

3 Configuration of the Basic Software Modemanager 16

3.1 Process how to configure and integrate a BswM . . . . . . . . . . . . . 163.2 Semantics of BswM Configuration: Interfaces and behavioral aspects . 17

3.2.1 Interface of the BswM . . . . . . . . . . . . . . . . . . . . . . . . 173.2.1.1 Mode Requests . . . . . . . . . . . . . . . . . . . . . . 173.2.1.2 Available Actions . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Definition of the interface in pseudo code . . . . . . . . . . . . . 193.2.2.1 Mode switch and mode request interfaces . . . . . . . . 193.2.2.2 ModeRequestPorts defined by the standardized inter-

face of the BswM . . . . . . . . . . . . . . . . . . . . . 213.2.2.3 Configurable ModeRequestPorts . . . . . . . . . . . . . 273.2.2.4 Configurable ModeSwitchPorts . . . . . . . . . . . . . . 28

3.2.3 Configuration of the BswM behavior . . . . . . . . . . . . . . . . 293.3 ECU state management . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.3 Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.4 Sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.5 Wakeup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Communication Management . . . . . . . . . . . . . . . . . . . . . . . . 343.4.1 Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 353.4.2 I-PDU Group Switching . . . . . . . . . . . . . . . . . . . . . . . 353.4.3 J1939 Networkmanagement . . . . . . . . . . . . . . . . . . . . 393.4.4 J1939 diagnostic mode management . . . . . . . . . . . . . . . 413.4.5 Pretended Networking . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4.5.1 Activation of Pretended Networking . . . . . . . . . . . 423.4.5.2 Deactivation of Pretended Networking . . . . . . . . . . 43

3.5 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.5.1 Diagnostic Session Control . . . . . . . . . . . . . . . . . . . . . 43




R4.1 Rev 3

3.5.2 ECU Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5.3 Rapid Power Shutdown . . . . . . . . . . . . . . . . . . . . . . . 463.5.4 Communciation Control diagnostic service . . . . . . . . . . . . 473.5.5 Control DTC Setting . . . . . . . . . . . . . . . . . . . . . . . . . 503.5.6 Roe Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Backward Compatibility 52

4.1 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2 Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4 Wakeup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Acronyms and abbreviations 60

5.1 Technical Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60




R4.1 Rev 3

References

[1] Specification of ECU State Manager with fixed state machineAUTOSAR_SWS_ECUStateManagerFixed

[2] Software Component TemplateAUTOSAR_TPS_SoftwareComponentTemplate

[3] Meta ModelAUTOSAR_MMOD_MetaModel

[4] Basic Software Module Description TemplateAUTOSAR_TPS_BSWModuleDescriptionTemplate

[5] Specification of Basic Software Mode ManagerAUTOSAR_SWS_BSWModeManager

[6] Specification of Diagnostic Communication ManagerAUTOSAR_SWS_DiagnosticCommunicationManager

[7] GlossaryAUTOSAR_TR_Glossary




R4.1 Rev 3

1 Introduction

This document is a general introduction to AUTOSAR mode management for the Re-lease 4.0.3 onwards. Its main purpose is to give users as well as developers ofAUTOSAR an detailed overview of the different aspects of AUTOSAR mode manage-ment based on examples, which are explained in context. The code listings in thisdocument together form the configuration of a sample ECU.

Chapter 2 explains the basic mode management concepts e.g. modes in general, howmode switches are implemented, roles of mode managers and mode users etc. It sec-ondly gives an introduction to Application Mode management and the dependencies toBasic Software Mode management, which are closely related.

The Basic Software Modemanager is the central mode management module inAUTOSAR R4.0. It is configurable to a high degree. How this configuration can beachieved is the topic of chapter 3.

Chapter 4 than deals with migration strategies from fixed ECU Management as it wasused in AUTOSAR R3.1 1 to the new approach of ECU management of AUTOSAR 4.0

1.1 Further Work

Due to complexity and broad scope of this topic there are still some uses cases whichare not yet described here in full detail. These issues will be enhanced in furtherreleases.

• ECUs as Gateways

• Communication management for FlexRay

• Communication management for Ethernet

• Communication management for Lin (including schedule table switching)

• DCM Routing path groups

• BSWM configuration for multicore ECUs

1and in R4.0 with the ECU Statemanager with fixed state machine[1]




R4.1 Rev 3

2 Overall mechanisms and concepts

This chapter gives an overview of the concept of modes and a short definition of statesin AUTOSAR. Defintions of the terms mode and state can be found in chapter 5.1 Amode can be seen as the current state of an ECU1 wide, global variable, which is main-tained by the RTE respectively the Schedule Manager. The possible assignments of amode are defined in ModeDeclarationGroups, which are defined in the AUTOSARSoftware Component Template [2]. Modes can be used for different purposes. Firstof all modes are used to synchronize Software Components and Basic Software Mod-ules. Via modes specified triggers can be enabled and disabled, and consequently theactivation of ExecutableEntitys can be prevented. Also ExecutableEntityscan be triggered explicitely during a Mode Switch. On the other hand mode switchescan explicitly trigger executable entities during transition from one mode to another.For example the RTE can activate an OnEntry ExecutableEntity to initialize acertain resource before entering a specific mode. In this mode the triggers of this Ex-ecutableEntity are activated. If the mode is left the OnExit ExecutableEntityis called, which could execute some cleanup code and the triggers would be deacti-vated.

2.1 Declaration of modes

The Software Component Template [2] defines a generic mechanism for describingmodes in AUTOSAR. Modes are defined via ModeDeclarations. A ModeDeclara-tion represents a possible assignment of the current state of a global variable. E.gin ECU state management there may exist the ModeDeclarations STARTUP, RUN,POST_RUN, SLEEP.

A ModeDeclarationGroup groups several ModeDeclarations in a similar way asan enumeration groups literals. In the given example this could be the ModeDeclara-tionGroup ECUMODE. For each ModeDeclarationGroup an InitialMode hasto be defined, which is assigned to the variable at startup. Figure 2.1 shows an ex-cerpt of the AUTOSAR Metamodel [3] with the relationships of ModeDeclarations,ModeDeclarationGroups and ExecutableEntitys.

1In R4.0 this is limited to a single partition




R4.1 Rev 3

Interface

ModeDeclaration

InternalBehavior and Runnables

Component and Port

AtpStructureElementIdentifiable

ModeDeclaration

ARElementAtpBlueprint

AtpBlueprintableAtpType

ModeDeclarationGroup

AtpPrototype

ModeDeclarationGroupPrototype

AtpStructureElementExecutableEntity

RunnableEntity

PPortPrototype RPortPrototype AtomicSwComponentType

InternalBehavior

SwcInternalBehavior



SwComponentType

AtpBlueprintableAtpPrototype

PortPrototype

AbstractEventAtpStructureElement

RTEEvent

SwcModeSwitchEvent

ModeSwitchInterface



PortInterface

«atpVariation» Tags:vh.latestBindingTime = preCompileTime

AtpStructureElementReferrable

ModeTransition

AbstractProvidedPortPrototype AbstractRequiredPortPrototype

PRPortPrototype

ModeSwitchedAckEvent

«atpVariation» Tags:vh.latestBindingTime =preCompileTime

+initialMode

1

+port

0..* «atpVariation,atpSplitable»

+component

+modeDeclaration

1..*«atpVariation»

«atpVariation,atpSplitable»

+internalBehavior 0..1

+modeGroup 1

«isOfType»

+type1{redefines atpType}

+startOnEvent

0..1

+event *


«instanceRef»

+disabledMode 0..*

0..*

«instanceRef»

+mode1..2{ordered}

+modeTransition 0..*

+runnable 1..*


«isOfType»

+re

qu

ired

Inte

rfa

ce

1{redefinesatpType}

«isOfType»

+p

rovi

de

dIn

terf

ace

1{redefinesatpType}

+enteredMode 1 +exitedMode 1

«isOfType»

+p

rovi

de

dR

eq

uire

dIn

terf

ace

1{redefinesatpType}

Figure 2.1: Excerpt of Metamodel regarding Modes




R4.1 Rev 3

2.2 Mode managers and mode users

In mode management there are two parties involved: Mode managers and mode users.Responsible for switching modes are Mode managers, which are the only instancesable to change the value of the global variable. A mode manager is either a SoftwareComponent, which provides a ModeRequestPort or a Basic Software Module, whicheither provides also a ModeRequestPort in its Software Component Descrip-tion or a ModeDeclarationGroup in its Basic Software Module Descrip-tion. Mode users are informed of Mode switches via well-defined mechanismsand have the possibility to read the currently active mode at any time. If a Mode userwants to change into a different mode it can request a Mode switch from the corre-sponding Mode manager.

2.3 Modes in the RTE

The AUTOSAR Runtime Environment implements the concept of modes. For thispurposes it creates for each ModeDeclarationGroupPrototype of an AtomicSoftware Component a so called ModeMachineInstance. A ModeMachineIn-stance is a state machine whose states are defined by the ModeDeclarations ofthe respective ModeDeclarationGroup.

Figure 2.2 depicts the interaction of ModeDeclarationGroupPrototypes Modemanagers and Mode users. Note that the mode switch ports of the mode users arenot directly connected to the corresponding PPorts of the mode managers but insteadare connected to the mode machine instances of the RTE. This is important to under-stand the mechanism of mode switching inside the RTE.

basic software mode userapplication mode userapplication mode manager

Runtime Environment

System Services

basic software mode manager

basic software mode user

mode machine Instance

mode switch port

mode request port

mode request port

mode switch port

mode switch port

mode switch port

mode request port

mode switch port

mode request port

mode request port

Figure 2.2: The RTE instantiates for each ModeDeclarationGroupPrototype a Modema-chineInstance




R4.1 Rev 3

Previous versions of the Basic Software Modules especially the ECU state managermodule have differentiated between ECU states and ECU modes. ECU modes werelonger lasting operational ECU states that were visible to applications i.e. startingup, shutting down, going to sleep and waking up. The ECU Manager states weregenerally continuous sequences of ECU Manager module operations terminated bywaiting until external conditions were fulfilled. Startup1, for example, contained all BSWinitialization before the OS was started and terminated when the OS returned control tothe ECU Manager module. With flexible ECU management the ECU state machine isimplemented as general modes under the control of the BSW Mode Manager module.To overcame this terminology problem states are used only internally and are not visibleto the application. For interaction with the application the basic software has to usemodes.

2.4 Modes in the Basic Software Scheduler

The Basic Software Scheduler provides for Basic Software Modules asimilar mechanism for mode communication as the RTE provides it for Soft-ware Components. If a Basic Software Module provides a ModeDecla-rationGroupPrototype as providedModeGroup in its Basic Software Mod-ule Description the Basic Software Scheduler instatiates a ModeMachine-Instance. Consequently for this Basic Software Module a SchM\protect\T1\textunderscore Switch API is provided, which enables this module toinitiate a Mode switch. Mode users have to reference the ModeDeclara-tionGroupPrototype as requiredModeGroup and will get a SchM\protect\T1\textunderscore Mode API to read the mode, which is currently active. Moderequests between Basic Software Modules can be comunicated directly viafunction calls, as Basic Software Modules.

Another possibility for a Basic Software Module acting as a Mode user to getinformed about mode switches, is to register a BSW Module Entry, which is triggeredby a Mode Switch Event (see also [4]).

2.5 Communication of modes

The Software Component Template differs the following distinctive types of mode com-munication between Mode managers and Mode users.

• Mode Switch: A Mode Switch is the communication of a current mode transitionfrom one mode to another. Mode Switches are always initiated by Mode Man-agers.

• Mode Request: A Mode Request is the request of a mode user to the ModeManager to enter a certain mode. Note that it is not guaranteed that the ModeManager will enter this mode. Moreover he has to arbitrate all requests from theMode Users and decide which mode he will enter.




R4.1 Rev 3

Furthermore, the concept of Mode Proxies and information about communication ofmodes on multi core ECUs is given.

2.5.1 Mode switch

As every other communication between Software Components or between SoftwareComponents and Basic Software Modules, Modes are communicated via PortPro-totypes. Each PortPrototype has to be typed by a PortInterface. In caseof mode communication there exist so called mode switch interfaces, whichare PortInterfaces. These are shown in Figure 2.3. Each ModeSwitchInter-face has exactly one ModeDeclarationGroupPrototype which consists of multi-ple ModeDeclarations. Any ModeDeclaration represents one mode of the Mod-eDeclarationGroup. One of these is defined as the initial mode.



ModeDeclarationGroup

+ onTransitionValue :PositiveInteger [0..1]

AtpStructureElementIdentifiable

ModeDeclaration

+ value :PositiveInteger [0..1]

AtpPrototype

ModeDeclarationGroupPrototype

+ swCalibrationAccess :SwCalibrationAccessEnum [0..1]

PortInterface

ModeSwitchInterface

+initialMode

1

+modeDeclaration

1..*«atpVariation»

«isOfType»

+type1{redefines atpType}

+modeGroup 1

Figure 2.3: mode switch interface

These Mode switches are necessary because Software Components need to becapable of reacting to state changes initiated by a ModeManager. Depending on theconfiguration there are two mechanisms available how a Software Component canreact on a mode change.

1. A ModeSwitchEvent can trigger a OnExtry, OnTransition or OnEntry-Runnable.

2. An RTEEvent can be disabled in a certain mode and consequently prevent theexecution of accordant ExecutableEntities.




R4.1 Rev 3

2.5.2 Mode request

Mode requests are distributed on the way from the mode requester (Mode ArbitrationSWC or a generic SWC) to the mode manager. The mode managers on each ECUthen have to decide and initiate the local mode switch. Thus the arbitration result iscommunicated only locally on each ECU using RTE mode switch mechanism.

For mode requests, the communication of modes works slightly differently as formode switches: without ModeDeclarationGroups.

The request of modes is done via standard SenderReceiverInterfaces. Contrarilyto ModeSwitchInterfaces the requested mode is not given by a ModeDeclara-tionGroup but by a VariableDataPrototype that has to contain an enumeration.This enumeration consists of a set which contains the modes that can be requested.

Mode requests can be distributed in the whole system. For application and vehiclemodes, the requests of the mode requester have to be distributed to all affected ECUs.This implies a 1:n-connection between the mode requester and the mode Managers.In AUTOSAR this is only possible with Sender-Receiver Communication. The modemanager only requires the information about the requested mode and not the modeswitch from the mode requester. The mode manager has one Sender-Receiver portfor each mode requester. To actually transmit the signal, COM shall use a periodicsignal with signal timeout notification to RTE. The mode manager will use the dataelement outdated event to release a mode request.

2.5.3 Conformance of mode switches and mode requests

As stated above, the ModeSwitchInterfaces work with ModeDeclara-tionGroups whereas mode request interfaces takes parameters via Vari-ableDataPrototypes containing enumerations.

The configuration utility is in duty to ensure with respect to consistency the equivalenceof represented data in both representations. That means that the elements of theenumeration must precisely match the elements of the ModeDeclarationGroup. Orformulated another way: All modes available in one of the interfaces must also beavailable in the other one.

2.5.4 Mode proxies

Currently AUTOSAR has a constraint that only local software components are allowedto communicate with ServiceComponents. So it is not possible that a SoftwareCom-ponent can request modes from a remote e.g Basic Software Mode Manager. Toovercome this limitation so called ServiceProxyComponentType were introducedin AUTOSAR Release 4.0. Figure 2.4 depicts this concept.




R4.1 Rev 3

For the application software and the RTE a ServiceProxySoftwareComponentTypebehaves like a "normal" AtomicSwComponentType, but it is actually a proxy for anAUTOSAR Service. This means that on the one side it has to communicate over ser-vice ports with the ECU-local ServiceSwComponentType it represents. On the otherside it has to offer the corresponding PortPrototypes to the ApplicationSwCom-ponentTypes. In the meta-model, the ServiceProxySwComponentType does notdiffer from an ApplicationSwComponentType except by its class. It is up to the im-plementer to meet the restrictions imposed by the semantics as a proxy. The maindifference between a ServiceProxySwComponentType and an Application-SwComponentType is on system level: A prototype of a ServiceProxySwCompo-nentType can be mapped to several ECUs even if it appears only once in the VFBsystem, because such a prototype is required on each ECU, where it has to addressa local ServiceSwComponentType. As a result of this, a ServiceProxySwCompo-nentType can only receive but not send signals over the network. (see also [2]).

System Services

service proxy software component

SWC1

Runtime Environment

System Services


Runtime Environment

SWC3

mode machine Instance

mode request port

mode switch port


mode request port

mode switch port

ECU1 ECU2

SWC2

Figure 2.4: Communication via ServiceProxySwComponents

2.5.5 Mode communication on multi core ECUs

The RTE does not synchronize ModeMachineInstances over the different partitions ofan ECU. rte_sws_2724 states that the RTE shall reject configurations where one Mod-eDeclarationGroupPrototype of a provide port is connected to ModeDeclara-tionGroupPrototypes of require ports from more than one partition. Consequentlyall ModeUsers of a ModeDeclarationGroupPrototype have to live inside a singlepartition. Note that the ModeManager of the ModeDeclarationGroupPrototypecan of course exist in another partition as shown in Fig. 2.6




R4.1 Rev 3

System Services


Runtime Environment



mode switch port

mode switch port

mode request port

mode switch port

mode request port

mode request port

Core1 Core2

Figure 2.5: Invalid configuration

System Services


Runtime Environment



mode switch port

mode switch port

mode request port

mode switch port

mode request port

mode request port

Core1 Core2

Figure 2.6: Corrected version accord-ing to [SWS_Rte_02724]

This limitation has a deep impact on mode managers with mode users on differentcores. The mode manager has to provide a dedicated ModePort for each partition inwhich one or more of it’s mode users are located. To trigger a mode change it has tocall Rte_switch for each mode port separately. If configured it will also get an separateMode_Switch_Acknowldegement from each ModeMachineInstance. This meansthat the possible mapping of mode users and mode managers to different core has tobe taken into account to some extend during design time of the Software Components.




R4.1 Rev 3

3 Configuration of the Basic Software Modemanager

The BSW Mode Manager is the module that implements the part of the Vehicle ModeManagement and Application Mode Management concept that resides in the BSW.Its responsibility is to arbitrate mode requests from application layer Software Compo-nents or other Basic Software Modules based on rules, and perform actions based onthe arbitration result.

From an functional point view the BswM is responsible to put the Basic Software in astate so that the Basic Software can run properly and meet the functional requirements.

The configuration of the BswM is very project- and ECU- specific. Therefore it cannot be standardized by AUTOSAR. Nevertheless it is expected that a BswM imple-mentation behaves in specific situations in a certain way . This chapter starts with anintroduction on the general concept of the BswM, which is more or less a execution en-vironment for rules described by the user. Afterwards typical scenarios in the lifecycleof an ECU are described and examples are given how the BswM could be configured.

3.1 Process how to configure and integrate a BswM

The configuration and integration of a BswM into an ECU project consists of the samesteps as for other Basic Software Modules. Nevertheless it is described for a betterunderstanding of the next steps. In general the following actions have to be taken:

1. Create a ECUC configuration of the module. For the BswM this configurationcontains:

(a) the necessary ModeRequestSources,

(b) the provided ModeSwitchPorts,

(c) a description of the Rules and ActionLists.

2. The configuration is used as input for the module generator, which creates

(a) a SoftwareComponentDescription of the AUTOSAR Interface,

(b) the implementation of the module1.

3. The last step is to integrate the Module into the ECU by connecting the ports ofthe Software Components with the corresponding ports of the BswM.

1This documents assumes that the Implementation of the BswM is generated to a large extend.




R4.1 Rev 3

3.2 Semantics of BswM Configuration: Interfaces and behavioralaspects

In general the BswM can be seen as a state machine, which is defined by its inter-face and a behavioral description. The input actions of this state machine are moderequests. Each mode request is described in the ECU configuration of the BswM asa BswMModeRequestSource. These mode requests can be of different types (C-APIcalls, mode requests via RTE, mode notifications via RTE, etc.) but internally they aretreated in the same way.

If a mode is requested the internal mirror of this BswMModeRequestSource is up-dated and depending on the configuration a rule evaluation is triggered, which resultsin the execution of predefined action lists. Action lists group Actions. Typically an actionis a triggering of a mode switch in the RTE or Schedule Manager, but there are alsopredefined actions which change the status of some Basic Software Module.

3.2.1 Interface of the BswM

The interface is defined by the BswMModeRequestSource and the BswMAction-ListItem containers.

3.2.1.1 Mode Requests

BswMModeRequestSource is a ChoiceContainer, which can be of the followingkinds:

1. C-APIs, which are defined in the specification of the BswM. BasicSoftware-Modules can directly call C-APIs from the BswM, who will translate them inter-nally into a ModeRequest. For example a call to the API

BswM_CanSM_CurrentState(NetworkHandleType Network,CanSM_BswMCurrentStateType CurrentState

)

is to be mapped to different ModeRequestPorts depending on the parameterNetwork, which identifies the channel on which the event occurred. The pa-rameter CurrentState then contains the mode which is requested. The moderequests, which are defined by the standardized interface of the BswM are de-scribed in more detailed in 3.2.2.2

2. RPorts typed by a SenderReceiverInterface. BswMSwcModeRequest:For each container of this type the BswM has to create a corresponding RPortin its Service Component Description.

3. RPorts typed by a ModeSwitchInterface. BswMSwcModeNotification:For each container of this type the BswM has to create a corresponding RPort in




R4.1 Rev 3

its Service Component Description. As it is typed by a ModeSwitchInterfacethe BswM acts as a mode user of this ModeMachineInstance and is informedif the mode manager performs an rte_switch.

4. RequiredModeDeclarationGroupPrototypes BswMBswModeNotifica-tion: For each container of this type the BswM has to create a correspond-ing RequiredModeDeclarationGroupPrototype in the role required-ModeDeclarationGroup in its Basic Software Module Description. In this casethe BswM also acts as a mode user, but the ModeMachineInstance is main-tained by the Schedule Manager. The BswM therefore gets informed if the modemanager e.g. another Basic Software Module performs a SchM_Switch call.

3.2.1.2 Available Actions

BswMActionListItems can be of the following kinds:

1. C-APIs from other BswM Modules, which are called directly during the executionof an ActionList.

• BswMComMAllowCom

• BswMComMModeLimitation

• BswMComMModeSwitch

• BswMDeadlineMonitoringControl

• BswMEcuMGoDown

• BswMEcuMSelectShutdownTarget

• BswMJ1939Rm

• BswMLinScheduleSwitch

• BswMNMControl

• BswMPduGroupSwitch

• BswMPduRouterControl

• BswMRteSwitch

• BswMSchMSwitch

• BswMSwitchIPduMode

• BswMTriggerIPduSend

• BswMTriggerSlaveRTEStop

• BswMTriggerStartUpPhase2

• BswMUserCallout




R4.1 Rev 3

2. PPorts typed by a ModeSwitchInterface: SwitchPort For each containerof this type the BswM has to create a corresponding PPort in its Service Com-ponent Description if it is referenced by a RteSwitch action.

3. ProvidedModeDeclarationGroupPrototypes SwitchPort: For eachcontainer of this type the BswM has to create a corresponding ProvidedMod-eDeclarationGroupPrototype in the role providedModeGroup in its BasicSoftware Module Description if the SwitchPort is referenced by a SchMSwitchaction. In this case the BswM also acts as a mode manager, but the ModeMa-chineInstance is maintained by the Schedule Manager.

3.2.2 Definition of the interface in pseudo code

The following paragraphs define the interface of the BswM in pseudo code.

3.2.2.1 Mode switch and mode request interfaces

An example of the BswM configuration of ModeSwitchInterfaces is shown in List-ing 3.1. There is a ModeDeclarationGroup and a ModeSwitchInterface cre-ated. The ModeSwitchInterface uses the defined ModeDeclarationGroup asprototype where exampleModes is the short name of the ModeSwitchInterface.

Listing 3.1: Mode switch interface for the overall mode of a ECUmodeGroup MDG_ApplicationModes {

APP_ACTIVE,APP_STARTING,APP_INACTIVE

}

interface modeSwitch MSIF_ApplicationModes {mode MDG_ApplicationModes appMode

}

A configuration of a mode request interface that corresponds to the Mod-eSwitchInterface of Listing 3.1 is shown as example in Listing 3.2. Out of thisBswM configuration an Arxml description will be created which includes the modedeclarations and interfaces. An excerpt of that arxml is shown in 3.3.

Listing 3.2: Declaration of a Mode request interface

enum ENUM_ApplicationModes{ModeA,ModeB,ModeC

}

interface senderReceiver exampleModeRequestPort {data ENUM_ApplicationsModes exampleModeRequest

}




R4.1 Rev 3

Listing 3.3: Excerpt of the mode request interface’s ARXML description<SENDER-RECEIVER-INTERFACE>

<SHORT-NAME>exampleModeRequestPort</SHORT-NAME><IS-SERVICE>false</IS-SERVICE><DATA-ELEMENTS><VARIABLE-DATA-PROTOTYPE>

<SHORT-NAME>exampleModeRequest</SHORT-NAME>...<TYPE-TREF DEST="APPLICATION-PRIMITIVE-DATA-TYPE">ENUM_ApplicationModes

</TYPE-TREF></VARIABLE-DATA-PROTOTYPE></DATA-ELEMENTS>

</SENDER-RECEIVER-INTERFACE>

...

<APPLICATION-PRIMITIVE-DATA-TYPE><SHORT-NAME>ENUM_ApplicationModes</SHORT-NAME><CATEGORY>VALUE</CATEGORY><SW-DATA-DEF-PROPS>

<SW-DATA-DEF-PROPS-VARIANTS><SW-DATA-DEF-PROPS-CONDITIONAL>

<COMPU-METHOD-REF DEST="COMPU-METHOD">ENUM_ApplicationModes_def</COMPU-METHOD-REF>

</SW-DATA-DEF-PROPS-CONDITIONAL></SW-DATA-DEF-PROPS-VARIANTS>

</SW-DATA-DEF-PROPS></APPLICATION-PRIMITIVE-DATA-TYPE>

...

<COMPU-METHOD><SHORT-NAME>ENUM_ApplicationModes_def</SHORT-NAME><CATEGORY>TEXTTABLE</CATEGORY><COMPU-INTERNAL-TO-PHYS><COMPU-SCALES>

<COMPU-SCALE><LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT><UPPER-LIMIT INTERVAL-TYPE="CLOSED">0</UPPER-LIMIT><COMPU-CONST>

<VT>ModeA</VT></COMPU-CONST></COMPU-SCALE><COMPU-SCALE><LOWER-LIMIT INTERVAL-TYPE="CLOSED">1</LOWER-LIMIT><UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT><COMPU-CONST>

<VT>ModeB</VT></COMPU-CONST></COMPU-SCALE><COMPU-SCALE><LOWER-LIMIT INTERVAL-TYPE="CLOSED">2</LOWER-LIMIT><UPPER-LIMIT INTERVAL-TYPE="CLOSED">2</UPPER-LIMIT><COMPU-CONST>

<VT>ModeC</VT>




R4.1 Rev 3

</COMPU-CONST></COMPU-SCALE>

</COMPU-SCALES></COMPU-INTERNAL-TO-PHYS>

</COMPU-METHOD>

Every mode request to the BswM has to be mapped to an restricted set of values,which allows the integrator the define the arbitration rules.

3.2.2.2 ModeRequestPorts defined by the standardized interface of the BswM

In the BswM configuration, the mode request sources have to be defined. The fol-lowing ModeRequestPorts are implicitly defined by API of the BswM. This subsectionsummarizes the port interface.

The following ModeDeclarationGroups are defined in the particular SWS docu-ments of the AUTOSAR specification as C-Enums. Nevertheless they are referencedhere in form of BswM configurations which act as a base for the rest of this document.Refer to the definition of C-Enums in the SWS documents for the definition of modes.

3.2.2.2.1 BswMComMIndication

Purpose: Function called by ComM to indicate its current state.

Signature: void BswM_ComM_CurrentMode(NetworkHandleType Network,ComM_ModeType RequestedMode

)

Modes: modeGroup ComM_ModeType

Example: request ComMIndication ComM_Mode_Channel1 {processing IMMEDIATEinitialValue COMM_NO_COM_NO_PENDING_REQUESTsource MyComM.ComMChannel1

}

Note: This ModeRequestSource has to be created once for each ComM-Channel identified by the Network parameter.

3.2.2.2.2 BswMComMPncRequest

Purpose: Function called by ComM to indicate the current state of a partialnetwork.

Signature: void BswM_ComM_CurrentPNCMode(PNCHandleType PNC,




R4.1 Rev 3

ComM_PncModeType CurrentPncMode)

Modes: modeGroup ComM_PncModeType

Example: request ComMPncRequest PNC1 {processing IMMEDIATEinitialValue PNC_NO_COMMUNICATIONsource MyComM.ComMPnc1

}request ComMPncRequest PNC2 {

processing IMMEDIATEinitialValue PNC_NO_COMMUNICATIONsource MyComM.ComMPnc2

}request ComMPncRequest PNC3 {

processing IMMEDIATEinitialValue PNC_NO_COMMUNICATIONsource MyComM.ComMPnc3

}

Note: This ModeRequestSource has to be created once for each partialnetwork.

3.2.2.2.3 BswMDcmComModeRequest

Purpose: Function called by DCM to indicate the current state of Communica-tionControl.

Signature: void BswM_Dcm_CommunicationMode_CurrentState(NetworkHandleType Network,Dcm_CommunicationModeType RequestedMode

)

Modes: modeGroup Dcm_CommunicationModeType

Example: request DcmComModeRequestBswM_Dcm_CommunicationMode_CurrentState {processing IMMEDIATEinitialValue DCM_ENABLE_RX_TX_NORMnetwork "network1"

}

3.2.2.2.4 BswMCanSMIndication

Purpose: Function called by CanSM to indicate its current state.

Signature: void BswM_CanSM_CurrentState(NetworkHandleType Network,CanSM_BswMCurrentStateType CurrentState

)




R4.1 Rev 3

Modes: modeGroup CanSM_BswMCurrentStateType

Example: request CanSMIndication CanSM_Can1 {processing IMMEDIATEinitialValue CANSM_BSWM_NO_COMMUNICATIONsource MyComM.CanNet1

}

request CanSMIndication CanSM_Can2 {processing IMMEDIATEinitialValue CANSM_BSWM_NO_COMMUNICATIONsource MyComM.CanNet2

}

Note: This ModeRequestSource has to be created once for each CANchannel.

3.2.2.2.5 BswMEthSMIndication

Purpose: Function called by EthSM to indicate its current state.

Signature: void BswM_EthSM_CurrentState(NetworkHandleType Network,EthSM_NetworkModeStateType CurrentState

)

Modes: modeGroup EthSM_NetworkModeStateType

Example: request EthSMIndication EthSM_Network1 {processing IMMEDIATEinitialValue ETHSM_NO_COMMUNICATIONsource MyComM.EthSmNetwork

}

Note: This ModeRequestSource has to be created once for each ethernetchannel.

3.2.2.2.6 BswMFrSMIndication

Purpose: Function called by FrSM to indicate its current state.

Signature: void BswM_FrSM_CurrentState(NetworkHandleType Network,FrSM_BswM_StateType CurrentState

)

Modes: modeGroup FrSM_BswM_StateType

Example: request FrSMIndication FrSM_BswM_StateType {processing IMMEDIATEinitialValue FRSM_BSWM_READY




R4.1 Rev 3

source MyComM.EthSmNetwork}

Note: This ModeRequestSource has to be created once for each FlexRaycluster.

3.2.2.2.7 BswMLinSMIndication

Purpose: Function called by LinSM to indicate its current state.

Signature: void BswM_LinSM_CurrentState(NetworkHandleType Network,LinSM_ModeType CurrentState

)

Modes: modeGroup LinSM_ModeType

Example: request LinSMIndication LinSM_CurrentState {processing IMMEDIATEinitialValue LINSM_NO_COMsource MyComM.LinSMChannel

}

Note: This ModeRequestSource has to be created once for each Lin chan-nel.

3.2.2.2.8 BswMEcuMIndication

Purpose: Function called by the ECUM with fixed state machine to indicate itscurrent state.

Signature: void BswM_EcuM_CurrentState(EcuM_StateType CurrentState

)

Modes: modeGroup EcuM_StateType

Example: request EcuMIndication EcuM_State {processing IMMEDIATEinitialValue ECUM_STATE_STARTUP

}

3.2.2.2.9 BswMEcuMWakeupSource

Purpose: Function called by the ECUM to indicate the current state of thewakeup sources.

Signature: void BswM_EcuM_CurrentWakeup(EcuM_WakeupSourceType source,




R4.1 Rev 3

EcuM_WakeupStatusType state)

Modes: modeGroup EcuM_WakeupStatusType

Example: request EcuMWakeupSource EcuM_WakeupSource {processing IMMEDIATEinitialValue ECUM_WKSTATUS_NONEsource MyEcuM.EcuMWakeupSource1

}

Note: This ModeRequestSource has to be created once for each Wakeupsource.

3.2.2.2.10 BswMLinScheduleIndication

Purpose: Function called by LinSM to indicate the currently active scheduletable for a specific LIN channel.

Signature: void BswM_LinSM_CurrentSchedule(NetworkHandleType Network,LinIf_SchHandleType CurrentSchedule

)

Modes: The reported modes depend on the configured schedules in the LinStatemanager.

Example: request LinScheduleIndication LinSM1_CurrentSchedule {processing IMMEDIATEinitialValue TBDsource MyLinSM.LinSMChannel

}

3.2.2.2.11 BswMLinTpModeRequest

Purpose: Function called by LinTP to request a mode for the correspondingLIN channel. The LinTp_Mode mainly correlates to the LIN scheduletable that should be used.

Signature: void BswM_LinTp_RequestMode(NetworkHandleType Network,LinTp_Mode LinTpRequestedMode

)

Modes: modeGroup LinTp_Mode

Example: request LinTpModeRequest LinTp_Mode {processing IMMEDIATEinitialValue LINTP_APPLICATIVE_SCHEDULEsource MyLinIF.config0.LinIFChannel

}




R4.1 Rev 3

3.2.2.2.12 BswMNvMJobModeIndication

Purpose: Indicates the current status of the multiblock job. The job is iden-tified via BswMNvmService, e.g. 0x0c for NvmReadAll, 0x0d forNvmWriteAll.

Signature: void BswM_NvM_CurrentJobMode(uint8 ServiceId,NvM_RequestResultType CurrentJobMode

)

Modes: modeGroup NvM_RequestResultType

Example: request NvMJobModeIndication NvMWriteAllJobMode {service WriteAllinitialValue NVM_BLK_NOT_OKprocessing IMMEDIATE

}

request NvMJobModeIndication NvMReadAllJobMode {service ReadAllinitialValue NVM_BLK_NOT_OKprocessing IMMEDIATE

}

3.2.2.2.13 BswMNvMRequest

Purpose: Via this Mode Request Source the NvM indicates the current statusof the specified block.

Signature: void BswM_NvM_CurrentBlockMode(NvM_BlockIdType Block,NvM_RequestResultType CurrentBlockMode

)

Modes: modeGroup NvM_RequestResultType

3.2.2.2.14 BswMJ1939NmIndication

Signature: void BswM_J1939Nm_StateChangeNotification(NetworkHandleType nmNetworkHandle,uint8 Node,Nm_StateType nmCurrentState

)

Modes: modeGroup Nm_StateType

Example: request BswMJ1939NmIndication J1939NmState {network "Channel1"




R4.1 Rev 3

node "Node1"initialValue NM_STATE_UNINITprocessing IMMEDIATE

}

Note: This ModeRequestSource has to be configured for each channelmanaged by J1939 network management. This type of Mode Re-quest Source is currently not supported by ARText.

3.2.2.2.15 BswMWdgMRequestPartitionReset

Signature: void BswM_WdgM_RequestPartitionReset(ApplicationType Application

)

Modes: modeGroup WdgM_PartitionResetType

Example: request WdgMRequestPartitionReset WdgM_RequestResetPart1 {processing IMMEDIATEinitialValue WDGM_PARTITION_RESET_NOTREQUESTEDsource MyEcuC.eCucPartition

}

Note: This ModeRequestSource has to be created once for each partitionfor which a reset can be requested by the Watchdog Manager mod-ule.

3.2.2.2.16 BswMJ1939DcmBroadcastStatus

Signature: void BswM_J1939DcmBroadcastStatus(uint16 networkMask)

Modes: modeGroup J1939DcmBroadcastStatusType

Example: request BswMJ1939DcmBroadcastStatusJ1939BroadcastStatusChannel1 {processing IMMEDIATEinitialValue NETWORK_DISABLEDsource MyComM.CanNet1

}

Note: This is a notification of the desired broadcast status per network, trig-gered via DM13.

3.2.2.3 Configurable ModeRequestPorts

Besides the interface, which is defined by the standardized interface of the BswM,additional mode request ports can be defined via the configuration parameters.




R4.1 Rev 3

E.g it is necessary for the interaction with applications, that an application softwarecomponent at least notifies the BswM about it’s current state. This can be achieved bydefinition of a ModeRequestPort as shown in Listing 3.4. The BswM will than createa corresponding RPort typed by a SenderReceiverInterface.

Listing 3.4: Application ModeRequestPort

request SwcModeRequest App1ModeRequest {source MSIF_ApplicationModes.appModeprocessing IMMEDIATEinitialValue ModeA

}

Note that the reference to a ModeDeclarationGroupPrototype can be misleading.The meaning is that the BswM creates a SenderReceiverInterface containing aVariableDataPrototype. The SwDataDefProps of this VariableDataProto-type refer to a CompuMethod, which defines an enumeration corresponding die to thereferred ModeDeclarationGroupPrototype.

Listing 3.5: Application ModeNotification

request SwcModeNotification App1ModeNotification {source MSIF_ApplicationModes.appModeprocessing IMMEDIATEinitialValue ModeA

}

Listing 3.5 shows the declaration of a mode notification port. Note that in contrast to3.4 the BswM will generate a RPort typed by a ModeSwitchInterface in this case.The BswM then gets informed via a ModeSwitchNotification if the mode managerinitiates a mode switch.

Listing 3.6: BasicSoftwareModeNotificationrequest BswModeNotification EcuMode {

source MSIF_EcuMode.ecuModeprocessing IMMEDIATEinitialValue ECU_STARTUP_ONE

}

Listing 3.6 shows the declaration of a mode notification port. If such a port is config-ured, the BswM configuration tool will create a requiredModeGroup ModeDecla-rationGroupPrototype, so that the BswM gets informed of mode switches via theSchedule Manager, if the corresponding mode manager initiates a mode switch with acall to SchM_Switch API.

3.2.2.4 Configurable ModeSwitchPorts

In the configuration of the BswM contains BswMSwitchPorts. These containerscontain references to mode switch interfaces. If a BswMSwitchPorts is ref-erenced by a BswMSchMSwitch action the module generator of the BswM shall create




R4.1 Rev 3

a providedModeGroup ModeDeclarationGroupPrototype. If a BswMSwitch-Ports is referenced by a BswMRteSwitch action the module generator of the BswMshall create a PPort typed by the corresponding ModeSwitchInterface. 3.7 showan example for a mode switch port.

Listing 3.7: Example for a configurable mode switch portswitchport EcuMode {

modeSwitchinterface MSIF_EcuMode}

3.2.3 Configuration of the BswM behavior

The behavior of the BswM is specified via rules and action lists. A rule is a logical ex-pression, which combines the current values of ModeRequestPorts. The evaluationof each rule either results in the execution of its true or false action lists.

The ModeControlContainer contains these ActionLists. An ActionList canconsist of a set of atomic actions, other “nested” ActionLists or it can reference(nested) rules which are then evaluated in the context of this Actionlist.

The following example shows a simple rule, which activates the IPDU Groupsof a dedicated CAN channel. According to this rule, the BswM has to pro-vide a ModeRequestPort of type CanSMIndication named Can1_Indication.This is a ModeRequest from a basic software module in this case from theCan State manager. In code this ModeRequestPorts corresponds to the APIBswM_CanSM_CurrentState as described in [SWS_BswM_00049] in [5]. Thesource parameter identifies the network to which this ModeRequestSourcePortbelongs to. It’s up to the configuration tool of the BswM to allocate the right parametersfor the API corresponding to the referenced ECUC Container.

The value of the ModeRequestSourcePort initially isCAN_SM_BswM_NO_COMMUNICATION.

processing immediate means that every evaluation rule, which refers to this Mod-eRequestSourcePort shall immediately be processed. If this parameter would bedeferred in case of a ModeRequest, the evaluation of rules would be delayed untilthe next run of the main function of the BswM.

The following example shows an arbitration rule called canIPDUActivation. Theoverall content is rather self explanatory. The initial parameters specifies that theinitial result of the rule evaluation is false.

Listing 3.8: Example for a rulerule checkApp1Request initially false {if ( App1ModeRequest == MDG_ApplicationModes.ModeA && EcuMode ==MDG_EcuMode.ECU_RUN) {

actionlist checkApp1RequestTrueActions}

}




R4.1 Rev 3

actions checkApp1RequestTrueActions on condition {ComMAllowCom MyComM.CanNet1 trueSchMSwitch EcuMode : ECU_RUN

}

At which point in time a rule is executed, after an event has occurred depends onthe parameter BswMActionListExecution. Either it is executed every time therule is evaluated with the corresponding result, or only when the evaluation result haschanged from the previous evaluation. This is called triggered respectively condi-tional execution.

Table 3.1 gives an overview in which situations an ActionList is executed or not.Triggered ActionLists are executed (triggered) if the result of the rule evaluationchanges. Conditional ActionLists depend only on the current result (condition) ofthe evaluation independent if it has changed or not.

Table 3.1: Execution of Action Lists depending on parameter BswMActionListExecu-tion

eval. result(old) -> (new) true -> true true -> false false -> false false -> true

TrueActionList CONDITION - - TRIGGERED/CONDITION

FalseActionList - TRIGGERED/CONDITION CONDITION -

3.3 ECU state management

During startup and shutdown the task of the BswM is to initialize all basic softwaremodules in a similar way as it is done by the ECUM in older AUTOSAR releases. Toachieve this the following ModeDeclarationGroup is defined, which indicates theoverall state of the ECU to application software components and is used for internalrule arbitration.

The modes of this ModeDeclarationGroup are named similar to the states of theECUM with fixed state machine. Nevertheless they have due to several reasons notexactly the same semantics.

Listing 3.9: ModeDeclarationGroup for overall ECU state managementmodeGroup MDG_EcuMode {

ECU_RUN,ECU_APP_RUN,ECU_APP_POST_RUN,ECU_GO_SLEEP,ECU_GO_OFF_ONE,ECU_SLEEP,ECU_GO_OFF_TWO,ECU_STARTUP_ONE,ECU_STARTUP_TWO,ECU_RESET_READY

}




R4.1 Rev 3

interface modeSwitch MSIF_EcuMode {mode MDG_EcuMode ecuMode

}

The initial mode of this ModeDeclarationGroup is ECU_STARTUP_ONE.

3.3.1 Startup

The ECUM starts the operating system and initializes in its post OS sequence theSchedule manager and the BswM. The BswM then has to take care, that all necessaryinit routines of the basic software modules are called and that the RTE is started.

In this scenario it is expected that the BswM has the following providedModeGroup.The purpose of this modeGroup is to track the current state/mode of the ECU similarto the states of the ECU State manager in previous AUTOSAR releases.

Rule InitBlockII specifies the initialization of basic drivers to access the NVRAMand initiates NvM_ReadAll. As the EcuMode source has the processing attribute setto DEFERRED this rule will be evaluated every time the main function of the BswM iscalled. After the first run it sets the EcuMode to ECU_STARTUP_TWO so that the actionlist will never be invoked again.

If the NvMReadAll job is finsihed the NvMReadAllFinished rule is triggered, whichinitiates the remaining initialization and switches the EcuMode to ECU_RUN.

Listing 3.10: Rules and ActionLists for Startuprule InitBlockII initially false {if ( EcuMode == MDG_EcuMode.ECU_STARTUP_ONE ) {

actionlist InitBlockIIActions}

}

actions InitBlockIIActions on condition {custom "Spi_Init(null)"custom "Eep_Init(null)"custom "Fls_Init(null)"custom "NvM_Init(null)"SchMSwitch EcuMode : ECU_STARTUP_TWOcustom "NvM_ReadAll()"

}

rule NvMReadAllFinished initially false {if ( NvMReadAllJobMode == NVM_REQ_OK && EcuMode == MDG_EcuMode.ECU_STARTUP_TWO) {actionlist NvMReadAllFinishedActions

}}

actions NvMReadAllFinishedActions on condition {custom "Can_Init(null)"




R4.1 Rev 3

custom "CanIf_Init(null)"custom "CanSM_Init(null)"custom "CanTp_Init(null)"custom "Lin_Init(null)"custom "LinIf_Init(null)"custom "LinSM_Init(null)"custom "LinTp_Init(null)"custom "Fr_Init(null)"custom "FrIf_Init(null)"custom "FrSM_Init(null)"custom "FrTp_Init(null)"custom "PduR_Init(null)"custom "CANNM_Init(null)"custom "FrNM_Init(null)"custom "NmIf_Init(null)"custom "IpduM_Init(null)"custom "COM_Init(null)"custom "DCM_Init(null)"custom "ComM_Init(null)"custom "DEM_Init(null)"custom "StartRte()"SchMSwitch EcuMode : ECU_RUN

}

When the RTE is started the runnables will be started. Now it is up to the applica-tion to keep the ECU running. To achieve this the BswM can for example provide aModeRequestPort as depicted in example 3.4. For the further reading is is expected,that the application software requests the mode APP1_ACTIVE from the BswM. If thismode is requested the BswM shall not shutdown the ECU.

Listing 3.11: Application runs, enable communicationrule checkApp1Request initially false {if ( App1ModeRequest == MDG_ApplicationModes.ModeA && EcuMode ==MDG_EcuMode.ECU_RUN) {

actionlist checkApp1RequestTrueActions}

}

actions checkApp1RequestTrueActions on condition {ComMAllowCom MyComM.CanNet1 trueSchMSwitch EcuMode : ECU_RUN

}

3.3.2 Run

As the BswM is a highly flexible module it depends to a high extend to the integrator,how it is determined if an ECU shall shut down or not. Many different variants are con-ceivable. This document proposes an approach, which is quite similar to the conceptof the ECUM in AUTOSAR R3.1. The general concept is, that a ECU keeps running aslong as at least one application software component requests the run state.




R4.1 Rev 3

The information if an application can be shut down in a certain mode has to be pro-vided by the software component developer. Example 3.12 shows a simplified rule foran ECU with one software component. If switches its mode to INACTIVE the BswMinitiates the shutdown sequence.

Listing 3.12: Initiate shutdown, if no application wants to run any morerule checkApp1Request initially false {

if ( App1ModeRequest == MDG_ApplicationModes.APP_INACTIVE && EcuMode ==MDG_EcuMode.ECU_RUN) {actionlist checkApp1RequestActions

}}

actions checkApp1RequestActions on condition {ComMAllowCom ArMmExample.EcuC.MyComM.ComMChannel1 falseSchMSwitch EcuMode : ECU_APP_POST_RUN

}

3.3.3 Shutdown

In state ECU_APP_POST_RUN the BswM waits until all channels report, that no requestsare pending any more. The rule in listing 3.12 is triggered every time the mode of aComM channel changes. If there are mmultiple ComM channels, they have to becombined to a single expression.

Listing 3.13: Shutdown sequencerule InitiateShutdown initially false {

if ( ComM_Mode_Channel1 == COMM_NO_COM_REQUEST_PENDING && EcuMode ==MDG_EcuMode.ECU_APP_POST_RUN) {

actionlist InitiateShutdownActions}

}

actions InitiateShutdownActions on condition {custom "Dem_Shutdown(null)"custom "Rte_Stop()"custom "ComM_DeInit()"SchMSwitch EcuMode : ECU_GO_OFF_ONEcustom "NvM_WriteAll()"

}

rule NvMWriteAllFinished initially false {if ( NvMWriteAllJobMode == NVM_BLK_OK && EcuMode == MDG_EcuMode.ECU_GO_OFF_ONE) {actionlist NvMWriteAllFinishedTrueActions

}}

actions NvMWriteAllFinishedTrueActions on condition {custom "EcuM_SelectShutdownCause(ECUM_CAUSE_ECU_STATE)"custom "EcuM_GoDown(MODULE_ID)"

}




R4.1 Rev 3

Note that the in the configuration of the ECUM the module id of the BswM has to beadded as a valid user to EcuMFlexUserConfig.

3.3.4 Sleep

Entering a sleep state is similar to the shutdown sequence 3.12 except thatEcuM_GoHalt resp. EcuM_GoPoll is called instead of EcuM_GoDown.

3.3.5 Wakeup

Example 3.14 shows a rule which starts the ECU only, if a certain wakeup event, iden-tified by EcuM_WakeupSource has occured. Otherwise the ECU will be immediatelyshut down.

Listing 3.14: start sequence with wakeup checkrule InitBlockII initially false {if ( EcuMode == MDG_EcuMode.ECU_STARTUP_ONE && EcuM_WakeupSource ==ECUM_WKSTATUS_VALIDATED) {actionlist InitBlockIITrueActions

} else {actionlist InitBlockIIFalseActions

}}

actions InitBlockIITrueActions on condition {custom "Spi_Init(null)"custom "Eep_Init(null)"custom "Fls_Init(null)"custom "NvM_Init(null)"SchMSwitch EcuMode : ECU_STARTUP_TWOcustom "NvM_ReadAll()"

}actions InitBlockIIFalseActions on condition {custom "EcuM_GoDown(MODULE_ID)"

}

3.4 Communication Management

Besides parts of the ECU state management, the BswM is also responsible for partsof the communication management. This section describes the functionality of theBswM, which is related to the Communication Stack of AUTOSAR. This covers but isnot restricted to the following uses cases.

• Starting and stopping of IPDU Groups in general

• Partial Networking




R4.1 Rev 3

• Diagnostic use cases which influence the communication of an ECU. e.g. itmight be necessary to set the FlexRay State manager to passive mode viaFrSm_SetEcuPassive() when requested by an application.

To fulfill the requested functionality the BswM has ModeRequestSources to

• the Communication Manager

• the bus state managers

• AUTOSAR COM

3.4.1 Startup and Shutdown

Besides the initialization of the communication stack the BswM can be configured toinitialize further modules or execute customs actions depending on the ECU’s needs.Due to the flexibility of the BswM it is also possible, that after a wake up event only apart of the communication stack is started.

Analogue to Startup, it is possible to configure additional actions to be executed onshutdown.

3.4.2 I-PDU Group Switching

For the I-PDU group switching it is expected that there exists for each channel a dedi-cated I-PDU group for outgoing and incoming I-PDUs in COM. AUTOSAR COM takescare that an I-PDU is active(started) if at least one I-PDU group containing this I-PDUis active.

To illustrate how the I-PDUs of an ECU can be managed the following scenario iscreated. The examplary ECU shall have two CAN channels and three partial networks.The mode request ports for the channels are named CanSM_Can1 and CanSM_Can2,the request sources for the partial networks are named PNC1, PNC2 and PNC3.

I-PDUs of PNC1 shall be communicated only over Channel1. I-PDUs of PNC3 shallbe communicated over Channel1 and Channel2. I-PDUs of PNC3 shall be commu-nicated only over Channel2.

In case of an indication by a bus state manager the BswM shall check, which partialnetworks are requested.

Listing 3.15: Active wakeup on channelrule activeWakeupChannel1 initially false {if ( CanSM_Can1 == CANSM_BSWM_FULL_COMMUNICATION) {

actionlist activeWakeupChannel1Actions}

}




R4.1 Rev 3

actions activeWakeupChannel1Actions on condition {rule pnc1requestedrule pnc2requestedrule pnc3requested

}

rule activeWakeupChannel2 initially false {if ( CanSM_Can2 == CANSM_BSWM_FULL_COMMUNICATION &&

PNC2 != PNC_REQUESTED &&PNC3 != PNC_REQUESTED) {

actionlist activeWakeupChannel2Actions}

}

actions activeWakeupChannel2Actions on condition {rule pnc1requestedrule pnc2requestedrule pnc3requested

}

If a bus state manager reports that the bus is going silent the BswM stop the corre-sponding I-PDU groups. If the channel is part of a partial network the whole partialnetwork has to be stopped.

Listing 3.16: CanSM reports SILENT_COMMUNICATION or NO_COMMUNICATIONrule stopComChannel1 initially false {if ( CanSM_Can1 == CANSM_BSWM_SILENT_COMMUNICATION ||

CanSM_Can1 == CANSM_BSWM_NO_COMMUNICATION) {

actionlist stopComChannel1Actions}

}

actions stopComChannel1Actions on condition {PduGroupSwitch {

init truedisable ArMmExample.EcuC.MyCom.CAN1IPDUS, ArMmExample.EcuC.MyCom.PNC1IPDUS, ArMmExample.EcuC.MyCom.PNC2IPDUS

}}

rule stopChannel2 initially false {if ( CanSM_Can2 == CANSM_BSWM_SILENT_COMMUNICATION ||

CanSM_Can2 == CANSM_BSWM_NO_COMMUNICATION) {actionlist stopChannel2Actions

}}

actions stopChannel2Actions on condition {PduGroupSwitch {

init true




R4.1 Rev 3

disable ArMmExample.EcuC.MyCom.CAN2IPDUS, ArMmExample.EcuC.MyCom.PNC2IPDUS, ArMmExample.EcuC.MyCom.PNC3IPDUS

}}

In case that a single partial network is going down the IPDU group representing thisnetwork has to be switched off.

Listing 3.17: PNC reports NO_COMMUNICATIONrule pnc1nocom initially false {if ( PNC1 == PNC_NO_COMMUNICATION ) {

actionlist pnc1nocomTrueActions}

}

actions pnc1nocomActions on condition {PduGroupSwitch {

init truedisable ArMmExample.EcuC.MyCom.PNC1IPDUS

}DeadlineMonitoring {

disable ArMmExample.EcuC.MyCom.PNC1IPDUS}

}

rule pnc2nocom initially false {if ( PNC2 == PNC_NO_COMMUNICATION ) {

actionlist pnc2nocomTrueActions}

}





}rule pnc3nocom initially false {if ( PNC3 == PNC_NO_COMMUNICATION ) {

actionlist pnc3nocomActions}

}








R4.1 Rev 3

}

If a partial network is requested the IPDU group is turned on.

Listing 3.18: PNC reports PNC_REQUESTED or PNC_READY_SLEEPrule pnc1requested initially false {if ( PNC1 == PNC_REQUESTED ||

PNC1 == PNC_READY_SLEEP ) {actionlist pnc1requestedActions

}}

actions pnc1requestedActions on condition {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.PNC1IPDUS

}}rule pnc2requested initially false {if ( PNC2 == PNC_REQUESTED ||


}}



}}rule pnc3requested initially false {if ( PNC3 == PNC_REQUESTED ||


}}



}}

In case of an indication that the partial network statemachine has switched to the pre-pare sleep state only the deadline monitoring of the corresponding IPDU groups shallbe turned off but the IPDUs are still transmitted until the state PNC_OFF is reached.

Listing 3.19: PNC reports PNC_PREPARE_SLEEPrule pnc1preparesleep initially false {if (PNC1 == PNC_PREPARE_SLEEP){

actionlist pnc1preparesleepActions




R4.1 Rev 3

}}

actions pnc1preparesleepActions on condition {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.PNC1IPDUS}

DeadlineMonitoring {disable ArMmExample.EcuC.MyCom.PNC1IPDUS}

}

rule pnc2preparesleep initially false {if (PNC2 == PNC_PREPARE_SLEEP ){

actionlist pnc2preparesleepActions}

}

actions pnc2preparesleepActions on condition {PduGroupSwitch {init true

enable ArMmExample.EcuC.MyCom.PNC2IPDUS}


}

rule pnc3preparesleep initially false {if (PNC3 == PNC_PREPARE_SLEEP ){

actionlist pnc3preparesleepActions}

}

actions pnc3preparesleepActions on condition {PduGroupSwitch {init true

enable ArMmExample.EcuC.MyCom.PNC3IPDUS}


}

3.4.3 J1939 Networkmanagement

In contrast to current AUTOSAR network management, the task of J1939 network man-agement is not to handle sleep and wake-up of ECUs, but to assign unique addressesto each node represented by an ECU.




R4.1 Rev 3

This is achieved by sending the AddressClaimed (AC, 0x0EE00) parameter group atstart-up, which announces the desired address. If another node claims the same ad-dress, and has higher priority, the node has to go silent after sending the Cannot-ClaimAddress parameter group (AC with null address as SA), or try to use anotheraddress.

To support this use case the BswM is extended to accept state change indications fromthe J1939Nm via the API function BswM_J1939Nm_StateChangeNotification()(see also 3.2.2.2.14).

Depending on the state indicated by the network management the BswM needs toswitch ComIPduGroups of COM, PduRRoutingPathGroups of PduR, and general re-quest handling of the J1939Rm.

The first two actions are realized via BswMPduGroupSwitch- andBswMPduRouterControl -actions. The J1939 Request Manager shall be switchedusing the BswMJ1939Rm action.

COM is expected to have IPDU groups containing all locally received and transmittedI-PDUs for each network. The PduR shall be configured in the same way, havingRoutingPathGroups for all locally received and transmitted IPDUs for each channel,excluding the received I-PDU for the Request message forwarded to the J1939Rm.

The BswM must then be configured to switch on and off the aforementioned IPDUgroups and PduRRoutingPathGroups depending on the reported NM states, as well asgeneral request handling of the J1939 Request Manager. The following rule shows theactions of the BswM depending on the NM states.

Listing 3.20: Rule to implement network management according to J19392

rule J1939_nm_normal_operation initially false {if ( J1939NmState == NM_STATE_NORMAL_OPERATION ) {

actionlist J1939NormalOperationActions}}

actions J1939NormalOperationActions on condition {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.J1939IPDUS

}PduRoute enable J1939_RoutingPathcustom "J1939Rm_SetState(J1939RM_STATE_ONLINE)"custom "Xcp_SetTransmissionMode(CHANNEL1,XCP_TX_ON)"

}

rule J1939_nm_offline initially false {if ( J1939NmState != NM_STATE_NORMAL_OPERATION ) {

actionlist J1939OfflineActions}}

actions J1939OfflineActions on condition {




R4.1 Rev 3

PduGroupSwitch {disable ArMmExample.EcuC.MyCom.J1939IPDUS

}PduRoute disable J1939_RoutingPathcustom " J1939Rm_SetState(J1939RM_STATE_OFFLINE)"custom "Xcp_SetTransmissionMode(CHANNEL1,XCP_TX_OFF)"

}

3.4.4 J1939 diagnostic mode management

In addition to address assignment the BswM has also to supervise the sending ofbroadcast messages in a J1939 environment. Each IPDU group represents the broad-cast messages (J1939 PGs with PDU2 format PGN or PDU1 format PGN and broad-cast destination address) of one network.

For this purpose it is also expected that COM contains one IPDU group for each chan-nel, which contains the broadcast messages of this ECU.

Listing 3.21: Rule to implement broadcast management according to J1939rule J1939_broadcast_management initially false {

if ( BswMJ1939DcmBroadcastStatus == NETWORK_ENABLED) {actionlist J1939ActivateBroadcastActions

} else {actionlist J1939DeactivateBroadcastActions

}}

actions J1939ActivateBroadcastActions on condition {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.J1939BroadcastIPDUS

}}

actions J1939DeactivateBroadcastActions on condition {PduGroupSwitch {

disable ArMmExample.EcuC.MyCom.J1939BroadcastIPDUS}

}

3.4.5 Pretended Networking

When implementing the Pretended Networking concept, the BswM should be user-configured to support the mode management requirements. The following subchapterscontain recommendations regarding the BswM configuration for Pretended Networking.

2It is recommended to use the BswMJ1939Rm action instead of the custom calls. The custom callsare only used in this listing as they are not supported in the current ARText version.




R4.1 Rev 3

3.4.5.1 Activation of Pretended Networking

For the configuration of the activation of Pretended Networking the following aspectshave to be considered:

• The BswM should be configured to arbitrate the Mode Request. If there aredifferent ICOM Mode Requests received during the same arbitration cycle of theBswM, the request with the lowest ICOM Configuration ID should be used.

• The BswM should be configured to request FULL_COM in ComM in order to pre-vent ComM from deactivating the CAN transceiver when switching to PretendedNetworking (transceiver stays in CANTRCV_NORMAL).

• Pretended Networking needs to be supported by the BswM on a per channelbasis. For this, the BswM should be configured with separate sets of Request-s/Rules/Actions for each channel.

• BswM should switch to Pretended Networking if and only if all SWCs affected byactivation of Pretended Networking have requested a switch to Pretended Net-working by a ModeRequest for this channel.

• The configured rules in the BswM should only take action on valid requestedICOM Configuration IDs. Therefore the BSW configurator should setup rules andactions which only react to valid ICOM IDs, such as in the following pseudo codesample:

if(IcomConfigId == 0) doActionList1;if(IcomConfigId == 1) doActionList2;//ignore all other IcomConfigIds

• BswM should be configured to stop all I-PDU groups for a channel to be switchedto Pretended Networking.

• BswM should be configured to request activation of Pretended Networking in<bus>SM by calling <bus>SM_SetIcomConfiguration.

• BswM should be configured to handle a notification from <bus>SM (e.g. CanSmcalls Bswm_CanSm_CurrentIComConfiguration) if activation of Pretended Net-working was successful. This can be performed by means of the ModeRequest-Source "BswMCanSMIcomIndication".

• The BswM should notify the affected SWCs when an ICOM configuration hasbeen changed. In order to ensure this, the BswM should be configured to performmode switch indications.

• Errors in case of failures in changing the ICOM configuration should be configuredbased on a sub state via a BswM action list. The error occured can be accessedby evaluation of the BswMModeRequestSource "BswMCanSMIcomIndication".




R4.1 Rev 3

3.4.5.2 Deactivation of Pretended Networking

For the configuration of the deactivation of Pretended Networking the following aspectshave to be considered:

• The BswM should be configured to start the I-PDU groups assigned to a channelwhen Pretended Networking is deactivated for this channel.

• The BswM should be configured to call <bus>SM to deactivate Pretended Net-working after the I-PDU groups have been started.

• The BswM should be configured to report an error to DEM in case a deactivationof Pretended Networking was not possible.

• The BswM should be configured to request new ICOM configurations from<bus>SM.

• The BswM should notify the affected SWCs when an ICOM configuration hasbeen changed. In order to ensure this, the BswM should be configured to performmode switch indications.

• Errors in case of failures in changing the ICOM configuration should be configuredbased on a sub state via a BswM action list. The error occured can be accessedby evaluation of the BswMModeRequestSource "BswMCanSMIcomIndication".

3.5 Diagnostics

In AUTOSAR release 4.0.3 onwards the DCM is the overall mode manager for all di-agnostic use cases. The BswM is responsible to change the state of the other basicsoftware modules accordingly.

3.5.1 Diagnostic Session Control

For session control [SWS_Dcm_00777] in SWS_DiagnosticCommunicationManager[6] defines the following ModeDeclarationGroup as providedModeGroup Note:The mode names and values are derived from the Dcm configuration. This guideshows just an example.

Listing 3.22: ModeGroup for session control service of the DCMmodeGroup DcmDiagnosticSessionControl {

DefaultSession,ProgrammingSession,ExtendedDiagnosticSession,SafetySystemDiagnosticSession,AllSessionLevel

}

interface modeSwitch MSIF_DcmDiagnosticSessionControl {




R4.1 Rev 3

mode DcmDiagnosticSessionControl diagnosticSessionControl}

The DCM acting as a mode manager can inform other BSW modules about the cur-rent mode of the session control service and if needed set the basic software in thecorresponding mode. Listing 3.23 shows the corresponding mode switch interface.

Note that the same interface can also be used to inform the application software aboutthe current diagnostic session.

Listing 3.23: ModeRequestPort for session control service of the DCMrequest BswModeNotification DiagnosticSessionControl {

source MSIF_DcmDiagnosticSessionControl.diagnosticSessionControlprocessing IMMEDIATEinitialValue DefaultSession

}

3.5.2 ECU Reset

In case of ECU Reset, the interaction between DCM and BswM is more complex. TheSpecification of the Diagnostic Communication Manager [6] specifies for this purposethe interface as described in listing 3.24. Via this interface the DCM signals the BswMto

1. prepare the ECU to execute a specific reset.

2. to explicitly execute this reset.

Listing 3.24: Mode switch interface for ECU reset diagnostic servicemodeGroup DcmEcuReset{

NONE,HARD,KEYONOFF,SOFT,JUMPTOBOOTLOADER,JUMPTOSYSSUPPLIERBOOTLOADER ,EXECUTE

}

interface modeSwitch MSIF_DcmEcuReset {mode DcmEcuReset ecureset

}

[SWS_Dcm_00373] states that on reception of a request for UDS Service with thesub functions other than enableRapidPowerShutDown (0x04) or disableRapidPower-ShutDown (0x05), the DCM module shall switch the ModeDeclarationGroupPrototypeDcmEcuReset to the received resetType. After the mode switch is requested the DCMtriggers the start of the positive response message transmission.

According to [SWS_Dcm_00594] on the transmit confirmation (call toDcm_TpTxConfirmation) of the positive response, the DCM module shall trig-




R4.1 Rev 3

ger the mode switch of ModeDeclarationGroupPrototype DcmEcuReset toEXECUTE. By this final mode switch the DCM request the BswM to finally shutdownthe ECU and to to perform the reset.

Listing 3.25 depicts how the different reset szenarios spezified in the DCM can beconfigured in the DCM. Note that in the running example of this document the overallEcuMode is used to signal to the DCM that the ECU is ready to be reset. Dependingon the diagnostic service the DCM shall wait for this acknowledgment or switch imme-diately to the EXECUTE mode, which will cause the BswM to invoke EcuM_GoDown.

Listing 3.25: Ruleset to implement different reset szenariosrule DcmEcuResetHard initially false {if ( DcmEcuResetMode == DcmEcuReset.HARD) {

actionlist DcmEcuResetHardActions}

}

actions DcmEcuResetHardActions on condition {custom "EcuM_SelectShutdownTarget(ECU_RESET, ECUM_RESET_IO)"custom "EcuM_SelectShutdownCause(ECUM_CAUSE_DCM)"SchMSwitch EcuMode : ECU_RESET_READY

}

rule DcmEcuResetKeyOnOff initially false {if ( DcmEcuResetMode == DcmEcuReset.KEYONOFF) {

actionlist DcmEcuResetKeyOnOffActions}

}

actions DcmEcuResetKeyOnOffActions on condition {custom "EcuM_SelectShutdownTarget(ECU_RESET,ECUM_RESET_IO)"custom "EcuM_SelectShutdownCause(ECUM_CAUSE_DCM)"SchMSwitch EcuMode : ECU_RESET_READY

}rule DcmEcuResetSoft initially false {

if ( DcmEcuResetMode == DcmEcuReset.SOFT) {actionlist DcmEcuResetSoftActions

}}

actions DcmEcuResetSoftActions on condition {custom "EcuM_SelectShutdownTarget(ECU_RESET, ECUM_RESET_MCU)"custom "EcuM_SelectShutdownCause(ECUM_CAUSE_DCM)"SchMSwitch EcuMode : ECU_RESET_READY

}rule DcmEcuResetBootLoader initially false {

if ( DcmEcuResetMode == DcmEcuReset.JUMPTOBOOTLOADER) {actionlist DcmEcuResetBootLoaderActions

}}




R4.1 Rev 3

actions DcmEcuResetBootLoaderActions on condition {custom "EcuM_SelectShutdownTarget(ECU_RESET, ECUM_RESET_MCU)"custom "EcuM_SelectShutdownCause(ECUM_CAUSE_DCM)"custom "EcuM_SelectBootTarget(ECUM_BOOT_TARGET_OEM_BOOTLOADER)"SchMSwitch EcuMode : ECU_RESET_READY

}rule DcmEcuResetSupplierBootloader initially false {if ( DcmEcuResetMode == DcmEcuReset.JUMPTOSYSSUPPLIERBOOTLOADER ) {

actionlist DcmEcuResetSupplierBootloaderActions}

}

actions DcmEcuResetSupplierBootloaderActions on condition {custom "EcuM_SelectShutdownTarget(ECU_RESET, ECUM_RESET_MCU)"custom "EcuM_SelectShutdownCause(ECUM_CAUSE_DCM)"custom "EcuM_SelectBootTarget(ECUM_BOOT_TARGET_SYS_BOOTLOADER)"SchMSwitch EcuMode : ECU_RESET_READY

}

rule DcmEcuReset initially false {if ( DcmEcuResetMode == DcmEcuReset.EXECUTE ) {

actionlist DcmEcuResetActions}

}actions DcmEcuResetActions on condition {custom "EcuM_GoDown(MODULE_ID)"

}

3.5.3 Rapid Power Shutdown

On reception of a request for UDS Service with the sub functions enableRapidPower-Shutdown (0x04) or disableRapidPowerShutdown (0x05), the DCM module triggers themode switch of ModeDeclarationGroupPrototype DcmRapidPowerShutDownENABLE_RAPIDPOWERSHUTDOWN or DISABLE_RAPIDPOWERSHUTDOWN.

In most use cases this is information is interpreted by the application to reduce overruntimes. Nevertheless it also can be provided to the BswM (listing 3.26) if differentshutdown sequences shall be realized by the BswM.

Listing 3.26: Mode switch interface for rapid power shutdownmodeGroup DcmRapidPowerShutDown {

ENABLE_RAPIDPOWERSHUTDOWN,DISABLE_RAPIDPOWERSHUTDOWN

}

interface modeSwitch MSIF_RapidPowerShutdown {mode DcmRapidPowerShutDown powerShutDown

}




R4.1 Rev 3

3.5.4 Communciation Control diagnostic service

If the DCM reports to the BswM that a specified communication control mode is en-tered, the BswM has to enable resp. disable the corresponding IPDU groups as shownin listing 3.27.

Listing 3.27: Ruleset for diagnostic communication controlrule communicationcontrol1 initially false on condition {

if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_TX_NORM ){

actionlist communicationcontrol_DCM_ENABLE_RX_TX_NORM}

}

actions communicationcontrol_DCM_ENABLE_RX_TX_NORM on trigger {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.CAN1IPDUS

}}//----------------------------------------------------------------rule communicationcontrol2 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_DISABLE_TX_NORM ){

actionlist communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NORM}

}actions communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NORM on trigger {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.CAN1RXIPDUSdisable ArMmExample.EcuC.MyCom.CAN1TXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol3 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_ENABLE_TX_NORM ){

actionlist communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NORM}

}actions communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NORM on trigger {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.CAN1TXIPDUSdisable ArMmExample.EcuC.MyCom.CAN1RXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol5 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_TX_NORMAL ){

actionlist communicationcontrol_DCM_DISABLE_RX_TX_NORMAL




R4.1 Rev 3

}}actions communicationcontrol_DCM_DISABLE_RX_TX_NORMAL on trigger {PduGroupSwitch {

init truedisable ArMmExample.EcuC.MyCom.CAN1IPDUS

}}//----------------------------------------------------------------

rule communicationcontrol6 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_TX_NM ){

actionlist communicationcontrol_DCM_ENABLE_RX_TX_NM}

}actions communicationcontrol_DCM_ENABLE_RX_TX_NM on trigger {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.CAN1NMIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol7 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_DISABLE_TX_NM ){

actionlist communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NM}

}actions communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NM on trigger {

PduGroupSwitch {init trueenable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUSdisable ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol8 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_ENABLE_TX_NM ){

actionlist communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NM}

}actions communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NM on trigger {

PduGroupSwitch {init trueenable ArMmExample.EcuC.MyCom.CAN1NMTXIPDUSdisable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol9 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_TX_NM )




R4.1 Rev 3

{actionlist communicationcontrol_DCM_DISABLE_RX_TX_NM

}}actions communicationcontrol_DCM_DISABLE_RX_TX_NM on trigger {

PduGroupSwitch {init truedisable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS, ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol10 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_TX_NORM_NM ){

actionlist communicationcontrol_DCM_ENABLE_RX_TX_NORM_NM}

}actions communicationcontrol_DCM_ENABLE_RX_TX_NORM_NM on trigger {PduGroupSwitch {

init trueenable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS, ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol11 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_ENABLE_RX_DISABLE_TX_NORM_NM ){

actionlist communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NORM_NM}

}actions communicationcontrol_DCM_ENABLE_RX_DISABLE_TX_NORM_NM on trigger {

PduGroupSwitch {init trueenable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS, ArMmExample.EcuC.MyCom.CAN1RXIPDUS

disable ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS, ArMmExample.EcuC.MyCom.CAN1TXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol12 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_ENABLE_TX_NORM_NM ){

actionlist communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NORM_NM}

}actions communicationcontrol_DCM_DISABLE_RX_ENABLE_TX_NORM_NM on trigger {

PduGroupSwitch {init trueenable ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS, ArMmExample.EcuC.MyCom.CAN1TXIPDUS




R4.1 Rev 3

disable ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS, ArMmExample.EcuC.MyCom.CAN1RXIPDUS

}}//----------------------------------------------------------------

rule communicationcontrol13 initially false on condition {if (Dcm_Communication_Control_CAN1 == DCM_DISABLE_RX_TX_NORM_NM ){

actionlist communicationcontrol_DCM_DISABLE_RX_TX_NORM_NM}

}actions communicationcontrol_DCM_DISABLE_RX_TX_NORM_NM on trigger {

PduGroupSwitch {init truedisable ArMmExample.EcuC.MyCom.CAN1NMTXIPDUS,ArMmExample.EcuC.MyCom.CAN1TXIPDUS, ArMmExample.EcuC.MyCom.CAN1NMRXIPDUS, ArMmExample.EcuC.MyCom.CAN1RXIPDUS

}}//----------------------------------------------------------------

3.5.5 Control DTC Setting

Listing 3.28: Mode switch interface for Control of DTC settingmodeGroup DcmControlDTCSetting {

ENABLEDTCSETTING,DISABLEDTCSETTING

}

interface modeSwitch MSIF_DcmControlDtcSetting {mode DcmControlDTCSetting dtcSetting

}

3.5.6 Roe Status

The Dcm will switch the current status of the Roe per configured Roe Event via a modeswitch of ModeDeclarationGroupPrototype DcmResponseOnEvent_<RoeEventID>switching the mode to EVENT_STARTED, EVENT_STOPPED and EVENT_CLEARED.The information is necessary mainly for applications that need to interact with the Dcmif the events shall be triggered from external.

Listing 3.29: Mode switch interface for Roe StatusModeGroup DcmResponseOnEvent_<RoeEventID> {

EVENT_STARTED,EVENT_STOPPED,EVENT_CLEARED

}

interface modeSwitch MSIF_DcmResponseOnEvent{mode DcmResponseOnEvent currentMode




R4.1 Rev 3

}




R4.1 Rev 3

4 Backward Compatibility

This chapter describes a setup to reuse software components (legacy SWCs), whichare designed to work with the “ECU State Manager (EcuM) with fixed state machine”[1]. This means that a setup based on EcuM with flexible state machines and theBswM is described described which emulates the behavior of the EcuM with a fixedstate machine.

An overview of the architectural solution is shown in Figure 4.1. A new Software Com-ponent EcuM Fixed Compatibility SWC is added to build a wrapper that presents aninterface of an EcuM with a fixed state machine to the legacy SWCs.

System Services

Runtime Environment


ecum user

mode switch port

mode request port

mode switch port

mode request port

ECU

ecum fixed compatibilty swc

EcuM_StateRequest

EcuM_CurrentMode

Figure 4.1: Use of SWCs designed to work with ECU State Manager with fixed statemachine

Figure 4.2 depicts the behavioral aspects of the proposal. The small boxes representthe states of fixed EcuM. The green boxes mark the phases of the EcuM flexible. Ap-plication software will only notice changes during the UP phase.




R4.1 Rev 3

Figure 4.2: Mapping: Phases of fixed EcuM to flexible EcuM

The result is that all states of the fixed EcuM in the UP phase have to be emulated usingthe BswM and the software component introduced for this scenario. This softwarecomponent has to map modes reported by the BswM to modes defined in the interfaceof the EcuM with fixed statemachine.




R4.1 Rev 3

According to [EcuM2762] it has to provide AUTOSAR ports for the following functional-ities:

• requesting RUN

• releasing RUN

• requesting POST RUN

• releasing POST RUN

So the BswM is used to emulate the fixed EcuM. For a backward compatible configu-ration the BswM must be configured in such a way that it executes these actions.

This chapter describes a compatibility SWC and the modifications of the BswM config-uration that are necessary. The following hints in this chapter for achieving backwardcompatibility are aligned along the phases of execution.

As most parts of the achievement of compatibility is done via BswM rules, this chaptershows only additional BswM rules and the modifications of the already introduced rulesof chapter 3.

4.1 Startup

During startup phase the same BSW modules shall be initialized as the fixed EcuMdoes. This is implemented via BswM rules which are executed after initialization ofEcuM and initialize these modules. The modules which are already initialized by flexibleEcuM are omitted by BswM.

The changed BswM rules can be seen in Listing 4.1.

Listing 4.1: BswM configuration for fixed EcuM compatible startuprule InitBlockII initially false {if ( EcuMode == MDG_EcuMode.ECU_STARTUP_ONE ) {

actionlist InitBlockIITrueActions}

}

actions InitBlockIITrueActions on condition {custom "EcuMCompatibility_SetStartup(null)"custom "Port_Init(null)"custom "Dio_Init(null)"custom "Adc_Init(null)"custom "Spi_Init(null)"custom "Eep_Init(null)"custom "Fls_Init(null)"custom "NvM_Init(null)"SchMSwitch EcuMode : ECU_STARTUP_TWOcustom "NvM_ReadAll()"

}




R4.1 Rev 3

rule NvMReadAllFinished initially false {if ( NvMReadAllJobMode != NVM_REQ_PENDING && EcuMode == MDG_EcuMode.ECU_STARTUP_TWO) {

actionlist NvMReadAllFinishedTrueActions}

}

actions NvMReadAllFinishedTrueActions on condition {custom "CanTrcv_Init(null)"custom "Can_Init(null)"custom "CanIf_Init(null)"custom "CanSM_Init(null)"custom "CanTp_Init(null)"custom "Lin_Init(null)"custom "LinIf_Init(null)"custom "LinSM_Init(null)"custom "LinTp_Init(null)"custom "FrTrcv_Init(null)"custom "Fr_Init(null)"custom "FrIf_Init(null)"custom "FrSM_Init(null)"custom "FrTp_Init(null)"custom "PduR_Init(null)"custom "CANNM_Init(null)"custom "FrNM_Init(null)"custom "NmIf_Init(null)"custom "IpduM_Init(null)"custom "COM_Init(null)"custom "DCM_Init(null)"custom "EcuMCompatibility_OnRteStartup()"custom "StartRte()"custom "ComM_Init(null)"custom "DEM_Init(null)"custom "FIM_Init(null)"custom "EcuMCompatibility_SetUp(null)"SchMSwitch EcuMode : ECU_RUN

}

4.2 Running

If the running phase is active, it is necessary for compatibility to emulate the interfacesof fixed EcuM as these are used by the legacy SWCs. There are two categories ofinterfaces: Those for getting the current mode and those for requesting a mode.

Firstly, in fixed EcuM the SWCs can get the current mode through the methodEcuM_CurrentMode(). In this setup for compatibility, the legacy SWC does not usethe method of EcuM but calls another method with the same name of the newly in-troduced EcuM Compatibility SWC which represents the wrapper. It gets the current




R4.1 Rev 3

mode of the flexible EcuM and transforms it into a mode of fixed EcuM which is knownby the legacy components.

The mapping of the flexible ECU modes into fixed modes can be found in Table 4.1.

Table 4.1: Mapping of modes from flexible EcuM to fixed EcuMModes reported by Compatibility SWC Modes reported by BswMECUM_STATE_STARTUP_ONE ECU_STARTUP_ONEECUM_STATE_STARTUP_TWO ECU_STARTUP_TWO

ECUM_STATE_RUN ECU_RUNECUM_STATE_APP_RUN ECU_RUN

ECUM_STATE_APP_POST_RUN ECU_POST_RUN

ECUM_STATE_GoSleep ECU_GO_SLEEPECUM_STATE_SleepWaitForNvMWriteAll ECU_GO_SLEEP

ECUM_STATE_GoOff1 ECU_GO_OFF_ONEECUM_STATE_GoOff2 ECU_GO_OFF_TWO

Secondly, legacy SWCs have to be able to request modes. Analogue tothe approach sketched above, the legacy components do not communicate di-rectly with the EcuM but with the compatibility SWC. The compatibility SWCoffers the same interfaces as fixed EcuM and relays the request to flexibleEcuM. The interface is called EcuM_ModeRequest and its methods to emu-late are: EcuM_RequestRUN(), EcuM_ReleaseRUN(), EcuM_RequestPOST_RUN(),EcuM_ReleasePOST_RUN() and EcuM_KillAllRunRequests().

For each fixed EcuM User the compatibility component needs an ownEcuM_ModeRequest-Port as this would also be provided by fixed EcuM. Thelegacy SWC then gets connected to exactly that port which belongs to the requesteduser.

The needed configuration of BswM is shown in Listing 4.2. This includes the declarationof a mode group which represents the requested mode. This information is given tothe BswM. The shown rule is responsible for activating the communication if runningmode was requested.

Listing 4.2: BswM configuration for fixed EcuM compatible running modemodeGroup EcuMCompatibilityMode {

ECUMCOMPATIBILITY_Run,ECUMCOMPATIBILITY_PostRun,ECUMCOMPATIBILITY_Off

}interface modeSwitch compatibilityModeSwitchInterface {

mode EcuMCompatibilityMode compatibilityMode}




R4.1 Rev 3

The compatibility SWC has to take all requested modes of the legacy components andtransform all requests into one mode which is given to the BswM. This consists of twosteps:

1. Depending on the called wrapping-method choose a mode of the above statedflexible EcuM modes. The mapping is described in Table 4.2.

2. Determine the “highest” mode of all compatibility users and request that from theBswM where ECUMCOMPATIBILITY_Run has the highest priority and ECUM-COMPATIBILITY_Off has the lowest.

Table 4.2: Mapping of modes requests from flexible EcuM to fixed EcuMCalled Method ModeEcuM_RequestRUN() ECUMCOMPATIBILITY_RunEcuM_ReleaseRUN() ECUMCOMPATIBILITY_Off

EcuM_RequestPOST_RUN() ECUMCOMPATIBILITY_PostRunEcuM_ReleasePOST_RUN() ECUMCOMPATIBILITY_Run

EcuM_KillAllRunRequests() ECUMCOMPATIBILITY_Off

If the method EcuM_KillAllRunRequests() is called, the compatibility component re-quests ECUMCOMPATIBILITY_Off from the BswM independent of other legacy SWC’srequests.

4.3 Shutdown

If no legacy SWC requested the running mode, the compatibility SWC signals that tothe BswM via the mode ECUMCOMPATIBILITY_Off and BswM can decide whether itwants to keep the ECU running, shut it down or put it into sleep. If it shall be shutdown or put into sleep, the BswM goes to post-run phase. During post-run phase anew request can bring the BswM into running mode again.

For that shutdown mechanism the BswM configuration of Listing 4.3 is responsible. Thelisted rules coordinate the post-run phase, deinitialize the modules and put the ECUinto shut down or sleep. These rules execute the same callouts EcuM_On<Mode>()as it would happen with a fixed EcuM. As the callouts during startup and shutdowncannot be called by the compatibility SWC, they are executed by the BswM via customcalls.

Listing 4.3: BswM configuration for fixed EcuM compatible shutdownrule checkEcuMCompatibilityModeRequest initially false {if ( EcuMode == MDG_EcuMode.ECU_APP_RUN) {

actionlist checkEcuMCompatibilityModeRequestActions}

}




R4.1 Rev 3

actions checkEcuMCompatibilityModeRequestActions on condition {ComMAllowCom MyComM.CanNet1 falseSchMSwitch EcuMode :ECU_APP_POST_RUN

}

rule GoBackToRun initially false {if ( EcuMode == MDG_EcuMode.ECU_APP_POST_RUN) {

actionlist GoBackToRunActions}

}

actions GoBackToRunActions on condition {SchMSwitch EcuMode :ECU_APP_RUN

}

rule PrepShutdown initially false {if ( ComM_Mode_Channel1 == COMM_NO_COM_REQUEST_PENDING && EcuMode ==MDG_EcuMode.ECU_APP_POST_RUN) {actionlist PrepShutdownActions

}}

actions PrepShutdownActions on condition {custom "EcuMCompatibility_OnPrepShutdown()"custom "Dem_Shutdown(null)"SchMSwitch EcuMode :ECU_GO_SLEEPSchMSwitch EcuMode :ECU_GO_OFF_ONE

}

rule GoSleep initially false {if ( ComM_Mode_Channel1 == COMM_NO_COM_REQUEST_PENDING && EcuMode ==MDG_EcuMode.ECU_GO_SLEEP) {actionlist GoSleepActions

}}

actions GoSleepActions on condition {custom "EcuMCompatibility_OnGoSleep()"SchMSwitch EcuMode : ECU_STARTUP_TWOcustom "NvM_WriteAll()"

}

rule GoOff initially false {if ( ComM_Mode_Channel1 == COMM_NO_COM_REQUEST_PENDING && EcuMode ==MDG_EcuMode.ECU_GO_OFF_ONE) {actionlist GoOffActions

}}

actions GoOffActions on condition {custom "EcuMCompatibility_OnGoOffOne()"custom "Rte_stop(null)"custom "ComM_DeInit(null)"SchMSwitch EcuMode :ECU_GO_OFF_TWOcustom "NvM_WriteAll()"




R4.1 Rev 3

}

rule GoSleepNvMWriteAllFinished initially false {if ( NvMWriteAllJobMode != NVM_REQ_PENDING && EcuMode == MDG_EcuMode.ECU_SLEEP)

{actionlist GoSleepNvMWriteAllFinishedActions

}}

actions GoSleepNvMWriteAllFinishedActions on condition {custom "EcuM_GoHalt()"

}

rule GoOff2 initially false {if ( NvMWriteAllJobMode == NVM_BLK_OK && EcuMode == MDG_EcuMode.ECU_GO_OFF_TWO) {actionlist GoOff2Actions

}}

actions GoOff2Actions on condition {custom "EcuMCompatibility_OnGoOffTwo()"custom "EcuM_GoDown()"

}

4.4 Wakeup

The functionality for correct wakeup from sleep mode has to be fully configured in theBswM. But as it does not need any adjustments for backward compatibility, there areno modifications to be done.




R4.1 Rev 3

5 Acronyms and abbreviations

5.1 Technical Terms

All technical terms used throughout this document – except the ones listed here – canbe found in the official AUTOSAR glossary [7] or the Software Component TemplateSpecification [2].

Term Description

mode

A Mode is a certain set of states of the various statemachines (not only of the ECU State Manager) thatare running in the vehicle and are relevant to a partic-ular entity, an application or the whole vehicle

state

States are internal to their respective BSW componentand thus not visible to the application. So they are onlyused by the BSW’s internal state machine. The Statesinside the ECU State Manager build the phases andtherefore handle the modes.

phase

A logical or temporal assembly of ECU Manager’s ac-tions and events, e.g. STARTUP, UP, SHUTDOWN,SLEEP, etc. Phases can consist of Sub-Phases whichare often called Sequences if they above all existto group sequences of executed actions into logicalunits. Phases in this context are not the phases of theAUTOSAR Methodology.

mode switch portThe port for receiving (or sending) a mode switch no-tification. For this purpose, a mode switch portistyped by a ModeSwitchInterface.

mode request interfaceA AUTOSAR SenderReceiverInterfaces, whichcarries the requested mode in a VariableDataProto-type..

mode user

An AUTOSAR SW-C or AUTOSAR Basic SoftwareModule that depends on modes by ModeDis-ablingDependency, SwcModeSwitchEvent,BswModeSwitchEvent, or simply by reading thecurrent state of a mode is called a mode user.A mode user is defined by having a require modeswitch port or a requiredModeGroup Mod-eDeclarationGroupPrototype. See also sectionr̃efsec:concept.




R4.1 Rev 3

mode manager

Entering and leaving modes is initiated by a modemanager. A mode manager is defined by hav-ing a provide mode switch port or a provided-ModeGroup ModeDeclarationGroupPrototype.A mode manager might be either an applica-tion mode manager or a Basic Software Mod-ule that provides a service including mode switches,like the ECU State Manager. See also sectionr̃efsec:ModeManager.

application mode manager

An application mode manager is a AUTOSARsoftware-component that provides the service ofswitching modes. The modes of a applicationmode manager do not have to be standardized.

mode request

The communication of a mode request from themode user to the mode manager using either theSenderReceiverInterface is called a mode re-quest.

mode switch notification

The communication of a mode switch from the modemanager to the mode user using either the Mod-eSwitchInterface or providedModeGroupndrequiredModeGroup ModeDeclarationGroupPro-totype is called mode switch notification.

mode machine instance

The instances of mode machines or ModeDecla-rationGroups are defined by the ModeDeclara-tionGroupPrototypes of the mode managerSince a mode switch is not executed instantaneously,the RTE or Basic Software Scheduler has to main-tain it’s own states. For each mode managers Mod-eDeclarationGroupPrototype, RTE or Basic SoftwareScheduler has one state machine. This state ma-chine is called mode machine instance. For allmode users of the same mode managers Mod-eDeclarationGroupPrototype RTE and BasicSoftware Scheduler uses the same mode machineinstance. See also section r̃efsec:ModeManager.

common mode machineinstance

A “common mode machine instance” is a special“mode machine instance” shared by BSW Mod-ules and SW-Cs: The RTE Generator creates onlyone mode machine instance if a ModeDecla-rationGroupPrototype instantiated in a port ofa software-component is synchronized synchronized-ModeGroup of a




R4.1 Rev 3

Mode Disabling Depen-dency

An RTEEvent and BswEvent that starts aRunnableEntity respectively a Basic Soft-ware Schedulable Entity can contain adisabledInModessociation which references aModeDeclaration. This association is calledModeDisablingDependency in this document.

mode disabling dependentExecutableEntity

A mode disabling dependent RunnableEntity ora Basic Software Schedulable Entity is trig-gered by an RTEEvent respectively a BswEventwith a ModeDisablingDependency. RTE and Ba-sic Software Scheduler prevent the start of thoseRunnableEntity or Basic Software Schedu-lable Entity by the RTEEvent / BswEvent, whenthe corresponding mode disabling is active. Seealso section r̃efsec:ModeManager.

mode disabling

When a ‘mode disabling’ is active, RTE and BasicSoftware Scheduler disables the start of modedisabling dependent ExecutableEntitys.The ‘mode disabling’ is active during the mode thatis referenced in the mode disabling dependency andduring the transitions that enter and leave this mode.See also section r̃efsec:ModeManager.

OnEntry ExecutableEntity

A Runnable Entity or a Basic SoftwareSchedulable Entity that is triggered by aSwcModeSwitchEvent respectively a BswMod-eSwitchEvent with ModeActivationKind ‘entry’is triggered on entering the mode. It is calledOnEntry ExecutableEntity. See also sectionr̃efsec:ModeManager.

OnExit ExecutableEntity

A RunnableEntity or a Basic SoftwareSchedulable Entity that is triggered by aSwcModeSwitchEvent respectively a BswMod-eSwitchEvent with ModeActivationKind‘exit’ is triggered on exiting the mode. It is calledOnExit ExecutableEntity. See also sectionr̃efsec:ModeManager.

OnTransition Exe-cutableEntity

A RunnableEntity or a Basic SoftwareSchedulable Entity that is triggered by aSwcModeSwitchEvent respectively a BswMod-eSwitchEvent with ModeActivationKind‘transition’ is triggered on a transition betweenthe two specified modes. It is called OnTran-sition ExecutableEntity. See also sectionr̃efsec:ModeManager.




R4.1 Rev 3

mode switch acknowledgeExecutableEntity

A RunnableEntity or a Basic SoftwareSchedulable Entity that is triggered by aSwcModeSwitchedAckEvent respectively aBswModeSwitchedAckEvent connected to themode manager’s ModeDeclarationGroupPro-totype. It is called mode switch acknowl-edge ExecutableEntity. See also sectionr̃efsec:ModeManager.

server runnable

A server that is triggered by an OperationIn-vokedEvent. It has a mixed behavior between arunnable and a function call. In certain situations, RTEcan implement the client server communication as asimple function call.

runnable activation

The activation of a runnable is linked to the RTEEventthat leads to the execution of the runnable. It is definedas the incident that is referred to by the RTEEvent.E.g., for a timing event, the corresponding runnable isactivated, when the timer expires, and for a data re-ceived event, the runnable is activated when the datais received by the RTE.

Basic Software Schedula-ble Entity activation

The activation of a Basic Software Schedula-ble Entity is defined as the activation of the taskthat contains the Basic Software SchedulableEntity and eventually includes setting a flag that tellsthe glue code in the task which Basic SoftwareSchedulable Entity is to be executed.

Runnable start A runnable is started by the calling the C-function thatimplements the runnable from within a started task.

Basic Software Schedula-ble Entity start

A Basic Software Schedulable Entity isstarted by the calling the C-function that implementsthe Basic Software Schedulable Entity fromwithin a started task.

Trigger Source

A Trigger Source administrate the particularTrigger and informs the RTE or Basic SoftwareScheduler if the Trigger is raised. A TriggerSource has dedicated provide trigger ports or /and releasedTrigger Triggers to communicateto the Trigger Sinks.

Trigger Sink

A Trigger Sink relies on the activation ofRunnable Entities or Basic SoftwareSchedulable Entities if a particular Trig-ger is raised. A Trigger Sink has a dedicatedrequire trigger ports or / and requiredTrig-ger Triggers to communicate to the TriggerSources.




R4.1 Rev 3

Trigger port A PortPrototype which is typed by an Trigger-Interface

triggered ExecutableEntity

A Runnable Entity or a Basic SoftwareSchedulable Entity that is triggered at leastby one ExternalTriggerOccurredEvent /BswExternalTriggerOccurredEvent or In-ternalTriggerOccurredEvent / BswInternal-TriggerOccurredEvent. In particular cases,the Trigger Event Communication or the InterRunnable Triggering is implemented by RTE orBasic Software Scheduler as a direct functioncall of the triggered ExecutableEntity by thetriggering ExecutableEntity.

triggered runnable

A Runnable Entity that is triggered at least by oneExternalTriggerOccurredEvent or Internal-TriggerOccurredEvent. In particular cases,the Trigger Event Communication or the InterRunnable Triggering is implemented by RTE asa direct function call of the triggered runnable bythe triggering runnable.

triggered Basic SoftwareSchedulable Entity

A Basic Software Schedulable Entity thatis triggered at least by one BswExternalTrig-gerOccurredEvent or BswInternalTrig-gerOccurredEvent. In particular cases, theTrigger Event Communication or the In-ter Basic Software Schedulable EntityTriggering is implemented by Basic Soft-ware Scheduler as a direct function call of thetriggered ExecutableEntity by the triggeringExecutableEntity.

execution-instanceAn execution-instance of a ExecutableEntity isone instance or call context of an ExecutableEn-tity with respect to concurrent execution.

inter-ECU communicationThe communication between ECUs, typically usingCOM is called inter-ECUcommunication in this doc-ument.

inter-partition communica-tion

The communication within one ECU but between dif-ferent partitions, represented by different OS appli-cations, is called inter-partition communicationin this document. It typically involves the use of OSmechanisms like IOC or trusted function calls. Thepartitions can be located on different cores or use dif-ferent memory sections of the ECU.




R4.1 Rev 3

intra-partition communica-tion

The communication within one partition of one ECUis called intra-partition communication. In thiscase, RTE can make use of internal buffers andqueues for communication.

intra-ECU communication

The communication within one ECU is called intra-ECU communication in this document. It is a super setof inter-partition communication and intra-partition communication.



document title - autosar · guide to modemanagement v2.2.0 r4.1 rev 3 1 introduction this document...

Documents