Guide to Mode Management, CP, No.440, AUTOSAR R22-11(2)

Guide to Mode Management, AUTOSAR R22-11, CP, No.440

AUTOSARは、ISO、IEC、ITUと情報交換契約を結んでいません。
AUTOSAR文書には、ISO、IEC,ITU記述を全文引用することはできません。
WTO/TBT協定に基づき、国際的な調達は国際規格との差異を記述することにより文化依存しない仕様を目指します。
ISO、IEC、ITU文書を合わせて読むと技術内容は理解できます。　
CAN、OSEK/VDX OS、DIAGは、ISO定義を先に確認しましょう。　　
OSEK COM、OSEK NMなどはISOの規定から基本的な部分で定義を変えています。
変更している部分を仕様等で明記するか、ISOを改定するとよいでしょう。　

AUTOSARの参考文献欄の改定が進んでいません。　
Glossary用語定義の網羅性が低いです。
本文を読む前に確認するとよいかもしれません。
本文を読んでから確認してもよいかもしれません。

AUTOSARが、2022年の版、R22-11公開しました。公開行事の模様は

AUTOSAR R22-11 Release Event 20221208

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

下記URL順次確認中です。

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

間違っていたら、いいね　を押していただいて、コメント欄にご報告くださると幸いです。
編集リクエストが、構造的な変更をしている最中に、構造的な編集リクエストをしていただくと、
何をどう直したらいいかわからなくなってしまいます。自動修復ツールがつくれていません。ごめんなさい。

https://www.autosar.org/

文書は検索してダウンロードすることができます。
クラウドサービスにありがちな、あるのにないかのような検索結果が出ることがあります。

https://www.autosar.org/nc/document-search/

equirement and Specification)

# 一覧

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

Classic Platform Release Overview, AUTOSAR R22-11, CP, No.0(2)

https://qiita.com/kaizen_nagoya/items/80636f4ca7c16501803b


AUTOSAR R22-11 マラソン

https://qiita.com/kaizen_nagoya/items/988aa405a6fdd794fe53



Qiitaの記事の一覧は作成中です。

AUTOSAR R22-11 一覧（２）

https://qiita.com/kaizen_nagoya/items/6b0615884e954c65fb43


# Abstract Platformとの関係

状態管理統一。

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


## 文書変更(Document Change) 
>• Added explanatory content for rework of PNC related ComM and NM handling
• Editorial Changes

