Specification of Execution Management, No.721, AUTOSAR R21-11 (21) AP

Specification of Execution Management, No.721, 2021-11

https://www.autosar.org/fileadmin/standards/adaptive/21-11/AUTOSAR_SWS_ExecutionManagement.pdf

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

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

# 用語(terms)

|Term| Description|
|:----|:----|
|Executable|Part of an Application. It consists of executable code (with exactly one entry point) created at integation time that can be deployed and installed on a Machine. An Application may consist of one or more Executables, each of which can be deployed to different Machines.process| A process refers to the OS concept of a running process. Attention: process is not equal to Modelled Process (see below). Hence each Modelled Process has at some time a related (OS) process but a process may not always have a related Modelled Process.|
|Modelled Process| A Modelled Process is an instance of an Executable to be executed on a Machine and has a 1:1 association with the ARXML/Meta-Model element Process. This document also uses the term process (without the "modelled" prefix) to refer to the OS concept of a running process.|
|Reporting Process| A type of Modelled Process with an associated Executable where reportingBehavior is omitted ([TPS_MANI_01279]) or set to reportsExecutionState. A Reporting Process is expected to report its Execution State to Execution Management.| |
|Non-reporting Process| A type of Modelled Process with an associated Executable where reportingBehavior set to doesNotReportExecutionState ([TPS_MANI_01279]). A Non-reporting Process is not expected to report its Execution State to Execution Management.|
|Companion Process| A type of Reporting Process that is associated with Non-reporting Process and used to determine when functionality expected from Non-reporting Process is available. Whenever functional dependencies on Non-reporting Processes exist, the integrator can configure proxy Execution Dependencies on the Companion Process and make the Companion Process kRunning reporting conditional on monitored Non-reporting Process.|
|Self-terminating Process| A type of Modelled Process that has terminationBehavior configured to processIsSelfTerminating. This type of Modelled Process is allowed to self initiate termination procedure (i.e. just terminate with exit status EXIT_SUCCESS), or wait for Execution Management to initiate termination procedure via SIGTERM.|
|Unexpected Self-termination| The event consumed by Execution Management when a Modelled Process terminates without justified reason, for example: - termination without prior request where terminationBehavior is configured to processIsNotSelfTerminating. - termination before reporting kRunning. Please note that every Unexpected Self-termination is also an Unexpected Termination, so requirements for the later apply here as well.|
|Unexpected Termination| The event consumed by Execution Management when a Modelled Process terminates with exit status other than 0 (EXIT_SUCCESS). Any kind of unhandled signal will result in an Unexpected Termination and thus a non 0 exit status.|
|Execution Dependency| Dependencies between Modelled Process instances can be configured to define a sequence for starting and terminating them.|
|Execution Management| The element of the AUTOSAR Adaptive Platform responsible for the ordered startup and shutdown of the AUTOSAR Adaptive Platform and Adaptive Applications.|
|State Management|The element defining modes of operation for AUTOSAR Adaptive Platform. It allows flexible definition of functions which are active on the platform at any given time.
|Function Group| A Function Group is a set of Modelled Processes which need to be controlled consistently. Depending on the state of the Function Group, processes (related to the Modelled Processes) are started or terminated. Modelled Processes can belong to more than one Function Group State, but at exactly one Function Group (if a Modelled Process were allowed to be running at the same point in time in more than one Function Group then potential contradictions in the logic of the Function Group state transitions could cause errors, see Section 7.5.3). MachineFG is a Function Group with a predefined name, which is mainly used to control Machine lifecycle and processes of platform level Applications. Other Function Groups are sort of general purpose tools used (for example) to control processes of user level Applications.| 
|Function Group State| The element of State Management that characterizes the current status of a set of (functionally coherent) user-level Applications. The set of Function Groups and their Function Group States are configured in the Execution Manifest.|
|Undefined Function Group State|Any state of a Function Group, which is not modelled. A Function Group is in an Undefined Function Group State during state transition, if a state transition failed or if an Unexpected Termination or Unexpected Self-termination happened. | 
|Machine State| A state of Function Group "MachineFG" with some predefined states (Startup/Shutdown/Restart). This can term can refer to the current state ("The Machine State is ..."), to a specific state ("In Machine State Startup ..."), or to a set of states ("In Machine States Startup or Shutdown ...").|
|Time Determinism| The results of a calculation are guaranteed to be available before a given deadline.|
|Data Determinism| The results of a calculation only depend on the input data and are reproducible, assuming a given initial internal state.|
|Full Determinism| Combination of Time and Data Determinism. Communication Management|
|Execution Manifest| Manifest file to configure execution of an Adaptive Application. An Execution Manifest is created at integration time and deployed onto a Machine together with the Executable to which it is attached. It supports the integration of the Executable code and describes the configuration properties (startup parameters, resource group assignment etc.) of each process, i.e. started instance of that Executable.|
|Machine Manifest| Manifest file to configure a Machine. The Machine Manifest holds all configuration information which cannot be assigned to a specific Executable or process.|
|Operating System| Software responsible for managing processes on a Machine and for providing an interface to hardware resources.|
|ExecutionClient| Adaptive Application interface to Execution Management.|
|DeterministicClient|Adaptive Application interface to Execution Management to support control of the process-internal cycle, a deterministic worker pool, activation time stamps and random numbers.| 
|StateClient| State Management interface to Execution Management to support Function Group State and Machine State management.|
|Platform Health Management| A Functional Cluster within the Adaptive Platform FoundationRecovery Action| Actions defined by the integrator to control Adaptive Application error recovery.|
|Process State| Lifecycle state of a Modelled Process|
|Service Instance| Manifest Manifest file to configure Service usage of an Adaptive Application.|
|Trusted Platform| An execution platform supporting a continuous chain of trust from boot through to application. The trust chain ensures that all execution is both authenticated (that all code executed is from the claimed source) and subjected to integrity validation (that prevents tampered code/data from being executed).| 
|DeterministicSyncMaster| A synchronization control point that receives the synchronization requests through a dedicated communication channel, for example ara::com, and sends the calculated cycle information for the next execution cycle to the connected DeterministicClients in the same domain.|
|Deterministic Random Numbers|A set of random numbers that follows a known sequence and thus the same set can be distributed (one at a time) to deterministic workers. Note that this does not mean that randomness is compromised as that relates to predictability of the sequence by an observer and not to the fact that the set is predefined.| 

