Requirements on Mode Management, No.69, AUTOSAR R21-11(254) CP

Requirements on Mode Management, No.69, 2021-11

https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SRS_ModeManagement.pdf

AUTOSAR R21-11記事一覧はこちら。

AUTOSAR 21-11,160文書読んだ。2022年5月中に全部読み。

https://qiita.com/kaizen_nagoya/items/9935c9e58bf82e1e63d2

AUTOSAR 21-11, 62文書読んだ。2022年5月中に半分到達予定。

https://qiita.com/kaizen_nagoya/items/648b32867635993410c8

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

https://qiita.com/kaizen_nagoya/items/9b3a1b9b8d1e8d7e288e

# 用語(terms)
|Term|Description|
|:--|:--|
|Active wake-up |Wake-up caused by the ECU e.g. by a sensor.
|Alive indication| Indication that a supervised SW-C is alive - meaning active -　provided from the SW-C itself to the Watchdog Manager [3].
|Application| Applications are used synonymous to a SW-C. A SW-C may　span several atomic SW-Cs. AUTOSAR provides the　element of a "composition" to formally group several atomic　SW-Cs of an application. A composition is used to structure　the description and does not affect the generated code.　Note: The atomic SW-Cs in a composition can still be　mapped to different ECUs. Application Modes are therefore　’local’ to an application but can be ’global’ to several ECUs.
|Application Mode |An Application Mode is a mode that is not controlled and　standardized by the Mode Managers in the BSW. The scope　of an Application Mode is a limited number of SW-Cs that　belongs to a logical Application. If a mode only affects one　composition, it is an Application Mode.　An Application Mode may be distributed across multiple　ECUs or may be local to one ECU depending on the　distribution of the SW-C belonging to that application.　Examples: Normal Operation, Limp Home
|Application Mode Manager |An Application Mode Manager is a SW-C therefore a priori　not standardized. It collects environmental data and Mode　Requests via application-specific (non-standardized)　interfaces from other SW-Cs. It can switch Application　Modes (that are not controlled and standardized by the　Mode Managers in the BSW). It can also request modes　from other Mode Managers, specifically from Mode　Managers in the BSW.
|BSW Mode |A BSW Mode is mode, which is controlled and standardized　by the Mode Manager in the BSW. A BSW Mode is always　local to one ECU.　Examples: EcuM Modes, ComM Modes
|BSW Mode Manager |[1] The BSW Mode Manager [1] is a BSW module that collects　mode requests via a standardized interface and controls　functionality of other BSW modules accordingly. Examples　are: LIN Schedule Table Switching, Enabling/Disabling　I-PDU Groups, ...
|Communication mode |Related to a physical channel or to a user, it indicates if it is　possible to send/receive, only receive, neither send nor　receive.
|Communication request |A communication request indicates a demand for　communication from a given user (e.g. a runnable requiring　an operational communication stack). However, it can　neither be assumed that the request will be fulfilled within a　certain time nor that it will be fulfilled at all. The demander　itself has to make sure that communication is indeed　established, by using query functions or callbacks.
|ECU state |General term to indicate the states managed by the ECU　State Manager [2]. They represent a structured model that　extends the power modes of the ECU with states and　transitions to support necessary activities of software to　enter/leave these power modes.
|Inoperation| An artificial word to describe the ECU when it is not　operational, i.e. not running. It comprises all meanings of off,　sleeping, frozen, etc. Using this definition is beneficial since　it has no predefined meaning.
|Low-power mode |All power modes except "on" (full power).
|Mode |A mode is a certain set of states of the various state　machines that are running in the vehicle that are relevant to　a particular entity, e.g. a SW-C, a BSW module, an　application, a whole vehicle　In its lifetime, an entity changes between a set of mutually　exclusive modes. These changes are triggered by　environmental data, e.g. signal reception, operation　invocation.
|Mode Declaration Group |A Mode Declaration Group is defined in the Software　Component Template and implemented by the RTE [7].　A Mode Declaration Group defines a number of mutually　exclusive modes. There is no hierarchy of modes within a　Mode Declaration Group.　Each Mode Declaration Group describes only one aspect of　the whole system. All modes of all Mode Declaration Groups　on an ECU describe the abstract mode of the ECU. Similarly,　all modes of all Mode Declaration Groups in a system　describe the abstract mode of all ECUs in the system. (The　mode is abstract because it cannot be physically accessed,　it just exists conceptually).　There is a standardized set of Mode Declaration Groups　defined in the BSW, e.g. ComM, WdgM, EcuM. Each system　designer is free to extend the number of Mode Declaration　Groups and define his/her own modes in there.　Only one Mode Manager is allowed to switch the mode of an　instance of a Mode Declaration Group. (Limitation in VFB　[8])
|Mode Manager |A Mode Manager is a role that can be taken by either a BSW　module (and optionally additionally by an SW-C).　The Mode Manager collects requests from Mode　Requesters, arbitrates them and switches the mode of its　Mode Declaration Group(s) accordingly.　Examples of Mode Managers are: EcuM, ComM, WdgM and　BswM　Note: If a SW-C Mode Manager switches modes directly, the　mode arbitration in the BSW Mode Manager [1] cannot　resolve conflicts. Thus, it is recommended to use multi-level　mode arbitration, of SW-C mode Manager and BSW Mode　Manager [1]
|Mode Port| A Mode Port is port that has a Sender-Receiver Interface　which contains a Mode Declaration Group.　Note: This is called Mode Port in SWS RTE [7] -> To　distinguish it from Mode Request Ports, we should call it　Mode Switch Port
|Mode Request| A Mode Request is some information communicated to a　Mode Manager that requests the Mode Manager to switch to　a certain mode.　For Mode Managers in the BSW the interface to send a　Mode Request is a standardized client-server interface　defined by the corresponding Mode Manager. Examples:　Client-server interface ComM_UserRequest with operation　RequestComMode(...).　For Application Mode Managers the interface can be any　client-server or sender-receiver interface defined by the　Mode Manager.
|Mode Request Port| A Mode Request Port is a port with the special semantics of　requesting a mode from a Mode Manager. It can be a　Client-Server or a Sender-Receiver Port.　For Mode Managers in the BSW the Mode Request Port is　standardized.　Note: For EcuM, ComM and WdgM it is always a Provided　Client-Server Port. For BswM it is a Required　Sender-Receiver Ports.
|Mode Requester|A Mode Requester is an entity that requests modes from a　Mode Manager.
|Mode Switch Port| Favored replacement of phrase Mode Port
|Mode User |A Mode User is an entity that reacts on mode changes.
|OFF state |ECU state. It denotes the unpowered ECU. Depending on　the hardware design, the ECU can or cannot react to　passive wake-up in this state (wakeability is not required in　this state).
|Passive wake-up| Wakeup initiated by another ECU and propagated (e.g. by　bus or wakeup-line) to the ECU currently in focus.
|Port Group |A Port Group is a logical group of ports that are needed to　realize the same functionality in the Application. A port can　be a member of multiple Port Groups.　A Port Group can be used to request all associated　communication resources and to inquire their state. Thereby,　the Port Group also defines a mapping between Application　Ports and Communication Resources. Thus, the purpose of　a port group is to have an abstraction of the required　communication resources of that functionality　For example, an Application contains normal-operation　functionality and limp-home functionality with reduced　communication requirements. Then it is useful to define two　Port Groups, A and B. A contains the ports that are　necessary for the normal-operation functionality and B　contains the ports for the limp-home functionality. Thereby,　the Application can recognize the condition when the　communication resources for normal operation are　unavailable but are sufficient for limp home.　Port Groups are defined on SW-C composition level, which　means that they may be distributed on several ECUs. The　requests and indications for the Port Groups shall however　only affect the portion of the Port Group that is local to an　ECU. If distributed control of Port Groups is needed it can be　handled on "Application Mode Management" level (above　the RTE [7]) using normal communication features.
|Power mode |Hardware power mode of the ECU. Typically: on (full power),　off, sleep, standby, etc... The last two items can take several　forms depending on hardware capabilities (reduced clock,　peripheral standby, etc.).
|Program flow monitoring| Technique to detect errors that cause a divergence from the　valid program sequence seen during valid execution of a　program.
|RUN state |ECU state. The ECU is fully functional, all BSW modules are　initialized and application software components are able to　run.
|Shutdown target |The chosen low-power state (OFF, SLEEP) for the next　shutdown. If the SLEEP state supports several sleep modes,　the shutdown target shall indicate the chosen sleep mode.
|Sleep mode |The term "mode" is related to the current availability of the　ECU’s capabilities. "Sleep mode" is the overall abstracted　term for a variety of low-power modes that could exist at　different CPU’s, which have in common that they currently do　not perform code-execution, but are still powered.
|SLEEP state| ECU state. It is an energy saving state: no code is executed　but power is still supplied, and if configured correctly, the　ECU is wakeable. The SLEEP state provides a configurable　set of sleep modes which typically are a trade off between　power consumption and time to restart the ECU.
|State/communication requestor |See User.
|Supervised Entity| A supervised entity is a software entity which is included in　the monitoring of the Watchdog Manager [3]. Each　supervised entity has exactly one identifier. A supervised　entity denotes a collection of checkpoints within a software　component or basic software module. There may be zero,　one or more supervised entities in a software component or　basic software module.
|User |Concept for requestors of the ECU State Manager [2] and of　the Communication Manager [4]. A user may be a runnable　entity, a SW-C/BSW or even a group of SW-Cs/BSWs, which　acts as a single unit towards the ECU State Manager [2]　and the Communication Manager [4].
|Vehicle Mode| A Vehicle Mode is a mode that is not controlled and　standardized by the Mode Managers in the BSW. The scope　of a Vehicle Mode is the whole vehicle. If a mode affects　multiple compositions, it is a Vehicle Mode.　A Vehicle Mode is by definition distributed across the whole　vehicle.　Example: Transport Mode, Power Saving Mode, Ignition On,　Ignition Off
|Vehicle Mode Manager |A Vehicle Mode Manager is a special kind of Application　Mode Manager that switches Vehicle Modes.
|Wake-up event |A physical event which causes a wake-up. A CAN message　or a toggling IO line can be wake-up events. Similarly, the internal SW representation, e.g. an interrupt, may also be　called a wake-up event.
|Wake-up reason |The wake-up event being actually the cause of the current/　last wake-up.
|Wake-up source |The peripheral or ECU component which deals with wake-up　events is called a wake-up source.
|BSW| Basic Software
|BswM |Basic Software Mode Manager
|ComM |Communication Manager [4]
|DCM |Diagnostic Communication Manager [4]
|DEM |Diagnostic Event Manager
|EcuM |ECU State Manager [2]
|FiM |Function Inhibition Manager
|RE| Runnable Entity
|SW-C |Software Component
|WdgM |Watchdog Manager [3]
## 英日
日本語は仮訳

T.B.D.

# 参考(reference)

[1] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager
[2] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager
[3] Specification of Watchdog Manager
AUTOSAR_SWS_WatchdogManager
[4] Specification of Communication Manager
AUTOSAR_SWS_COMManager
[5] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[6] Glossary
AUTOSAR_TR_Glossary
[7] Specification of RTE Software
AUTOSAR_SWS_RTE
[8] Virtual Functional Bus
AUTOSAR_EXP_VFB
[9] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[10] System Template
AUTOSAR_TPS_SystemTemplate
[11] Requirements on AUTOSAR Features
AUTOSAR_RS_Features

 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞

# 文書履歴(document history)
ver. 0.01 初稿 　20220529