## 用語(terms)
|Term|Description|
|:--|:--|
|mode|A Mode is a certain set of states of the various state machines (not only of the ECU State Manager) that are running in the vehicle and are relevant to a particular entity, an application or the whole vehicle
|state|States are internal to their respective BSW component and thus not visible to the application. So they are only used by the BSW’s internal state machine. The States inside the ECU State Manager build the phases and therefore handle the modes.
|phase|A logical or temporal assembly of ECU Manager’s actions and events, e.g. STARTUP, UP, SHUTDOWN, SLEEP, etc. Phases can consist of Sub-Phases which are often called Sequences if they above all exist to group sequences of executed actions into logical units. Phases in this context are not the phases of the AUTOSAR Methodology.
|mode switch port|The port for receiving (or sending) a mode switch notification. For this purpose, a mode switch portis typed by a ModeSwitchInterface.
|mode request interface |A AUTOSAR SenderReceiverInterfaces, which carries the requested mode in a VariableDataPrototype..
|mode user|An AUTOSAR SW-C or AUTOSAR Basic Software Module that depends on modes by SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the current state of a mode is called a mode user. A mode user is defined by having a require mode switch port or a requiredModeGroup ModeDeclarationGroupPrototype. See also section 2.
|mode manager|Entering and leaving modes is initiated by a mode manager. A mode manager is defined by having a provide mode switch port or a providedModeGroup ModeDeclarationGroupPrototype. A mode manager might be either an application mode manager or a Basic Software Module that provides a service including mode switches, like the ECU State Manager. See also section 2.2.
|application mode manager|An application mode manager is a AUTOSAR softwarecomponent that provides the service of switching modes. The modes of a application mode manager do not have to be standardized.
|mode request|The communication of a mode request from the mode user to the mode manager using either the SenderReceiverInterface is called a mode request.
|mode switch notification|The communication of a mode switch from the mode manager to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclarationGroupPrototype is called mode switch notification.
|mode machine instance|The instances of mode machines or ModeDeclarationGroups are defined by the ModeDeclarationGroupPrototypes of the mode manager Since a mode switch is not executed instantaneously, the RTE or Basic Software Scheduler has to maintain it’s own states. For each mode managers ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one state machine. This state machine is called mode machine instance. For all mode users of the same mode managers ModeDeclarationGroupPrototype RTE and Basic Software Scheduler uses the same mode machine instance. See also section 2.2.
|common mode machine instance|A “common mode machine instance” is a special “mode machine instance” shared by BSW Modules and SW-Cs: The RTE Generator creates only one mode machine instance if a ModeDeclarationGroupPrototype instantiated in a port of a softwarecomponent is synchronized synchronizedModeGroup of a
|Mode Disabling Dependency|An RTEEvent and BswEvent that starts a RunnableEntity respectively a Basic Software Schedulable Entity can contain a disabledMode or disabledInMode association which references a ModeDeclaration. This association is called ModeDisablingDependency in this document.
|mode disabling| dependent ExecutableEntity A mode disabling dependent RunnableEntity or a Basic Software Schedulable Entity is triggered by an RTEEvent respectively a BswEvent with a ModeDisablingDependency. RTE and Basic Software Scheduler prevent the start of those RunnableEntity or Basic Software Schedulable Entity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. See also section 2.2.
|mode disabling|When a ‘mode disabling’ is active, RTE and Basic Software Scheduler disables the start of mode disabling dependent ExecutableEntitys. The ‘mode disabling’ is active during the mode that is referenced in the mode disabling dependency and during the transitions that enter and leave this mode. See also section 2.2.
|OnEntry ExecutableEntity|A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘entry’ is triggered on entering the mode. It is called OnEntry ExecutableEntity. See also section 2.2.
|OnExit ExecutableEntity|A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘exit’ is triggered on exiting the mode. It is called OnExit ExecutableEntity. See also section 2.2.
|OnTransition ExecutableEntity|A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘transition’ is triggered on a transition between the two specified modes. It is called OnTransition ExecutableEntity. See also section 2.2. 
|mode switch acknowledge ExecutableEntity|A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchedAckEvent connected to the mode manager’s ModeDeclarationGroupPrototype. It is called mode switch acknowledge ExecutableEntity. See also section 2.2.
|server runnable|A server that is triggered by an OperationInvokedEvent. It has a mixed behavior between a runnable and a function call. In certain situations, RTE can implement the client server communication as a simple function call.
|runnable activation|The activation of a runnable is linked to the RTEEvent that leads to the execution of the runnable. It is defined as the incident that is referred to by the RTEEvent. E.g., for a timing event, the corresponding runnable is activated, when the timer expires, and for a data received event, the runnable is activated when the data is received by the RTE.
|Basic Software Schedulable Entity activation|The activation of a Basic Software Schedulable Entity is defined as the activation of the task that contains the Basic Software Schedulable Entity and eventually includes setting a flag that tells the glue code in the task which Basic Software Schedulable Entity is to be executed.
|Runnable start |A runnable is started by the calling the C-function that implements the runnable from within a started task.
|Basic Software Schedulable Entity start|A Basic Software Schedulable Entity is started by the calling the C-function that implements the Basic Software Schedulable Entity from within a started task.
|Trigger Source|A Trigger Source administrate the particular Trigger and informs the RTE or Basic Software Scheduler if the Trigger is raised. A Trigger Source has dedicated provide trigger ports or / and releasedTrigger Triggers to communicate to the Trigger Sinks.
|Trigger Sink|A Trigger Sink relies on the activation of Runnable Entities or Basic Software Schedulable Entities if a particular Trigger is raised. A Trigger Sink has a dedicated require trigger ports or / and requiredTrigger Triggers to communicate to the Trigger Sources.
|Trigger port |A PortPrototype which is typed by an TriggerInterface
|triggered ExecutableEntity|A Runnable Entity or a Basic Software Schedulable Entity that is triggered at least by one ExternalTriggerOccurredEvent / BswExternalTriggerOccurredEvent or InternalTriggerOccurredEvent / BswInternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE or Basic Software Scheduler as a direct function call of the triggered ExecutableEntity by the triggering ExecutableEntity.
|triggered runnable|A Runnable Entity that is triggered at least by one ExternalTriggerOccurredEvent or InternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE as a direct function call of the triggered runnable by the triggering runnable.
|triggered Basic Software Schedulable Entity|A Basic Software Schedulable Entity that is triggered at least by one BswExternalTriggerOccurredEvent or BswInternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Basic Software Schedulable Entity Triggering is implemented by Basic Software Scheduler as a direct function call of the triggered ExecutableEntity by the triggering ExecutableEntity.
|execution-instance|An execution-instance of a ExecutableEntity is one instance or call context of an ExecutableEntity with respect to concurrent execution.
|inter-ECU communication |The communication between ECUs, typically using COM is called inter-ECUcommunication in this document.
|inter-partition communication|The communication within one ECU but between different partitions, represented by different OS applications, is called inter-partition communication in this document. It typically involves the use of OS mechanisms like IOC or trusted function calls. The partitions can be located on different cores or use different memory sections of the ECU.
|intra-partition communication|The communication within one partition of one ECU is called intra-partition communication. In this case, RTE can make use of internal buffers and queues for communication.
|intra-ECU communication|The communication within one ECU is called intra-ECU communication in this document. It is a super set of inter-partition communication and intra-partition communication.

## 英日
日本語は仮訳

T.B.D.

## 参考(reference)

[1] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[2] Meta Model
AUTOSAR_MMOD_MetaModel
[3] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[4] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager
[5] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager
[6] Glossary, AUTOSAR_TR_Glossary
https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_Glossary.pdf

# 関連文書(Related document)

AUTOSAR Abstract Platformへの道（詳細編）

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

2023年1月　記事数一覧

https://qiita.com/kaizen_nagoya/items/78153968c5de76a7fd83

年末100記事を30点に仕上げる。

https://qiita.com/kaizen_nagoya/items/3ffdc82caee3a325d1d7

2023 書き初め

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

「はじめての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

AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8

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

AUTOSAR Abstract Platform User Group Weekly Report(2) 2022.1.15

https://qiita.com/kaizen_nagoya/items/6f1168a36e795976a906

# 202304 URL更新
Guide to Mode Management, AUTOSAR 440, R22-11, CP, 20230421

https://qiita.com/kaizen_nagoya/items/73941cf5aebc1b560c7f

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

# 文書履歴(document history)
ver. 0.01 初稿　20230122
ver. 0.02 ありがとう追記　20230701

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

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

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

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