Requirements on Mode Management, AUTOSAR 69,  R22-11, CP, 20230421

 2023年4月URL変更
この項は2023年4月21日、AUTOSARの文書のURLが変更になった。
/classic/22-11/
が
/R22-11/CP/
過去記事で、URLでエラーが出たら書き換えてみてください。

/adaptive/22-11/
は　
/R22-11/AP/

/foundation/22-11/
は　
/R22-11/FO/
です。
## 2023年11月URL変更
2023年11月にもAUTOSAR文書のURLが変更になっている。
/user_upload/standards/classic/21-11/
を
/standards/R21-11/CP/
などに書き換えてください。

/user_upload/standards/adaptive/21-11/
を
/standards/R21-11/AP/

/user_upload/standards/foundation/21-11/
を
/standards/R21-11/FO/

お手数をおかけします。
１年に２度URLを変更するなんて、新しい記事が書ける。とても嬉しい。

# 一覧

AUTOSAR R22-11 Qiita記事一覧 20230421 。

https://qiita.com/kaizen_nagoya/items/81a35774f1aa3d64d3f6

この記事の表題の最後に「20230421」を加えます。

<この項は書きかけです。順次追記します。>

AUTOSARが、2022年の版、R22-11を公開しました。

https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SRS_ModeManagement.pdf

R21-11

https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SRS_ModeManagement.pdf


R20-11
https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SRS_ModeManagement.pdf


R19-11
https://www.autosar.org/fileadmin/standards/R19-11/CP/AUTOSAR_SRS_ModeManagement.pdf


https://www.autosar.org/

文書は検索してダウンロードできます。

R20-11,R21-11, R22-11の３年分だけになりました。


公開行事の模様は

AUTOSAR R22-11 Release Event 20221208

https://qiita.com/kaizen_nagoya/items/18471d0b340480fdcd42


AUTOSAR R22-11 Classic Platform 一覧はこちら。


Classic Platform Release Overview, AUTOSAR No.0 ,R22-11, CP, 20230421

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

# 要求仕様対応(Requirement and Specification)
# Abstract Platformとの関係
# Abstract Platformとの関係


Template, TypeはAbstract Platformで統一的に定義するとよい。　
Template, Typeで、複数の文書を統合するとよい。

<この項は書きかけです。順次追記します。>


## 文書変更(Document Change) 
>• Rework of PNC related ComM and NM handling
• Removed "DRAFT"-tag from [SRS_ModeMgm_09249]
• Editorial Changes
# 用語(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
https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_Glossary.pdf
[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

# 関連文書(Related document)

Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>

https://qiita.com/kaizen_nagoya/items/24a1ba5da3d09b2a95d1

JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)

https://qiita.com/kaizen_nagoya/items/4789832baf494cb74626



「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】

https://qiita.com/kaizen_nagoya/items/1fee270be00ef90ca4ec


三方良し　Udemy 車載LAN入門講座 CAN通信編

https://qiita.com/kaizen_nagoya/items/bed038c52510fea72c0a


詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者　 ＜エンジニア夏休み企画 読書感想文＞

https://qiita.com/kaizen_nagoya/items/e9971698a108c3dba794

詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】

https://qiita.com/kaizen_nagoya/items/e156cbdd5fce9263776e

詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために

https://qiita.com/kaizen_nagoya/items/44a9e6b0f5363b4a5b35


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

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

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

####  Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.