## 英日
日本語は仮訳

|no.|count|word|日本語|
|:----|:----|:----|:----|
|1|1835|the|その|
|2|1219|of|の|
|3|1014|sws_em_|sws_em_|
|4|827|state|状態|
|5|769|management|管理|
|6|761|to|に|
|7|739|execution|実行|
|8|644|process|処理する|
|9|621|a|一つの|
|10|519|and|と|
|11|497|in|の|
|12|493|is|は|
|13|461|function|働き|
|14|402|group|班|
|15|367|be|です|
|16|350|for|にとって|
|17|323|ara|AUTOSAR Runtime for Adaptive Applications(短縮名)|
|18|284|autosar|AUTomotive Open System Architecture(短縮名)|
|19|281|deterministic|決定論的|
|20|281|this|これ|
|21|276|that|それ|
|22|265|exec|execution(短縮名)|
|23|251|client|顧客|
|24|229|by|に|
|25|218|machine|機械|
|26|217|specification|仕様|
|27|203|rs_em_|rs_em_|
|28|201|on|の上|
|29|201|processes|過程|
|30|200|c|c|
|31|198|r|r|
|32|192|document|資料|
|33|191|are|それは|
|34|185|shall|しなければならない|
|35|175|an|と|
|36|170|id|identifier, 識別子(短縮名）|
|37|167|not|いいえ|
|38|166|time|時間|
|39|164|draft|下書き|
|40|160|class|級|
|41|159|ap|adaptive platform(短縮名)|
|42|159|autosar_sws_execution|autosar_sws_execution|
|43|143|atp|AUTOSAR template profile(短縮名)|
|44|141|rs_ap_|rs_ap_|
|45|140|transition|遷移|
|46|139|platform|土台|
|47|139|which|どれの|
|48|136|as|なので|
|49|136|or|また|
|50|134|it|それ|
|51|132|can|できる|
|52|132|see|見る|
|53|129|with|と|
|54|127|error|誤り|
|55|120|no|いいえ|
|56|117|adaptive|適用|
|57|115|b|b|
|58|112|e|e|
|59|107|if|もしも|
|60|105|cycle|周期|
|61|104|other|他の|
|62|104|startup|起動|
|63|103|application|応用|
|64|102|status|状態|
|65|98|from|から|
|66|98|start|始める|
|67|98|tags|札|
|68|97|running|走行中|
|69|96|system|系|
|70|96|termination|終了|
|71|93|d|d|
|72|91|note|記録|
|73|90|manifest|管理票|
|74|90|software|ソフトウェア|
|75|86|value|価値|
|76|85|type|型|
|77|84|kind|親切|
|78|81|api|application programming interface(短縮名)|
|79|80|behavior|行動|
|80|80|except|それ外|
|81|79|configuration|構成|
|82|78|description|説明|
|83|77|scope|範囲|
|84|76|states|状態|
|85|76|when|いつ|
|86|74|has|もっている|
|87|74|include|含む|
|88|74|resource|資源|
|89|74|will|意思|
|90|73|code|符号|
|91|73|executable|実行可能|
|92|72|change|変化する|
|93|72|data|与件|
|94|72|file|紙ばさみ|
|95|71|specific|明確|
|96|71|worker|労働者|
|97|70|core|芯|
|98|70|g|g|
|99|70|mode|状態|
|100|70|scheduling|予定|

# 参考資料(Reference)

[1] Specification of Communication Management, AUTOSAR_SWS_CommunicationManagement
[2] Glossary, AUTOSAR_TR_Glossary
https://www.autosar.org/fileadmin/standards/foundation/21-11/AUTOSAR_TR_Glossary.pdf
[3] Specification of Manifest, AUTOSAR_TPS_ManifestSpecification
[4] Specification of Adaptive Platform Core, AUTOSAR_SWS_AdaptivePlatformCore
[5] Requirements on Execution Management, AUTOSAR_RS_ExecutionManagement
[6] Specification of Operating System Interface,AUTOSAR_SWS_OperatingSystemInterface
[7] Specification of Persistency, AUTOSAR_SWS_Persistency
[8] Specification of Platform Health Management, AUTOSAR_SWS_PlatformHealthManagement
[9] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology
[10] Specification of State Management, AUTOSAR_SWS_StateManagement
[11] Guidelines for using Adaptive Platform interfaces, AUTOSAR_EXP_AdaptivePlatformInterfacesGuidelines
[12] Standard for Information Technology–Portable Operating System Interface
(POSIX(R)) Base Specifications, Issue 7, http://pubs.opengroup.org/onlinepubs/9699919799/
[13] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, ’Basic Concepts and Taxonomy of Dependable and Secure Computing’, IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, January-March 2004
[14] Explanation of Adaptive Platform Designm AUTOSAR_EXP_PlatformDesign
16 of 159 D