Specification of Execution Management

AUTOSAR AP R23-11

Specification of Execution
Document Title Management
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 721

Document Status published

Part of AUTOSAR Standard Adaptive Platform
Part of Standard Release R23-11

Document Change History

Date Release Changed by Description
• Requirements for deterministic execution
are set to obsolete

• The right to create child processes can

be configured by integrator
AUTOSAR • Added support for standardized trace
2023-11-23 R23-11 Release points
Management
• API Refinement (ExecutionClient
termination handler, remove
FunctionGroup, C++ Core Guidelines
compliance)

• Clarification of Unrecoverable State

• Clarification on error handling during
Function Group State transition
AUTOSAR
• Changes to ara::exec::ExecErrc
2022-11-24 R22-11 Release
Management • Clarification on interaction between
Platform Health Management and
Execution Management
5

1 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
• Clarified handling of unexpected
Process termination

• ara::exec::StateClient API
AUTOSAR updated (constructor token removed)
2021-11-25 R21-11 Release
Management • Invalid state transitions identified and
handling defined

• ara::exec::DeterministicClient
API and behaviour clarified
• Further refinement of State
Management API and semantics

AUTOSAR • Update process lifecycle (terminating

2020-11-30 R20-11 Release report optional)
Management
• Added Deterministic Synchronization
support

• EM-PHM interaction
• Further refinement of State
Management API and semantics

• Introduced support for trusted platform

• Added support for non-reporting

AUTOSAR
2019-11-28 R19-11 Processes
Release
• Execution Management API uses Core
types

• Changed Document Status from Final to

published
• Refinement of State Management
AUTOSAR semantics
2019-03-29 19-03 Release
Management • Document structure modified to reflect
current template
• Refinement of Deterministic Execution
AUTOSAR
• Updated Process lifecycle to clarify
2018-10-31 18-10 Release
Process and Execution States
Management
• Updated Application Recovery Actions
5

2 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
• Deterministic Execution
AUTOSAR • Resource Limitation
2018-03-29 18-03 Release
Management • State Management

• Fault Tolerance elaboration

• State Management elaboration,
introduction of Function Groups
AUTOSAR
• Recovery actions for Platform Health
2017-10-27 17-10 Release
Management
Management
• Resource limitation and deterministic
execution
AUTOSAR
2017-03-31 17-03 Release • Initial release
Management

3 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Disclaimer

This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

4 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Requirement Levels

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as follows.
Note that the requirement level of the document in which they are used modifies the
force of these words.
• MUST: This word, or the adjective "LEGALLY REQUIRED", means that the defi-
nition is an absolute requirement of the specification due to legal issues.
• MUST NOT: This phrase, or the phrase "MUST NOT", means that the definition
is an absolute prohibition of the specification due to legal issues.
• SHALL: This phrase, or the adjective "REQUIRED", means that the definition is
an absolute requirement of the specification.
• SHALL NOT: This phrase means that the definition is an absolute prohibition of
the specification.
• SHOULD: This word, or the adjective "RECOMMENDED", means that there may
exist valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.
• SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED", means that
there may exist valid reasons in particular circumstances when the particular be-
havior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label.
• MAY: This word, or the adjective "OPTIONAL", means that an item is truly op-
tional. One vendor may choose to include the item because a particular market-
place requires it or because the vendor feels that it enhances the product while
another vendor may omit the same item.
An implementation, which does not include a particular option, SHALL be prepared
to interoperate with another implementation, which does include the option, though
perhaps with reduced functionality. In the same vein an implementation, which does
include a particular option, SHALL be prepared to interoperate with another implemen-
tation, which does not include the option (except, of course, for the feature the option
provides.)

5 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Contents
1 Introduction and functional overview 12
1.1 What is Execution Management? . . . . . . . . . . . . . . . . . . . . . 12
1.2 Interaction with AUTOSAR Runtime for Adaptive . . . . . . . . . . . . 12
2 Acronyms and abbreviations 14

3 Related documentation 18
3.1 Input documents & related standards and norms . . . . . . . . . . . . 18
3.2 Further applicable specification . . . . . . . . . . . . . . . . . . . . . . 19
4 Constraints and assumptions 20
4.1 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Dependencies to other Functional Clusters 21
5.1 Provided Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Required Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Requirements Tracing 24
6.1 Not applicable requirements . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Functional specification 29
7.1 Functional Cluster Lifecyle . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.1 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.2 Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.3 Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.2 Adaptive Application . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.3 Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.4 Modelled Process . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2.5 Execution Manifest . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.6 Machine Manifest . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.7 Manifest Format . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3 Execution Management Responsibilities . . . . . . . . . . . . . . . . . 35
7.3.1 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4 Process Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1 Execution State . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1.2 Termination . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1.3 Unexpected Termination . . . . . . . . . . . . . . . . 40
7.4.1.4 Application Reporting . . . . . . . . . . . . . . . . . 40
7.4.2 Process States . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.4.2.1 Synchronization with Platform Health Management . 42
7.4.3 Trace Process State Transitions . . . . . . . . . . . . . . . . 43
7.4.4 Startup and Termination . . . . . . . . . . . . . . . . . . . . . 44

6 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.4.4.1 Execution Dependency . . . . . . . . . . . . . . . . . 44

7.4.4.2 Signal Mask . . . . . . . . . . . . . . . . . . . . . . . 49
7.4.4.3 Arguments . . . . . . . . . . . . . . . . . . . . . . . 50
7.4.4.4 Environment Variables . . . . . . . . . . . . . . . . . 50
7.4.5 Machine Startup Sequence . . . . . . . . . . . . . . . . . . . 51
7.5 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.5.2 Machine State . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.5.2.1 Startup . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5.2.2 Shutdown/Restart . . . . . . . . . . . . . . . . . . . 61
7.5.3 Function Group State . . . . . . . . . . . . . . . . . . . . . . 62
7.5.4 State Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.5.5 State Transition . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.6 Deterministic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.6.1 Determinism . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.6.1.1 Time Determinism . . . . . . . . . . . . . . . . . . . 77
7.6.1.2 Data Determinism . . . . . . . . . . . . . . . . . . . 77
7.6.1.3 Full Determinism . . . . . . . . . . . . . . . . . . . . 77
7.6.2 Deterministic Client . . . . . . . . . . . . . . . . . . . . . . . 78
7.6.3 Cyclic Deterministic Execution . . . . . . . . . . . . . . . . . 81
7.6.3.1 Control of Cyclic Execution . . . . . . . . . . . . . . 81
7.6.3.2 Worker Pool . . . . . . . . . . . . . . . . . . . . . . . 84
7.6.3.3 Random Numbers . . . . . . . . . . . . . . . . . . . 87
7.6.3.4 Time Stamps . . . . . . . . . . . . . . . . . . . . . . 87
7.6.3.5 Real-Time Resources . . . . . . . . . . . . . . . . . 88
7.6.4 Deterministic Synchronization . . . . . . . . . . . . . . . . . 91
7.6.4.1 DeterministicSyncMaster . . . . . . . . . . . . . . . 91
7.6.4.2 Synchronization Control Messages . . . . . . . . . . 95
7.7 Resource Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.7.1 Resource Configuration . . . . . . . . . . . . . . . . . . . . . 98
7.7.2 Resource Monitoring . . . . . . . . . . . . . . . . . . . . . . 100
7.7.3 Application-level Resource Configuration . . . . . . . . . . . 101
7.7.3.1 CPU Usage . . . . . . . . . . . . . . . . . . . . . . . 101
7.7.3.2 Core Affinity . . . . . . . . . . . . . . . . . . . . . . . 101
7.7.3.3 Scheduling . . . . . . . . . . . . . . . . . . . . . . . 102
7.7.3.4 Memory Budget and Monitoring . . . . . . . . . . . . 103
7.7.3.5 Working Folder . . . . . . . . . . . . . . . . . . . . . 105
7.8 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.8.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.8.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.8.4 Execution Management internal Error handling . . . . . . . . 107
7.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.9.1 Trusted Platform . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.9.1.1 Handling of failed authenticity checks . . . . . . . . . 111
7.9.2 Identity and Access Management . . . . . . . . . . . . . . . 113

7 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8 API specification 115

8.1 Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1.1 ExecutionState . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1.2 ActivationReturnType . . . . . . . . . . . . . . . . . . . . . . 115
8.1.3 DeterministicClient::TimeStamp . . . . . . . . . . . . . . . . 116
8.1.4 ExecutionError . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.1.5 ExecutionErrorEvent . . . . . . . . . . . . . . . . . . . . . . . 117
8.1.5.1 ExecutionErrorEvent::executionError . . . . . . . . . 117
8.1.5.2 ExecutionErrorEvent::functionGroup . . . . . . . . . 117
8.2 Class Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.2.1 ExecutionClient class . . . . . . . . . . . . . . . . . . . . . . 118
8.2.1.1 ExecutionClient::ExecutionClient . . . . . . . . . . . 118
8.2.1.2 ExecutionClient::Create . . . . . . . . . . . . . . . . 119
8.2.1.3 ExecutionClient::~ExecutionClient . . . . . . . . . . 120
8.2.1.4 ExecutionClient::ExecutionClient (deleted Copy
Constructor) . . . . . . . . . . . . . . . . . . . . . . . 120
8.2.1.5 ExecutionClient::operator= (deleted Copy assign-
ment operator) . . . . . . . . . . . . . . . . . . . . . 120
8.2.1.6 ExecutionClient::ExecutionClient (use of default
move constructor) . . . . . . . . . . . . . . . . . . . 121
8.2.1.7 ExecutionClient::operator= (use of default move as-
signment) . . . . . . . . . . . . . . . . . . . . . . . . 121
8.2.1.8 ExecutionClient::ReportExecutionState . . . . . . . . 121
8.2.2 WorkerRunnable class . . . . . . . . . . . . . . . . . . . . . 122
8.2.2.1 WorkerRunnable::Destructor . . . . . . . . . . . . . 122
8.2.2.2 WorkerRunnable::WorkerRunnable . . . . . . . . . . 123
8.2.2.3 WorkerRunnable::operator= (Copy assignment oper-
ator) . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.2.4 WorkerRunnable::Run . . . . . . . . . . . . . . . . . 124
8.2.3 WorkerThread class . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.3.1 WorkerThread::WorkerThread . . . . . . . . . . . . . 125
8.2.3.2 WorkerThread::~WorkerThread . . . . . . . . . . . . 126
8.2.3.3 WorkerThread::operator= (Copy assignment operator) 126
8.2.3.4 WorkerThread::GetRandom . . . . . . . . . . . . . . 126
8.2.4 DeterministicClient class . . . . . . . . . . . . . . . . . . . . 127
8.2.4.1 DeterministicClient::DeterministicClient . . . . . . . 127
8.2.4.2 DeterministicClient::~DeterministicClient . . . . . . . 128
8.2.4.3 DeterministicClient::WaitForActivation . . . . . . . . 128
8.2.4.4 DeterministicClient::RunWorkerPool . . . . . . . . . 129
8.2.4.5 DeterministicClient::GetRandom . . . . . . . . . . . 129
8.2.4.6 DeterministicClient::SetRandomSeed . . . . . . . . 130
8.2.4.7 DeterministicClient::GetActivationTime . . . . . . . . 130
8.2.4.8 DeterministicClient::GetNextActivationTime . . . . . 131
8.2.5 FunctionGroup class . . . . . . . . . . . . . . . . . . . . . . . 131
8.2.5.1 FunctionGroup::Create . . . . . . . . . . . . . . . . . 132
8.2.5.2 FunctionGroup::FunctionGroup . . . . . . . . . . . . 132

8 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.5.3 FunctionGroup::FunctionGroup (Copy Constructor) . 133

8.2.5.4 FunctionGroup::FunctionGroup (Move Constructor) . 133
8.2.5.5 FunctionGroup::operator= (Copy assignment operator)133
8.2.5.6 FunctionGroup::operator= (Move assignment operator)134
8.2.5.7 FunctionGroup::~FunctionGroup . . . . . . . . . . . 134
8.2.5.8 FunctionGroup::operator== . . . . . . . . . . . . . . 134
8.2.5.9 FunctionGroup::operator!= . . . . . . . . . . . . . . . 135
8.2.6 FunctionGroupState class . . . . . . . . . . . . . . . . . . . . 135
8.2.6.1 FunctionGroupState::Create . . . . . . . . . . . . . . 136
8.2.6.2 FunctionGroupState::FunctionGroupState . . . . . . 136
8.2.6.3 FunctionGroupState::FunctionGroupState (Copy
Constructor) . . . . . . . . . . . . . . . . . . . . . . . 137
8.2.6.4 FunctionGroupState::FunctionGroupState (Move
Constructor) . . . . . . . . . . . . . . . . . . . . . . . 137
8.2.6.5 FunctionGroupState::operator= (Copy assignment
operator) . . . . . . . . . . . . . . . . . . . . . . . . 137
8.2.6.6 FunctionGroupState::operator= (Move assignment
operator) . . . . . . . . . . . . . . . . . . . . . . . . 138
8.2.6.7 FunctionGroupState::~FunctionGroupState . . . . . 138
8.2.6.8 FunctionGroupState::operator== . . . . . . . . . . . 139
8.2.6.9 FunctionGroupState::operator!= . . . . . . . . . . . . 139
8.2.7 StateClient class . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.2.7.1 StateClient::StateClient . . . . . . . . . . . . . . . . 140
8.2.7.2 StateClient::Create . . . . . . . . . . . . . . . . . . . 141
8.2.7.3 StateClient::~StateClient . . . . . . . . . . . . . . . . 141
8.2.7.4 StateClient::StateClient (deleted Copy Constructor) . 142
8.2.7.5 StateClient::operator= (deleted Copy assignment op-
erator) . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.2.7.6 StateClient::StateClient (use of default move con-
structor) . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.2.7.7 StateClient::operator= (use of default move assign-
ment) . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.2.7.8 StateClient::SetState . . . . . . . . . . . . . . . . . . 143
8.2.7.9 StateClient::GetInitialMachineStateTransitionResult . 144
8.2.7.10 StateClient::GetExecutionError . . . . . . . . . . . . 145
8.3 Log and Trace Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.4 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.1 Execution Management error codes . . . . . . . . . . . . . . 148
8.4.2 ExecException class . . . . . . . . . . . . . . . . . . . . . . . 149
8.4.2.1 ExecException::ExecException . . . . . . . . . . . . 149
8.4.3 GetExecErrorDomain function . . . . . . . . . . . . . . . . . 149
8.4.4 MakeErrorCode function . . . . . . . . . . . . . . . . . . . . 150
8.4.5 ExecErrorDomain class . . . . . . . . . . . . . . . . . . . . . 150
8.4.5.1 ExecErrorDomain::ExecErrorDomain . . . . . . . . . 150
8.4.5.2 ExecErrorDomain::Name . . . . . . . . . . . . . . . 151
8.4.5.3 ExecErrorDomain::Message . . . . . . . . . . . . . . 151

9 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.4.5.4 ExecErrorDomain::ThrowAsException . . . . . . . . 152

9 Service Interfaces 153

A Mentioned Manifest Elements 154

B History of Constraints and Specification Items 164

B.1 Constraint and Specification Item History of this document according
to AUTOSAR Release 17-03 . . . . . . . . . . . . . . . . . . . . . . . . 164
B.1.1 Added Specification Items in 17-03 . . . . . . . . . . . . . . 164
B.1.2 Changed Specification Items in 17-03 . . . . . . . . . . . . . 165
B.1.3 Deleted Specification Items in 17-03 . . . . . . . . . . . . . . 165
B.1.4 Added Constraints in 17-03 . . . . . . . . . . . . . . . . . . . 166
B.1.5 Changed Constraints in 17-03 . . . . . . . . . . . . . . . . . 166
B.1.6 Deleted Constraints in 17-03 . . . . . . . . . . . . . . . . . . 166
B.2 Constraint and Specification Item History of this document according
to AUTOSAR Release 17-10 . . . . . . . . . . . . . . . . . . . . . . . . 166
B.2.1 Added Specification Items in 17-10 . . . . . . . . . . . . . . 166
B.2.2 Changed Specification Items in 17-10 . . . . . . . . . . . . . 167
B.2.3 Deleted Specification Items in 17-10 . . . . . . . . . . . . . . 168
B.2.4 Added Constraints in 17-10 . . . . . . . . . . . . . . . . . . . 169
B.2.5 Changed Constraints in 17-10 . . . . . . . . . . . . . . . . . 169
B.2.6 Deleted Constraints in 17-10 . . . . . . . . . . . . . . . . . . 169
B.3 Constraint and Specification Item History of this document according
to AUTOSAR Release 18-03 . . . . . . . . . . . . . . . . . . . . . . . . 169
B.3.1 Added Specification Items in 18-03 . . . . . . . . . . . . . . 169
B.3.2 Changed Specification Items in 18-03 . . . . . . . . . . . . . 171
B.3.3 Deleted Specification Items in 18-03 . . . . . . . . . . . . . . 172
B.3.4 Added Constraints in 18-03 . . . . . . . . . . . . . . . . . . . 173
B.3.5 Changed Constraints in 18-03 . . . . . . . . . . . . . . . . . 173
B.3.6 Deleted Constraints in 18-03 . . . . . . . . . . . . . . . . . . 173
B.4 Constraint and Specification Item History of this document according
to AUTOSAR Release 18-10 . . . . . . . . . . . . . . . . . . . . . . . . 173
B.4.1 Added Specification Items in 18-10 . . . . . . . . . . . . . . 173
B.4.2 Changed Specification Items in 18-10 . . . . . . . . . . . . . 173
B.4.3 Deleted Specification Items in 18-10 . . . . . . . . . . . . . . 175
B.4.4 Added Constraints in 18-10 . . . . . . . . . . . . . . . . . . . 175
B.4.5 Changed Constraints in 18-10 . . . . . . . . . . . . . . . . . 175
B.4.6 Deleted Constraints in 18-10 . . . . . . . . . . . . . . . . . . 175
B.5 Constraint and Specification Item History of this document according
to AUTOSAR Release 19-03 . . . . . . . . . . . . . . . . . . . . . . . . 176
B.5.1 Added Specification Items in R19-03 . . . . . . . . . . . . . . 176
B.5.2 Changed Specification Items in R19-03 . . . . . . . . . . . . 176
B.5.3 Deleted Specification Items in R19-03 . . . . . . . . . . . . . 177
B.5.4 Added Constraints in R19-03 . . . . . . . . . . . . . . . . . . 177
B.5.5 Changed Constraints in R19-03 . . . . . . . . . . . . . . . . 177
B.5.6 Deleted Constraints in R19-03 . . . . . . . . . . . . . . . . . 178

10 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.6 Constraint and Specification Item History of this document according

to AUTOSAR Release R19-11 . . . . . . . . . . . . . . . . . . . . . . . 178
B.6.1 Added Specification Items in R19-11 . . . . . . . . . . . . . . 178
B.6.2 Changed Specification Items in R19-11 . . . . . . . . . . . . 180
B.6.3 Deleted Specification Items in R19-11 . . . . . . . . . . . . . 182
B.6.4 Added Constraints in R19-11 . . . . . . . . . . . . . . . . . . 182
B.6.5 Changed Constraints in R19-11 . . . . . . . . . . . . . . . . 182
B.6.6 Deleted Constraints in R19-11 . . . . . . . . . . . . . . . . . 183
B.7 Constraint and Specification Item History of this document according
to AUTOSAR Release R20-11 . . . . . . . . . . . . . . . . . . . . . . . 183
B.7.1 Added Specification Items in R20-11 . . . . . . . . . . . . . . 183
B.7.2 Changed Specification Items in R20-11 . . . . . . . . . . . . 184
B.7.3 Deleted Specification Items in R20-11 . . . . . . . . . . . . . 185
B.7.4 Added Constraints in R20-11 . . . . . . . . . . . . . . . . . . 186
B.7.5 Changed Constraints in R20-11 . . . . . . . . . . . . . . . . 186
B.7.6 Deleted Constraints in R20-11 . . . . . . . . . . . . . . . . . 186
B.8 Constraint and Specification Item History of this document according
to AUTOSAR Release R21-11 . . . . . . . . . . . . . . . . . . . . . . . 186
B.8.1 Added Specification Items in R21-11 . . . . . . . . . . . . . . 186
B.8.2 Changed Specification Items in R21-11 . . . . . . . . . . . . 187
B.8.3 Deleted Specification Items in R21-11 . . . . . . . . . . . . . 188
B.8.4 Added Constraints in R21-11 . . . . . . . . . . . . . . . . . . 188
B.8.5 Changed Constraints in R21-11 . . . . . . . . . . . . . . . . 188
B.8.6 Deleted Constraints in R21-11 . . . . . . . . . . . . . . . . . 189
B.9 Constraint and Specification Item History of this document according
to AUTOSAR Release R22-11 . . . . . . . . . . . . . . . . . . . . . . . 189
B.9.1 Added Specification Items in R22-11 . . . . . . . . . . . . . . 189
B.9.2 Changed Specification Items in R22-11 . . . . . . . . . . . . 189
B.9.3 Deleted Specification Items in R22-11 . . . . . . . . . . . . . 192
B.9.4 Added Constraints in R22-11 . . . . . . . . . . . . . . . . . . 192
B.9.5 Changed Constraints in R22-11 . . . . . . . . . . . . . . . . 192
B.9.6 Deleted Constraints in R22-11 . . . . . . . . . . . . . . . . . 192
B.10 Constraint and Specification Item History of this document according
to AUTOSAR Release R23-11 . . . . . . . . . . . . . . . . . . . . . . . 192
B.10.1 Added Specification Items in R23-11 . . . . . . . . . . . . . . 192
B.10.2 Changed Specification Items in R23-11 . . . . . . . . . . . . 194
B.10.3 Deleted Specification Items in R23-11 . . . . . . . . . . . . . 197
B.10.4 Added Constraints in R23-11 . . . . . . . . . . . . . . . . . . 197
B.10.5 Changed Constraints in R23-11 . . . . . . . . . . . . . . . . 197
B.10.6 Deleted Constraints in R23-11 . . . . . . . . . . . . . . . . . 197

11 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

1 Introduction and functional overview

This document is the software specification of the Execution Management func-
tional cluster within the Adaptive Platform Foundation.
Execution Management is responsible for the management of all aspects of sys-
tem execution including platform initialization and the startup / shutdown of Appli-
cations. Execution Management works with, and configures, the Operating
System to perform run-time scheduling of Applications.
Chapter 7 describes how Execution Management concepts are realized within the
AUTOSAR Adaptive Platform.

1.1 What is Execution Management?

Execution Management is the functional cluster within the Adaptive Platform
Foundation that is responsible for platform initialization and the startup and shutdown
of Modelled Processes. Modelled Processes are self-contained, e.g. have in-
ternal control of thread creation. Execution Management performs these tasks us-
ing information contained within one or more Manifest content such as when and
how Executables should be started. Execution Management also provides sup-
port for State Management (see Section 7.5), Deterministic Execution (see Section
7.6), and Security (Section 7.9).
The Execution Management functional cluster is part of the AUTOSAR Adaptive
Platform. However, the AUTOSAR Adaptive Platform is usually not exclusively
used within a single AUTOSAR System as the vehicle is also equipped with a number
of ECUs developed on the AUTOSAR Classic Platform. The System design for the
entire vehicle will therefore cover both AUTOSAR Classic Platform ECUs as well as
AUTOSAR Adaptive Platform Machines.

1.2 Interaction with AUTOSAR Runtime for Adaptive

The set of programming interfaces to the Adaptive Applications is called
AUTOSAR Runtime for Adaptive (ARA). The interfaces that constitute ARA include
those of Execution Management specified in Chapter 8.
Execution Management, in common with other Applications is assumed to be a
process executed on a POSIX compliant operating system. Execution Management
is responsible for initiating execution of the processes in all the Functional Clusters,
Adaptive AUTOSAR Services, and user-level Applications. Therefore, Execution
Management has no standardized dependencies. The launching order of Applica-
tions is derived by Execution Management according to the specification defined
in this document to ensure proper startup of the AUTOSAR Adaptive Platform.

12 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The Adaptive AUTOSAR Services are provided via mechanisms provided by the
Communication Management functional cluster [1] of the Adaptive Platform
Foundation. In order to use the Adaptive AUTOSAR Services, the functional clusters
in the Adaptive Platform Foundation must be properly initialized beforehand.
Please refer to the respective specifications regarding more information on Communi-
cation Management.

13 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

2 Acronyms and abbreviations

All technical terms used throughout this document – except the ones listed here – can
be found in the official [2] AUTOSAR Glossary or [3] TPS Manifest Specification.
Description
Term
A process refers to the OS concept of a running process.
Attention: process is not equal to Modelled Process (see
process below). Hence each Modelled Process has at some time a
related (OS) process but a process may not always have a related
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
Modelled Process 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.
A type of Modelled Process with an associated Executable
where reportingBehavior is omitted ([TPS_MANI_01279]) or
Reporting Process set to reportsExecutionState. A Reporting Process is
expected to report its Execution State to Execution Manage-
ment.
A type of Modelled Process with an associated Executable
where reportingBehavior is set to doesNotReportExecu-
tionState ([TPS_MANI_01279]). Please note that the Non-
reporting Process was not developed for the AUTOSAR Adap-
tive Platform and for this reason it is not using Adaptive
Non-reporting Process Platform Services. For example, it is not using ara::
exec::ExecutionClient API and therefore cannot report Ex-
ecution State to Execution Management. In general, this
type of a process is intended to allow integration of a software
that cannot be modified for use with the AUTOSAR Adaptive
Platform.
A type of Reporting Process that is associated with Non-re-
porting Process and used to determine when functionality
expected from Non-reporting Process is available. When-
ever functional dependencies on Non-reporting Processes
Companion Process
exist, the integrator can configure proxy Execution Depen-
dencies on the Companion Process and make the Compan-
ion Process kRunning reporting conditional on monitored
Non-reporting Process.
A type of Modelled Process that has terminationBehav-
ior configured to processIsSelfTerminating. This type of
Modelled Process is allowed to self initiate termination proce-
Self-terminating Process
dure (i.e. just terminate with exit status EXIT_SUCCESS), or wait
for Execution Management to initiate termination procedure
via SIGTERM.

14 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The event consumed by Execution Management when a

Modelled Process terminates without justified reason, for ex-
ample:
• termination without prior request where termination-
Behavior is configured to processIsNotSelfTermi-
Unexpected Self-termination nating.
• 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.
The event consumed by Execution Management when a
Modelled Process terminates with exit status other than 0
Unexpected Termination
(EXIT_SUCCESS). Any kind of unhandled signal will result in an
Unexpected Termination and thus a non 0 exit status.
Dependencies between Modelled Process instances can be
Execution Dependency configured to define a sequence for starting and terminating
them.
The element of the AUTOSAR Adaptive Platform responsi-
Execution Management ble for the ordered startup and shutdown of the AUTOSAR Adap-
tive Platform and Adaptive Applications.
The element defining modes of operation for AUTOSAR Adap-
State Management tive Platform. It allows flexible definition of functions which
are active on the platform at any given time.
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 Mod-
elled Process were allowed to be running at the same point
Function Group in time in more than one Function Group then potential con-
tradictions 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 pro-
cesses of platform level Applications. Other Function
Groups are sort of general purpose tools used (for example) to
control processes of user-level Applications.
The element of State Management that characterizes the cur-
rent status of a set of user-level Applications.
Function Group State
The set of Function Groups and their Function Group
States are configured in the Execution Manifest.
Any state of a Function Group, which is not modelled.
A Function Group is in an Undefined Function Group
Undefined Function Group State State during state transition, if a state transition failed or if
an Unexpected Termination or Unexpected Self-ter-
mination happened.
A state of Function Group "MachineFG" with some prede-
fined states (Startup/Shutdown/Restart). This can term can refer
Machine State 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 ...").

15 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The results of a calculation are guaranteed to be available before

Time Determinism
a given deadline.
The results of a calculation only depend on the input data and
Data Determinism
are reproducible, assuming a given initial internal state.
Full Determinism Combination of Time and Data Determinism.
A Functional Cluster within the Adaptive Platform
Communication Management
Foundation
Manifest file to configure execution of an Adaptive Appli-
cation. An Execution Manifest is created at integration
time and deployed onto a Machine together with the Exe-
Execution Manifest cutable 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.
Manifest file to configure a Machine. The Machine Man-
Machine Manifest ifest holds all configuration information which cannot be as-
signed to a specific Executable or process.
Software responsible for managing processes on a Machine
Operating System
and for providing an interface to hardware resources.
Adaptive Application interface to Execution Manage-
ExecutionClient
ment.
Adaptive Application interface to Execution Manage-
DeterministicClient ment to support control of the process-internal cycle, a determin-
istic worker pool, activation time stamps and random numbers.
State Management interface to Execution Management to
StateClient support Function Group State and Machine State man-
agement.
A Functional Cluster within the Adaptive Platform
Platform Health Management
Foundation
Process State Lifecycle state of a Modelled Process
Manifest file to configure Service-oriented communication
Service Instance Manifest
used by an Adaptive Application.
An execution platform supporting a continuous chain of trust from
boot through to application. The trust chain ensures that all ex-
Trusted Platform ecution is both authenticated (that all code executed is from the
claimed source) and subjected to integrity validation (that pre-
vents tampered code/data from being executed).
A synchronization control point that receives the synchroniza-
tion requests through a dedicated communication channel, for
DeterministicSyncMaster example ara::com, and sends the calculated cycle information
for the next execution cycle to the connected Deterministic-
Clients in the same domain.
A set of random numbers that follows a known sequence and
thus the same set can be distributed (one at a time) to determin-
Deterministic Random Numbers istic 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.
A state entered by Execution Management in response to a
situation that it cannot resolve. In the state, Execution Man-
Unrecoverable State agement stops taking any further actions, terminates all pro-
cesses managed by Execution Management and provides a
facility for further project-specific handling.

Table 2.1: Technical Terms

16 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The following technical terms used throughout this document are defined in the official
[2] AUTOSAR Glossary or [3] TPS Manifest Specification – they are repeated here for
tracing purposes.
Description
Term
Adaptive Application see [2] AUTOSAR Glossary
Application see [2] AUTOSAR Glossary
AUTOSAR Adaptive Platform see [2] AUTOSAR Glossary
Adaptive Platform Foundation see [2] AUTOSAR Glossary
Adaptive Platform Services see [2] AUTOSAR Glossary
Manifest see [2] AUTOSAR Glossary
Executable see [2] AUTOSAR Glossary
Functional Cluster see [2] AUTOSAR Glossary
Machine see [2] AUTOSAR Glossary
Processed Manifest see [2] AUTOSAR Glossary
Service see [2] AUTOSAR Glossary
Service Interface see [2] AUTOSAR Glossary
Service Discovery see [2] AUTOSAR Glossary
PLATFORM_CORE see [3] TPS Manifest Specification

Table 2.2: Glossary-defined Technical Terms

17 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

3 Related documentation

3.1 Input documents & related standards and norms

The main documents that serve as input for the specification of the Execution Man-
agement are:

[1] Specification of Communication Management

AUTOSAR_AP_SWS_CommunicationManagement
[2] Glossary
AUTOSAR_FO_TR_Glossary
[3] Specification of Manifest
AUTOSAR_AP_TPS_ManifestSpecification
[4] Specification of Adaptive Platform Core
AUTOSAR_AP_SWS_Core
[5] Requirements on Execution Management
AUTOSAR_AP_RS_ExecutionManagement
[6] Explanation of Adaptive Platform Software Architecture
AUTOSAR_AP_EXP_SWArchitecture
[7] Methodology for Adaptive Platform
AUTOSAR_AP_TR_Methodology
[8] Specification of Platform Health Management
AUTOSAR_AP_SWS_PlatformHealthManagement
[9] Specification of State Management
AUTOSAR_AP_SWS_StateManagement
[10] Guidelines for using Adaptive Platform interfaces
AUTOSAR_AP_EXP_InterfacesGuidelines
[11] Safety Requirements for AUTOSAR Adaptive Platform and AUTOSAR Classic
Platform
AUTOSAR_FO_RS_Safety
[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 Transac-
tions on Dependable and Secure Computing, Vol. 1, No. 1, January-March 2004
[14] Explanation of Adaptive Platform Design

18 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

AUTOSAR_AP_EXP_PlatformDesign
[15] Explanation of Identity and Access Management
AUTOSAR_AP_EXP_IdentityAndAccessManagement

3.2 Further applicable specification

AUTOSAR provides a core specification [4] which is also applicable for Execution
Management. The chapter “General requirements for all FunctionalClusters” of this
specification shall be considered as an additional and required specification for imple-
mentation of Execution Management.

19 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4 Constraints and assumptions

4.1 Known Limitations

This chapter lists known limitations of Execution Management and their relation to
this release of the AUTOSAR Adaptive Platform with the intent to provide an indi-
cation how Execution Management within the context of the AUTOSAR Adaptive
Platform will evolve in future releases.
The following functionality is mentioned within this document but is not fully specified
in this release:
Section 7.7 Resource Limitation and Section 7.8 Fault Tolerance – these sec-
tions have been expanded in this release but are not complete. In particular
the contents will be expanded with more properties and formal requirements in
the next release.
Section 7.6.4 describes synchronization requirements for redundant deterministic ex-
ecution that were required but not elaborated in 7.6.2. The interface of using com-
munication APIs other than ara::com is not in the scope of the specification. We
focus on the single domain synchronization for the current release, i.e. the redundant
deterministic execution is in the same OS or ECU. The models and configuration for
deterministic synchronization and the details of interaction with Software Lockstep will
be specified in a later release.
Section 6.1 details requirements from Execution Management Requirement Spec-
ification [5] that are not elaborated within this specification. The presence of these
requirements in this document ensures that the requirement tracing is complete and
also provides an indication of how Execution Management will evolve in future re-
leases of the AUTOSAR Adaptive Platform.
The functionality described above is subject to modification and will be considered for
inclusion in a future release of this document.

20 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

5 Dependencies to other Functional Clusters

This chapter provides an overview of the dependencies to other Functional Clusters in
the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the interfaces
provided by Execution Management to other Functional Clusters. Section 5.2 “
Required Interfaces” lists the interfaces required by Execution Management.
A detailed technical architecture documentation of the AUTOSAR Adaptive Platform is
provided in [6].

5.1 Provided Interfaces

«aapFunctionalClust... «aapFunctionalClust... «aapFunctionalClust... «aapFunctionalClust... «aapFunctionalClust...

State Management Platform Health Diagnostic Management Update and Configuration Time Synchronization
Management Management

daemon-based daemon-based daemon-based daemon-based daemon-based

«use» «use» «use» «use» «use»

«aapAPI,aapNativeInterface»
ExecutionClient

+ Create()
+ ReportExecutionState(ExecutionState): Result

«aapFunctionalCluster»
Execution Management
daemon-based

Figure 5.1: Interfaces provided by Execution Management to other Functional Clusters

Figure 5.1 shows the interfaces provided by Execution Management to other Func-
tional Clusters within the AUTOSAR Adaptive Platform.
«aapFunctionalCluster»
State Management
daemon-based

«use» «use»
«aapRequiredPort»

«aapAPI,aapNativeInterface» «aapAPI,aapPortInterface»
StateClient FunctionGroupState

+ Create(function)
+ GetExecutionError()
+ GetInitialMachineStateTransitionResult()
+ SetState(FunctionGroupState): Future

«aapFunctionalCluster»
Execution Management
daemon-based

Figure 5.2: Interfaces provided by Execution Management to State Management

Figure 5.2 shows the interfaces provided by Execution Management to State

Management. Table 5.1 provides a complete list of interfaces provided to other Func-
tional Clusters within the AUTOSAR Adaptive Platform.

21 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Interface Functional Cluster Purpose

ExecutionClient Diagnostic Management This interface is used to report the status of the
Diagnostic Management daemon process(es).
Platform Health Management Platform Health Management uses this interface to
report the state of its daemon process to Execution
Management.
State Management This interface shall be used to report the state of the
State Management process(es).
Time Synchronization Time Synchronization shall use this interface to
report the state of its daemon process.
Update and Configuration This interface shall be used by the daemon process(es)
Management inside Update and Configuration Management to
report their execution state to Execution Management.
Vehicle Update and Configuration This interface shall be used by the daemon process(es)
Management inside Vehicle Update and Configuration
Management to report their execution state to Execution
Management.
FunctionGroup State Management This interface shall be used to request
State FunctionGroupState transitions and to check their status.
StateClient State Management This interface shall be used to request
FunctionGroupState transitions.

Table 5.1: Interfaces provided to other Functional Clusters

5.2 Required Interfaces

«aapFunctionalCluster»
Execution Management
daemon-based

«use»
«use» «use»
«aapRequiredPort»

«aapAPI,aapNativeInterf... «aapAPI,aapPortInterface» «aapInternal»

Logger SupervisedEntity Multi-Process System Interface

+ IsEnabled() + ReportCheckpoint() + SetProcessConfiguration()

+ Log(MsgId, Params) + StartProcess()
+ LogDebug(): LogStream + TerminateProcess()
+ LogError(): LogStream
+ LogFatal(): LogStream
+ LogInfo(): LogStream
+ LogVerbose(): LogStream
+ LogWarn(): LogStream
+ WithLevel(): LogStream

«aapFunctionalClust... «aapFunctionalClust... Operating System

Log and Trace Platform Health
Management
daemon-based

Figure 5.3: Interfaces required by Execution Management from other Functional Clusters

Figure 5.3 shows the interfaces required by Execution Management from other
Functional Clusters within the AUTOSAR Adaptive Platform. Table 5.2 provides a com-
plete list of required interfaces from other Functional Clusters within the AUTOSAR
Adaptive Platform.

22 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Functional Cluster Interface Purpose

Log and Trace Logger Execution Management shall use this interface to log
standardized messages.
Persistency KeyValueStorage Execution Management should use this interface to
read/write persistent data.
Platform Health SupervisedEntity Execution Management shall use this interface to
Management enable supervision of its process(es) by Platform
Health Management.

Table 5.2: Interfaces required from other Functional Clusters

23 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

6 Requirements Tracing
The following tables reference the requirements specified in [5] and links to the fulfill-
ment of these. Please note that if column “Satisfied by” is empty for a specific require-
ment this means that this requirement is not fulfilled by this document.
Requirement Description Satisfied by
[RS_AP_00114] C++ interface shall be compatible [SWS_EM_02560] [SWS_EM_02561]
with C++14.
[RS_AP_00116] Header file name. [SWS_EM_02210] [SWS_EM_02510]
[SWS_EM_02530] [SWS_EM_02544]
[RS_AP_00119] Return values / application errors. [SWS_EM_02003] [SWS_EM_02276]
[SWS_EM_02278] [SWS_EM_02279]
[SWS_EM_02560] [SWS_EM_02561]
[SWS_EM_02562]
[RS_AP_00120] Method and Function names. [SWS_EM_02003] [SWS_EM_02217]
[SWS_EM_02221] [SWS_EM_02225]
[SWS_EM_02226] [SWS_EM_02231]
[SWS_EM_02236] [SWS_EM_02276]
[SWS_EM_02278] [SWS_EM_02279]
[SWS_EM_02283] [SWS_EM_02286]
[SWS_EM_02287] [SWS_EM_02288]
[SWS_EM_02289] [SWS_EM_02290]
[SWS_EM_02291] [SWS_EM_02520]
[SWS_EM_02540] [SWS_EM_02542]
[SWS_EM_02560] [SWS_EM_02561]
[SWS_EM_02562]
[RS_AP_00121] Parameter names. [SWS_EM_02003] [SWS_EM_02221]
[SWS_EM_02226] [SWS_EM_02276]
[SWS_EM_02278] [SWS_EM_02283]
[SWS_EM_02288] [SWS_EM_02289]
[SWS_EM_02291] [SWS_EM_02520]
[SWS_EM_02542] [SWS_EM_02560]
[SWS_EM_02561]
[RS_AP_00122] Type names. [SWS_EM_02201] [SWS_EM_02203]
[SWS_EM_02210] [SWS_EM_02281]
[SWS_EM_02282] [SWS_EM_02284]
[SWS_EM_02510] [SWS_EM_02530]
[SWS_EM_02531] [SWS_EM_02532]
[SWS_EM_02541] [SWS_EM_02544]
[RS_AP_00124] Variable names. [SWS_EM_02544] [SWS_EM_02545]
[SWS_EM_02546]
[RS_AP_00127] Usage of ara::core types. [SWS_EM_02203] [SWS_EM_02217]
[SWS_EM_02221] [SWS_EM_02231]
[SWS_EM_02236] [SWS_EM_02281]
[SWS_EM_02282] [SWS_EM_02284]
[RS_AP_00128] Error reporting. [SWS_EM_02003] [SWS_EM_02292]
[SWS_EM_02542] [SWS_EM_02562]
[RS_AP_00129] Public types defined by functional [SWS_EM_02201]
clusters shall be designed to allow
implementation without dynamic
memory allocation.
5

24 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Requirement Description Satisfied by
[RS_AP_00130] AUTOSAR Adaptive Platform shall [SWS_EM_02246] [SWS_EM_02247]
represent a rich and modern [SWS_EM_02248] [SWS_EM_02249]
programming environment. [SWS_EM_02281] [SWS_EM_02282]
[SWS_EM_02283] [SWS_EM_02284]
[SWS_EM_02286] [SWS_EM_02287]
[SWS_EM_02288] [SWS_EM_02289]
[SWS_EM_02290] [SWS_EM_02291]
[RS_AP_00132] noexcept behavior of API functions [SWS_EM_02003] [SWS_EM_02211]
[SWS_EM_02217] [SWS_EM_02221]
[SWS_EM_02225] [SWS_EM_02226]
[SWS_EM_02231] [SWS_EM_02236]
[SWS_EM_02276] [SWS_EM_02278]
[SWS_EM_02279] [SWS_EM_02283]
[SWS_EM_02286] [SWS_EM_02287]
[SWS_EM_02288] [SWS_EM_02290]
[SWS_EM_02291] [SWS_EM_02540]
[SWS_EM_02542] [SWS_EM_02562]
[RS_AP_00134] noexcept behavior of class [SWS_EM_02000] [SWS_EM_02002]
destructors [SWS_EM_02215] [SWS_EM_02272]
[SWS_EM_02277] [SWS_EM_02532]
[RS_AP_00138] Return type of asynchronous function [SWS_EM_02278] [SWS_EM_02279]
calls.
[RS_AP_00139] Return type of synchronous function [SWS_EM_02003] [SWS_EM_02217]
calls. [SWS_EM_02221] [SWS_EM_02231]
[SWS_EM_02236] [SWS_EM_02276]
[SWS_EM_02542] [SWS_EM_02562]
[RS_AP_00140] Usage of "final specifier" in ara types. [SWS_EM_02210] [SWS_EM_02544]
[RS_AP_00143] Use 32-bit integral types by default. [SWS_EM_02201]
[RS_AP_00144] Availability of a named constructor. [SWS_EM_02276] [SWS_EM_02562]
[RS_AP_00145] Availability of special member [SWS_EM_02002] [SWS_EM_02272]
functions. [SWS_EM_02277] [SWS_EM_02325]
[SWS_EM_02330] [SWS_EM_02331]
[SWS_EM_02332] [SWS_EM_02563]
[SWS_EM_02564] [SWS_EM_02565]
[SWS_EM_02566] [SWS_EM_02567]
[SWS_EM_02568] [SWS_EM_02580]
[SWS_EM_02581]
[RS_AP_00148] Default arguments are not allowed in [SWS_EM_02520] [SWS_EM_02532]
virtual functions.
[RS_AP_00149] Guidance on error handling. [SWS_EM_02557]
[RS_AP_00150] Provide only interfaces that are [SWS_EM_02001] [SWS_EM_02210]
intended to be used by AUTOSAR [SWS_EM_02263] [SWS_EM_02269]
applications and other Functional [SWS_EM_02275] [SWS_EM_02282]
Clusters. [SWS_EM_02284] [SWS_EM_02510]
[SWS_EM_02530]
[RS_AP_00151] C++ Core Guidelines. [SWS_EM_02331] [SWS_EM_02332]
[SWS_EM_02560] [SWS_EM_02561]
[SWS_EM_02566] [SWS_EM_02567]
[SWS_EM_02580] [SWS_EM_02581]
[RS_AP_00153] Assignment operators should restrict [SWS_EM_02330] [SWS_EM_02332]
"this" to lvalues
5

25 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Requirement Description Satisfied by
[RS_AP_00154] Internal namespaces. [SWS_EM_02001] [SWS_EM_02201]
[SWS_EM_02210] [SWS_EM_02263]
[SWS_EM_02269] [SWS_EM_02275]
[SWS_EM_02281] [SWS_EM_02282]
[SWS_EM_02284] [SWS_EM_02290]
[SWS_EM_02291] [SWS_EM_02510]
[SWS_EM_02530] [SWS_EM_02541]
[SWS_EM_02544]
[RS_AP_00155] Avoidance of cluster-specific [SWS_EM_02557]
initialization functions.
[RS_EM_00002] Execution Management shall [SWS_EM_01014] [SWS_EM_01015]
set-up one process for the execution [SWS_EM_01041] [SWS_EM_01042]
of each Modelled Process. [SWS_EM_01043]
[RS_EM_00005] Execution Management shall [SWS_EM_02102] [SWS_EM_02103]
support the configuration of OS [SWS_EM_02106] [SWS_EM_02108]
resource budgets for process and [SWS_EM_02109]
groups of processes.
[RS_EM_00008] Execution Management shall [SWS_EM_02104]
support the binding of all threads of a
given process to a specified set of
processor cores.
[RS_EM_00009] Execution Management shall [SWS_EM_01030] [SWS_EM_01033]
control the right to create child [SWS_EM_02559]
processes for each process it
starts.
[RS_EM_00010] Execution Management shall [SWS_EM_01012] [SWS_EM_01072]
support multiple instances of [SWS_EM_01078] [SWS_EM_02246]
Executables. [SWS_EM_02247] [SWS_EM_02248]
[SWS_EM_02249]
[RS_EM_00011] Execution Management shall [SWS_EM_01006] [SWS_EM_01404]
support self-initiated graceful
shutdown of processes.
[RS_EM_00014] Execution Management shall [SWS_EM_02299] [SWS_EM_02300]
support a Trusted Platform. [SWS_EM_02301] [SWS_EM_02302]
[SWS_EM_02303] [SWS_EM_02305]
[SWS_EM_02306] [SWS_EM_02307]
[SWS_EM_02308] [SWS_EM_02309]
[SWS_EM_02556]
[RS_EM_00015] Execution Management shall [SWS_EM_02300] [SWS_EM_02301]
support integrity and authenticity [SWS_EM_02302] [SWS_EM_02303]
monitoring. [SWS_EM_02305] [SWS_EM_02306]
[SWS_EM_02400] [SWS_EM_02556]
[RS_EM_00050] Execution Management shall [SWS_EM_01320] [SWS_EM_01321]
perform Machine-wide coordination [SWS_EM_01322] [SWS_EM_01325]
of processes. [SWS_EM_01326] [SWS_EM_01327]
[SWS_EM_01328]
[RS_EM_00051] Execution Management shall [SWS_EM_01304] [SWS_EM_01313]
provide APIs to the process for [SWS_EM_01320] [SWS_EM_01325]
configuring external trigger conditions [SWS_EM_01326]
for its activities.
5

26 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Requirement Description Satisfied by
[RS_EM_00052] Execution Management shall [SWS_EM_01301] [SWS_EM_01302]
provide APIs to the process for [SWS_EM_01303] [SWS_EM_01304]
configuring cyclic triggering of its [SWS_EM_01351] [SWS_EM_01352]
activities. [SWS_EM_01353] [SWS_EM_02201]
[SWS_EM_02203] [SWS_EM_02210]
[SWS_EM_02211] [SWS_EM_02215]
[SWS_EM_02217] [SWS_EM_02510]
[SWS_EM_02511] [SWS_EM_02512]
[SWS_EM_02513] [SWS_EM_02514]
[SWS_EM_02515] [SWS_EM_02520]
[SWS_EM_02530] [SWS_EM_02531]
[SWS_EM_02532] [SWS_EM_02533]
[SWS_EM_02534] [SWS_EM_02535]
[SWS_EM_02540] [SWS_EM_02550]
[RS_EM_00053] Execution Management shall [SWS_EM_01305] [SWS_EM_01306]
provide APIs to the process to [SWS_EM_01310] [SWS_EM_01311]
support deterministic redundant [SWS_EM_01312] [SWS_EM_01313]
execution of processes. [SWS_EM_01320] [SWS_EM_01321]
[SWS_EM_01322] [SWS_EM_01323]
[SWS_EM_01324] [SWS_EM_01325]
[SWS_EM_01326] [SWS_EM_01327]
[SWS_EM_01328] [SWS_EM_02203]
[SWS_EM_02211] [SWS_EM_02215]
[SWS_EM_02221] [SWS_EM_02225]
[SWS_EM_02226] [SWS_EM_02231]
[SWS_EM_02236] [SWS_EM_02551]
[RS_EM_00100] Execution Management shall [SWS_EM_01000] [SWS_EM_01001]
support the ordered startup and [SWS_EM_01050] [SWS_EM_01051]
shutdown of processes. [SWS_EM_CONSTR_00001]
[SWS_EM_CONSTR_01744]
[RS_EM_00101] Execution Management shall [SWS_EM_01013] [SWS_EM_01023]
support State Management [SWS_EM_01032] [SWS_EM_01033]
functionality. [SWS_EM_01060] [SWS_EM_01065]
[SWS_EM_01066] [SWS_EM_01067]
[SWS_EM_01107] [SWS_EM_01110]
[SWS_EM_02241] [SWS_EM_02245]
[SWS_EM_02250] [SWS_EM_02251]
[SWS_EM_02253] [SWS_EM_02254]
[SWS_EM_02255] [SWS_EM_02258]
[SWS_EM_02259] [SWS_EM_02260]
[SWS_EM_02263] [SWS_EM_02266]
[SWS_EM_02267] [SWS_EM_02268]
[SWS_EM_02269] [SWS_EM_02272]
[SWS_EM_02273] [SWS_EM_02274]
[SWS_EM_02275] [SWS_EM_02276]
[SWS_EM_02277] [SWS_EM_02278]
[SWS_EM_02279] [SWS_EM_02280]
[SWS_EM_02295] [SWS_EM_02296]
[SWS_EM_02297] [SWS_EM_02298]
[SWS_EM_02310] [SWS_EM_02312]
[SWS_EM_02313] [SWS_EM_02314]
[SWS_EM_02315] [SWS_EM_02316]
[SWS_EM_02321] [SWS_EM_02322]
[SWS_EM_02323] [SWS_EM_02324]
[SWS_EM_02325] [SWS_EM_02326]
[SWS_EM_02327] [SWS_EM_02328]
[SWS_EM_02329] [SWS_EM_02330]
[SWS_EM_02331] [SWS_EM_02332]
[SWS_EM_02541] [SWS_EM_02542]
[SWS_EM_02543] [SWS_EM_02544]
[SWS_EM_02545] [SWS_EM_02546]
5

27 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Requirement Description Satisfied by
4
[SWS_EM_02549] [SWS_EM_02552]
[SWS_EM_02555] [SWS_EM_02561]
[SWS_EM_CONSTR_02556]
[SWS_EM_CONSTR_02557]
[SWS_EM_CONSTR_02558]
[SWS_EM_CONSTR_02559]
[RS_EM_00103] Execution Management shall [SWS_EM_01002] [SWS_EM_01003]
support process lifecycle [SWS_EM_01004] [SWS_EM_01006]
management. [SWS_EM_01055] [SWS_EM_01210]
[SWS_EM_01211] [SWS_EM_01212]
[SWS_EM_01309] [SWS_EM_01314]
[SWS_EM_01401] [SWS_EM_01402]
[SWS_EM_01403] [SWS_EM_01404]
[SWS_EM_02000] [SWS_EM_02001]
[SWS_EM_02002] [SWS_EM_02003]
[SWS_EM_02243] [SWS_EM_02558]
[SWS_EM_02560] [SWS_EM_02562]
[SWS_EM_02563] [SWS_EM_02564]
[SWS_EM_02565] [SWS_EM_02566]
[SWS_EM_02567] [SWS_EM_02568]
[SWS_EM_02577] [SWS_EM_02578]
[SWS_EM_02579] [SWS_EM_02580]
[SWS_EM_02581]
[RS_EM_00111] Execution Management shall [SWS_EM_02400]
assist identification of processes
during Machine runtime.
[RS_EM_00113] Execution Management shall [SWS_EM_01301] [SWS_EM_01310]
support time-triggered execution. [SWS_EM_01312] [SWS_EM_01313]
[RS_EM_00150] Error Handling. [SWS_EM_02032] [SWS_EM_02033]
[SWS_EM_02034] [SWS_EM_02547]
[SWS_EM_02548]
[RS_EM_00152] Execution Management shall [SWS_EM_02569] [SWS_EM_02570]
support standardized trace points [SWS_EM_02571] [SWS_EM_02572]
throughout the state transitions. [SWS_EM_02573] [SWS_EM_02574]
[SWS_EM_02575] [SWS_EM_02576]

Table 6.1: RequirementsTracing

6.1 Not applicable requirements

[SWS_EM_NA]{DRAFT} dThese requirements are not applicable as they are not within
the scope of this release.c(RS_AP_00111, RS_AP_00115, RS_AP_00125, RS_AP_-
00133, RS_AP_00135, RS_AP_00136, RS_AP_00137, RS_AP_00141, RS_AP_-
00142, RS_EM_00151, RS_AP_00156, RS_EM_NA)

28 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7 Functional specification
Execution Management is a functional cluster contained in the Adaptive Plat-
form Foundation. Execution Management is responsible for all aspects of sys-
tem execution management including platform initialization and startup / shutdown of
Applications.
Execution Management works in conjunction with the Operating System. In partic-
ular, Execution Management is responsible for configuring the Operating System to
perform run-time scheduling and resource monitoring of Applications.
This chapter describes the functional behavior of Execution Management.
• Section 7.2 presents an introduction to key terms within Execution Manage-
ment focusing on the relationship between Application, Executable, and
Modelled Process. With the latter, we refer to an instance of the meta-model
describing a process, it will eventually be realized by an operating system pro-
cess.
• Section 7.3 covers the core Execution Management run-time responsibilities
including the start of Applications.
• Section 7.4 describes the lifecycle of Applications including Modelled Pro-
cess state transitions and startup / shutdown sequences.
• Section 7.5 covers several topics related to State Management within Execu-
tion Management including Function Group state management and state
transition behavior.
• Section 7.6 documents support provided by Execution Management Deter-
ministic execution such that given the same input and internal state, a calculation
will always produce the same output.
• Section 7.7 describes how Execution Management supports resource man-
agement including the limitation of usage of CPU and memory by an Applica-
tion.
• Section 7.8 provides an introduction to Fault Tolerance strategies in general. This
section will be expanded in a future release to describe how such strategies are
realized within Execution Management.
• Section 7.9 covers the topic of Trusted Platform, i.e. ensuring the integrity
and authenticity of Applications.

29 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.1 Functional Cluster Lifecyle

7.1.1 Startup

See Section 7.5.2.1.

7.1.2 Shutdown

See Section 7.5.2.2.

7.1.3 Restart

See Section 7.5.2.2.

7.2 Technical Overview

This chapter presents a short summary of the relationship between Application,
Executable, and Modelled Process.

7.2.1 Application

Applications are developed to resolve a set of coherent functional requirements.

An Application consists of executable software units, additional execution related
items (e.g. data or parameter files), and descriptive information used for integration
and execution (e.g. a formal model description based on the AUTOSAR meta model,
test cases, etc.).
Application Executables can be located on user-level above the middleware or
can implement functional clusters of the AUTOSAR Adaptive Platform (located on
the level of the middleware), see [constr_1605] in [3].
In general, an Application, whether user-level or platform-level, is treated the same
by Execution Management and can use all mechanisms and APIs provided by the
Operating System and other functional clusters of the AUTOSAR Adaptive Plat-
form. However in doing so it potentially restricts its portability to other implementations
of the AUTOSAR Adaptive Platform.

7.2.2 Adaptive Application

An Adaptive Application is a specific type of Application. The implementa-

tion of an Adaptive Application fully complies with the AUTOSAR specification,

30 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

i.e. it is restricted to the use of APIs standardized by AUTOSAR and needs to follow
specific coding guidelines to allow reallocation between different implementations of
the AUTOSAR Adaptive Platform.
Adaptive Applications are always located above the middleware. To allow porta-
bility and reuse, user-level Applications should be Adaptive Applications
whenever technically possible.
Figure 7.1 shows the different types of Applications.
Information Classification: Internal

non portable, e.g. portable

hardware-dependent Adaptive
user Application Application
Adaptive
user-level Application

platform/
machine

reusable
typical platform
functional cluster OS/hardware
fully AUTOSAR Application
Application specific
compliant
implementation

Figure 7.1: Types of Applications

An Adaptive Application is the result of functional development and is the unit of

delivery for Machine specific configuration and integration. Some contracts (e.g. con-
cerning used libraries) and Service Interfaces to interact with other Adaptive
Applications need to be agreed on beforehand. For details see [7].

7.2.3 Executable

An Executable is a software unit which is part of an Application. It has exactly

one entry point (main function) [SWS_OSI_01001]. An Application can be imple-
mented in one or more Executables [TPS_MANI_01010].
The lifecycle of Executables usually consists of:
process Step Software Meta Information
Linked, configured and calibrated bi-
Execution Manifest, see 7.2.5
nary for deployment onto the target
Development and [3], and Service Instance
Machine. The binary might contain
and Integration Manifest (not used by Execution
code which was generated at integra-
Management).
tion time.

31 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Binary installed on the target Ma- Processed Manifests, stored in a

Deployment
chine. Previous version (if any) re- platform-specific format which is effi-
and Removal
moved. ciently readable at Machine startup.
The Execution Management uses
process started as instance of the contents of the processed Manifests
Execution
binary. to start up and configure each pro-
cess individually.

Table 7.1: Executable Lifecycle

Executables which belong to the same Adaptive Application might need to be

deployed to different Machines, e.g. to one high performance Machine and one high
safety Machine.
Figure 7.2 shows the lifecycle of an Executable from deployment to execution.

design, development, integration

Service
executable Execution
Machine Instance
(binary) Manifest
Manifest Manifest
Software Package

offboard
machine
process
application process installed
(loaded executable instance) executable Update and
Configuration
Management
API
API API API
API deployment,
Execution processed
application authentication,
other
Management manifests
manifest installation
functional
function
functional OS
clusters
cluster startup, configure OS, data base
cluster
shutdown, …

Figure 7.2: Executable Lifecycle from deployment to execution

7.2.4 Modelled Process

A Modelled Process is an instance of an Executable. On the AUTOSAR Adap-

tive Platform, a Modelled Process is realized at run-time as an OS process.
For details on how Execution Management starts and stops processes see 7.4.
Execution Management treats all Executables and the derived Modelled Pro-
cesses the same way, independent of Application boundaries.

32 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Remark: In this release of this document it is mostly assumed that processes are
self-contained, i.e. that they take care of controlling thread creation and scheduling
by calling APIs of the Operating System Interface from within the code. Execution
Management only starts and terminates the processes and while the processes
are running, Execution Management only interacts with the processes by pro-
viding State Management mechanisms (see 7.5) or APIs to support Deterministic
Execution (see 7.6.3).

7.2.5 Execution Manifest

An Execution Manifest is created together with a Service Instance Mani-

fest (not used by Execution Management) at design time and deployed onto a Ma-
chine together with the Executable it is attached to.
The Execution Manifest specifies the deployment related information of an Ex-
ecutable and describes in a standardized way the machine specific configuration
of Modelled Process properties (startup parameters, resource group assignment,
scheduling priorities etc.).
The Execution Manifest is bundled with the actual executable code in order to
support the deployment of the executable code onto the Machine.
Each instance of an Executable binary, i.e. each started process, is individually
configurable, with the option to use a different configuration set per Machine State
or per Function Group State (see Section 7.5 and [TPS_MANI_01012], [TPS_-
MANI_01013], [TPS_MANI_01017] and [TPS_MANI_01041]).
To perform its necessary actions, Execution Management imposes a number of
requirements on the content of the Machine Manifest and Execution Manifest.
The validation of the configuration is expected to be done by the vendor tooling.
For more information regarding the Execution Manifest specification please see
[3].

7.2.6 Machine Manifest

The Machine Manifest is also created at integration time for a specific Machine
and is deployed like Execution Manifests whenever its contents change. The
Machine Manifest holds all configuration information which cannot be assigned to
a specific Executable or its instances (the Modelled Processes), i.e. which is
not already covered by an Execution Manifest or a Service Instance Mani-
fest.
The contents of a Machine Manifest includes the configuration of Machine prop-
erties and features (resources, safety, security, etc.). For details see [3].

33 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.2.7 Manifest Format

The Execution Manifests and the Machine Manifest can be transformed from
the original standardized ARXML into a platform-specific format (called Processed
Manifest), which is efficiently readable at Machine startup. The format transforma-
tion can be done either off board at integration time or at deployment time, or on the
Machine (by Update and Configuration Management) at installation time.

34 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.3 Execution Management Responsibilities

Execution Management is responsible for all aspects of process execution man-
agement. A process is a loaded instance of an Executable, which is part of an
Application.
Execution Management is started as part of the AUTOSAR Adaptive Platform
startup phase and is responsible for starting and terminating processes.
Execution Management determines when, and possibly in which order, to start or
stop processes, i.e. instances of the deployed Executables, based on information
in the Machine Manifest and Execution Manifests.
Execution Management ensures that the integrity and authenticity of all Executa-
bles and Executable-related data (e.g. manifests) is checked. In the case of a
failed integrity or authenticity check, Execution Management carries out the mea-
sures defined in Section 7.9.
[SWS_EM_01030]{OBSOLETE} Restriction of process creation right for pro-
cesses dExecution Management shall restrict the rights of processes such that
they cannot start other processes.c(RS_EM_00009)
[SWS_EM_02558]{DRAFT} Default value for permissionToCreateChildProcess at-
tribute dA Modelled Process without a specified permissionToCreateChild-
Process attribute shall be considered by Execution Management as though the
attribute was set to false.c(RS_EM_00103)
[SWS_EM_02559]{DRAFT} Restriction of process creation right for processes dIf
permissionToCreateChildProcess attribute is false then Execution Manage-
ment shall restrict the rights of the created process such that it cannot start / create
other processes.c(RS_EM_00009)
The mechanism by which the restriction of [SWS_EM_02559] is implementation-
specific, but could be realized by configuring the process capability attribute mask at
the time of process creation (OS feature).
Please note that when setting permissionToCreateChildProcess to true, the in-
tegrator should consider several aspects:
• the safety and security implications of this configuration. Does this software come
from a trusted source? Is this configuration absolutely necessary for the software
to fulfill its task? etc.
• the process that creates child processes is responsible for termination of pro-
cesses that it creates; processes not started by Execution Management
are not controlled by Execution Management and exist outside of AUTOSAR
Adaptive Platform.
• the system resources used by the child processes are generally unplanned. It is
recommended to assign the parent to a dedicated ResourceGroup to limit the
impact on memory and CPU usage.

35 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Depending on the Machine State or on any other Function Group State, de-
ployed Executables are started during AUTOSAR Adaptive Platform startup or
later, however it is not expected that all will begin active work immediately since many
processes will provide services to other processes and therefore wait and “listen”
for incoming service requests.
Execution Management derives an ordering for startup/shutdown of deployed Exe-
cutables within the context of Machine and/or Function Group State changes based
on declared Execution Dependencies [SWS_EM_01050]. The dependencies are
described in the Execution Manifests, see [TPS_MANI_01041].
Execution Management is not responsible for run-time scheduling of processes
since this is the responsibility of the Operating System [SWS_OSI_01003]. How-
ever, Execution Management is responsible for initialization / configuration of the
OS to enable it to perform the necessary run-time scheduling and resource manage-
ment based on information extracted by Execution Management from the Machine
Manifest and Execution Manifests.
Execution Management does not perform standardized termination handling - the
response to receipt of a signal, e.g. SIGTERM, by Execution Management is there-
fore implementation defined.

7.3.1 Error handling

All API operations can potentially raise errors.

[SWS_EM_02547] Obtain error information dAccording to Adaptive Platform Core
[4], Execution Management shall provide means to obtain information about errors
that occurred during API calls. For that reason, Execution Management can return
the following errors:
• ara::exec::ExecErrc [SWS_EM_02281]
• ara::exec::ExecException [SWS_EM_02282]
• ara::exec::ExecException::ExecException [SWS_EM_02283]
• ara::exec::ExecErrorDomain [SWS_EM_02284]
• ara::exec::ExecErrorDomain::ExecErrorDomain [SWS_EM_02286]
• ara::exec::ExecErrorDomain::Name [SWS_EM_02287]
• ara::exec::ExecErrorDomain::Message [SWS_EM_02288]
• ara::exec::GetExecErrorDomain [SWS_EM_02290]
c(RS_EM_00150)

36 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02548] Create error information dAccording to Adaptive Platform Core

[4], Execution Management shall provide means to create error information as listed
below.
• ara::exec::ExecErrorDomain::ThrowAsException [SWS_EM_02289]
• ara::exec::MakeErrorCode [SWS_EM_02291]
c(RS_EM_00150)

37 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.4 Process Lifecycle Management

7.4.1 Execution State

Execution States characterizes the internal lifecycle of a process. In other words, they
describe it from the point of view of a process that is executed. The states visible to
the process are defined by the ara::exec::ExecutionState enumeration, see
[SWS_EM_02000].

Initializing Terminating
create process Running
application store data,
allocate perform main Terminate
data free resources,
resources functionality
initialization exit

Figure 7.3: Execution States

The Execution State of a process is used by Execution Management to construct

and maintain the Process State as described in Section 7.4.2. Execution State
change notifications from a process result in Process State changes managed
by Execution Management. The Execution State and Process State are main-
tained separately so that there is no explicit dependency between a process’s Ex-
ecution State and Execution Management’s Process State. This allows future
evolution of Process State without impacting the internal Execution State of the
process.

7.4.1.1 Initialization

[SWS_EM_01401] ExecutionClient usage restriction dThe AUTOSAR Adaptive

Platform implementation shall only allow a process to report its own Execution-
State.c(RS_EM_00103)
Execution Management considers process initialization complete when the Pro-
cess State Running is reached whether this is achieved implicitly (by a Non-re-
porting Process) or explicitly through a process reporting its Execution State.
A process is required (see [SWS_EM_01004]) to report kRunning state using the
ara::exec::ExecutionClient::ReportExecutionState [SWS_EM_02003]
method of class ara::exec::ExecutionClient, see [SWS_EM_02001]. It would
typically report after the completion of its initialization, but before Service Discov-
ery is completed. If the process were to report kRunning only after Service Dis-
covery completion, the non-deterministic delays may impact other processes, due
to delays in resolution of Execution Dependencies.

38 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.4.1.2 Termination

[SWS_EM_01055] Initiation of process termination dExecution Management

shall initiate process termination by sending the SIGTERM signal to the process.c
(RS_EM_00103)
Note that from the perspective of Execution Management, requirement
[SWS_EM_01055] only requests the initiation of the steps necessary for grace-
ful termination under the control of the process.
It is possible that a process that should be terminated according to [SWS_EM_01055],
e.g. during the handling of Execution Dependencies, is no longer alive. However,
as Execution Management can determine the status of child processes it would
thus not attempt to terminate a process that no longer exists.
Execution Management may send SIGTERM at any time, even before the process
has reported kRunning state and thus the process is still in the Initializing
Process State.
On receipt of SIGTERM, a process commences the actual termination.
Execution Management provides a termination handler to minimize the required
signal handling in the Adaptive Application (see [SWS_EM_02577]).
[SWS_EM_02577]{DRAFT} Call of Termination Handler dOn receipt of SIGTERM
ara::exec::ExecutionClient shall invoke the termination handler defined by
ara::exec::ExecutionClient::Create.c(RS_EM_00103)
Please note the API defines the execution context of the termination handler to be a
background thread which is maintained by the ara::exec::ExecutionClient. It
is not executed in a signal handler context, therefore usage of POSIX and ara APIs is
not restricted (potential restrictions in the contract of ara APIs still apply).
During the Terminating state, the process is expected to save persistent data and
free all internally used resources. The process indicates completion of the Termi-
nating state by termination with exit status 0 (EXIT_SUCCESS).
Execution Management as the parent process can detect termination of the child
process and take the appropriate platform-specific actions such as processing exe-
cution dependencies that rely on the Terminated state and thus ensure that there is
no overlap between these processes when both are running.
[SWS_EM_01314] Default value for terminationBehavior dExecution Man-
agement shall treat a Modelled Process without specified terminationBehav-
ior as a process that terminates only on request by Execution Management.c
(RS_EM_00103)

39 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.4.1.3 Unexpected Termination

[SWS_EM_01309] Unexpected Termination of a process dIn case of Unex-

pected Termination outside a state transition resulting from previous request from
ara::exec::StateClient::SetState, Execution Management shall perform
the following actions:
1. log event, if logging is activated
2. Set the Function Group State (of the Function Group to which the rel-
evant Modelled Process was mapped) to Undefined Function Group
State.
3. Call undefinedStateCallback defined by ara::exec::StateClient with
ara::exec::ExecutionErrorEvent.
c(RS_EM_00103)
If the State Management decides to invoke the ara::exec::StateClient::
GetExecutionError interface, after receiving the undefinedStateCallback
[SWS_EM_01309] or inside the callback, the ara::exec::ExecutionErrorEvent
will contain the same information as provided by the undefinedStateCallback. This is
guaranteed by [SWS_EM_02542]. Please note that [SWS_EM_01309] also applies
for Unexpected Self-termination.
Correct Execution State reporting performed by processes is a part of consistent
behavior of Execution Management.

7.4.1.4 Application Reporting

[SWS_EM_02243] Handling Execution State Running dExecution Management

shall return kInvalidTransition when a process reports Execution State kRun-
ning (using the method ara::exec::ExecutionClient::ReportExecution-
State) and the process is not in Process State Starting.c(RS_EM_00103)
To prevent denial-of-service attacks on Execution Management an implementation
could rate-limit acceptance of Execution State reports or could request the Operating
System to terminate the underlying process. However such reactions are not standard-
ized.
Execution Management differentiates between two types of processes: Report-
ing Processes and Non-reporting Processes. Reporting Processes are
considered to be the normal form of processes and Non-reporting Processes
are considered to be an exception.
Non-reporting Processes can be used to support running Executables which
have not been designed with the AUTOSAR Adaptive Platform in mind. For exam-
ple, if an Executable is available as binary only, if it is not feasible to patch its source
code or if the Executable is only used during development time.

40 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The implicit transition to Running Process State is described by [SWS_EM_01402]

In safety related systems the system designer has to use Non-reporting Process
functionality with care. Such processes will probably not provide safety critical func-
tionality and will not be monitored by Platform Health Management but still they
might influence other safety related processes and therefore can introduce a safety
risk. To isolate Non-reporting Processes from safety critical parts Resource-
Group can be used (see Section 7.7).
An attempt to report Execution State by a Non-reporting Process is considered
an error by Execution Management.
[SWS_EM_01403] Reporting Non-reporting Process dara::exec::Execution-
Client::ReportExecutionState shall treat it as a Violation when invoked by a
Non-reporting Process.c(RS_EM_00103)

7.4.2 Process States

Process States characterize the lifecycle of a process from the point of view of
Execution Management. In other words, Process States represent the Exe-
cution Management internal tracking of the Execution States (see Section 7.4.1)
and hence there is no need for a standardized type. Note that each process is in-
dependent and therefore has its own Process State. Process State is used by
Execution Management to resolve Execution Dependencies, manage timeouts, etc.
Additionally to the existing values for the Process State (Idle, Starting, Run-
ning, Terminating, Terminated), the implementation may define its own Process
States, which are not in conflict/not replacing the existing ones.

Starting
Terminated
process
Idle Execute Schedule Running Terminate Terminating process
created,
resources
resources
freed
allocated

Figure 7.4: process Lifecycle

[SWS_EM_01002] Idle Process State dThe Idle Process State shall be the
Process State prior to creation of the process and to resource allocation.c(RS_-
EM_00103)
[SWS_EM_01003] Starting Process State dThe Starting Process State shall
apply when the process has been created and resources have been allocated.c(RS_-
EM_00103)
[SWS_EM_01004] Running Process State of Reporting Processes dThe Running
Process State shall apply to a Reporting Process after it has reported kRun-
ning Execution State to Execution Management.c(RS_EM_00103)

41 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01402] Implicit Running Process State dFor Non-reporting Process

the transition from Starting to Running Process State shall implicitly apply after
Execution Management has allocated the required resources and created the run-
time process.c(RS_EM_00103)
[SWS_EM_01404] Terminating Process State after Termination Request dThe
Terminating Process State shall apply when Execution Management sent
SIGTERM signal to the process.c(RS_EM_00103, RS_EM_00011)
[SWS_EM_01006] Terminated Process State dThe Terminated Process State
shall apply after the process has terminated and the process resources have been
freed.c(RS_EM_00103, RS_EM_00011)
For [SWS_EM_01006], Execution Management observes the exit status of all pro-
cesses. The mechanism is implementation dependent but could, for example, use the
POSIX waitpid() API.
From the resource allocation point of view, the Terminated Process State is sim-
ilar to the Idle Process State – there is no process running and no resources
are allocated. However from the execution point of view, the Terminated Process
State is different from Idle as it tells Execution Management that the process
has already been executed, terminated and can be now restarted (if needed) as spec-
ified in [SWS_EM_01066]. The distinction between Process State Idle and Ter-
minated is relevant for resolving Execution Dependencies to Self-terminat-
ing Processes (see Section 7.4.4.1).

7.4.2.1 Synchronization with Platform Health Management

Platform Health Management requires Process State information for starting

and stopping of Supervisions. For details see [8].
Platform Health Management needs the information that a Supervised process
reported Execution State kRunning ([SWS_EM_01004]) to start Alive Supervision.
[SWS_EM_01210] Report “kRunning received event” to Platform Health Manage-
ment dExecution Management shall inform Platform Health Management if a
Supervised process has reported Execution State kRunning.c(RS_EM_00103)
Platform Health Management needs the information that termination of a Super-
vised process will be initiated ([SWS_EM_01055]) to stop Intra-process Supervisions.
[SWS_EM_01211] Report “initiating process termination” event to Platform
Health Management dExecution Management shall inform Platform Health
Management when a Supervised process termination is about to be initiated.c(RS_-
EM_00103)
Platform Health Management needs the information that a Supervised process
is terminated ([SWS_EM_01006]) to supervise Self-terminating Processes.

42 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01212] Report “process terminated” event to Platform Health Man-

agement dExecution Management shall inform Platform Health Management
when a Supervised process is terminated.c(RS_EM_00103)
Hint: Which processes are Supervised by Platform Health Management can
be determined by referring to the configuration of Platform Health Management.
The above notifications are provided through Inter-Functional Cluster Interface(s) be-
tween Execution Management and Platform Health Management. As such
interfaces are vendor-specific, their definition (signature) is not standardized.
If Execution Management is used in Safety Critical Platform, then it is suggested to
use Alive/Logical/Deadline supervision(s) and report their checkpoints appropriately to
Platform Health Management.

7.4.3 Trace Process State Transitions

The timing behavior of processes is a mandatory part of the lifecycle of an Appli-

cation. Wrong timing and timing shortages in processes can lead to unexpected
behavior or failures. Therefore it is important to provide a way to trace process lifetime
events within the Execution Management. The following trace points are introduced
to be able to do a timing analysis of an Application based on its processes.
[SWS_EM_02573]{DRAFT} State Transition logging – process created dWhenever
Execution Management has created a process (see [SWS_EM_01003]), Execu-
tion Management shall log a DltMessage of type ProcessCreated.c(RS_EM_-
00152)
[SWS_EM_02574]{DRAFT} State Transition logging – process kRunning re-
ceived dWhenever Execution Management has received a kRunning (see
[SWS_EM_02003]), Execution Management shall log a DltMessage of type Pro-
cessKRunningReceived.c(RS_EM_00152)
[SWS_EM_02575]{DRAFT} State Transition logging – process termination re-
quest dWhenever Execution Management is requesting a process to be terminated
(see [SWS_EM_01055]), Execution Management shall log a DltMessage of type
ProcessTerminationRequest.c(RS_EM_00152)
[SWS_EM_02576]{DRAFT} State Transition logging – process terminated
dWhenever a process terminates (independent of a success return result), Execution
Management shall log a DltMessage of type ProcessTerminated.c(RS_EM_00152)

43 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.4.4 Startup and Termination

7.4.4.1 Execution Dependency

Execution Management can derive an ordering for the startup and termination of
processes within State Management framework based on the declared Execu-
tion Dependencies. This ensures that Applications are started before depen-
dent Applications use the services that they provide and, likewise, that Applica-
tions are shutdown only when their provided services are no longer required.
The Execution Dependencies, see [TPS_MANI_01041] and [constr_1606], are
configured in the Execution Manifests, which is created at integration time based
on information provided by the Application developer. An Execution Depen-
dency defines the provider of functionality required by a process necessary for that
process to provide its own functionality. Execution Management ensures the de-
pendent processes are in the state defined by the Execution Dependency before
the process defining the dependency is started.
User-level Applications are expected to use the service discovery mechanisms of
Communication Management as the primary mechanism for execution sequencing
as this is supported both within a Machine and across Machine boundaries. Thus
user-level applications should not rely on Execution Dependencies unless strictly
necessary. Which processes are running depends on the current Function Group
States, including the Machine State, see Section 7.5. The integrator should en-
sure that all service dependencies are mapped to the State Management configuration,
i.e. that all dependent processes are running when needed.
In real life, specifying a simple dependency to a process might not be sufficient to
ensure that the depending service is actually provided. Since some processes shall
reach a certain Execution State (see Section 7.4.1) to be able to offer their services to
other processes, the dependency information shall also refer to Process State of
the process specified as dependency. With that in mind, the dependency information
may be represented as a pair like: <process>.<processState>. For more details
regarding the Process States refer to Section 7.4.2.
The following dependency use-cases have been identified:
Dependency on Running Process State In case process B has a simple depen-
dency on process A, the Running Process State of process A is specified
in the dependency section of process B’s Execution Manifest.
When process B has a Running Execution Dependency to process A,
then process B will only be started once the process A achieves Running
Process State.
Dependency on Terminated Process State In case process D depends on
Self-terminating Process C, the Terminated Process State of pro-
cess C is specified in the dependency section of process D’s Execution
Manifest.

44 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

If process D has Terminated Execution Dependency on process C, then

process D will only be started once process C reaches the Terminated state.
A Terminated Execution Dependency specified on a non self-terminating
process is considered to be a configuration error as this would indi-
cate a dependency that can only be fulfilled at the next group transition
[SWS_EM_CONSTR_00001]
Note: No use-case has been identified for an Execution Dependency on other
Process States, i.e. Idle or Terminating, and therefore these are not supported
for Execution Dependency configuration. See also [SWS_EM_CONSTR_01744].
[SWS_EM_CONSTR_01744]{DRAFT} Definition of process state in the context of
the ExecutionDependency dThe target ModeDeclaration referenced in the role
ExecutionDependency.processState shall fulfill the following conditions:
• It shall be owned by a ModeDeclarationGroup that is referenced by a Mod-
eDeclarationGroupPrototype (in the role type) that in turn shall be aggre-
gated by a Process.
• The shortNames of the encapsulated ModeDeclarations shall only be one of
the following values:
– Running
– Terminated
c(RS_EM_00100)
[SWS_EM_CONSTR_00001]{DRAFT} Modeling execution dependency for the
Terminated state dA Terminated ModeDeclaration referenced in the Pro-
cess.stateDependentStartupConfig.executionDependency shall only be al-
lowed if the process referenced in the stateDependentStartupConfig.execu-
tionDependency has StartupConfig.terminationBehavior set to proces-
sIsSelfTerminating.c(RS_EM_00100)

Example 7.1

Consider a process, DataLogger, which has an Execution Dependency on an-

other process, Storage. For startup this means DataLogger has a Execution De-
pendency on Storage so the latter is required to be started by Execution Manage-
ment before DataLogger so that DataLogger can store its data.

processes are only started by Execution Management if they reference a re-

quested Machine State or Function Group State, but not because of config-
ured Execution Dependencies. Execution Dependencies are only used to
control a startup or terminate sequence at state transitions. Note that the scope of Ex-
ecution Dependency resolution is limited to one Function Group State only
(see [constr_1689] and [SWS_EM_02245]).

45 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01050] Start Dependent processes dDuring startup of a process, Ex-

ecution Management shall respect Execution Dependencies by ensuring that
each process upon which the process to be started depends have reached its re-
quested Process State (at some previous point in time) during the current state
transition before starting the process.c(RS_EM_00100)
The same Execution Dependencies used to define the startup order are also used
to define the termination order. However the situation is reversed as Execution Man-
agement is required to ensure that dependent processes are terminated after the
process to ensure that the services required remain available until no longer required.
[SWS_EM_01051] Termination of processes dDuring termination of a process, Ex-
ecution Management shall respect Execution Dependencies by ensuring that
each process upon which the process to be terminated depends is not terminated
before termination of the process.c(RS_EM_00100)

Example 7.2

Consider the same process, DataLogger, as above which has an Execution De-
pendency on another process, Storage. For termination the Execution Depen-
dency indicates Execution Management is required to only terminate Storage after
DataLogger so the latter can flush its data during termination.

Note that [SWS_EM_01051] merely requires Execution Management to not termi-

nate the dependent processes before terminating a process. It is not an error if the
process has self-terminated so is not available to be terminated.
If no Execution Dependencies are specified between two processes then no
order is imposed and they can be started or terminated in an arbitrary order.

Example 7.3

Consider three processes:

• Storage, a service process without any dependencies;
• StorageConsistencyChecker, a self-terminating process, it requires Storage to
be in Process State Running;
• Conf igReader, a service process, it requires that the
StorageConsistencyChecker has reached Process State Terminated;
For startup this means Execution Management should start Storage and
wait till it reports kRunning, then Execution Management should start
StorageConsistencyChecker and wait till it terminates and only then start
Conf igReader. For termination the Execution Dependency indicates that Exe-
cution Management can terminate Storage and Conf igReader simultaneously be-
cause StorageConsistencyChecker is already terminated and Conf igReader does not
have a direct dependency on Storage. If Conf igReader has to be terminated before

46 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Storage, then this can be achieved by adding a direct Execution Dependency be-
tween Conf igReader and Storage.

The required dependency information is provided by the Application developer. It

is adapted to the specific Machine environment at integration time and made available
in the Execution Manifest.
Execution Management parses the information and uses it to build the startup se-
quence to ensure that the required antecedent processes have reached a certain
Process State before starting a dependent process [SWS_EM_01050].
[SWS_EM_01001] Execution Dependency error dIf Execution Management
needs to start process A that depends on another process B and process B is
not part of the same Function Group State as process A, then Execution Man-
agement shall consider this as an Error and fail to start process A.c(RS_EM_00100)

Example 7.4

Let assume that process “A” depends on the Running Process State of a pro-
cess “B”. At a Machine State transition, process “A” shall be started, because it
references the new Machine State. However, process “B” does not reference that
Machine State, so it is not started. Due to the Execution Dependency between
the two processes, process “A” would never start running in the new Machine
State because it waits forever for process “B”. This is considered to be a configura-
tion error and shall also cause run time error.

Please note that requirement [SWS_EM_01001] effectively forbids any Execution

Dependencies that spans outside of a single Function Group State (or a Ma-
chine State) definition, see also [constr_1689]. This is done on purpose, as
this kind of dependencies will introduce hidden dependencies between Function
Groups and they will not be visible to State Management. If dependencies be-
tween Function Groups need to be expressed (e.g. mapping software could have
dependency on GPS software), then this should be done inside State Management.
For more information see [9].
Unlike a Reporting Process, a Non-reporting Process is in Process State
Running directly after start. Regardless of whether the process has completed its
initialization phase and is ready to offer its services or not. This means that Running
Execution Dependencies are immediately satisfied and thus do not achieve the
original semantics when specified for a Non-reporting Processes without further
action.
This limitation can be overcome by introducing a Companion Process, which acts
as a representative of the Non-reporting Process. The Companion Process
waits for availability of the service provided by the Non-reporting Process and
reports kRunning to Execution Management. The processes which in fact need
the services of the Non-reporting Process can be configured to be dependent on

47 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

the Companion Process. Please note that the Terminated Execution Depen-
dency is not affected as Execution Management is informed by the Operating
System when Non-reporting Processes are Terminated. Please see Figure
7.5 for more details.

Process reference
state transition A B

Function Group 1
FG1:Off FG1:Running
State

C D
Terminated
A Running
Idle

Terminated
B Running
Idle

Terminated
C Running
Idle

dependency

Terminated
D Running
Idle

Process State

Figure 7.5: Execution dependencies on Non-reporting Process

• Non-reporting Process (and Self-terminating Process) A refer-

ences FG1:Running. This process is started first (as it doesn’t have any Execu-
tion Dependencies configured) and automatically enters Running Process
State as per [SWS_EM_01402].
• Companion Process B is started after Non-reporting Process A (please
note that A and B are also standard AUTOSAR processes) enter Running
state. process B can use project specific method to assess if process A is
fully functional and signal this to Execution Management by reporting (or not)
kRunning state.

48 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• process C is started when (and only when) process B enters Running Pro-
cess State (i.e. reports kRunning). Please note this Execution Depen-
dency will work independently from reporting / non-reporting configuration of
process C.
• process D has Terminated Execution Dependency configured on Self-
-terminating Process (and Non-reporting Process) A. As mentioned
earlier this works out of the box (no special action needed here).

7.4.4.2 Signal Mask

AUTOSAR Adaptive Platform is defining a POSIX based system for Applica-

tions - this includes POSIX signals. Signal handling is not a trivial task. Therefore
interaction with POSIX signals is limited to a necessary minimum in AUTOSAR Adap-
tive Platform. The only reason for POSIX signal interaction is Execution Man-
agement’s process termination request (see [SWS_EM_01055]).
Execution Management starts processes with a well defined signal mask to avoid
the situation of threads having an undefined signal mask (e.g. threads created by ara).
[SWS_EM_02578]{DRAFT} Initial signal mask for Reporting Process dExecution
Management shall start Reporting Processes with a signal mask having all POSIX
signals blocked except of:
• SIGABRT
• SIGBUS
• SIGFPE
• SIGILL
• SIGSEGV
c(RS_EM_00103)
The set of unblocked POSIX signals provided in [SWS_EM_02578] are raised by the
OS when an error occurs where there is no reasonable way to continue program exe-
cution. According to POSIX, ignoring these signals would lead to undefined behavior.
If one of these signals occurs, the default signal handling action, in this case abnor-
mal termination, is performed. Note also that the two POSIX signals SIGSTOP and
SIGKILL cannot be caught or blocked.
Adaptive Application make use of ara::exec::ExecutionClient which im-
plements catching the SIGTERM signal (see [SWS_EM_02577]).
Non-reporting Processes won’t use the ara::exec::ExecutionClient and
will implement their own signal handling. For such Applications Execution Man-
agement prepares an empty signal mask.

49 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02579]{DRAFT} Initial signal mask for Non-Reporting process dExe-

cution Management shall start Non-reporting Processes with an empty signal
mask.c(RS_EM_00103)

7.4.4.3 Arguments

Execution Management provides argument passing for a process containing

one or more StateDependentStartupConfig in the role Process.stateDepen-
dentStartupConfig. This permits different processes to be started with different
arguments.
[SWS_EM_01012] Process Argument Passing dAt the initiation of startup of a pro-
cess, the aggregated ProcessArgument of the StartupConfig referenced by the
StateDependentStartupConfig shall be passed to the process by Execution
Management based on [SWS_EM_01072] and [SWS_EM_01078].c(RS_EM_00010)
Note that [SWS_EM_01012] deliberately does not specify the OS mechanism used to
start a process, e.g. the exec-family based POSIX interface, as this is ultimately an
implementation specific property.
The first argument passed by Execution Management is the name of the Exe-
cutable.
[SWS_EM_01072] process Argument Zero dArgument 0 shall be set to name of the
Executable.c(RS_EM_00010)
Execution Management supports passing arguments to a process in the same
way that a shell passes command line arguments to a POSIX process. Execu-
tion Management assigns each ProcessArgument.argument to an element in
the argv[] array, starting at element index 1, and passes this to the process main()
function. ProcessArgument ordering is used to preserve the semantics of an (op-
tion, argument) pair such as “-b value”, where the “-b” argument must precede
the “value” argument. This method supports the short form and long form argument
passing conventions typically used in POSIX environments.
[SWS_EM_01078] Process Argument strings dProcessArgument.argument shall
be passed to the process in order with the first ProcessArgument.argument start-
ing at Process Argument 1.c(RS_EM_00010)
The order in which the defined ProcessArgument are passed is defined by the or-
dered StartupConfig.processArgument aggregation.

7.4.4.4 Environment Variables

Execution Management initializes environment variables for processes. process

specific environment variables are configured in its Execution Manifest. Machine

50 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

specific environment variables are configured in the Machine Manifest. During run-
time environment variables are accessible via POSIX getenv() command.
[SWS_EM_02246] process specific Environment Variables dExecution Manage-
ment shall prepare environment variables based on the configuration from Process.
stateDependentStartupConfig.startupConfig.environmentVariable and
pass them during a process start.c(RS_EM_00010, RS_AP_00130)
[SWS_EM_02247] Machine specific Environment Variables dExecution Man-
agement shall prepare environment variables based on the configuration from Ma-
chine.environmentVariable and pass them during a process start.c(RS_EM_-
00010, RS_AP_00130)
Please note that AUTOSAR meta model (see [3]) uses TagWithOptionalValue for
environment variables definition ([TPS_MANI_01208] and [TPS_MANI_01209]). As
explained there, the value (TagWithOptionalValue.value) can be omitted as a
way of specifying environment variable with empty value.
[SWS_EM_02249] Missing value from Environment Variable definition dWhenever
Execution Management finds environment variable definition, that has TagWith-
OptionalValue.value missing, it should use empty string as a value for this envi-
ronment variable.c(RS_EM_00010, RS_AP_00130)
[SWS_EM_02248] Environment Variables precedence dWhenever the same envi-
ronment variable is configured within both the Execution Manifest and the Ma-
chine Manifest then Execution Management shall use the environment variable
value from the Execution Manifest.c(RS_EM_00010, RS_AP_00130)

7.4.5 Machine Startup Sequence

Execution Management is the AUTOSAR Adaptive Platform’s first process.

When ready, Execution Management initiates the Machine State transition
from the Off state (the default state before EM is started) to the Startup state
([SWS_EM_01023], [SWS_EM_02250]). During the transition, Execution Manage-
ment requests startup of processes that exist in the Startup Machine State.
After the necessary state transition conditions have been met (see Section 7.5.5
and 7.5.2.1), Execution Management reports Machine State Startup transition
confirmation to State Management ([SWS_EM_02241]). At that point, Execution
Management hands over responsibility for Function Group state management (i.e.
initiation of state change requests) to State Management.
On a Machine, which can be any group of resources, i.e. a physical environment, a
virtualized environment over a hypervisor, or an OS-level virtualization (container), Ex-
ecution Management is not necessarily the first process launched; Other processes
needed by the system may exist, such as an Operating System init process, or an
Operating System Micro-kernel user-level processes like drivers, filesystem, etc.

51 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

All of these processes might be started and managed outside of the context of the
AUTOSAR Adaptive Platform.
Please note that an Application consists of one or more Executables. There-
fore to launch an Application, Execution Management starts processes as
instances of each Executable.
[SWS_EM_01000] Startup order dThe startup order of the platform-level processes
shall be determined by Execution Management based on Machine Manifest
and Execution Manifest information.c(RS_EM_00100)
Please see Section 7.2.5.
Figure 7.6 shows the overall startup sequence.

State Change

Figure 7.6: Startup sequence

52 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.7: AUTOSAR Adaptive Platform Boundary

53 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.5 State Management

7.5.1 Overview

State Management functional cluster defines the operational state of an AUTOSAR

Adaptive Platform, while Execution Management performs the transitions be-
tween different states.
The Execution Manifest allows to define in which states the Modelled Pro-
cesses have to run (see [3]). As mentioned before, a Modelled Process is an
instance of an Executable, which is part of an Application. State Manage-
ment mechanisms grant full control over the set of Applications to be executed
and ensures that processes are only executed (and hence resources allocated) when
actually needed.
Four different states are relevant for Execution Management:
Execution State – An Execution States characterizes the internal lifecycle of each
started process, see Section 7.4.1
Process State – Process States are managed by an Execution Management
internal state machine. For details see Section 7.4.2.
Machine State – see Section 7.5.2
Function Group State – see Section 7.5.3
An example for the interaction between these states will be shown in section Section
7.5.4.

7.5.2 Machine State

[SWS_EM_CONSTR_02556]{DRAFT} Mandatory states dExecution Manage-

ment requires that at least one Function Group with the name "MachineFG" is
configured for each Machine. This Function Group has several mandatory states:
• Off,
• Verify,
• Startup,
• Shutdown, and
• Restart.
c(RS_EM_00101)
In order to clarify the required contents of the "MachineFG" function group and its
type, the ARXML model AUTOSAR_MOD_GeneralDefinition_MachineFG.arxml (avail-
able in MOD_GeneralDefinitions) provides a definition.

54 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Additional Machine States can be defined on a machine specific basis and are
therefore not standardized.
The Execution Manifest defines the relation between processes and Function
Group States. Therefore it is possible to determine the set of executed processes for
each Function Group State. A Function Group State is modeled by means
of ModeDeclaration, see [TPS_MANI_03145] and [TPS_MANI_03194].
In the API, a Function Group is represented by the class ara::exec::Func-
tionGroup, see [SWS_EM_02263] and a Function Group State by the class
ara::exec::FunctionGroupState, see [SWS_EM_02269]. Class ara::exec::
StateClient performs state management during the lifetime of a Machine, see
[SWS_EM_02275].
Machine States (as well as other Function Group States) are requested by
State Management. The set of active states is significantly influenced by vehicle-
wide events and modes. For details on state change management see Section 7.5.5.
[SWS_EM_01032] Machine States configuration dExecution Management shall
obtain the configuration of Machine States from Function Group "MachineFG"
within the SoftwareCluster with category PLATFORM_CORE.c(RS_EM_00101)
[SWS_EM_CONSTR_02557]{DRAFT} Scope of machine Function Group
dThe function-Group that represents the Machine Function Group group (see
[SWS_EM_CONSTR_02556]) shall only be referenced in the role claimedFunction-
Group by a SoftwareCluster of category PLATFORM_CORE.c(RS_EM_00101)
Please note that according to [constr_1788] there must be exactly one Soft-
wareCluster with category PLATFORM_CORE on each machine.
The start-up sequence from initial state Startup to the point where State Manage-
ment, SM, requests the initial running machine state StateXYZ is illustrated in Figure
7.8.

55 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.8: Start-up Sequence – from Startup to initial running state StateXYZ

A successful Function Group state change sequence is illustrated in Figure 7.9. Here,
on receipt of the state change request, Execution Management terminates running
processes and then starts processes active in the new state before confirming the
state change to State Management.

56 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.9: State Change Sequence - Success

Figure 7.10 shows a Function Group state change which is continued even if a termi-
nation timeout happens. Figure 7.11 shows a Function Group state change which is
aborted because of a start-up timeout.

57 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.10: State Change Sequence - Termination Timeout

58 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.11: State Change Sequence - Start-up Timeout

There are more cases which lead to failure during Function Group state change, which
are not illustrated here. For details see chapter 7.5.5 "State Transition" and chapter
8.2.7.8 "StateClient::SetState".

7.5.2.1 Startup

[SWS_EM_02250]{DRAFT} Machine State Startup dExecution Management shall

enter Unrecoverable State if Execution Management is not able to parse the
Startup state information of Function Group "MachineFG".c(RS_EM_00101)
Execution Management depends on the existence of a Startup state
[SWS_EM_CONSTR_02556]. However, at run time the state may not be available
to Execution Management for a number of reasons (e.g. misconfigured develop-
ment system, corrupted file system, memory errors etc.). While these situations may
not be common, to avoid implementation specific behavior, Execution Management
should have standardized reaction to them.
[SWS_EM_01023] Self initiation of Machine State Startup transition dExecution
Management shall self initiate the state transition to the Startup Machine State.c
(RS_EM_00101)

59 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Please note that for Machine State transitions, the requirements of section Section
7.5.5 apply.
[SWS_EM_02555]{DRAFT} Failure in Machine State Startup transition dExecu-
tion Management shall enter Unrecoverable State in the event of failed transi-
tion to the Startup Machine State.c(RS_EM_00101)
A failure in transition to Startup Machine State is considered as a serious prob-
lem. In that event Execution Management can’t be sure what level of functionality is
available and if a failed state transition can be handled by State Management. It is
worth to note that the State Management itself can be unavailable or its functionality
can be very limited at that point in time.
[SWS_EM_02241] Machine State Startup Completion dUpon completion of initial
(self initiated) Machine State transition to the Startup state, Execution Man-
agement shall make the result of that transition available to State Management
through ara::exec::StateClient::GetInitialMachineStateTransition-
Result API.c(RS_EM_00101)
Please note that the notification in [SWS_EM_02241] is not done via broadcast mes-
sage but has to be requested by State Management via the ara::exec::State-
Client::GetInitialMachineStateTransitionResult API.
The function ara::exec::StateClient::GetInitialMachineStateTransi-
tionResult retrieves the result of the Machine State’s initial transition to the Startup
state. After the Startup state is reached (as described by [SWS_EM_02241]) Execu-
tion Management does not initiate any further Function Group State changes
(this includes Machine State). Instead such changes are requested by State
Management and then performed by Execution Management.
Execution Management will be controlled by other software entities and should
not execute any Function Group State changes on its own (with one exception:
[SWS_EM_01023]). This creates some expectations towards system configuration.
The specification expects that State Management will be configured to run in ev-
ery Machine State (this includes Startup, Shutdown and Restart) [SWS_SM_-
CONSTR_00001]. Above expectation is needed in order to ensure that there is always
a software entity that can introduce changes in the current state of the Machine. If
(for example) system integrator doesn’t configure State Management to be started
in Startup Machine State, then Machine will never be able transit to any other
state and will be stuck forever in it. This also applies to any other Machine State
that doesn’t have State Management configured.
The possibility that the Machine State transition to the Startup state is never
reached shall be taken into account. In this case the State Management can
interrupt the Startup state transition and request e.g. a recovery state using
the ara::exec::StateClient::SetState interface. The ara::exec::State-
Client::GetInitialMachineStateTransitionResult would return the value
kCancelled.

60 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.5.2.2 Shutdown/Restart

Execution Management does not perform shutdown/restart of the Machine to

avoid embedding project-specific behavior within Execution Management. Instead
a project-specific actor is expected to provide a mechanism to shutdown/restart the
Machine, such as, a standalone process that is configured to be started by Execu-
tion Management during transition to the Shutdown / Restart Machine State
or a process started in Startup Machine State that waits for a signal before shut-
ting down the Machine. This approach enables the control of both WHEN and HOW
shutdown/restart occurs to be managed in a project-specific manner. See [3] [constr_-
1618] and [constr_1619].
Requirements [SWS_EM_02241] and [SWS_EM_01023] dictate a dependency by
Execution Management on the presence of the Startup Machine State and
[SWS_EM_CONSTR_02556] mandates configuration of Startup and Shutdown /
Restart Machine States. However there is no equivalent requirement on Shut-
down or Restart Machine States as their omission does not prevent Execution
Management from starting. Therefore, the response by Execution Management to
this misconfiguration is implementation-specific.
A request to Execution Management to change the current Machine State to
either Shutdown or Restart is handled the same as any other Function Group state
change request. From the point of view of Execution Management all Function
Groups are independent and therefore changes to them, can be applied without any
side effects.
However, from the point of view of State Management, where knowledge of the de-
pendencies between different Function Groups exist this may not be true. AUTOSAR
assumes that State Management will requests "MachineFG" Shutdown or Restart
when it’s valid to do so; see [9] for advice on how to orchestrate shutdown of the
Machine.
Please note it is system integrator’s responsibility to carefully consider when system
shutdown / restart should be requested because all processes which are still running
will not be terminated by Execution Management, which means that they will not be
able to persist their data.
As mentioned in Section 7.5.2.1, AUTOSAR assumes that State Management will
be configured to run in Shutdown and Restart. State transition is not a trivial system
change and it can fail for a number of reasons - in which case State Management
should remain alive to report errors and wait for further instructions. Please note that
the purpose of entering the Shutdown or Restart state is to shutdown or restart the
Machine (this includes State Management) in a clean manner.
[SWS_EM_CONSTR_02558]{DRAFT} Ability to shut down dIn the context of one
Machine, at least one Process shall have a stateDependentStartupConfig.
functionGroupState that has the shortName Shutdown.c(RS_EM_00101)

61 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_CONSTR_02559]{DRAFT} Ability to restart dIn the context of one

Machine, at least one Process shall have a stateDependentStartupConfig.
functionGroupState that has the shortName Restart.c(RS_EM_00101)
[SWS_EM_02549]{DRAFT} MachineFG.Off handling dExecution Management
shall refuse a request to change "MachineFG" Function Group State to Off
with error kInvalidTransition.c(RS_EM_00101)

7.5.3 Function Group State

If there is a group of Applications installed on the machine, it will be useful to have

ability of controlling them coherently. For that very reason the concept of Function
Groups was introduced to AUTOSAR Adaptive Platform.
Each Function Group has its own set of processes and set of states called Func-
tion Group States. Each Function Group State defines which processes
shall be started when State Management requests Function Group State acti-
vation from Execution Management.
The Function Groups mechanism is very flexible and is intended as a tool used to
start and stop processes of Applications. System integrator can assign pro-
cesses to a Function Group State and then request it by State Management.
For details on state change management see Section 7.5.5.
A Modelled Process may not be assigned to more than one Function Group
[constr_1688]. To see why this constraint is required consider the contrary a Modelled
Process mapped to two states in two Function Groups. The Modelled Process
is now running in the two states and a Function Group State transition in either
state would require the process to be terminated. This termination would violate the
integrity of the second Function Group State and hence the constraint exists to
prevent this situation.
In general, Machine States (see Section 7.5.2) are used to control machine lifecy-
cle (startup/shutdown/restart) and processes of platform level Applications, while
other Function Group States individually control processes which belong to
groups of user-level Applications. Please note that this doesn’t mean that all pro-
cesses of platform level Applications have to be controlled by Machine States.
Figure 7.12 shows an example of state change sequence where several pro-
cesses reference Machine States and Function Group States of two addi-
tional Function Groups FG1 and FG2. For simplicity, only the three static Process
States Idle, Running, and Terminated are shown for each process.

62 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Machine State Off Startup Running Diagnostics Shutdown

C reference state
A B process transition

Function Group 1
FG1:Off FG1:Running FG1:Off
State

D E

Function Group 2 FG2:

FG2:Off FG2:Running FG2:Fallback FG2:Diag FG2:Off
State Off
self-
terminating F
Terminated
A Running
Idle
dependency
Terminated
B Running
Idle

Terminated
C Running
Idle

Terminated
D Running
Idle

Terminated
E Running
Idle

Terminated
F Running
Idle
Process State
different
StartupOptions

Figure 7.12: State dependent process control

• process A references the Machine State Startup. It is a Self-termi-

nating Process, i.e. it terminates after executing once.
• process B references Machine States Startup and Running. It depends
on the termination of process A, i.e. an Execution Dependency has been
configured, as described in Section 7.4.4.1
• process C references Machine State Running only. It terminates when
Machine State Diagnostics is requested by State Management.
• processes D and E references Function Group State FG1:Running only
and there is no Execution Dependency configured between them. Execu-
tion Management will start and terminate them in an arbitrary order (e.g. in
parallel if possible).
• process F references FG2:Running and FG2:Fallback. It has different
startup configurations assigned to the two states, therefore it terminates at the
state transition and starts again, using a different startup configuration.

63 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

System design and integration should ensure that enough resources are available on
the machine at any time, i.e. the added resource consumption of all processes which
reference simultaneously active states should be considered.
[SWS_EM_01107]{OBSOLETE} Function Group configuration dExecution Man-
agement shall obtain configuration of the Function Group from the Processed
Manifest to set-up the Function Group specific state management.c(RS_EM_-
00101)
A proper system configuration requires that each process references in its Ex-
ecution Manifest one or more Function Group States (which can be Ma-
chine States) of the same Function Group. If a process doesn’t reference any
Function Group States it will never be started, for more details please refer to
[SWS_EM_01066] and chapter 7.5.5 State Transition.
[SWS_EM_01013]{OBSOLETE} Function Group State dExecution Management
shall support the execution of a specific Modelled Process, depending on the cur-
rent Function Group State and on information provided in the Execution Man-
ifests.c(RS_EM_00101)
Each Modelled Process is assigned to one or several startup configurations (Star-
tupConfig), which each can define the startup behavior in one or several Function
Group States (including Machine States). For details see [3]. By parsing this
information from the Execution Manifests, Execution Management can de-
termine which Modelled Processes need to be launched if a specific Function
Group State is entered, and which startup parameters are valid.
[SWS_EM_01033] process start-up configuration dTo enable a Modelled Pro-
cess to be launched in multiple Function Group States, Execution Manage-
ment shall be able to configure the process started on every Function Group
State change based on information provided in the Execution Manifest.c(RS_-
EM_00009, RS_EM_00101)
[SWS_EM_02254]{OBSOLETE} Misconfigured process - assigned to more than
one Function Group dDuring a Function Group State transition, any process
involved that references states from more than one Function Group, shall cause
EM to perform following actions:
1. Stop the Function Group State transition, so State Management can de-
cide how to proceed.
2. Log event if needed
3. Set the current Function Group State to Undefined Function Group
State.
4. Report kFailed in the ara::exec::StateClient::SetState interface to
indicate that the State change request cannot be fulfilled.
5. Report the executionError configured for requested Function Group
State via the ara::exec::StateClient::GetExecutionError interface.

64 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

c(RS_EM_00101)
Please note AUTOSAR doesn’t support the possibility of assigning a single process
to more than one Function Group, see [3] ([constr_1688]).
[SWS_EM_01110] Off States dEach Function Group (including the Function
Group "MachineFG") has an Off State which shall be used by Execution Man-
agement as initial Function Group State.c(RS_EM_00101)
Within any FunctionGroup, including "MachineFG", the “Off” state is mandatory as
the initial state [TPS_MANI_03195] and cannot have Modelled Processes mapped
according to [constr_3424]. [SWS_EM_01110] and [SWS_EM_01023] together define
the very first Function Group state transition after the power up.
processes reference in their Execution Manifest the states in which they want
to be executed. A state can be any Function Group State, including a Machine
State. For details see [3], especially "State-dependent Startup Configuration" chapter
and "Function Groups" chapter.
The arbitrary state change sequence as shown in Figure 7.9 applies to state changes
of any Function Group - just replace "MachineFG" by the name of the Function
Group. On receipt of the state change request, Execution Management terminates
no longer needed processes and then starts processes active in the new Func-
tion Group State before confirming the state change to State Management. For
details see Section 7.5.5.

7.5.4 State Interaction

Figure 7.13 shows a simplified example for the interaction between different types of
states, after State Management functional cluster has requested different Func-
tion Group States . One can see the state transitions of the Function Group
and the process and Execution States of one process which references one state
of this Function Group, ignoring possible delays and dependencies if several pro-
cesses were involved.

65 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

vehicle management, error management, diagnostics, authorized applications, etc.

ara::com

State Management
Arbitration of input data (e.g. state requests, events) to determine current target states

SetState(FG1, State2) return SetState(FG1, State3) return

(success) (success)

Execution Management

FG1:State1
initial state of
Function State Transition FG1:State2 State Transition FG1:State3
Group “FG1“
(example)
State Transitions
FG1 State managed by EM

Idle Starting
Terminated
(Execution process
Execute Schedule Running Terminate Terminating process
Manifest created,
resources
references resources
freed
FG1:State2) allocated
Process Lifecycle
Process State managed by EM

SIGTERM EXIT_SUCCESS
ReportExecutionState
schedule
Start() (Running) process
terminated

Initializing Terminating
Running
application store data,
create process perform main Terminate
data free resources,
allocate functionality trigger
initialization exit
resources
optional
Execution State
confirm
process

Figure 7.13: Interaction between states

7.5.5 State Transition

State Management can request to change one or several Function Group

States (including the Machine State), using API described in Section 8.2.7. ara::
exec::StateClient::SetState allows State Management to request several
Function Group State changes in parallel. If Machine State change is re-
quired, the name of the Function Group passed shall be: "MachineFG".
[SWS_EM_02298] Request of a state transition different to the state that the
Function Group is already in transition to dAfter successful validation of a ara::
exec::StateClient::SetState call for a Function Group that is already un-
der state transition, Execution Management shall cancel the ongoing Function

66 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Group State transition (and set that request’s ara::core::Future to kCan-

celled) before starting the new Function Group State transition (and returning
a new ara::core::Future for the new request).c(RS_EM_00101)
[SWS_EM_02296] Request of a state transition to a state that the Function
Group is already in transition to dAfter successful validation of a ara::exec::
StateClient::SetState call for a Function Group that is already under state
transition, Execution Management shall:
• set the ara::core::Future of the previous request to kCancelled if there is
one
• return a new ara::core::Future for the new request
• continue the ongoing Function Group state transition
c(RS_EM_00101)
There is only one situation where a transition to a state could be performed without a
previous request. When Execution Management is performing the initial transition
to "MachineFG" startup [SWS_EM_01023], State Management can decide to request
a different state of "MachineFG". In this situation there is no previous request, so
there is no ara::core::Future, that can be set to kCancelled.
Before Execution Management cancels an ongoing request according to
[SWS_EM_02298] or [SWS_EM_02296] the new request should be assessed as valid,
this includes, but is not limited to, [SWS_EM_02549].
Please note that [SWS_EM_02298] merely ensures that Execution Management
first informs the requester of the ongoing transition (instance of ara::exec::State-
Client) about the cancellation, before informing the new requester that the new re-
quest has been accepted. Both requesters could be the same instance of ara::
exec::StateClient.
[SWS_EM_02295] Request of a state transition to a state that the Function
Group is already in dara::exec::StateClient::SetState shall ignore the re-
quest and return immediately with success.c(RS_EM_00101)
Note that an error domain value is not used for [SWS_EM_02295] as this would be
interpreted as an error by State Management and thus trigger the associated error
handling.
There are no other requirements or assumtions on order in which requests from ara::
exec::StateClient::SetState are processed.
Requesting the same Function Group State like before (independently if the pre-
vious state request is already finished or still ongoing) shall be prevented, because it
might lead to unwanted execution dependencies. When the same Function Group
State is to be requested again another state has to be requested before. Please
note that State Management can repeat state transition request (to the same state)

67 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

if previous transition ended with error. This is allowed because a failed state transition
is considered as invalid Function Group State.
Since Execution Management allows a new ara::exec::StateClient::Set-
State call to interrupt an ongoing transition and thus change the destination Func-
tion Group State of the transition, it may happen (especially in misconfigured sys-
tem, or during the development phase) that some of ara::exec::StateClient::
SetState requests will be issued by mistake. It is in the best interest of Execution
Management to inform requester (instance of ara::exec::StateClient) of the
ongoing transition, that it had been canceled by a newer request as soon as possible.

FG_A FG_B

ON ABC

XYZ
 state

 Process
 dependency
 forbidden dependency
Figure 7.14: Example configuration for state transition

Before we specify how internals of a state transition works, let’s consider an exam-
ple configuration illustrated in figure Figure 7.14. As we can see Execution De-
pendencies that spans outside of a Function Group and moreover of a single
Function Group State are forbidden. The dependency from process B (inside
Function Group FG_B) to process A (inside Function Group FG_A) is forbid-
den, as it would introduce hidden dependencies between Function Groups that are
not visible to State Management. If system configuration requires this kind of depen-
dencies, please see [9] for advice on how to configure them. Dependencies outside

68 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

of a single Function Group State definition are forbidden, as they would result in
starting a process that is not configured to run in the given State. For more informa-
tion on Execution Dependencies see chapter Section 7.4.4.1 ([SWS_EM_01001]
and [constr_1689]).
Please note that process B has different Execution Dependencies in Func-
tion Group State ABC and Function Group State XYZ. This configuration
requires existence of two different startup configurations (StateDependentStar-
tupConfig), which in turns will mandate process B restart if State Management
request Function Group State change from ABC to XYZ. This is enforced by
[SWS_EM_02251].
From the above we can conclude that each Function Group is a separate entity
and state transition of one Function Group doesn’t have side effects on another
Function Group. Please note that this is true from the point of view of Execution
Management and may differ from the point of view of State Management (see [9] if
you need more information on this).
In the following requirements the Execution Manifest of a Modelled Process
is the formal modelling of process startup behaviour and is implemented by means
of the aggregation of meta-class StateDependentStartupConfig in the role Pro-
cess ([TPS_MANI_01012]).
The term "the process references a State" indicates a functionGroupState that
references an instance of StateDependentStartupConfig within the Startup-
Config that is applicable for the process associated with the specific Function
Group State.
CurrentState is the current (currently active) State of a Function Group for
which the state transition was requested; or the current Machine State if the Func-
tion Group has "MachineFg" name. In short this is a Function Group State
or Machine State.
RequestedState is the state that will become the CurrentState, once the state
transition finishes successfully.
In other words CurrentState is the starting point of the transition, the list of the pro-
cesses that should be currently running inside the Function Group (please note the
existence of Self-terminating Processes). RequestedState is a destination
point of the state transition, the list of the processes that will be running inside of
the Function Group once the state transition finishes successfully (please note the
existence of Self-terminating Processes).
StartupConfig is a StateDependentStartupConfig that is aggregated in the
role Process.stateDependentStartupConfig for a given process.
State transition is a complicated process, however it is composed out of three simple
logical steps:
• Terminate all processes that are currently running and are not needed in the
RequestedState

69 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• Restart all processes that are currently running and have StartupConfig that
differs between the CurrentState and the RequestedState
• Start all processes that are not running currently and are needed in the Re-
questedState
Please see Section 7.4.1 and Section 7.4.2 for more detail information on how Exe-
cution Management handles termination and start of processes (restart is a se-
quence of termination and start).
[SWS_EM_01060] State transition - termination behavior dOn state transition Ex-
ecution Management shall request termination ([SWS_EM_01055]) of each pro-
cess that references the CurrentState in its Execution Manifest, but does not
reference the RequestedState and has a Process State different than [Idle or
Terminated].c(RS_EM_00101)
[SWS_EM_02251] State transition - restart behavior dOn state transition Execu-
tion Management shall terminate all processes that reference the CurrentState
in its Execution Manifest, but references the RequestedState with different
StartupConfig and have Process State different than [Idle or Terminated].c
(RS_EM_00101)
Please note that [SWS_EM_02251] only request a termination of processes, the start
part will fall under [SWS_EM_01066] requirement thus making the restart complete.
Execution Management monitors the time required by each process to terminate.
The default value of the process termination timeout is defined by the system inte-
grator in the Machine Manifest, see [TPS_MANI_03151]. This value may be over-
written in the startup configuration of individual processes by defining the termination
timeout parameter in the Execution Manifest, see [TPS_MANI_01278].
[SWS_EM_01065] State transition - process termination timeout monitoring d
Execution Management shall monitor the time required by the process to termi-
nate (the time needed by the process to reach the Terminated Process State).c
(RS_EM_00101)
[SWS_EM_02255] State transition - process termination timeout reaction dIn
the event of a process termination timeout (defined by configuration StartupCon-
fig.timeout), Execution Management shall request the Operating System to
forcibly terminate the underlying process.c(RS_EM_00101)
On multi-process POSIX platforms, this could be achieved using a SIGKILL signal.
[SWS_EM_02258] State transition - process termination timeout reporting dWhen
the termination of a process resulted in the timeout, Execution Management shall
log the event, if logging is activated.c(RS_EM_00101)
Execution Management continues a state-transition even in the presence of non-
terminating processes, since the target Function Group State will be reached as
these processes will be killed (see [SWS_EM_02255] and [SWS_EM_01060]). Con-
tinuing in case of a timeout on termination assures in particular, that the Function

70 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Group State "Off" can always be reached (provided that a process termination on
OS level is always successful).
This is different in case of processes that timeout during start-up (see
[SWS_EM_02259]): these processes cannot be forced to start and the Function
Group State will not be reached.
[SWS_EM_01066] State transition - start behavior dOn state transition Execution
Management shall start all processes that references the RequestedState in its
Execution Manifest and have Process State that is [Idle or Terminated].c
(RS_EM_00101)
Execution Management monitors the time required by each process to start. The
start-up timeout is defined per process startup configuration by the system integrator
in the Execution Manifest, see [TPS_MANI_01277].
[SWS_EM_02253] State transition - process start-up timeout monitoring dExe-
cution Management shall monitor the time required by the process to start-up (the
time between Execution Management requesting process creation from the operat-
ing system and the process successfully reporting the Running Process State).c
(RS_EM_00101)
Execution Management monitors the time required by each process to start. The
value of the process start-up timeout is defined by the system integrator in the Exe-
cution Manifest, see [TPS_MANI_01277]. Please note that startup time for Non-
-reporting Processes is zero because Non-reporting Processes immedi-
ately switch from Process State Idle to Running skipping the Starting state.
[SWS_EM_02260] State transition - process start-up timeout reaction dIn the event
of a process start-up timeout (defined by configuration StartupConfig.time-
out), Execution Management shall attempt to restart the process up to num-
berOfRestartAttempts times.c(RS_EM_00101)
process start-up timeout is caused by a malfunction and therefore Execution Man-
agement requests termination of the process by the operating system (e.g. using
SIGKILL) rather than requesting termination through SIGTERM as the process is
assumed to be in an erroneous state.
[SWS_EM_02280] Effect on Execution Dependency dA restart attempt according to
[SWS_EM_02260] shall not fulfill any terminated dependencies.c(RS_EM_00101)
[SWS_EM_02310] State transition - process termination after start-up timeout re-
action dIn case a process start-up timeout occurred after Execution Management
attemted to restart the process numberOfRestartAttempts times, Execution
Management shall request the Operating System to terminate the underlying pro-
cess.c(RS_EM_00101)
[SWS_EM_02259] State transition - process start-up timeout reporting dWhen
the start-up of a process resulted in the timeout, Execution Management shall
perform following actions:

71 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

1. Stop the Function Group State transition, so State Management can de-
cide how to proceed.
2. log event, if logging is activated
3. Set the CurrentState to Undefined Function Group State.
4. Report kFailed in the ara::exec::StateClient::SetState interface to
indicate that the State change request cannot be fulfilled.
5. Report the configured executionError via the ara::exec::State-
Client::GetExecutionError interface.
c(RS_EM_00101)
[SWS_EM_02552]{DRAFT} State transition - integrity or authenticity check failed
dWhen the start-up of a process results in the failure of an integrity or authentic-
ity check and strictMode is active ([SWS_EM_02305]), Execution Management
shall perform following actions:
1. Stop the Function Group State transition, so State Management can de-
cide how to proceed.
2. log event, if logging is activated
3. Set the CurrentState to Undefined Function Group State.
4. Report kIntegrityOrAuthenticityCheckFailed in the ara::exec::
StateClient::SetState interface to indicate that the State change request
cannot be fulfilled.
5. Report the configured executionError via the ara::exec::State-
Client::GetExecutionError interface.
c(RS_EM_00101)
[SWS_EM_02312] Order of process start-up timeout reaction dExecution Man-
agement shall perform the terminate reaction [SWS_EM_02310] before reporting to
State Management [SWS_EM_02259].c(RS_EM_00101)
When starting new processes, Execution Management is obligated to perform
dependency resolution. When doing so it may came across a configuration where
process B depends on process A, but process A needs to be restarted during
state change. Another example is a configuration where process D depends on a
Self-terminating Process C to be in Process State Terminated. process
C has to be started and terminated in the requested Function Group State to fulfill
D’s Execution Dependency. Please see Figure 7.15 for more details.

72 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Information Classification: Internal

A C B D

Function Group 2
FG2:Off FG2:Running FG2:Fallback
State
different
StartupOptions
Terminated
A Running
Idle

Process State
dependency on process A
“Running“
Terminated
B Running
Idle

Self
Termination

Terminated
C Running
Idle

Terminated
D Running
Idle
dependency on process C
“Terminated“

Figure 7.15: Dependency resolution during state change

[SWS_EM_02245] Dependency resolution during state change dExecution

Management shall perform Execution Dependency resolution against the pro-
cesses that are configured for RequestedState.c(RS_EM_00101)
Please note that [SWS_EM_02245] doesn’t bring new functionality to state transition.
It merely ensures that [SWS_EM_02251] and [SWS_EM_01066] are performed on
process A, before [SWS_EM_01066] is performed on process B. If this order is
not ensured then [SWS_EM_02245] could not be satisfied as process A will be a
process that is configured for CurrentState and not for RequestedState.
Description of Function Group State transition in this chapter may give impres-
sion that, it is required to first stop all processes that are not needed in Requested-
State, before you can start any of the processes that are needed. Please note that
this is not the case. Step by step approach of this chapter was chosen to introduce as

73 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

much clarity as possible, when describing Function Group State transition. Imple-
menters are free to parallelize as much steps (needed for state transition) as possible
for a particular implementation.
Execution Management considers a state transition has been performed success-
fully when the following have occurred:
• Dependency resolution ([SWS_EM_02245]) has identified processes to
start/stop
• All processes expected to terminate have terminated ([SWS_EM_01060])
• All started ([SWS_EM_01066]) or restarted [SWS_EM_02251]) Reporting
Processes have reported kRunning.
[SWS_EM_01067] Actions on Completion State Transition dOn successful comple-
tion of a state transition, Execution Management shall set the CurrentState to
the RequestedState and report success back to State Management.c(RS_EM_-
00101)
[SWS_EM_02313]{OBSOLETE} Unexpected Termination of starting pro-
cesses during Function Group State transition dIn case of Unexpected
Termination during process startup ([SWS_EM_01066]), Execution Manage-
ment shall perform the following actions:
1. Stop the Function Group State transition, so State Management can de-
cide how to proceed.
2. log event, if logging is activated
3. Set the CurrentState to Undefined Function Group State.
4. Report kFailedUnexpectedTerminationOnEnter in the ara::exec::
StateClient::SetState interface to indicate that the State change request
cannot be fulfilled.
5. Report the configured executionError via the ara::exec::State-
Client::GetExecutionError interface.
c(RS_EM_00101)
[SWS_EM_02315] Unexpected Termination of processes configured for the
RequestedState during a Function Group State transition dIn case of Unex-
pected Termination of a process configured for the RequestedState, Execution
Management shall perform the following actions:
1. Stop the Function Group State transition, so State Management can de-
cide how to proceed.
2. log event, if logging is activated
3. Set the CurrentState to Undefined Function Group State.

74 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4. Report kFailedUnexpectedTermination in the ara::exec::State-

Client::SetState interface to indicate that the State change request cannot
be fulfilled.
5. Return the configured executionError via the ara::exec::StateClient::
GetExecutionError interface.
c(RS_EM_00101)
Please note that [SWS_EM_02313] also applies to Unexpected Self-termina-
tion.
[SWS_EM_02314]{OBSOLETE} Unexpected Termination of terminating pro-
cesses during Function Group State transition dIn case of Unexpected
Termination during process termination ([SWS_EM_01060],[SWS_EM_02251]),
Execution Management shall log the event, if logging is activated.c(RS_EM_00101)
[SWS_EM_02316] Unexpected Termination of a process not configured for
the RequestedState during a Function Group State transition dIn case of
Unexpected Termination of a process not configured for the RequestedState
during a Function Group State, Execution Management shall continue the
Function Group State transition and log the event, if logging is activated.c(RS_-
EM_00101)
If process B depends on the termination of process A during a Function Group
State transition (this means that both are configured for the RequestedState), the
transition fails if process A dies unexpectedly before reaching the Terminated pro-
cess state ([SWS_EM_02315]).
However if a process is only configured for the CurrentState and it dies unexpect-
edly during the Function Group State transition, then this doesn’t stop the Func-
tion Group State transition. The Unexpected Termination is logged and nor-
mal state transition activities are resumed ([SWS_EM_02316]). The reason to continue
the transition is twofold:
• The process was already marked to be terminated by Execution Manage-
ment (it was not configured for the RequestedState). It is irrelevant from the
State Management point of view if it terminated as expected or due to an internal
error.
• Transition to the Off state is always guaranteed to be successful and can be
used as a reaction to an error condition.
[SWS_EM_02297] StateClient usage restriction dStateClient API shall treat it as
a Violation when invoked by a process with Process.functionClusterAffili-
ation configured to anything else than STATE_MANAGEMENT.c(RS_EM_00101)
If not protected StateClient can be used to destabilise Machine, see Section 8.2.7
for more details.

75 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.6 Deterministic Execution

7.6.1 Determinism

Please note that all requirements in this chapter have been set to obsolete.
In real-time systems, deterministic execution often means, that a calculation of a given
set of input data always produces a consistent output within a bounded time, i.e. the
behavior is reproducible.
It is also worthwhile to note that determinism must be distinguished from other non-
functional qualities like reliability or availability, which all deal in different ways with the
statistical risk of failures. Determinism does not provide such numbers, it only defines
the behavior in the absence of errors.
There are multiple elements in determinism and here we distinguish them as follows:
• Time Determinism: The output of the calculation is always produced before a
given deadline (a point in time).
• Data Determinism: Given the same input and internal state, the calculation al-
ways produces the same output.
• Full Determinism: Combination of Time and Data Determinism as defined above.
In particular, deterministic behavior is important for safety-critical systems, which may
not be allowed to deviate from the specified behavior at all. Whether Time Determin-
ism, or in addition Data Determinism is necessary to provide the required functionality
depends on the system and on the safety goals.
Expected use cases of the AUTOSAR Adaptive Platform where such determinism
is required include:
• Software Lockstep: To execute ASIL C/D applications with high computing perfor-
mance demands, specific measures, such as software lockstep are required, due
to high transient hardware error rates of high performance microprocessors. Soft-
ware lockstep is a technique where the calculation is done redundantly through
two different execution paths and the results are compared. To make the re-
dundant calculations comparable, software lockstep requires a fully deterministic
calculation. For details see 7.6.2.
• Reuse of verified software: The deterministic subsystem shows the same be-
havior on different platforms which satisfy the performance and resource needs
of the subsystem, regardless of other differences in each environment, such as
existence of unrelated applications. Examples include the different development
and simulation platforms. Due to reproducible functional behavior, many results
of testing, configuration and calibration of the subsystem are valid in each envi-
ronment where the subsystem is deployed on and don’t need to be repeated.

76 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.6.1.1 Time Determinism

Each time a calculation is started, its results are guaranteed to be available before
a specified deadline. To achieve this, sufficient and guaranteed computing resources
(processor time, memory, service response times etc.) should be assigned to the
software entities that perform the calculation. For more information on resources see
chapter 7.7.
Non-deterministic “best-effort” processes can request guaranteed minimum re-
sources for basic functionality, and additionally can have maximum resources specified
for monitoring purposes. However, if Time Determinism is requested, the resources
must be guaranteed at any time, i.e. minimum and maximum resources are identical.
If the assumptions for deterministic execution are violated, e.g. due to a deadline miss,
this is an error detectable by the Application. In non-deterministic “best-effort” subsys-
tems such deadline violations or other deviations from normal behavior sometimes can
be tolerated and mitigated without dedicated error management.
Fully-Deterministic behavior additionally requires Data Determinism, however in many
cases Time Determinism is sufficient.

7.6.1.2 Data Determinism

For Data Determinism, each time a calculation is started, its results only depend on the
input data. For a specific sequence of input data, the results always need to be exactly
the same, assuming the same initial internal state.
A common approach to verify Data Determinism in a safety context is the use of
lockstep mechanisms, where execution is done simultaneously through two different
paths and the result is compared to verify consistency. Hardware lockstep means that
the hardware has specific equipment to make this double-/multi-execution transparent.
Software lockstep is another technique that allows providing a similar property without
requiring the use of dedicated hardware.
Depending on the Safety Level, as well as the Safety Concept employed, software lock-
step may involve executing multiple times the same software, in parallel or sequentially,
but may also involve running multiple separate implementations of the same algorithm.

7.6.1.3 Full Determinism

For Full Determinism, each time a calculation is started, its results are available before
a specified deadline and only depend on the input data, i.e. both Time and Data
Determinism must be guaranteed.
Non-deterministic behavior may arise from different reasons; for example insufficient
computing resources, or uncoordinated access of data, potentially by multiple threads

77 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

running on multiple processor cores. The order in which the threads access such data
will affect the result, which makes it non-deterministic (“race condition”).
A fully deterministic calculation must be designed, implemented and integrated in a
way such that it is independent of processor load caused by other functions and cal-
culations, sporadic unrelated events, race conditions, deviating random numbers etc.,
i.e. for the same input and initial conditions it always produces the same result within
a given time.

7.6.2 Deterministic Client

As explained in 7.6.1, future systems need high computing performance in combina-

tion with high ASIL safety goals. In this chapter we specify mechanisms which support
deterministic multithread execution to support high performance software lockstep so-
lutions. Here are some additional rationales behind it:
• Safety goals for Highly Automated Driving (HAD) systems can be up to ASIL D.
• High Performance Computing (HPC) demands can only be met by non
automotive-grade, e.g. consumer electronics (CE), microprocessors, which have
high transient hardware error rates compared to automotive-grade microcon-
trollers. Most likely no such microprocessor is available for ASIL above B, at
least for the parts relevant to the design.
• To deal with high error rates, ASIL C/D HAD applications require specific mea-
sures, in particular software lockstep, where execution is done redundantly
through two different paths and the result is compared to detect errors.
• To make these redundant calculations comparable, software lockstep requires a
fully deterministic calculation as defined in 7.6.1.3.
• To meet HPC demands, highly predictable and reliable multi-threading must be
supported
Two redundant processes, which run in an internal cycle, get in each cycle the same
input data via regular interfaces of Communication Management and produce (in
the absence of errors) the same results, due to full deterministic execution.
Execution Management provides DeterministicClient APIs to support control
of the process-internal cycle, a deterministic worker pool, activation time stamps and
random numbers. In case of multiple processes for redundant execution, the Deter-
ministicClient interacts with a DeterministicSyncMaster to ensure identical
behavior of the redundantly executed processes.
The activation time stamps are provided by local time sychronization slave or mas-
ter, and the redundant executions between the processes are handled by the corre-
sponding DeterministicSyncMaster, which propagates the activation time stamp

78 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

and the calculated cycle information for next execution to all the connected Deter-
ministicClient. The calculated data of the application processes is published
through Communication Management.
For each execution cycle, the DeterministicSyncMaster synchronizes the De-
terministicClients. It makes sure that random numbers and activation time
stamps that are sent to DeterministicClients are identical for the redundantly ex-
ecution. The DeterministicClients then synchronize the triggering of execution
based on the received activation time stamps. An optional software lockstep framework
may subscribe to the output of the redundant processes and compare the output to
detect failures (e.g. transient processor core or memory errors due to radiation) in
one of the redundant processes. This infrastructure layer can span over multiple
hardware instances and is implementation specific.
The AUTOSAR Adaptive Platform needs to provide some library functions to sup-
port redundant deterministic execution with sufficient isolation. The library functions
(DeterministicClient) run in the context of the user process. Figure 7.16 con-
siders how DeterministicClient can be used in one of the redundantly executed
processes.

user process

no
interaction
worker worker
Register
Services
worker worker
Service
Discovery workers
worker joining
Init

Run

Terminate
GetRandom() GetActivationTime()
GetNextActivationTime()

WaitForActivation() RunWorkerPool() RunWorkerPool()

DeterministicClient
provide activation cycle control, worker pool, random numbers, activation time

access input data synchronization with details not yet publish output data
activation cycle specified
ara::com ara::com
Communication Management
service registration and discovery, provide stable input data, receive output data

Figure 7.16: Cyclic Deterministic Execution

Cyclic process behavior is controlled by a wait point API. The API returns a code
to control the process mode (register services/ service discovery/ init/ run/ termi-
nate). The execution is triggered by the ara::exec::DeterministicClient (see

79 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02210]), depending on a defined period or on received events. Within a

process, all input data is available via ara::com (polling-based access only) when
execution starts and is stable over one execution cycle. For details see 7.6.3.1.
The workload can be deployed to a worker pool API, which allows deterministic execu-
tion of a set of container elements (e.g. data sets), which are processed in parallel by
the same runnable object (i.e. application function). The runnable object is not allowed
to exchange any information while it is running, i.e. it doesn’t access data which can be
altered by other instances of the runnable object to avoid race conditions. The runnable
object instances can physically run in parallel or sequentially in any order. For details
see 7.6.3.2.
Additional DeterministicClient APIs provide random numbers and activation time
stamps. Common HAD algorithms use particle filters which require random numbers.
If used from within the worker pool, the random numbers are assigned to specific con-
tainer elements to allow deterministic redundant execution. The activation time stamps
don’t change until the process reaches its next wait point. For deterministic redun-
dant execution, random number seeds and time stamps need to be synchronized. For
details see 7.6.3.3 and 7.6.3.4.
At the end of the execution cycle, the process returns to the wait point and waits for
the next activation.
The APIs of DeterministicClient are standardized and provide abstraction of the
application deployment on the actual hardware. The implementation is vendor specific
and needs to be configured at integration time individually for each process which
uses it.
The DeterministicClient Class is only local to the process. Therefore, there is
currently no security concern foreseen for this API.
Different variants of the DeterministicClient might work in a software lockstep
environment or stand-alone, to support cyclic execution and deterministic worker pools.
[SWS_EM_02551]{OBSOLETE} Missing DeterministicClient dIf the configuration of
DeterministicClient is missing then ara::exec::DeterministicClient::
WaitForActivation shall return Error kFailed.c(RS_EM_00053)

80 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.17: Deterministic Execution Interface

7.6.3 Cyclic Deterministic Execution

This section describes the APIs shown in Figure 7.16, and how they need to be used
by a process to execute deterministically, so the process can be transparently inte-
grated into a software lockstep environment.

7.6.3.1 Control of Cyclic Execution

Execution Management provides an API to trigger and control recurring, i.e. cyclic
execution of the main thread code within a process.
[SWS_EM_01301]{OBSOLETE} Cyclic Execution dExecution Management shall
provide a blocking wait point API ara::exec::DeterministicClient::Wait-
ForActivation.c(RS_EM_00052, RS_EM_00113)
After the process has been started by Execution Management, it reports ara::
exec::ExecutionState kRunning (see 7.4.1) and calls ara::exec::Deter-
ministicClient::WaitForActivation.

81 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The process executes one cycle when ara::exec::DeterministicClient::

WaitForActivation returns and then calls the API again to wait for the next activa-
tion.
A return value controls the internal lifecycle (e.g. init, run, terminate) of the process,
see Figure 7.16. The return codes are used to synchronize the behavior of two pro-
cesses in case they are executed redundantly.
[SWS_EM_01302]{OBSOLETE} Cyclic Execution Control dara::exec::Deter-
ministicClient::WaitForActivation shall return a code to control the execu-
tion mode of the calling process. Possible codes are kRegisterServices, kSer-
viceDiscovery, kInit, kRun, and kTerminate.c(RS_EM_00052)
The ara::exec::ActivationReturnType (see [SWS_EM_02201]) returned from
ara::exec::DeterministicClient::WaitForActivation determines the ac-
tions taken at each cycle:
• kRegisterServices – The process registers its communication services, i.e.
the services it offers via Communication Management. This should be the
only occasion for performing service registering. No other functionality should be
performed in this step to limit resource consumption and runtime, so no dedicated
budget needs to be assigned.
• kServiceDiscovery – The process does communication service discovery.
This should be the only occasion for performing service discovery, except a ser-
vice needs to be replaced later (see ([SWS_EM_01304]). No other functionality
should be performed in this step to limit resource consumption and runtime, so
no dedicated budget needs to be assigned.
• kInit – The process initializes its internal data structures. The worker pool
(see 7.6.3.2) can be accessed once or several time sequentially. A budget (see
7.6.3.5) needs to be assigned to the “Init” cycle.
• kRun – The process performs one cycle of its normal cyclic execution. This can
be repeated indefinitely. The worker pool (see 7.6.3.2) can be accessed once
or several times sequentially within a cycle. A budget (see 7.6.3.5) needs to be
assigned.
• kTerminate – The deterministic client prepares to terminate. It is up to the
process whether this also leads to the actual termination of the process and
if so the actual termination is performed according to [SWS_EM_01404], see
Section 7.4.2.
[SWS_EM_01303]{OBSOLETE} Cyclic Execution Control Sequence dThe return
code of ara::exec::DeterministicClient::WaitForActivation shall follow
this sequence: kRegisterServices, kServiceDiscovery, kInit, kRun, and
kTerminate. Note that kRun is expected to be returned multiple times.c(RS_EM_-
00052)
[SWS_EM_01304]{OBSOLETE} Service Modification dIn case a service which is ac-
cessed by the process needs to be replaced (e.g. due to unavailability) while the

82 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

kRun cycles are executed, ara::exec::DeterministicClient::WaitForAc-

tivation shall return kServiceDiscovery once immediately after ara::exec::
DeterministicClient::WaitForActivation is called, and then continue with
the normal kRun cycle.c(RS_EM_00051, RS_EM_00052)
The service discovery update needs to be triggered in an implementation specific way,
e.g. through a callback triggered by StartFindService indicating service unavail-
ability. Because the service discovery update runs in addition to the kRun execution
within a kRun cycle, the worst case execution time estimation and budget assignment
need to consider that kRun and kServiceDiscovery might run sequentially within
the configured execution cycle time (see below).
The point in time when ara::exec::DeterministicClient::WaitForActiva-
tion returns with kRegisterServices, kServiceDiscovery, kInit, kRun (first
kRun cycle only, otherwise see below) or kTerminate is implementation specific. In
case of redundant execution, the sequences need to be synchronized.
The activation behavior of the kRun-cycles can be realized by Execution Manage-
ment together with the Communication Management as required by the safety con-
cept. Execution can be triggered via two distinct mechanisms.
• Periodic activation means that ara::exec::DeterministicClient::
WaitForActivation returns periodically based on a configured period.
• Event-triggered activation means that ara::exec::Deterministic-
Client::WaitForActivation returns based on the communication-
event-triggers that are configured for the process from the outside via
Communication Management, e.g. by external units, events generated due to
the arrival of data or timer events.
Details of the synchronization for both periodic and event-triggered activation are dis-
cussed in section 7.6.4.
[SWS_EM_01351]{OBSOLETE} Execution Cycle Time dara::exec::Determin-
isticClient::WaitForActivation shall return kRun when a configurable cy-
cleTimeValue (as measured from the last return of kRun) has been reached.c(RS_-
EM_00052)
[SWS_EM_02550]{OBSOLETE} Execution Cycle Termination dara::exec::
DeterministicClient::WaitForActivation shall return kTerminate when
the kRun-cycle is to be terminated by either exceeding the kRun loop count
[SWS_EM_01323] or by DeterministicSyncMaster synchronization response
[SWS_EM_01326].c(RS_EM_00052)
[SWS_EM_01352]{OBSOLETE} Execution Cycle Timeout dara::exec::Deter-
ministicClient::WaitForActivation shall return error kCycleOverrun if the
previous cycle did overrun (i.e. configured cycleTimeValue has been exceeded).c
(RS_EM_00052)

83 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Note that with respect to [SWS_EM_01352], the deterministic client used by the Ap-
plication detects the cycleTimeValue overrun and reports it to the application. The
Application developer/System Designer can then take the relevant project-specific ac-
tions.
[SWS_EM_01353]{OBSOLETE} Event-triggered Cycle Activation dIf the configured
cycleTimeValue is zero, ara::exec::DeterministicClient::WaitForAc-
tivation shall support event triggered activation.c(RS_EM_00052)
DeterministicSyncMaster provides support for event triggered ara::
exec::DeterministicClient::WaitForActivation (see Section 7.6.4.1)
as well as synchronized cyclic execution. In these cases the return from
ara::exec::DeterministicClient::WaitForActivation is synchronized
through a Synchronization Response Message from DeterministicSyncMaster
[SWS_EM_01326][SWS_EM_01327][SWS_EM_01327].
This cyclic behavior can be used in a software lockstep environment to initialize and
trigger execution of redundant processes and compare the results after a cycle has
finished. For redundant execution, the execution behavior and its budget (activation
timing, computing time, computing resources) should be explicitly visible at integration
time to configure Execution Management accordingly.
Optionally, e.g. if necessary for a software lockstep implementation, all input data as
received via Communication Management should be available when a cycle starts
and guaranteed to be deterministically consistent.

7.6.3.2 Worker Pool

[SWS_EM_01305]{OBSOLETE} Worker Pool dExecution Management shall pro-

vide a blocking API ara::exec::DeterministicClient::RunWorkerPool to
run a deterministic worker pool to be used within the process execution cycle.c(RS_-
EM_00053)
The worker pool is triggered by the main-thread of the process in a sequential order.
ara::exec::DeterministicClient::RunWorkerPool is blocking and therefore
there is no parallelism between the main-thread and the worker pool. The user pro-
cess is not allowed to create threads on its own by using normal POSIX mechanisms
to avoid the risk of inducing indeterministic behavior.
ara::exec::DeterministicClient::RunWorkerPool registers a
runnableObj, along with a container. The container contains a set of
objects, which are processed in parallel by the the container invoked from multiple
workers (e.g. based on POSIX threads) in the pool (see Figure 7.18). This means, the
deterministic worker pool is used to process a set of container elements, which are
the parameters to the runnableObj. Each element in the container represents a
job to be computed. The deterministic distribution of the elements to individual workers
is done by using the container iterator.

84 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01306]{OBSOLETE} processing Container Objects dara::exec::De-

terministicClient::RunWorkerPool shall sequentially (using the iterator of in-
put parameter container) call a method ara::exec::WorkerRunnable::Run
(input parameter runnableObj) on every element of container, by using a worker
pool of size numberOfWorkers.c(RS_EM_00053)
The Worker object passed to ara::exec::DeterministicClient::RunWork-
erPool is an instance of ara::exec::WorkerRunnable. This would typically be
achieved through a sub-class derived from ara::exec::WorkerRunnable using
public inheritance to enable project-specification extensions to be added.
Within ara::exec::DeterministicClient::RunWorkerPool the elements of
container are iteratively processed by the background worker pool. If more ele-
ments are available than workers then sequential processing will occur. In pseudo-
code (ignoring parallelisation) the method ara::exec::DeterministicClient::
RunWorkerPool behaves as follows:
1 std::array<WorkerThread,4> workers;
2

3 template<typename C> ara::core::Result<void>

4 DeterministicClient::RunWorkerPool( WorkerRunnable<typename C::value_type>&
w, C& container) noexcept
5 {
6 ara::core::Result r;
7 int count = 0;
8 auto c = container.begin();
9 while( c != container.end() ) {
10 w.Run( *c++, workers[count++] );
11 count %= workers.size();
12 }
13 return r;
14 }

The implementation and size of the worker pool (i.e. number of threads) is hidden from
the Application. The Integrator decides about the size and the implementation and
configures a parameter numberOfWorkers. The distribution of the worker threads to
processor cores is left to the Operating System.

85 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

iterator

parameter
object
(container)
1st set of 2nd set of
container container
elements elements

worker pool worker worker worker worker

worker
runnable
object

Figure 7.18: Worker Pool Usage

If the number of required container elements exceeds the number of workers (threads)
in the deterministic worker pool, Execution Management can use the worker pool
several times sequentially (with unrestricted interleaving), which shall be transparent
to the user of the worker pool.
To achieve Data Determinism, the parallel workers need to satisfy certain implemen-
tation properties, e.g. no exchange of data is allowed between the instances of the
runnable object which are processed by the workers. For details see [10]. Other, more
complex solutions which allow interaction between the workers would be possible, but
they increase complexity, reduce utilization and transparency, and are error-prone re-
garding the deterministic behavior.
The worker pool runs within the process context of the caller of this API. It is de-
signed as part of Execution Management to guarantee the deterministic behavior
by incorporating it in the ara::exec::DeterministicClient::WaitForActi-
vation cycle.
An example for the implementation of a ara::exec::WorkerRunnable can be
found in [10].
The aim is to abstract the data processing as far as possible, irrespective of the ac-
tual number of available threads. Example: a job with N similar sub-jobs (e.g. N
Kalman-filters). The job is assigned to the worker pool by calling ara::exec::

86 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

DeterministicClient::RunWorkerPool. The workrt pool processes it using a

given runnableObj (in this example the Kalman-filter).
The worker pool cannot be used to process multiple different tasks in parallel. The use
of multiple potentially different explicit functions (runnableObj) could add unneces-
sary complexity and can lead to extremely heterogeneous runtime utilization, as each
runnableObj may have different computing time. This would complicate the planning
of resource deployment, which is necessary for black-box integration.

7.6.3.3 Random Numbers

Execution Management provides the ara::exec::DeterministicClient::

GetRandom [SWS_EM_02225] API to support the distribution of Deterministic
Random Numbers to workers within the worker pool.
If used from within ara::exec::DeterministicClient::RunWorkerPool, the
random numbers are assigned to specific container elements, using the container
iterator, to allow deterministic redundant execution.
The ara::exec::DeterministicClient::SetRandomSeed API can be used to
seed the pseudo random numbers generation to guarantee the deterministic behavior
by incorporating it in the DeterministicClient::WaitForActivation cycle.
Implementations of DeterministicClient which do not need to support redundant
execution can provide standard random numbers without specific properties.

7.6.3.4 Time Stamps

The deterministic user process might need timing information while cyclically (see
7.6.3.1) processing its input data in the kRun cycle. The used time value may have
an influence on the calculated results. Therefore, Execution Management returns
deterministic timestamps that represent the points in time when the current cycle was
activated and when the next cycle will be activated, if this value is known. The times-
tamps are required to be identical for processes which are executed redundantly, e.g.
in a lockstep environment (see 7.6.2).
[SWS_EM_01310]{OBSOLETE} Get Activation Time dExecution Management
shall provide an API ara::exec::DeterministicClient::GetActivation-
Time which returns an ara::exec::DeterministicClient::TimeStamp that
represents the point in time when the current kRun cycle was activated by ara::
exec::DeterministicClient::WaitForActivation (see [SWS_EM_01301]).
Deterministic means, that the timestamps are identical for processes which are exe-
cuted redundantly. Subsequent calls within a cycle shall always return the same value.c
(RS_EM_00053, RS_EM_00113)

87 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01311]{OBSOLETE} Activation Time Unknown dIf ara::exec::De-

terministicClient::GetActivationTime is called from outside a kRun cycle,
Execution Management shall return kNoTimeStamp.c(RS_EM_00053)
[SWS_EM_01312]{OBSOLETE} Get Next Activation Time dara::exec::De-
terministicClient::GetNextActivationTime shall provide a deterministic
timestamp that represents the point in time when the next kRun cycle will be
activated by ara::exec::DeterministicClient::WaitForActivation (see
[SWS_EM_01301]). Deterministic means, that the timestamps are identical for pro-
cesses which are executed redundantly. Subsequent calls within a cycle shall always
return the same value.c(RS_EM_00053, RS_EM_00113)
[SWS_EM_01313]{OBSOLETE} Next Activation Time Unknown dara::exec::
DeterministicClient::GetNextActivationTime shall return kNoTimeStamp
if cycleTimeValue is configured to zero.c(RS_EM_00051, RS_EM_00053, RS_-
EM_00113)

7.6.3.5 Real-Time Resources

To ensure Time Determinism (see 7.6.1.1), i.e. to make sure that a cyclic deterministic
execution within a process (see 7.6.3.1) is finished at a given deadline we need:
• Execution Management supports deterministic multithreading to meet high
performance demand, see 7.6.3.2.
• The integrator needs to assign appropriate resources to the process, see Sec-
tion 7.7.
• The integrator needs to assign appropriate scheduling policies.
• The integrator needs to configure deadline monitoring, possibly execution budget
monitoring.
To make sure that all processes which use the DeterministicClient APIs get
enough computing resources and can finish their cycle in time, it is in particular impor-
tant to know when the worker pool (ara::exec::DeterministicClient::Run-
WorkerPool) is needed within a kInit and kRun ara::exec::Deterministic-
Client::WaitForActivation cycle. Also, a good computing resource utilization
can only be achieved if usage of the workers (i.e. of available cores) can be distributed
evenly over time. If the application code is known to the integrator, it should not be
a problem to analyze the behavior and configure the system accordingly. However,
if third party “black box” applications are delivered for integration, their resource de-
mands need to be described in a standardized way, so the integrator has a rough idea
about the distribution of resource consumption within a ara::exec::Determinis-
ticClient::WaitForActivation-cycle.
To describe budget needs within the kInit and kRun cycle, we use a normalized value
NormalizedInstruction to specify runtime consumption on the target system.

88 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

NormalizedInstruction = runtime in sec * clock frequency in Hz

NormalizedInstruction does not reflect the actual number of code instructions,
but allows the description of comparative resource needs.
The following parameters (DeterministicClientResource, see
[TPS_MANI_01200] in [3]) are relevant for describing the computing time bud-
get needs of a process which uses ara::exec::DeterministicClient::
RunWorkerPool.
The parameters are needed to be specified twice per process which uses De-
terministicClient, once for the kInit cycle and once for the kRun cycles
(DeterministicClientResourceNeeds, and [TPS_MANI_01199]).
• numberOfInstructions [NormalizedInstructions]
This is the normalized runtime consumption on the target system within one cy-
cle, assuming the “worst-case” runtime where the workers would be executed
sequentially.
• speedup = sequental runtime / parallelized runtime
Defines how much faster the calculations within one cycle can be finished if num-
berOfWorkers (see 7.6.3.2) are physically available, i.e. if enough cores were
available on the machine to perform parallel execution of all workers.
• sequentialInstructionsBegin [NormalizedInstructions]
This is the normalized sequential runtime at the beginning of the cycle (which
mostly cannot be parallelized), before the main usage of the worker pool starts.
• sequentialInstructionsEnd [NormalizedInstructions]
This is the normalized sequential runtime at the end of the cycle (which mostly
cannot be parallelized), after the main usage of the worker pool has ended.

Examples

Example 7.5

The process uses the worker pool mainly in the middle of the cycle. The first 100
(normalized) instructions are mostly sequential, the next 275 instructions have a benefit
when using the worker pool, and the last 125 instructions are mostly sequential again.
The average speedup, over the complete 500 instructions is 1.3.
• numberOfInstructions = 500
• numberOfWorkers = 2
• speedup = 1.3
• sequentialInstructionsBegin = 100

89 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• sequentialInstructionsEnd = 125

main main
workers
thread thread

NormalizedInstructions
0 100 375 500
begin of end of
cycle cycle

Figure 7.19: Worker pool used in middle of cycle

Example 7.6

The process runs sequentially throughout most of the cycle and does not benefit in
using the worker pool, i.e. the overhead of using the worker pool compensates the
parallelization gain.
• numberOfInstructions = 200
• numberOfWorkers = 2
• speedup = 1
• sequentialInstructionsBegin = 200
• sequentialInstructionsEnd = 0

main thread

NormalizedInstructions
0 200
begin of end of
cycle cycle

Figure 7.20: No benefit from worker pool

Example 7.7

The process fully utilizes the worker pool throughout the cycle.
• numberOfInstructions = 200
• numberOfWorkers = 3
• speedup = 2.9

90 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• sequentialInstructionsBegin = 0
• sequentialInstructionsEnd = 0

workers

NormalizedInstructions
0 200
begin of end of
cycle cycle

Figure 7.21: Full utilization of worker pool

7.6.4 Deterministic Synchronization

The API ara::exec::DeterministicClient::WaitForActivation is de-

scribed in 7.6.3 as the wait point in deterministic redundant execution. In this sec-
tion, more details on synchronization behaviors will be provided for both periodic and
event-triggered activation in the execution cycles.

7.6.4.1 DeterministicSyncMaster

A DeterministicSyncMaster [TPS_MANI_01406] is 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.
Note that it is not limited to use ara::com or API of other communication channel,
and it is up to the vendor to decide which to use. This specification only describes
the integration with ara::com API for DeterministicSyncMaster. The integration
with other communication APIs is not covered and may be specified in a later release.
Figure 7.22 shows an example of how a DeterministicSyncMaster controls the
synchronization for two DeterministicClients of the application process based
on ara::com interface for request and response communication.

91 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Figure 7.22: Sequence Diagram of the Synchronization Control Messages with single
DeterministicSyncMaster

For event-triggered activation, a specific policy of the synchronization should be pro-

vided. The policy is highly dependent on vendor solution and requirements, for ex-
ample, the synchronization response is sent to the DeterministicClients only if
the synchronization requests from all the processes are received. There can be more
complicated policies, e.g. the match of 2 out of 3 synchronization requests are received
before the given deadline, which is also known as the M-out-of-N (MooN) policy.
For periodic activation, the DeterministicClients require a single synchroniza-
tion for the first ara::exec::DeterministicClient::WaitForActivation call
that is initiated after the execution of kInit or kServiceDiscovery cycle (see
[SWS_EM_01304] for service modification). The activation response includes a global
time stamp for the activation of the first kRun cycle, which should also give a reason-
able time buffer for receiving the activation response for the DeterministicClients
through the channel. All DeterministicClients will count on local time until the
activation time is reached and then starts kRun. Further calls of ara::exec::De-
terministicClient::WaitForActivation will not send any synchronization re-
quest, but just return when the predefined deadline that was configured with cycle-
TimeValue property is reached by the local time counter (see [SWS_EM_01351]).
The handling of missed deadline in the kRun cycles for periodic activation is described
in [SWS_EM_01352].
For both periodic and event-triggered activation, a set of parameters need to be defined
before the DeterministicSyncMaster starts.
[SWS_EM_01320]{OBSOLETE} Number of DeterministicClients dThe number
of DeterministicClients that are connected to the DeterministicSyncMas-
ter shall be defined by attribute numberOfConnectedClients.c(RS_EM_00050,
RS_EM_00051, RS_EM_00053)

92 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01321]{OBSOLETE} Minimum number of required synchronization re-

quests dThe attribute minimumNumberOfRequests shall define the minimum num-
ber of required synchronization requests (from the connected Deterministic-
Clients in the same domain) that are necessary to be received by the Determin-
isticSyncMaster to continue calculation of the next cycle.c(RS_EM_00050, RS_-
EM_00053)
The MooN policy defines a rule for DeterministicSyncMaster to decide when it
should respond to the synchronization requests for next execution cycle. N is the
number of the processes that are connected to the DeterministicSyncMaster
in the same domain ([SWS_EM_01320]), and M is the minimum required synchroniza-
tion requests to be received in the same domain ([SWS_EM_01321]). The usage of
MooN can be modified based on the requirements of the redundant execution. For
example, when M requests are received (M < N ), the DeterministicSyncMas-
ter may ignore the rest of the unreceived requests, and start calculating the cycle
information for the next activation based on the received requests. The cycle informa-
tion is encapsulated into a response message and propagated to all of the connected
DeterministicClients. If M equals N , this means all of the requests from N
DeterministicClients should be received before proceeding to the calculation of
next cycle .
Note that for the current release only MooN policy is described and the configuration
of other policies may be specified in a later release.
[SWS_EM_01322]{OBSOLETE} Calculation of the next cycle dIf verification-
Method is set to DeterministicSyncMOutOfN, DeterministicSyncMaster
shall calculate the next activation time based on the MooN policy and the received
synchronization request. The MooN policy shall use the attribute numberOfConnect-
edClients as N and the attribute minimumNumberOfRequests as M. The received
synchronization request is used as the current valid input (see [SWS_EM_01325]).c
(RS_EM_00050, RS_EM_00053)
The calculated cycle information is sent via a response message to all connected De-
terministicClients (see [SWS_EM_01326]). Based on the response message,
a DeterministicClient triggers the next execution cycle on the activation time by
returning from the ara::exec::DeterministicClient::WaitForActivation
call.
[SWS_EM_01323]{OBSOLETE} Total kRun loop count dIf maxRunCycleLoop is
configured not to be zero, ara::exec::DeterministicClient::WaitForActi-
vation (of the referencing DeterministicClient) shall return kTerminate, after
kRun has been returned maxRunCycleLoop timesc(RS_EM_00053)
[SWS_EM_01324]{OBSOLETE} Infinite kRun loop dOmission of maxRunCycleLoop
configuration or a setting of zero shall indicate an infinite kRun cycle count.c(RS_EM_-
00053)
Note: The data type for storing the kRun loop count is implementation specific.

93 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The current specification of DeterministicSyncMaster supports redundant deter-

ministic execution in single domain. Multiple domains are not part of current specifica-
tion. The DeterministicSyncMaster acts as a Time Slave [TPS_MANI_01409], in
order to receive the global time stamp when it is needed for calculating and distribut-
ing the deterministic time stamps of execution cycles. The processes implemented
with DeterministicClients should be in the same global time domain as the De-
terministicSyncMaster, so they can be synchronized even if they are connected
through network or gateway.
For single domain synchronization, both DeterministicClient and Determinis-
ticSyncMaster can use the local time resource for simplicity and efficiency when
acquiring the current time. The access of the local time can be achieved by calling
ara::core::SteadyClock or, for example, the std::chrono APIs.
The assurance of secure access to the Time Resource should be managed by the Pol-
icy Decision Point (PDP) and Policy Enforcement Point (PEP) configurations for Time
Slave and Master. For example an Access Manager may be able to grant the per-
mission for DeterministicSyncMaster to access the configured Time Master and
Time Resource. As the DeterministicSyncMaster exposes only ara::com and
ara::tsync interfaces, access control to functions of the DeterministicSync-
Master should be enforced using IAM for ara::com and ara::tsync.
When the process is running in the execution cycles, each cycle needs to be
synchronized by calling ara::exec::DeterministicClient::WaitForActi-
vation. The behaviors to synchronize the process and the redundancies should
be performed by the DeterministicSyncMaster, which can be deployed in Execu-
tion Management process, Software Lockstep process or in a separate process.
Figure 7.23 shows an example of running the DeterministicSyncMaster in a sep-
arate process.

Figure 7.23: An example deployment of DeterministicSyncMaster in a separate pro-

cess

The Software Lockstep is an optional framework to ensure identical behavior of the

redundantly executed processes. The Software Lockstep framework does not nec-
essarily interact with DeterministicSyncMaster, but they can be integrated in or-
der to simplify the control logic and reduce the communication effort over ara::com

94 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

or other dedicated communication channels. For example the Software Lockstep may
also need to understand the state of each execution cycle, in order to give more reason-
able and trusty comparison results. Figure 7.24 gives examples of a Software Lockstep
framework in library mode and process mode. Details of Software Lockstep will be
specified in a later release.

Figure 7.24: process mode (left) and library mode (right) integration

For process mode of Software Lockstep, the DeterministicSyncMaster function-

ality can be integrated inside the Software Lockstep as a library. For library mode of
Software Lockstep, it can be integrated into the DeterministicSyncMaster pro-
cess.
Figure 7.25 and 7.26 illustrates examples of the possible ways to integrate Determin-
isticSyncMaster with the Software Lockstep in process mode and library mode
for cross domain with two DeterministicSyncMasters. For both modes, the De-
terministicSyncMasters should be connected via the synchronization channel for
making the final decision. Whether multiple Software Lockstep instances should run in
different domains is not within the scope of this concept as it depends on the deploy-
ment and solution of the vendor based on the available integration possibilities.

Figure 7.25: Library Mode with multiple DeterministicSyncMasters

Figure 7.26: Process Mode with multiple DeterministicSyncMasters

7.6.4.2 Synchronization Control Messages

In this section, we specify the basic elements of the control messages, in order to
run redundant deterministic execution based on platform vendor implementation and
data structure. Dedicated interface(s) and data structure(s) will be specified in a later
release.

95 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_01325]{OBSOLETE} Synchronization Request Message dThe ara::

exec::DeterministicClient::WaitForActivation for a Deterministic-
Client activation shall send a synchronization request message to the connected
DeterministicSyncMaster.c(RS_EM_00050, RS_EM_00051, RS_EM_00053)
A synchronization request should contain at least the following data members:
• Identification: the request needs to provide a unique identification.
• Activation timestamp of the previous cycle: the activation of the previous cycle
is used for calculate the next cycle.
• Code of the current cycle: the type of the current cycle is used to determine the
type of next execution cycle. Possible codes are kServiceDiscovery, kInit,
kRun.
• Count of the current loop: the number of the execution loop is used to
determine when ara::exec::DeterministicClient::WaitForActiva-
tion should return kTerminate.
The concrete structure of the synchronization request/response messages, including
the data types of the members, is platform specific. Additionally, the interface mech-
anism is between two platform specific elements and therefore also platform specific.
In case the interface between DeterministicClient and DeterministicSyncMaster is real-
ized using ara::com communication, the required identification could be a combination
of the service instance ID of the service skeleton in the DeterministicClient/Determin-
isticSyncMaster sending the message and the instance ID of the sending process.
[SWS_EM_01326]{OBSOLETE} Synchronization Response Message dA Deter-
ministicSyncMaster shall send a synchronization response message to all the
connected DeterministicClients when the applied synchronization policy is
matched.c(RS_EM_00050, RS_EM_00051, RS_EM_00053)
A synchronization response should contain at least the following data members:
• Identification: the request needs to provide a unique identification.
• Activation timestamp for the next cycle: The calculated activation timestamp
of the next execution cycle.
• Code of the next cycle: The determined code of the next cycle. Possi-
ble values are kRun, kServiceDiscovery, and kTerminate. A kSer-
viceDiscovery code is returned when a service modification is necessary (see
[SWS_EM_01304]). The code kTerminate indicates the termination of the de-
terministic client and is returned when the total kRun loop count is reached or the
termination is requested by Execution Management (see [SWS_EM_01404]).
As for the request message, the concrete structure, including the data types of the
members, of the response message is platform specific.
[SWS_EM_01327]{OBSOLETE} Return of the wait point API dA ara::exec::
DeterministicClient::WaitForActivation call shall not return until the local

96 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

time counter reaches the activation timestamp that was sent with the response mes-
sage of the synchronization for the next kRun cycle.c(RS_EM_00050, RS_EM_00053)
[SWS_EM_01328]{OBSOLETE} Immediate return from wait point dA "0" value in the
synchronization response message timestamp [SWS_EM_01326] shall indicate that
ara::exec::DeterministicClient::WaitForActivation call shall return im-
mediately.c(RS_EM_00050, RS_EM_00053)

97 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.7 Resource Limitation

Despite the correct behavior of a particular Adaptive Application in the system,
it is important to ensure any potentially incorrect behavior, as well as any unforeseen
interactions cannot cause interference in unrelated parts of the system [RS_SAF_-
10008][11]. As AUTOSAR Adaptive Platform also strives to allow consolidation of
several functions on the same machine, ensuring Freedom From Interference is a key
property to maintain.
However, AUTOSAR Adaptive Platform cannot support all mechanisms as de-
scribed in this overview chapter in a standardized way, because the availability highly
depends on the used Operating System.
In addition, it is important to consider that Execution Management is only respon-
sible for the correct configuration of the Machine. However, enforcing the associated
restrictions is usually done by either the Operating System or another Applica-
tion like the Persistency service.
Some mechanisms that could be standardized will not yet be defined in this release.

7.7.1 Resource Configuration

This section provides an overview on resource assignment to Modelled Processes.

The resources considered in this specification are:
• RAM (e.g. for code, data, thread stacks, heap)
• CPU time
Other resources like persistent storage or I/O usage are also relevant, but are currently
out of scope for this specification.
In general, we need to distinguish between two resource demand values:
• Minimum resources, which need to be guaranteed so the process can reach its
Running state and perform its basic functionality.
• Maximum resources, which might be temporarily needed and shall not be ex-
ceeded at any time, otherwise an error can be assumed.
The following stakeholders are involved in resource management:
• Application Developer
The Application developer should know how much memory (RAM) and comput-
ing resources the Modelled Processes need to perform their tasks within a
specific time. This needs to be specified in the Application description (which
can be the pre-integration stage of the Execution Manifest) which is handed
over to the integrator. Additional constraints like a deadline for finishing a specific
task, e.g. cycle time, will usually also be configured here.

98 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

However, the exact requirements may depend on the specific use case, e.g.
– The RAM consumption might depend on the intended use, e.g. a video filter
might be configurable for different video resolutions, so the resource needs
might vary within a range.
– The computing power required depends on the processor type. i.e. the re-
source demands need to be converted into a computing time on that specific
hardware. Possible parallel thread execution on different cores also needs
to be considered here.
Therefore, while the Application developer should be able to bring estimates re-
garding the resource consumption, a precise usage cannot be provided out of
context.
• Integrator
The integrator knows the specific platform and its available resources and con-
straints, as well as other applications which may run at the same time as the
Modelled Processes to be configured. The integrator should assign avail-
able resources to the applications which can be active at the same time, which
is closely related to State Management configuration, see section 7.5. If not
enough resources are available at any given time to fulfill the maximum resource
needs of all running Modelled Processes, assuming they are actually used
by the Modelled Processes, several steps have to be considered:
– Assignment of resource criticality to Modelled Processes, depending on
safety and functional requirements.
– Depending on the Operating System, maximum resources which cannot be
exceeded by design (e.g. Linux cgroups) can be assigned to a process or a
group of processes.
– A scheduling policy has to be applied, so threads of processes with high
criticality get guaranteed computing time and finish before a given deadline,
while threads of less critical processes might not. For details see section
7.7.3.1.
– If the summarized maximum RAM needs of all processes, which can be
running in parallel at any given time, exceeds the available RAM, this cannot
be solved easily by prioritization, since memory assignment to low critical
processes cannot just be removed without compromising the process.
However, it should be ensured that processes with high criticality have
ready access to their maximum resources at any time, while lower criticality
processes need to share the remaining resources. For details see 7.7.3.4.
Based on the above, all the resource configuration elements are to be configured dur-
ing platform integration, most probably by the Integrator. To group these configuration
elements, we define a ResourceGroup. It may have several properties configured

99 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

to enable restricting Applications running in the group. Subsequently, each Mod-

elled Process is required to belong to a ResourceGroup, clarifying how the Ap-
plication will be constrained at the system level.
[SWS_EM_02102] Memory control dExecution Management shall use Re-
sourceGroup.memUsage to configure the maximum amount of RAM available for
all processes in the ResourceGroup before loading any process from the Re-
sourceGroup.c(RS_EM_00005)
If a ResourceGroup does not have a configured RAM limit, then the processes are
only bound by their implicit memory limit.
[SWS_EM_02103] CPU usage control dExecution Management shall use Re-
sourceGroup.cpuUsage to configure the maximum amount of CPU time available
for all processes in each ResourceGroup before loading any process from the
ResourceGroup.c(RS_EM_00005)
If ResourceGroup does not have a configured CPU usage limit, then the processes
are only bound by their implicit CPU usage limit (priority, scheduling scheme...).
Because scheduling is done in very different ways depending on the Operating
System, the specific algorithm for scheduling as well as limiting the CPU usage is
not described [SWS_OSI_02002].
The intention of ResourceGroup is that limits are never reached and the Resource-
Group limits shall be configured by the integrator, based on measurement, not worst-
case execution time.

7.7.2 Resource Monitoring

As far as technically possible, the resources which are actually used by a process
should be controlled at any given time. For the entire system, the monitoring part of
this activity is fulfilled by the Operating System. For details on CPU time monitoring
see 7.7.3.1. For RAM monitoring see 7.7.3.4. The monitoring capabilities depend on
the used Operating System. Depending on system requirements and safety goals,
an appropriate Operating System has to be chosen and configured accordingly, in
combination with other monitoring mechanisms (e.g. for execution deadlines) which
are provided by Platform Health Management.
Resource monitoring can serve several purposes, e.g.
• Detection of misbehavior of the monitored process to maintain the provided
functionality and guarantee functional safety.
• Protection of other parts of the system by isolating the erroneous processes
from unaffected ones to avoid resource shortage.
For processes which are attempting to exceed their configured maximum resource
needs (see 7.7.1), one of the following alternatives is valid:

100 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• The resource limit violation is considered as a failure and recovery actions may
need to be initiated. Therefore the specific violation gets reported to the State
Management, which then starts recovery actions.
• If the OS provides a way to limit resource consumption of a process or a group
of processes by design, explicit external monitoring is usually not necessary
and often not even possible. Instead, the limitation mechanisms make sure that
resource availability for other parts of the system is not affected by failures within
the enclosed processes. When such by-design limitation is used, monitoring
mechanisms may still be used for the benefit of the platform, but are not re-
quired. Self-monitoring and out-of-process monitoring is currently out-of-scope in
AUTOSAR Adaptive Platform.

7.7.3 Application-level Resource Configuration

We need to be able to configure minimum, guaranteed resources (RAM, computing

time) and maximum resources. In case Time or Full Determinism is required, the
maximum resource needs are guaranteed.

7.7.3.1 CPU Usage

CPU usage is represented in a process by its threads. Generally speaking, Operat-

ing Systems use some properties of each thread’s configuration to determine when
to run it, and additionally constrain a group of threads to not use more than a defined
amount of CPU time. Because threads may be created at runtime, only the first thread
can be configured by Execution Management.

7.7.3.2 Core Affinity

[SWS_EM_02104] Core affinity dExecution Management shall configure the Core

affinity of the process initial thread (restricting it to a sub-set of cores in the sys-
tem) based on the configuration ProcessToMachineMapping.shallRunOn and
ProcessToMachineMapping.shallNotRunOn.c(RS_EM_00008)
Requirement [SWS_EM_02104] permits the initial thread (the “main” thread of the pro-
cess) to be bound to certain cores [SWS_OSI_01012]. Depending on the capabilities
of the Operating System the sub-set could be a single core. If the Operating
System does not support binding to specific cores then the only supported sub-set is
the entire set of cores.

101 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.7.3.3 Scheduling

Currently available POSIX compliant Operating Systems offer the scheduling poli-
cies required by POSIX, and in most cases additional, but different and incompatible
scheduling strategies. This means for now, the required scheduling properties need to
be configured individually, depending on the chosen OS.
Moreover, scheduling strategy is defined per thread and the POSIX standard al-
lows for modifying the scheduling policy at runtime for a given thread, using
pthread_setschedparam(). It is therefore not currently possible for the AUTOSAR
Adaptive Platform to enforce a particular scheduling strategy for an entire pro-
cess, but only for its first thread.
[SWS_EM_01014] Scheduling policy dExecution Management shall configure the
process scheduling policy (when launching a process) based on the relevant config-
uration StartupConfig.schedulingPolicy.c(RS_EM_00002)
For the detailed definitions of these policies, refer to [12]. Note, SCHED_OTHER shall be
treated as non real-time scheduling policy, and actual behavior of the policy is imple-
mentation specific. It should not be assumed that the scheduling behavior is compatible
between different AUTOSAR Adaptive Platform implementations, except that it is
a non real-time scheduling policy in a given implementation.
• [SWS_EM_01041] Scheduling FIFO dExecution Management shall be able
to configure FIFO scheduling using policy SCHED_FIFO.c(RS_EM_00002)
• [SWS_EM_01042] Scheduling Round-Robin dExecution Management shall
be able to configure round-robin scheduling using policy SCHED_RR.c(RS_EM_-
00002)
• [SWS_EM_01043] Scheduling Other dExecution Management shall be able
to configure non real-time scheduling using policy SCHED_OTHER.c(RS_EM_-
00002)
Note that the Scheduling Policies specified here are the minimal set. Depending on the
OS there may be more Scheduling Policies configurable.
While scheduling policies are not a sufficient method to guarantee Full Determinism,
they contribute to improve it. While the aim is to limit CPU time for a process, schedul-
ing policies apply to threads.
Note that while Execution Management will ensure the proper configuration for the
first thread (that calls the main() function), it is the responsibility of the process itself
to properly configure secondary threads.
[SWS_EM_01015] Scheduling priority dExecution Management shall support the
configuration of a scheduling priority when launching a process based on the relevant
configuration StartupConfig.schedulingPriority.c(RS_EM_00002)

102 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The available priority range and actual meaning of the scheduling priority depends
on the selected scheduling policy, see [constr_1692], [TPS_MANI_01061] and [TPS_-
MANI_01188] in [3].

7.7.3.3.1 Resource Management

In general, for deterministic behavior the required computing time is guaranteed and
violations are treated as errors, while best-effort subsystems are more robust and might
be able to mitigate sporadic violations, e.g. by continuing the calculation at the next
activation, or by providing a result of lesser quality. This means, if time (e.g. deadline
or runtime budget) monitoring is in place, the reaction on deviations is different for
deterministic and best-effort subsystems.
In fact, it may not even be necessary to monitor best-effort subsystems, since they by
definition are doing only a function that may not succeed. This leads to an architecture
where monitoring is an optional property.
The remaining critical property however is to guarantee that a particular process or set
of processes cannot adversely affect the behavior of other processes.
To guarantee Full Determinism for the entire system, it is important to ensure Free-
dom From Interference, which the ResourceGroup contribute to ensure through the
optional partitioning of available CPU and memory for the processes mapped to the
group [SWS_EM_02108].
[SWS_EM_02106] ResourceGroup assignment dExecution Management shall
configure the process according to its ResourceGroup membership.c(RS_EM_-
00005)

7.7.3.4 Memory Budget and Monitoring

processes require memory for their execution (e.g. code, data, heap, thread stacks).
Over the course of its execution however, not all of this memory is required at all times,
such that an OS can take advantage of this property to make these ranges of memory
available on-demand, and provide them to other processes when the memory is no
longer used.
While this has clear advantages in terms of system flexibility as well as memory effi-
ciency, it is also in the way of both Time Determinism and Full Determinism: when a
range of memory that was previously unused should now be made available, the OS
may have to execute some amounts of potentially-unbounded activities to make this
memory available. Often, the reverse may also be happening, removing previously
available (but unused) memory from the process under scope, to make it available to
other processes. This is detrimental to an overall system determinism.

103 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Execution Management should ensure that the entire memory range that determin-
istic processes may be using is available at the start and for the whole duration of the
respective process execution.
Applications not configured to be deterministic may be mapped on-demand.
In order to provide sufficient memory at the beginning of the execution of a process,
some properties may need to be defined for each process.
[SWS_EM_02108] Maximum memory usage dExecution Management shall con-
figure the Maximum memory usage of the process according to the configuration
item Process.stateDependentStartupConfig.resourceConsumption.memo-
ryUsage.c(RS_EM_00005)

<< Process >> << Process >>

Process A, which should be Process B, which provides basic
limited functionality (e.g. sockets,
filesystem, …)

Address Space Does not contain Address Space

effects on other
Memory Usage processes
Main Thread Stack Main Thread Stack
Stack1 Stack1
… …
<<use>>, e.g. open() or socket()
Stackn Stackn
via IPC

Heap
Heap Process A Maintenance
Data
BSS
BSS
Data
Data
Text/Code
Text/Code

Figure 7.27: Memory Usage.

The resourceConsumption.memoryUsage is the amount of memory which can be

allocated by the process itself. Please be aware, depending on the OS and its con-
figuration this does not necessarily contain all the memory the process can allocate
within the system. For example in an OS where common functionality like a file system
is implemented on process level, the restricted process might still lead to memory
allocations within the process providing the file system.
On POSIX OS the memory limit is typically restricted by the resource RLIMIT_AS.
[SWS_EM_02109] process pre-mapping dExecution Management shall pre-map
a process if Process.preMapping is set to true.c(RS_EM_00005)
Fully pre-mapping a Modelled Process ensures that code and data execution is
not going to be delayed at its first execution by demand-loading. This helps providing
Time Determinism during system startup and first execution phases, but also helps

104 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

with safety where code handling error cases can be preloaded and made guaranteed
to be available. In addition, pre-mapping avoids late issues where filesystem may be
corrupted and part of the Modelled Process may not be loadable anymore.

7.7.3.5 Working Folder

The working folder of a process is not defined by configuration but rather is deliberately
left as an implementation-specific element. The required PSE51 POSIX profile does
not define that an (Adaptive) Application may use the path or file argument for any
function using a file pathname (e.g., open), instead only to specify the name of the
object without any file system semantics implied.
The PSE51 POSIX profile does not require the existence of a file system. Conse-
quently, paths in Adaptive Applications merely identify objects (e.g. in calls
to open() or stat()). The usage of sub-parts of a given path (e.g. "/data" when
"/data/config.dat" was given) is implementation-defined.

105 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.8 Fault Tolerance

7.8.1 Introduction

What is Fault-Tolerance?
The method of coping with faults within a large-scale software system is termed fault
tolerance.
The model adopted for Execution Management is outlined in [13].
This section provides context to the application of fault tolerance concepts with respect
to Execution Management and perspective on how this contributes in overall plat-
form instance’s dependability.
Platform-wide Service Oriented Architecture fault tolerance aspects are outside the
scope of this document and are not further addressed.

7.8.2 Scope

Execution Management has a crucial influence on overall system behavior of the

AUTOSAR Adaptive Platform.
The effect of erroneous functionality, within Execution Management can have very
different severity depending on operational mode and fault type. For example, a fault
identified by Execution Management may have a local effect, influencing an inde-
pendent process only, or may become a root cause for a Machine wide failure.
It is therefore necessary not to specify only correct behavior but also to introduce alter-
native behavior in case of deviations.
Such mechanisms address a broad spectrum of concerns that emerge during Ma-
chine and process Life Cycle Management.
The AUTOSAR Adaptive Platform architecture is composed of two levels; Appli-
cation and Platform Instance. The Application level constitutes cooperative
Applications intended to satisfy overall system’s needs and objectives and repre-
sents a service level in vehicle context. The Platform Instance level as a reusable
asset providing basic capabilities and platform level services. Fault tolerance within
Execution Management is therefore required to handle both levels.

7.8.3 Threat Model

The main threats which leading to incorrect behavior of software - whether Appli-
cation or Platform Instance - is the presence of systematic defects or faults
i.e. those incorporated during design phase and remaining dormant untill deployment.
Other sources of faults include physical faults, e.g. random hardware failures, that

106 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

might influence resource allocation and correct execution, and interraction faults which
can be a source for incorrect state transition requests.

Figure 7.28: General Fault Tolerance scheme.

From the perspective of Execution Management, fault activation occures when re-
sulting Function Group State or combination of such is requested. Due to the
different nature of faults, these can lead to various types of deviations from expected
functional behavior and finally result in erroneous system functionality either in terms
of correct computational results or timing response.
In general, the implementation of fault tolerance mechanism is based on two consistent
steps - Error Detection and subsequent Error Recovery. The major focus of
Error Detection during Design Phase activities and thus the focus of Fault
Tolerance in this specification is on the analysis of potential Failure Modes and
the consequent error detection mechanisms that should later be incorporated into the
implementation.
In contrast, Error Recovery consists of actions that should be taken in order to
restore the system’s state where the system can once again perform correct service
delivery. Binding of Error Detection and Recovery Actions should be a subject
of platform wide fault tolerance model.
Remark:The remainder of this section is the subject for elaboration for the next release
of this specification. Provision for fault-tolerance mechanisms will consider possible
faults, how they can lead to errors within Execution Management and the mecha-
nisms that are introduced to ensure error detection.

7.8.4 Execution Management internal Error handling

From System design point of view it is useful to have an Execution Management/OS

internal Unrecoverable State, which can be entered by Execution Manage-
ment when it has no other course of action. The Unrecoverable State is only
triggered by Execution Management.
[SWS_EM_02032] On entry to the Unrecoverable State, dExecution Man-
agement shall invoke a pre-cleanup action.c(RS_EM_00150)
[SWS_EM_02033] After execution of the pre-cleanup action, dall processes man-
aged by Execution Management shall be shutdown.c(RS_EM_00150)

107 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02034] After all processes managed by Execution Management ter-

minated, da post-cleanup action shall be called.c(RS_EM_00150)
The mechanism for invoking pre- and post-cleanup function is Platform specific. There
is no requirement on which actions should be taken at each stage.
It is not possible to give an exhaustive of list of when the Unrecoverable State
is entered. Potential examples when the Unrecoverable State should be entered
include:
• The underlying OS is not functioning as expected – for example failure of
SIGKILL (i.e. Execution Management cannot kill processes).
• Execution Management has lost the ability to read the processed manifest,
i.e. nothing can be started / stopped.
• Execution Management cannot deliver responses (i.e. result of the requested
Function Group state transitions) to State Management. Essentially Exe-
cution Management will never respond back to SM for technical reasons.
• Trusted platform configuration cannot be read meaning Execution Manage-
ment does not know it should run in a strictMode or monitorMode.
Note: Unrecoverable State should not be entered if Execution Management
can normally communicate with State Management – in this case it is State Man-
agement’s responsibility to handle system errors (i.e. failed startup attempts).

108 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

7.9 Security

7.9.1 Trusted Platform

From a security perspective, it is essential that all software executed on the Adaptive
Platform is trusted, i.e. the integrity and authenticity of the software is ensured.
Execution Management - as the entity responsible for process creation - has to
take over this task.
A key requirement for a trusted Adaptive Platform is a Trust Anchor on the Machine
that is authentic by definition (hence that alternative name, "root of trust"). A Trust
Anchor is often realized as a public key stored in a secure environment, e.g. in non-
modifiable persistent memory or in an HSM. The trust has to be passed to Execution
Management by appropriate means, e.g. by a chain of trust. If the Machine does not
exhibit a Trust Anchor, it cannot be ensured that the Adaptive Platform is trusted.
[SWS_EM_02299] Availability of a Trust Anchor dIf there is no Trust Anchor avail-
able on the Machine, the following requirements may be ignored: [SWS_EM_02300],
[SWS_EM_02301], [SWS_EM_02302], [SWS_EM_02303], [SWS_EM_02305],
[SWS_EM_02306], [SWS_EM_02307], [SWS_EM_02308], [SWS_EM_02309].c
(RS_EM_00014)
There are many ways to verify the integrity and authenticity of the Adaptive Platform.
A Trusted Platform can be realized e.g. (but not limited to) by
• Verification of the complete Ramdisk by the Bootloader
• Verification of individual Executables and data files, e.g. using OS-
functionalities or a trusted third-party process
• Verification of individual memory pages upon being loaded, e.g. using OS-
functionalities or a trusted third-party process
[SWS_EM_02300] Integrity and Authenticity of Machine configuration dExecu-
tion Management shall ensure that the integrity and authenticity of Machine informa-
tion from the processed Manifests are checked before use.c(RS_EM_00014, RS_-
EM_00015)
[SWS_EM_02301] Integrity and Authenticity of each Executable dExecution
Management shall ensure that for every process that is about to be started, the in-
tegrity and authenticity of the Executable itself are checked.c(RS_EM_00014, RS_-
EM_00015)
[SWS_EM_02302] Integrity and Authenticity of shared objects dExecution Man-
agement shall ensure that for every process that is about to be started, the integrity
and authenticity of each related shared object are checked.c(RS_EM_00014, RS_-
EM_00015)
[SWS_EM_02303] Integrity and Authenticity of processed Execution Manifest
configurations dExecution Management shall ensure that for every process that

109 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

is about to be started, the integrity and authenticity of its corresponding processed

Manifests are checked.c(RS_EM_00014, RS_EM_00015)
The information validated by [SWS_EM_02303] includes all manifest information, e.g.
Service Instance information, and not just the information directly used by Execution
Management.
From a security perspective, the rationale for choosing these items is as follows:
• Executables: Modifying the Executable itself allows an attacker to execute ar-
bitrary code on the machine;
• Manifests: Machine Manifests, Execution Manifests and Service
Instance Manifests describe what and how something should be executed
and are thus an obvious attack vector on the Adaptive Platform;
• Shared Objects: Shared objects can either contain code that is executed within
the context of the process or data that (potentially) influences the execution of
a process accessing this data. A modified shared object could consequently be
used to compromise the system.
In order to establish a Trusted Platform, it must be ensured that only trusted soft-
ware is launched. Therefore, a system designer has to ensure that Execution Man-
agement is started authentically. For instance, this could be realized by a chain of trust
as described in [14].
Execution Management in turn has to ensure that all Executable code on the
Adaptive Platform is authenticated before being executed. The complete authenticated
start-up sequence looks like this:

110 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Trust Anchor authenticates and starts Bootloader

Bootloader authenticates and starts OS

OS authenticates and starts Execution Management

Execution Management authenticates the Processed Manifests, reads

them and determines the application startup order based on the
dependency description.

Other Adaptive Platform Foundation modules are also started as

they are Applications described with Manifests

After successful authentication of Execution Manifest and Application

Executables, processes of Application Executables are instantiated
based on the startup order.

Figure 7.29: Authenticated start-up sequence

The integrity and authenticity of persistent data stored by applications is not considered
here. The Functional Cluster Persistency takes care of the integrity of this data.

7.9.1.1 Handling of failed authenticity checks

If the integrity and authenticity has been verified successfully, the system has to con-
tinue with its regular start-up process. If the integrity and authenticity check has failed,
however, Execution Management offers a configuration option on how to proceed
with the start-up process.
[SWS_EM_02305] Failed authenticity checks dExecution Management shall
select the trusted platform mode based on the value of Machine.trustedPlat-
formExecutableLaunchBehavior.c(RS_EM_00014, RS_EM_00015)
The configuration of the three modes is done via the trustedPlatformExe-
cutableLaunchBehavior attribute within the Processed Manifest. The config-
uration option is only allowed to be processed after the integrity and authenticity of the
relevant Processed Manifest has been verified.
These three modes of the Machine.trustedPlatformExecutableLaunchBe-
havior are:

111 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

• monitorMode
• noTrustedPlatformSupport
• strictMode
[SWS_EM_02306]{DRAFT} Launch Behavior Validation dExecution Manage-
ment shall stop the start-up sequence of the Adaptive Platform if the integrity or au-
thenticity check of the Processed Manifest containing the trustedPlatformEx-
ecutableLaunchBehavior selection has failed and switch to the unrecoverable
state.c(RS_EM_00014, RS_EM_00015)
The integrity and authenticity check applies to all trusted platform modes; to do oth-
erwise would leave the system open to attacks that maliciously corrupt the Manifest
information. Reaction to a failure is limited as, by definition, no Adaptive Applications
other than Execution Management are running and hence are restricted to imple-
mentation defined actions such as OS-level logging.

7.9.1.1.1 Monitor Mode

In monitorMode, the integrity and authenticity checks are performed, but the start-up
process is not affected. Hence, the Adaptive Platform starts up even if the file system
has been compromised.
[SWS_EM_02556] Monitor Mode dIn monitorMode, if a check ([SWS_EM_02300],
[SWS_EM_02301], [SWS_EM_02302] and [SWS_EM_02303]) fails then Execution
Management shall log the failure and continue regular startup of the Adaptive Plat-
form.c(RS_EM_00014, RS_EM_00015)
monitorMode is useful when the integrator wants the system to keep running, even if
the platform is not considered trusted. In this case, the integrator might use additional
measures outside the scope of Adaptive AUTOSAR, like e.g. restricted key access
when using an HSM that supports this feature.
monitorMode is also useful during development phase, when frequent changes on
the Adaptive Platform are performed and keeping the authentication tag (e.g. signa-
tures) valid is a tedious task.

7.9.1.1.2 Strict Mode

In strictMode, the Adaptive Platform ensures that no processes are executed,

where the integrity and authenticity of the corresponding Executable, manifests or
linked library could not be verified.

112 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02307]{DRAFT} Strict Mode - Execution manifest dIn strictMode,

Execution Management shall not initiate the execution of an Executable if the in-
tegrity or authenticity check of the corresponding processed Execution Manifest
has failed.c(RS_EM_00014)
[SWS_EM_02308]{DRAFT} Strict Mode - Service Instance manifests dIn strict-
Mode, Execution Management shall not initiate the execution of an Executable if the
integrity or authenticity check of at least one of the corresponding processed Service
Instance Manifests has failed.c(RS_EM_00014)
[SWS_EM_02309]{DRAFT} Strict Mode - Executables dIn strictMode, Execu-
tion Management shall start a process only if the integrity and authenticity of the
corresponding Executable was successfully verified.c(RS_EM_00014)
Executable code can be provided by executables and by statically linked shared objects
linked by the executable. Execution Management cannot determine dynamically
linked shared objects and thus these needs to be validated through an alternative,
implementation specific, mechanism.
Example: Consider an Adaptive Platform in strictMode. Execution Management
has started several Executables after successfully verifying the integrity and authen-
ticity of the Executable, its related shared objects and its processed Execution
Manifest. Now, Execution Management wants to start another Executable,
where the authenticity check has failed. Execution Management does not launch
this Executable, because it is not trusted. The other Executables that passed the
authenticity check may however continue to run. When Execution Management at-
tempts to start another Executable it can be started as long as all authenticity checks
are passed.

7.9.2 Identity and Access Management

Following the "Principle of Least Privilege", Identity and Access Management (IAM)
[15] was introduced in the Adaptive Platform. IAM allows to assign permissions to Mod-
elled Processes for accessing public Interfaces from Functional Clusters. Hence,
Modelled Processes have to be identifiable during runtime in order to lookup and
enforce permissions accordingly.
Execution Management starts processes based on Modelled Processes.
Hence Execution Management is able to maintain the association between the two.
Execution Management supports IAM by revealing information about this associ-
ation. This allows IAM to authenticate processes during runtime with the help of the
operating system and Execution Management.
[SWS_EM_02400] Properties of IAM-configuration assigned to processes dExe-
cution Management shall associate the identity of a specific Modelled Process
with the identity of the corresponding process during process creation.c(RS_EM_-
00111, RS_EM_00015)

113 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

The form of identity is implementation specifc but could, for example, be the process
identifier, a cryptographic token, user ID, etc.
Based on implementation requirements, Execution Management may expose inter-
faces that allow IAM to retrieve information about the association between process
and Modelled Process identity. The exact form of this interface is implementation
defined.

114 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8 API specification

8.1 Type Definitions

8.1.1 ExecutionState

[SWS_EM_02000] Definition of API enum ara::exec::ExecutionState d

Kind: enumeration
Header file: #include "ara/exec/execution_client.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecutionState
Underlying type: std::uint8_t
Syntax: enum class ExecutionState : std::uint8_t {...};
Values: kRunning= 0 After a Process has been started by Execution Management, it
reports ExecutionState kRunning.
Description: Defines the internal states of a Process (see 7.3.1). Scoped Enumeration of uint8_t .

c(RS_EM_00103, RS_AP_00134)
Please note that ExecutionState includes only states reportable by the process to
Execution Management and therefore does not include enumerations e.g. the "Ini-
tializing" state mentioned in figure 7.3 and 7.13, which are an implied states for Exe-
cution Management. The Initializing state starts when process is first scheduled
(so no code executed yet) and ends when kRunning is reported ([SWS_EM_01004]).
The Terminating state starts when termination is requested by Execution Manage-
ment and ends when the process terminates ([SWS_EM_01404]). For the reasons
mentioned, Execution Management assumes that process is in initializing state
until kRunning will be reported by it.

8.1.2 ActivationReturnType

[SWS_EM_02201]{OBSOLETE} Definition of API enum ara::exec::ActivationRe-

turnType d
Kind: enumeration
Header file: #include "ara/exec/deterministic_client.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ActivationReturnType
Underlying type: std::uint32_t
Syntax: enum class ActivationReturnType : std::uint32_t {...};
5

115 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Values: kRegisterServices= 0 application shall register communication services(this must be the
only occasion for performing service registering)
kServiceDiscovery= 1 application shall do communication service discovery (this must be
the only occasion for performing service discovery)
kInit= 2 application shall initialize its internal data structures (once)
kRun= 3 application shall perform its normal operation
kTerminate= 4 deterministic execution shall terminate
Description: Defines the return codes for WaitForActivation operations. Scoped Enumeration of uint32_t .

c(RS_EM_00052, RS_AP_00122, RS_AP_00143, RS_AP_00129, RS_AP_00154)

8.1.3 DeterministicClient::TimeStamp

[SWS_EM_02203]{OBSOLETE} Definition of API type ara::exec::Deterministic

Client::TimeStamp d
Kind: type alias
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: TimeStamp
Syntax: using TimeStamp = std::chrono::time_point<ara::core::SteadyClock>;
Description: Time stamp of deterministic cycles .

c(RS_EM_00052, RS_EM_00053, RS_AP_00122, RS_AP_00127)

8.1.4 ExecutionError

[SWS_EM_02541]{DRAFT} Definition of API type ara::exec::ExecutionError d

Kind: type alias
Header file: #include "ara/exec/execution_error_event.h"
Scope: namespace ara::exec
Symbol: ExecutionError
Syntax: using ExecutionError = std::uint32_t;
Description: Represents the execution error.

c(RS_EM_00101, RS_AP_00122, RS_AP_00154)

116 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.1.5 ExecutionErrorEvent

[SWS_EM_02544] Definition of API class ara::exec::ExecutionErrorEvent d

Kind: struct
Header file: #include "ara/exec/execution_error_event.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecutionErrorEvent
Syntax: struct ExecutionErrorEvent final {...};
Description: Represents an execution error event which happens in a Function Group.

c(RS_EM_00101, RS_AP_00116, RS_AP_00122, RS_AP_00124, RS_AP_00140,

RS_AP_00154)

8.1.5.1 ExecutionErrorEvent::executionError

[SWS_EM_02545]{DRAFT} Definition of API variable ara::exec::ExecutionError

Event::executionError d
Kind: variable
Header file: #include "ara/exec/execution_error_event.h"
Scope: struct ara::exec::ExecutionErrorEvent
Symbol: executionError
Type: ExecutionError
Syntax: ExecutionError executionError;
Description: The execution error of the Process which unexpectedly terminated .

c(RS_EM_00101, RS_AP_00124)

8.1.5.2 ExecutionErrorEvent::functionGroup

[SWS_EM_02546]{DRAFT} Definition of API variable ara::exec::ExecutionError

Event::functionGroup d
Kind: variable
Header file: #include "ara/exec/execution_error_event.h"
Scope: struct ara::exec::ExecutionErrorEvent
Symbol: functionGroup
Type: ara::core::StringView
Syntax: ara::core::StringView functionGroup;
Description: The function group in which the error occurred .

c(RS_EM_00101, RS_AP_00124)

117 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2 Class Definitions

As specified in [4] AUTOSAR Adaptive Platform requires initialization and deinitial-
ization, see [SWS_CORE_10001] and [SWS_CORE_10002]. Usage of Execution
Management API before a call to ara::core::Initialize, or after ara::core::
Deinitialize will result in implementation defined behavior, see [SWS_CORE_-
90022] and [SWS_CORE_15005].
[SWS_EM_02557]{DRAFT} dThe Execution Management shall use ara::
core::Initialize and ara::core::Deinitialize and no cluster specific
(de)initialization functions.c(RS_AP_00155, RS_AP_00149)

8.2.1 ExecutionClient class

The Execution State API provides the functionality for a process to report its state to
the Execution Management.
[SWS_EM_02001] Definition of API class ara::exec::ExecutionClient d
Kind: class
Header file: #include "ara/exec/execution_client.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecutionClient
Syntax: class ExecutionClient final {...};
Description: Class to implement operations on Execution Client.
Notes: To eventually implement the Named Constructor Idiom, the developer may either make the
default constructor private or delete it and define a non-default constructor.

c(RS_EM_00103, RS_AP_00154, RS_AP_00150)

8.2.1.1 ExecutionClient::ExecutionClient

[SWS_EM_02560]{DRAFT} Definition of API function ara::exec::Execution

Client::ExecutionClient d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: ExecutionClient(std::function< void()> terminationHandler)
Syntax: ExecutionClient (std::function< void()> terminationHandler);
5

118 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Parameters (in): terminationHandler Callback which is called if ExecutionClient receives SIGTERM
signal. The callback is executed in a background thread. A typical
implementation of this callback will set a global flag (and potentially
unblock other threads) to perform a graceful termination. The
lifetime of the given function has to exceed the lifetime of the
ExecutionClient object.
Exception Safety: not exception safe
Errors: ara::exec::ExecErrc::k Communication error occurred.
CommunicationError
ara::exec::ExecErrc::k Given terminationHandler doesn’t contain a callable function.
InvalidArgument
Description: Regular constructor for ExecutionClient.

c(RS_EM_00103, RS_AP_00114, RS_AP_00119, RS_AP_00120, RS_AP_00121,

RS_AP_00151)

8.2.1.2 ExecutionClient::Create

[SWS_EM_02562]{DRAFT} Definition of API function ara::exec::Execution

Client::Create d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: Create(std::function< void()> terminationHandler)
Syntax: static ara::core::Result< ExecutionClient > Create (std::function<
void()> terminationHandler) noexcept;
Parameters (in): terminationHandler Callback which is called if ExecutionClient receives SIGTERM
signal. The callback is executed in a background thread. A typical
implementation of this callback will set a global flag (and potentially
unblock other threads) to perform a graceful termination. The
lifetime of the given function has to exceed the lifetime of the
ExecutionClient object.
Return value: ara::core::Result< a result that contains either a ExecutionClient object or an error.
ExecutionClient >
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::k Communication error occurred.
CommunicationError
ara::exec::ExecErrc::k Given terminationHandler doesn’t contain a callable function.
InvalidArgument
Description: Named constructor for ExecutionClient.
Notes: This named constructor may call a constructor defined by the developer.

c(RS_AP_00119, RS_AP_00120, RS_AP_00128, RS_AP_00132, RS_AP_00139,

RS_AP_00144, RS_EM_00103)

119 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.1.3 ExecutionClient::~ExecutionClient

[SWS_EM_02002] Definition of API function ara::exec::Execution

Client::~ExecutionClient d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: ~ExecutionClient()
Syntax: ~ExecutionClient () noexcept;
Exception Safety: noexcept
Description: noexcept destructor

c(RS_AP_00134, RS_AP_00145, RS_EM_00103)

8.2.1.4 ExecutionClient::ExecutionClient (deleted Copy Constructor)

[SWS_EM_02563]{DRAFT} Definition of API function ara::exec::Execution

Client::ExecutionClient d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: ExecutionClient(const ExecutionClient &)
Syntax: ExecutionClient (const ExecutionClient &)=delete;
Description: Suppress default copy construction for ExecutionClient.

c(RS_AP_00145, RS_EM_00103)

8.2.1.5 ExecutionClient::operator= (deleted Copy assignment operator)

[SWS_EM_02564]{DRAFT} Definition of API function ara::exec::Execution

Client::operator= d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: operator=(const ExecutionClient &)
Syntax: ExecutionClient & operator= (const ExecutionClient &)=delete;
Description: Suppress default copy assignment for ExecutionClient.

c(RS_AP_00145, RS_EM_00103)

120 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.1.6 ExecutionClient::ExecutionClient (use of default move constructor)

[SWS_EM_02580]{DRAFT} Definition of API function ara::exec::Execution

Client::ExecutionClient d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: ExecutionClient(ExecutionClient &&rval)
Syntax: ExecutionClient (ExecutionClient &&rval) noexcept;
Parameters (in): rval reference to move
Exception Safety: noexcept
Description: Intentional use of default move constructor for ExecutionClient.

c(RS_AP_00145, RS_AP_00151, RS_EM_00103)

8.2.1.7 ExecutionClient::operator= (use of default move assignment)

[SWS_EM_02581]{DRAFT} Definition of API function ara::exec::Execution

Client::operator= d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: operator=(ExecutionClient &&rval)
Syntax: ExecutionClient & operator= (ExecutionClient &&rval) noexcept;
Parameters (in): rval reference to move
Return value: ExecutionClient & the new reference
Exception Safety: noexcept
Description: Intentional use of default move assignment for ExecutionClient.

c(RS_AP_00145, RS_AP_00151, RS_EM_00103)

8.2.1.8 ExecutionClient::ReportExecutionState

[SWS_EM_02003] Definition of API function ara::exec::ExecutionClient::Report

ExecutionState d
Kind: function
Header file: #include "ara/exec/execution_client.h"
Scope: class ara::exec::ExecutionClient
Symbol: ReportExecutionState(ExecutionState state)
Syntax: ara::core::Result< void > ReportExecutionState (ExecutionState state)
const noexcept;
5

121 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Parameters (in): state Value of the Execution State
Return value: ara::core::Result< void > An instance of ara::core::Result. The instance holds an ErrorCode
containing either one of the specified errors or a void-value.
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::k Communication error between Application and Execution
CommunicationError Management, e.g. unable to report state for Non-reporting Process.
ara::exec::ExecErrc::k Invalid transition request (e.g. to Running when already in Running
InvalidTransition state)
Description: Interface for a Process to report its internal state to Execution Management.

c(RS_EM_00103, RS_AP_00119, RS_AP_00120, RS_AP_00121, RS_AP_00128,

RS_AP_00132, RS_AP_00139)

8.2.2 WorkerRunnable class

Please note that all requirements in this chapter have been set to obsolete.
The WorkerRunnable class provides a base-class defining the expected interface for
DeterministicClient worker definition.
[SWS_EM_02510]{OBSOLETE} Definition of API class ara::exec::Worker
Runnable d
Kind: class
Header file: #include "ara/exec/worker_runnable.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: WorkerRunnable
Syntax: template <typename ValueType>
class WorkerRunnable {...};
Template param: typename ValueType Value type of Container passed to DeterministicClient::RunWorker
Pool
Description: Base-class for implementation of worker runnable for Deterministic Client.

c(RS_EM_00052, RS_AP_00116, RS_AP_00122, RS_AP_00154, RS_AP_00150)

8.2.2.1 WorkerRunnable::Destructor

[SWS_EM_02512]{OBSOLETE} Definition of API function ara::exec::Worker

Runnable::~WorkerRunnable d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
5

122 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Symbol: ~WorkerRunnable()
Syntax: virtual ~WorkerRunnable ();
Exception Safety: not exception safe
Description: Destructor .

c(RS_EM_00052)

8.2.2.2 WorkerRunnable::WorkerRunnable

[SWS_EM_02513]{OBSOLETE} Definition of API function ara::exec::Worker

Runnable::WorkerRunnable d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
Symbol: WorkerRunnable(const WorkerRunnable &obj)
Syntax: WorkerRunnable (const WorkerRunnable &obj)=delete;
Description: copy constructor

c(RS_EM_00052)
[SWS_EM_02514]{OBSOLETE} Definition of API function ara::exec::Worker
Runnable::WorkerRunnable d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
Symbol: WorkerRunnable(WorkerRunnable &&obj)
Syntax: WorkerRunnable (WorkerRunnable &&obj)=delete;
Description: Move constructor.

c(RS_EM_00052)
[SWS_EM_02511]{OBSOLETE} Definition of API function ara::exec::Worker
Runnable::WorkerRunnable d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
Symbol: WorkerRunnable()
Syntax: WorkerRunnable ();
Exception Safety: not exception safe
Description: Constructor .

c(RS_EM_00052)

123 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.2.3 WorkerRunnable::operator= (Copy assignment operator)

[SWS_EM_02515]{OBSOLETE} Definition of API function ara::exec::Worker

Runnable::operator= d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
Symbol: operator=(const WorkerRunnable &obj)
Syntax: WorkerRunnable & operator= (const WorkerRunnable &obj)=delete;
Description: Copy/move operator.

c(RS_EM_00052)

8.2.2.4 WorkerRunnable::Run

[SWS_EM_02520]{OBSOLETE} Definition of API function ara::exec::Worker

Runnable::Run d
Kind: function
Header file: #include "ara/exec/worker_runnable.h"
Scope: class ara::exec::WorkerRunnable
Symbol: Run(ValueType &element, ara::exec::WorkerThread &t)
Syntax: virtual void Run (ValueType &element, ara::exec::WorkerThread &t)=0;
Parameters (in): element Reference to container element
t Reference to worker thread (for random numbers)
Return value: None
Exception Safety: not exception safe
Description: Deterministic client worker runnable.

c(RS_EM_00052, RS_AP_00120, RS_AP_00121, RS_AP_00148)

8.2.3 WorkerThread class

Please note that all requirements in this chapter have been set to obsolete.
The WorkerThread class provides class defining the expected interface for Deter-
ministicClient worker threads, in particular, access to deterministic random num-
bers. Users can extend this class in order to provide common methods for all threads.
Therefore, the class is not declared as a final.

124 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02530]{OBSOLETE} Definition of API class ara::exec::WorkerThread d

Kind: class
Header file: #include "ara/exec/worker_thread.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: WorkerThread
Syntax: class WorkerThread {...};
Description: Class to implement worker thread for Deterministic Client .

c(RS_EM_00052, RS_AP_00116, RS_AP_00122, RS_AP_00154, RS_AP_00150)

8.2.3.1 WorkerThread::WorkerThread

[SWS_EM_02531]{OBSOLETE} Definition of API function ara::exec::Worker

Thread::WorkerThread d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
Symbol: WorkerThread()
Syntax: WorkerThread ();
Exception Safety: not exception safe
Description: Constructor .

c(RS_EM_00052, RS_AP_00122)
[SWS_EM_02533]{OBSOLETE} Definition of API function ara::exec::Worker
Thread::WorkerThread d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
Symbol: WorkerThread(const WorkerThread &obj)
Syntax: WorkerThread (const WorkerThread &obj)=delete;
Description: copy constructor

c(RS_EM_00052)
[SWS_EM_02534]{OBSOLETE} Definition of API function ara::exec::Worker
Thread::WorkerThread d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
Symbol: WorkerThread(WorkerThread &&obj)
5

125 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Syntax: WorkerThread (WorkerThread &&obj)=delete;
Description: Move constructor.

c(RS_EM_00052)

8.2.3.2 WorkerThread::~WorkerThread

[SWS_EM_02532]{OBSOLETE} Definition of API function ara::exec::Worker

Thread::~WorkerThread d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
Symbol: ~WorkerThread()
Syntax: virtual ~WorkerThread () noexcept;
Exception Safety: noexcept
Description: Destructor .

c(RS_EM_00052, RS_AP_00122, RS_AP_00134, RS_AP_00148)

8.2.3.3 WorkerThread::operator= (Copy assignment operator)

[SWS_EM_02535]{OBSOLETE} Definition of API function ara::exec::Worker

Thread::operator= d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
Symbol: operator=(const WorkerThread &obj)
Syntax: WorkerThread operator= (const WorkerThread &obj)=delete;
Description: Copy move operator.

c(RS_EM_00052)

8.2.3.4 WorkerThread::GetRandom

[SWS_EM_02540]{OBSOLETE} Definition of API function ara::exec::Worker

Thread::GetRandom d
Kind: function
Header file: #include "ara/exec/worker_thread.h"
Scope: class ara::exec::WorkerThread
5

126 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Symbol: GetRandom()
Syntax: std::uint64_t GetRandom () noexcept;
Return value: std::uint64_t Deterministic random number
Exception Safety: noexcept
Description: Returns a deterministic pseudo-random number which is unique for each container element.

c(RS_EM_00052, RS_AP_00120, RS_AP_00132)

8.2.4 DeterministicClient class

Please note that all requirements in this chapter have been set to obsolete.
The DeterministicClient class provides the functionality for an Application
to run a cyclic deterministic execution, see 7.6.3. Each Modelled Process which
needs support for cyclic deterministic execution has to instantiate this class.
[SWS_EM_02210]{OBSOLETE} Definition of API class ara::exec::Deterministic
Client d
Kind: class
Header file: #include "ara/exec/deterministic_client.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: DeterministicClient
Syntax: class DeterministicClient final {...};
Description: Class to implement operations on Deterministic Client .

c(RS_EM_00052, RS_AP_00116, RS_AP_00122, RS_AP_00140, RS_AP_00154,

RS_AP_00150)

8.2.4.1 DeterministicClient::DeterministicClient

[SWS_EM_02211]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::DeterministicClient d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: DeterministicClient()
Syntax: DeterministicClient () noexcept;
Exception Safety: noexcept
5

127 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Description: Constructor for DeterministicClient which opens the Execution Management communication
channel (e.g. POSIX FIFO) to access a wait point for cyclic execution, a worker pool,
deterministic random numbers and time stamps .

c(RS_EM_00052, RS_EM_00053, RS_AP_00132)

8.2.4.2 DeterministicClient::~DeterministicClient

[SWS_EM_02215]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::~DeterministicClient d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: ~DeterministicClient()
Syntax: ~DeterministicClient () noexcept;
Exception Safety: noexcept
Description: Destructor of the Deterministic Client instance .

c(RS_EM_00052, RS_EM_00053, RS_AP_00134)

8.2.4.3 DeterministicClient::WaitForActivation

[SWS_EM_02217]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::WaitForActivation d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: WaitForActivation()
Syntax: ara::core::Result< ActivationReturnType > WaitForActivation ()
noexcept;
Return value: ara::core::Result< Process control value (or error) In the absence of an error, the
ActivationReturnType > return value contains the activation state defined by
ara::exec::ActivationReturnType.
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::k The deterministic activation cycle time exceeded.
CycleOverrun
ara::exec::ExecErrc::k Requested operation could not be performed.
Failed
Description: Blocks and returns with a process control value when the next activation is triggered by the
Runtime .

c(RS_EM_00052, RS_AP_00120, RS_AP_00132, RS_AP_00127, RS_AP_00139)

128 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.4.4 DeterministicClient::RunWorkerPool

[SWS_EM_02221]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::RunWorkerPool d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: RunWorkerPool(WorkerRunnable< ValueType > &runnableObj, Container &container)
Syntax: template <typename ValueType, typename Container>
ara::core::Result< void > RunWorkerPool (WorkerRunnable< ValueType >
&runnableObj, Container &container) noexcept;
Template param: ValueType Element type of container
Container Container for which method WorkerRunnable::Run is invoked for
each element
Parameters (in): runnableObj Object derived from WorkerRunnable that provides a method called
Run(...), which will be called on every container element
container C++ container which supports a standard iterator interface with -
begin() - end() - operator*() - operator++
Return value: ara::core::Result< void > –
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::k Not in ara::exec::ActivationReturnType::kRun or
Failed ara::exec::ActivationReturnType::kInit cycle state
Description: Run a deterministic worker pool.
Uses a pool of Deterministic workers to call a method WorkerRunnable::Run for every element
of the container. The sequential iteration is guaranteed by using the container’s increment
operator. The API provides the guarantee that no other iteration scheme is used.
This function shall not participate in overload resolution unless ValueType is compatible with
Container::value_type.

c(RS_EM_00053, RS_AP_00120, RS_AP_00121, RS_AP_00132, RS_AP_00127,

RS_AP_00139)

8.2.4.5 DeterministicClient::GetRandom

[SWS_EM_02225]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::GetRandom d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: GetRandom()
Syntax: std::uint64_t GetRandom () noexcept;
Return value: std::uint64_t uint64_t 64 bit uniform distributed pseudo random number
Exception Safety: noexcept
5

129 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Description: Return deterministic sequence of random numbers.
This returns the next in a sequence of ‘Deterministic’ random numbers. Deterministic’ means,
that the returned random numbers are identical within redundant DeterministicClient::WaitFor
Activation() cycles, which are used within redundantly executed Processes.

c(RS_EM_00053, RS_AP_00120, RS_AP_00132)

8.2.4.6 DeterministicClient::SetRandomSeed

[SWS_EM_02226]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::SetRandomSeed d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: SetRandomSeed(std::uint64_t seed)
Syntax: void SetRandomSeed (std::uint64_t seed) noexcept;
Parameters (in): seed Random number seed to DeterministicClient::SetRandomSeed.
Return value: None
Exception Safety: noexcept
Description: Seed random number generator used for redundantly executed deterministic clients.

c(RS_EM_00053, RS_AP_00120, RS_AP_00121, RS_AP_00132)

8.2.4.7 DeterministicClient::GetActivationTime

[SWS_EM_02231]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::GetActivationTime d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: GetActivationTime()
Syntax: ara::core::Result< TimeStamp > GetActivationTime () noexcept;
Return value: ara::core::Result< Time TimeStamp of current activation cycle
Stamp >
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::kNo Time stamp not available
TimeStamp
Description: TimeStamp of activation point.
This method provides the timestamp that represents the point in time when the activation was
triggered by DeterministicClient::WaitForActivation() with return value kRun. Subsequent calls
within an activation cycle will always provide the same value. The same value will also be
provided within redundantly executed Processes

c(RS_EM_00053, RS_AP_00120, RS_AP_00127, RS_AP_00132, RS_AP_00139)

130 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.4.8 DeterministicClient::GetNextActivationTime

[SWS_EM_02236]{OBSOLETE} Definition of API function ara::exec::Deterministic

Client::GetNextActivationTime d
Kind: function
Header file: #include "ara/exec/deterministic_client.h"
Scope: class ara::exec::DeterministicClient
Symbol: GetNextActivationTime()
Syntax: ara::core::Result< TimeStamp > GetNextActivationTime () noexcept;
Return value: ara::core::Result< Time TimeStamp of next activation cycle
Stamp >
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::kNo Time stamp not available
TimeStamp
Description: Timestamp of next activation point.
This method provides the timestamp that represents the point in time when the next activation
will be triggered by DeterministicClient::WaitForActivation() with return value kRun. Subsequent
calls within an activation cycle will always provide the same value. The same value will also be
provided within redundantly executed Process

c(RS_EM_00053, RS_AP_00120, RS_AP_00132, RS_AP_00127, RS_AP_00139)

8.2.5 FunctionGroup class

An instance of this class will represent Function Group defined inside meta-model
(ARXML). This class is intended to be an implementation specific representation, of
information inside meta-model. Once created based on ARXML path, its internal value
stays bounded to it for entire lifetime of a object.
[SWS_EM_02263]{OBSOLETE} Definition of API class ara::exec::FunctionGroup
d
Kind: class
Header file: #include "ara/exec/function_group.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: FunctionGroup
Syntax: class FunctionGroup final {...};
Description: Class representing Function Group defined in meta-model (ARXML).
Notes: Once created based on ARXML path, it’s internal value stay bounded to it for entire lifetime of an
object.

c(RS_EM_00101, RS_AP_00154, RS_AP_00150)

131 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.5.1 FunctionGroup::Create

[SWS_EM_02323]{OBSOLETE} Definition of API function ara::exec::Function

Group::Create d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: Create(ara::core::StringView qualifiedShortName)
Syntax: static ara::core::Result< FunctionGroup > Create (ara::core::String
View qualifiedShortName) noexcept;
Parameters (in): qualifiedShortName stringified meta model identifier (short name path) where path
separator is ’/’.
Return value: ara::core::Result< an instance of FunctionGroup, or ExecErrc error.
FunctionGroup >
Exception Safety: noexcept
Thread Safety: Thread-safe
Errors: ara::exec::ExecErrc::k if qualifiedShortName passed is incorrect (e.g. FunctionGroupState
MetaModelError identifier has been passed).
Description: Named constructor for FunctionGroup.
This method shall validate/verify meta-model path passed and perform FunctionGroup object
creation.

c(RS_EM_00101)

8.2.5.2 FunctionGroup::FunctionGroup

[SWS_EM_02321]{OBSOLETE} Definition of API function ara::exec::Function

Group::FunctionGroup d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: FunctionGroup()
Syntax: FunctionGroup ()=delete;
Description: Default constructor.
Notes: Default constructor is deleted in favour of named constructor (Create).

c(RS_EM_00101)

132 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.5.3 FunctionGroup::FunctionGroup (Copy Constructor)

[SWS_EM_02322]{OBSOLETE} Definition of API function ara::exec::Function

Group::FunctionGroup d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: FunctionGroup(const FunctionGroup &other)
Syntax: FunctionGroup (const FunctionGroup &other)=delete;
Description: Copy constructor.
Notes: To prevent problems with resource allocations during copy operation, this class is non-copyable.

c(RS_EM_00101)

8.2.5.4 FunctionGroup::FunctionGroup (Move Constructor)

[SWS_EM_02328]{OBSOLETE} Definition of API function ara::exec::Function

Group::FunctionGroup d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: FunctionGroup(FunctionGroup &&other)
Syntax: FunctionGroup (FunctionGroup &&other) noexcept;
Parameters (in): other FunctionGroup instance to move to a newly constructed object.
Exception Safety: noexcept
Description: Move constructor.

c(RS_EM_00101)

8.2.5.5 FunctionGroup::operator= (Copy assignment operator)

[SWS_EM_02327]{OBSOLETE} Definition of API function ara::exec::Function

Group::operator= d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: operator=(const FunctionGroup &other)
Syntax: FunctionGroup & operator= (const FunctionGroup &other)=delete;
Description: Copy assignment operator.
Notes: To prevent problems with resource allocations during copy operation, this class is non-copyable.

c(RS_EM_00101)

133 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.5.6 FunctionGroup::operator= (Move assignment operator)

[SWS_EM_02329]{OBSOLETE} Definition of API function ara::exec::Function

Group::operator= d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: operator=(FunctionGroup &&other)
Syntax: FunctionGroup & operator= (FunctionGroup &&other) noexcept;
Parameters (in): other FunctionGroup instance to move to this object.
Return value: FunctionGroup & –
Exception Safety: noexcept
Description: Move assignment operator.

c(RS_EM_00101)

8.2.5.7 FunctionGroup::~FunctionGroup

[SWS_EM_02266]{OBSOLETE} Definition of API function ara::exec::Function

Group::~FunctionGroup d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: ~FunctionGroup()
Syntax: ~FunctionGroup () noexcept;
Exception Safety: noexcept
Description: Destructor of the FunctionGroup instance.

c(RS_EM_00101)

8.2.5.8 FunctionGroup::operator==

[SWS_EM_02267]{OBSOLETE} Definition of API function ara::exec::Function

Group::operator== d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: operator==(const FunctionGroup &other)
Syntax: bool operator== (const FunctionGroup &other) const noexcept;
Parameters (in): other FunctionGroup instance to compare this one with.
5

134 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Return value: bool true in case both FunctionGroups are representing exactly the
same meta-model element, false otherwise.
Exception Safety: noexcept
Thread Safety: Thread-safe
Description: eq operator to compare with other FunctionGroup instance.

c(RS_EM_00101)

8.2.5.9 FunctionGroup::operator!=

[SWS_EM_02268]{OBSOLETE} Definition of API function ara::exec::Function

Group::operator!= d
Kind: function
Header file: #include "ara/exec/function_group.h"
Scope: class ara::exec::FunctionGroup
Symbol: operator!=(const FunctionGroup &other)
Syntax: bool operator!= (const FunctionGroup &other) const noexcept;
Parameters (in): other FunctionGroup instance to compare this one with.
Return value: bool false in case both FunctionGroups are representing exactly the
same meta-model element, true otherwise.
Exception Safety: noexcept
Thread Safety: Thread-safe
Description: uneq operator to compare with other FunctionGroup instance.

c(RS_EM_00101)

8.2.6 FunctionGroupState class

An instance of this class will represent Function Group State defined inside meta-
model (ARXML). This class is intended to be an implementation specific representa-
tion, of information inside meta-model. Once created based on ARXML path, its inter-
nal value stays bounded to it for entire lifetime of a object.
[SWS_EM_02269] Definition of API class ara::exec::FunctionGroupState d
Kind: class
Header file: #include "ara/exec/function_group_state.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: FunctionGroupState
Syntax: class FunctionGroupState final {...};
Description: Class representing Function Group State defined in meta-model (ARXML).
Notes: Once created based on ARXML path, it’s internal value stay bounded to it for entire lifetime of an
object.

135 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

c(RS_EM_00101, RS_AP_00154, RS_AP_00150)

8.2.6.1 FunctionGroupState::Create

[SWS_EM_02326]{OBSOLETE} Definition of API function ara::exec::Function

GroupState::Create d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: Create(const FunctionGroup &functionGroup, ara::core::StringView qualifiedShortName)
Syntax: static ara::core::Result< FunctionGroupState > Create (const Function
Group &functionGroup, ara::core::StringView qualifiedShortName)
noexcept;
Parameters (in): functionGroup the FunctionGroup instance the state shall be connected with.
qualifiedShortName stringified meta model identifier (short name path) where path
separator is ’/’.
Return value: ara::core::Result< an instance of FunctionGroupState, or ExecErrorDomain error.
FunctionGroupState >
Exception Safety: noexcept
Thread Safety: Thread-safe
Errors: ara::exec::ExecErrc::k if qualifiedShortName passed is incorrect (e.g. FunctionGroup
MetaModelError identifier has been passed).
Description: Named constructor for FunctionGroupState.
This method shall validate/verify meta-model path passed and perform FunctionGroupState
object creation.

c(RS_EM_00101)

8.2.6.2 FunctionGroupState::FunctionGroupState

[SWS_EM_02324]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::FunctionGroupState d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: FunctionGroupState(ara::core::StringView functionGroup, ara::core::StringView functionGroup
State)
Syntax: FunctionGroupState (ara::core::StringView functionGroup,
ara::core::StringView functionGroupState) noexcept;
Parameters (in): functionGroup stringified meta model identifier (short name path) where path
separator is ’/’
functionGroupState stringified meta model identifier (short name path) where path
separator is ’/’.
Exception Safety: noexcept
Description: Default constructor.

c(RS_EM_00101)

136 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.6.3 FunctionGroupState::FunctionGroupState (Copy Constructor)

[SWS_EM_02325]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::FunctionGroupState d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: FunctionGroupState(const FunctionGroupState &other)
Syntax: FunctionGroupState (const FunctionGroupState &other) noexcept;
Parameters (in): other FunctionGroupState instance to be copied
Exception Safety: noexcept
Description: Copy constructor.

c(RS_EM_00101, RS_AP_00145)

8.2.6.4 FunctionGroupState::FunctionGroupState (Move Constructor)

[SWS_EM_02331]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::FunctionGroupState d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: FunctionGroupState(FunctionGroupState &&other)
Syntax: FunctionGroupState (FunctionGroupState &&other) noexcept;
Parameters (in): other FunctionGroupState instance to be moved to a newly constructed
object.
Exception Safety: noexcept
Description: Move constructor.

c(RS_EM_00101, RS_AP_00145, RS_AP_00151)

8.2.6.5 FunctionGroupState::operator= (Copy assignment operator)

[SWS_EM_02330]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::operator= d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: operator=(const FunctionGroupState &other)
Syntax: FunctionGroupState & operator= (const FunctionGroupState &other) &
noexcept;
5

137 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Parameters (in): other FunctionGroupState instance to be copied
Return value: FunctionGroupState & –
Exception Safety: noexcept
Description: Copy assignment operator.

c(RS_EM_00101, RS_AP_00153, RS_AP_00145)

8.2.6.6 FunctionGroupState::operator= (Move assignment operator)

[SWS_EM_02332]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::operator= d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: operator=(FunctionGroupState &&other)
Syntax: FunctionGroupState & operator= (FunctionGroupState &&other) &
noexcept;
Parameters (in): other FunctionGroupState instance to move to this object.
Return value: FunctionGroupState & –
Exception Safety: noexcept
Description: Move assignment operator.

c(RS_EM_00101, RS_AP_00153, RS_AP_00145, RS_AP_00151)

8.2.6.7 FunctionGroupState::~FunctionGroupState

[SWS_EM_02272]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::~FunctionGroupState d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: ~FunctionGroupState()
Syntax: ~FunctionGroupState () noexcept;
Exception Safety: noexcept
Description: Destructor of the FunctionGroupState instance.

c(RS_EM_00101, RS_AP_00134, RS_AP_00145)

138 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.6.8 FunctionGroupState::operator==

[SWS_EM_02273]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::operator== d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: operator==(const FunctionGroupState &other)
Syntax: bool operator== (const FunctionGroupState &other) const noexcept;
Parameters (in): other FunctionGroupState instance to compare this one with.
Return value: bool true in case both FunctionGroupStates are representing exactly the
same meta-model element, false otherwise.
Exception Safety: noexcept
Thread Safety: Thread-safe
Description: eq operator to compare with other FunctionGroupState instance.

c(RS_EM_00101)

8.2.6.9 FunctionGroupState::operator!=

[SWS_EM_02274]{DRAFT} Definition of API function ara::exec::FunctionGroup

State::operator!= d
Kind: function
Header file: #include "ara/exec/function_group_state.h"
Scope: class ara::exec::FunctionGroupState
Symbol: operator!=(const FunctionGroupState &other)
Syntax: bool operator!= (const FunctionGroupState &other) const noexcept;
Parameters (in): other FunctionGroupState instance to compare this one with.
Return value: bool false in case both FunctionGroupStates are representing exactly
the same meta-model element, true otherwise.
Exception Safety: noexcept
Thread Safety: Thread-safe
Description: uneq operator to compare with other FunctionGroupState instance.

c(RS_EM_00101)

8.2.7 StateClient class

Class used to perform Function Group state management operation needed during
lifetime of a Machine. State Management during its own lifetime will need to start
and stop software, that is intended to run on a Machine managed by it. This can
be achieved by performing state transition of a Function Group to which required
software is assigned. Integrator will assign software to run in a particular state (of
Function Group) and State Management can start it, by requesting Execution

139 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Management to perform state transition (of this Function Group) to the mentioned
state. Execution Management will then start mentioned software and report tran-
sition result back to State Management. Please note that stopping software can be
done in similar way (i.e. Function Group state transition, to a state in which software
is not configured to be run).
[SWS_EM_02275] Definition of API class ara::exec::StateClient d
Kind: class
Header file: #include "ara/exec/state_client.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: StateClient
Syntax: class StateClient final {...};
Description: StateClient is an interface of Execution Management that is used by State Management to
request transitions between Function Group States or to perform other related operations.
Notes: StateClient opens communication channel to Execution Management (e.g. POSIX FIFO). Each
Process that intends to perform state management, should create an instance of this class and it
should have rights to use it. To eventually implement the Named Constructor Idiom, the
developer may either make the default constructor private or delete it and define a non-default
constructor.

c(RS_EM_00101, RS_AP_00154, RS_AP_00150)

8.2.7.1 StateClient::StateClient

[SWS_EM_02561]{DRAFT} Definition of API function ara::exec::StateClient::State

Client d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: StateClient(std::function< void(const ara::exec::ExecutionErrorEvent &)> undefinedState
Callback)
Syntax: StateClient (std::function< void(const ara::exec::ExecutionErrorEvent
&)> undefinedStateCallback);
Parameters (in): undefinedStateCallback callback to be invoked by StateClient library if a FunctionGroup
changes its state unexpectedly to an Undefined Function Group
State, i.e. without previous request by SetState(). The affected
FunctionGroup and ExecutionError is provided as an argument to
the callback in form of ExecutionErrorEvent
Exception Safety: not exception safe
Errors: ara::exec::ExecErrc::k communication error occurred
CommunicationError
Description: Regular constructor for StateClient.

c(RS_EM_00101, RS_AP_00114, RS_AP_00119, RS_AP_00120, RS_AP_00121,

RS_AP_00151)

140 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.7.2 StateClient::Create

[SWS_EM_02276] Definition of API function ara::exec::StateClient::Create d

Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: Create(std::function< void(const ara::exec::ExecutionErrorEvent &)> undefinedStateCallback)
Syntax: static ara::core::Result< StateClient > Create (std::function<
void(const ara::exec::ExecutionErrorEvent &)> undefinedStateCallback)
noexcept;
Parameters (in): undefinedStateCallback callback to be invoked by StateClient library if a FunctionGroup
changes its state unexpectedly to an Undefined Function Group
State, i.e. without previous request by SetState(). The affected
FunctionGroup and ExecutionError is provided as an argument to
the callback in form of ExecutionErrorEvent.
Return value: ara::core::Result< State a result that contains either a StateClient object or an error.
Client >
Exception Safety: noexcept
Errors: ara::exec::ExecErrc::k communication error occurred
CommunicationError
Description: Named constructor for StateClient.
Notes: This named constructor may call a private constructor defined by the developer.

c(RS_EM_00101, RS_AP_00119, RS_AP_00120, RS_AP_00121, RS_AP_00132,

RS_AP_00139, RS_AP_00144)

8.2.7.3 StateClient::~StateClient

[SWS_EM_02277] Definition of API function ara::exec::StateClient::~StateClient

d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: ~StateClient()
Syntax: ~StateClient () noexcept;
Exception Safety: noexcept
Description: noexcept destructor

c(RS_AP_00134, RS_AP_00145, RS_EM_00101)

141 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.7.4 StateClient::StateClient (deleted Copy Constructor)

[SWS_EM_02565]{DRAFT} Definition of API function ara::exec::StateClient::State

Client d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: StateClient(const StateClient &)
Syntax: StateClient (const StateClient &)=delete;
Description: Suppress default copy construction for StateClient.

c(RS_AP_00145, RS_EM_00103)

8.2.7.5 StateClient::operator= (deleted Copy assignment operator)

[SWS_EM_02568]{DRAFT} Definition of API function ara::exec::State

Client::operator= d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: operator=(const StateClient &)
Syntax: StateClient & operator= (const StateClient &)=delete;
Description: Suppress default copy assignment for StateClient.

c(RS_AP_00145, RS_EM_00103)

8.2.7.6 StateClient::StateClient (use of default move constructor)

[SWS_EM_02566]{DRAFT} Definition of API function ara::exec::StateClient::State

Client d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: StateClient(StateClient &&rval)
Syntax: StateClient (StateClient &&rval) noexcept;
Parameters (in): rval reference to move
Exception Safety: noexcept
Description: Intentional use of default move constructor for StateClient.

c(RS_AP_00145, RS_AP_00151, RS_EM_00103)

142 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.2.7.7 StateClient::operator= (use of default move assignment)

[SWS_EM_02567]{DRAFT} Definition of API function ara::exec::State

Client::operator= d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: operator=(StateClient &&rval)
Syntax: StateClient & operator= (StateClient &&rval) noexcept;
Parameters (in): rval reference to move
Return value: StateClient & the new reference
Exception Safety: noexcept
Description: Intentional use of default move assignment for StateClient.

c(RS_AP_00145, RS_AP_00151, RS_EM_00103)

8.2.7.8 StateClient::SetState

[SWS_EM_02278] Definition of API function ara::exec::StateClient::SetState d

Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: SetState(const FunctionGroupState &state)
Syntax: ara::core::Future< void > SetState (const FunctionGroupState &state)
const noexcept;
Parameters (in): state representing meta-model definition of a state inside a specific
Function Group. Execution Management will perform state
transition from the current state to the state identified by this
parameter.
Return value: ara::core::Future< void > void if requested transition is successful, otherwise it returns Exec
ErrorDomain error.
Exception Safety: noexcept
Thread Safety: thread-safe

Errors: ara::exec::ExecErrc::k if transition to the requested Function Group state was cancelled by
Cancelled a newer request
ara::exec::ExecErrc::k if transition to the requested Function Group state failed
Failed
ara::exec::ExecErrc::k if Unexpected Termination in Process of target Function Group
FailedUnexpected State happened.
TerminationOnEnter
ara::exec::ExecErrc::k if StateClient can’t communicate with Execution Management (e.g.
CommunicationError IPC link is down)
ara::exec::ExecErrc::k if transition to the requested state is prohibited (e.g. Off state for
InvalidTransition MachineFG) or the requested Function Group State is invalid (e.g.
does not exist anymore after a software update)
ara::exec::ExecErrc::k if an integrity or authenticity check failed during state transition.
IntegrityOrAuthenticity
CheckFailed
5

143 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
ara::exec::ExecErrc::k One of the processes terminated in an unexpected way during the
FailedUnexpected state transition.
Termination
ara::exec::ExecErrc::k The given Function Group State couldn’t be found in the Processed
MetaModelError Manifest.
Description: Method to request state transition for a single Function Group.
This method will request Execution Management to perform state transition and return
immediately. Returned ara::core::Future can be used to determine result of requested transition.

c(RS_EM_00101, RS_AP_00119, RS_AP_00120, RS_AP_00121, RS_AP_00132,

RS_AP_00138)
Asynchronous nature of ara::exec::StateClient::SetState makes the re-
turned ara::core::Future dependable on lifetime of the instance from which it
was received. It is expected that once state change request is received by Execution
Management, it will be processed independently of lifetime of the instance from which
it was requested.
Please note that the qualified short names representing FunctionGroups and Func-
tionGroupStates could be quite long. They can be replaced by implementation specific
data types to speed up any checks that have to be performed by the SetState method.
This is enabled by the FunctionGroupState data-type.

8.2.7.9 StateClient::GetInitialMachineStateTransitionResult

[SWS_EM_02279] Definition of API function ara::exec::StateClient::GetInitialMa-

chineStateTransitionResult d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: GetInitialMachineStateTransitionResult()
Syntax: ara::core::Future< void > GetInitialMachineStateTransitionResult ()
const noexcept;
Return value: ara::core::Future< void > void if requested transition is successful, otherwise it returns Exec
ErrorDomain error.
Exception Safety: noexcept
Thread Safety: thread-safe
Errors: ara::exec::ExecErrc::k StateManagement may decide to cancel SWS_EM_01023
Cancelled transition and start specific startup sequence. This could happen
for number of reasons and one of them could be interrupted
Machine update sequence.
ara::exec::ExecErrc::k if transition to the requested Function Group state failed
Failed
ara::exec::ExecErrc::k if StateClient can’t communicate with Execution Management (e.g.
CommunicationError IPC link is down)
Description: Method to retrieve result of Machine State initial transition to Startup state.
5

144 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Notes: This method allows State Management to retrieve the result of a transition specified by SWS_
EM_01023 and SWS_EM_02241. Please note that this transition happens once per machine life
cycle, thus the result delivered by this method shall not change (unless machine is started
again).

c(RS_EM_00101, RS_AP_00119, RS_AP_00120, RS_AP_00132, RS_AP_00138)

Please note that concerns about returned ara::core::Future from ara::exec::
StateClient::SetState apply for ara::exec::StateClient::GetInitial-
MachineStateTransitionResult.

8.2.7.10 StateClient::GetExecutionError

[SWS_EM_02542] Definition of API function ara::exec::StateClient::GetExecution

Error d
Kind: function
Header file: #include "ara/exec/state_client.h"
Scope: class ara::exec::StateClient
Symbol: GetExecutionError(const ara::exec::FunctionGroupState &functionGroupState)
Syntax: ara::core::Result< ara::exec::ExecutionErrorEvent > GetExecutionError
(const ara::exec::FunctionGroupState &functionGroupState) noexcept;
Parameters (in): functionGroupState Function Group State of interest.
Return value: ara::core::Result< The execution error which changed the Function Group of the given
ara::exec::Execution Function Group State to an Undefined Function Group State.
ErrorEvent >
Exception Safety: noexcept
Thread Safety: thread-safe
Errors: ara::exec::ExecErrc::k The Function Group of the given Function Group State is not in an
Failed Undefined Function Group State.
ara::exec::ExecErrc::k if StateClient can’t communicate with Execution Management (e.g.
CommunicationError IPC link is down)
ara::exec::ExecErrc::k The given Function Group State couldn’t be found in the Processed
MetaModelError Manifest.
Description: Returns the execution error which changed the Function Group of the given Function Group
State to an Undefined Function Group State.
This function will return with error and will not return an ExecutionErrorEvent object, if the
Function Group is in a defined Function Group state again.

c(RS_EM_00101, RS_AP_00120, RS_AP_00121, RS_AP_00128, RS_AP_00132,

RS_AP_00139)
[SWS_EM_02543]{DRAFT} Default value for ExecutionError dIn case of Un-
expected Termination or Unexpected Self-termination of a Modelled
Process which does not have an executionError configured, Execution Man-
agement shall report the ExecutionError value 1.c(RS_EM_00101)

145 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.3 Log and Trace Messages

[SWS_EM_02569]{DRAFT} LogMessage ProcessCreated d
Dlt-Message ProcessCreated
Description Message that is sent by the Execution Management right after the Execution Management successfully
created a process.
MessageId 0x80004001
MessageType DLT_TRACE_VFB
Info
Dlt-Argument ArgumentDescription ArgumentType ArgumentUnit
processId OS specific PID which has been assigned to the process. uint32 NoUnit
processName Shortname of the Process element which has been started. Utf8BaseType NoUnit
is_created is created. predefined text

c(RS_EM_00152)
[SWS_EM_02570]{DRAFT} LogMessage ProcessKRunningReceived d
Dlt-Message ProcessKRunningReceived
Description Message that is sent by the Execution Management when the Execution Management received a k
Running from ara::exec::ExecutionClient::ReportExecutionState.
MessageId 0x80004002
MessageType DLT_TRACE_VFB
Info
Dlt-Argument ArgumentDescription ArgumentType ArgumentUnit
processId OS specific PID which has been assigned to the process. uint32 NoUnit
received_k received kRunning. predefined text
Running

c(RS_EM_00152)
[SWS_EM_02571]{DRAFT} LogMessage ProcessTerminationRequest d
Dlt-Message ProcessTerminationRequest
Description Message that is sent by the Execution Management when the Execution Management requested to
terminate a process.
MessageId 0x80004003
MessageType DLT_TRACE_VFB
Info
Dlt-Argument ArgumentDescription ArgumentType ArgumentUnit
execution_ Execution Management requested to terminate predefined text
management_
requested_to_
terminate
processId OS specific PID which has been assigned to the process. uint32 NoUnit

c(RS_EM_00152)

146 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

[SWS_EM_02572]{DRAFT} LogMessage ProcessTerminated d

Dlt-Message ProcessTerminated
Description Message that is sent by the Execution Management when the Execution Management received an
EXIT_SUCCESS or an unexpected termination from the process.
MessageId 0x80004004
MessageType DLT_TRACE_VFB
Info
Dlt-Argument ArgumentDescription ArgumentType ArgumentUnit
processId OS specific PID which has been assigned to the process. uint32 NoUnit
is_terminated is terminated. predefined text

c(RS_EM_00152)

147 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.4 Errors
The Execution Management cluster implements an error handling based on ara::
core::Result. The errors supported by the Execution Management cluster are
listed in section 8.4.1.

8.4.1 Execution Management error codes

[SWS_EM_02281]{DRAFT} Definition of API enum ara::exec::ExecErrc d

Kind: enumeration
Header file: #include "ara/exec/exec_error_domain.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecErrc
Underlying type: ara::core::ErrorDomain::CodeType
Syntax: enum class ExecErrc : ara::core::ErrorDomain::CodeType {...};
kCommunicationError= 3 Communication error occurred
Values:
kMetaModelError= 4 Wrong meta model identifier passed to a function
kCancelled= 5 Transition to the requested Function Group state was cancelled by
a newer request
kFailed= 6 Requested operation could not be performed
kFailedUnexpected Unexpected Termination during transition in Process of target
TerminationOnEnter= 8 Function Group State happened
kInvalidTransition= 9 Transition invalid (e.g. report kRunning when already in Running
Process State)
kNoTimeStamp= 12 DeterministicClient time stamp information is not available
kCycleOverrun= 13 Deterministic activation cycle time exceeded
kIntegrityOrAuthenticity Integrity or authenticity check for a Process to be spawned in the
CheckFailed= 14 requested Function Group state failed
kFailedUnexpected Unexpected Termination of a non terminating Process during a
Termination= 15 Function Group State transition happened.
kInvalidArgument= 16 Passed argument doesn’t appear to be valid.
Description: Defines an enumeration class for the Execution Management error codes.

c(RS_AP_00130, RS_AP_00122, RS_AP_00127, RS_AP_00154)

Please note Execution Management intentionally violates [SWS_CORE_90006]
here. Violation handling as required by [SWS_CORE_90006] leads to Unexpected
Termination, which would be reported to and handled by State Management.
Note that for APIs intended to be used by State Management itself, this error han-
dling strategy is not considered to contribute to robust system design (State Man-
agement would be terminated by [SWS_CORE_90006]). Therefore ara::exec APIs
which are intended to be used by State Management return kMetaModelError in-
stead, as this allows implementation of fallback strategies within State Management.

148 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.4.2 ExecException class

[SWS_EM_02282] Definition of API class ara::exec::ExecException d

Kind: class
Header file: #include "ara/exec/exec_error_domain.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecException
Base class: ara::core::Exception
Syntax: class ExecException : public ara::core::Exception {...};
Description: Defines a class for exceptions to be thrown by the Execution Management.

c(RS_AP_00130, RS_AP_00122, RS_AP_00127, RS_AP_00154, RS_AP_00150)

8.4.2.1 ExecException::ExecException

[SWS_EM_02283] Definition of API function ara::exec::ExecException::ExecEx-

ception d
Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: class ara::exec::ExecException
Symbol: ExecException(ara::core::ErrorCode errorCode)
Syntax: explicit ExecException (ara::core::ErrorCode errorCode) noexcept;
Parameters (in): errorCode The error code.
Exception Safety: noexcept
Description: Constructs a new ExecException object containing an error code.

c(RS_AP_00120, RS_AP_00121, RS_AP_00130, RS_AP_00132)

8.4.3 GetExecErrorDomain function

[SWS_EM_02290] Definition of API function ara::exec::GetExecErrorDomain d

Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: namespace ara::exec
Symbol: GetExecErrorDomain()
Syntax: const ara::core::ErrorDomain & GetExecErrorDomain () noexcept;
Return value: const ara::core::Error Return a reference to the global ExecErrorDomain object.
Domain &
Exception Safety: noexcept
Description: Returns a reference to the global ExecErrorDomain object.

c(RS_AP_00120, RS_AP_00130, RS_AP_00132, RS_AP_00154)

149 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.4.4 MakeErrorCode function

[SWS_EM_02291] Definition of API function ara::exec::MakeErrorCode d

Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: namespace ara::exec
Symbol: MakeErrorCode(ara::exec::ExecErrc code, ara::core::ErrorDomain::SupportDataType data)
Syntax: ara::core::ErrorCode MakeErrorCode (ara::exec::ExecErrc code,
ara::core::ErrorDomain::SupportDataType data) noexcept;
Parameters (in): code Error code number.
data Vendor defined data associated with the error.
Return value: ara::core::ErrorCode An ErrorCode object.
Exception Safety: noexcept
Description: Creates an instance of ErrorCode.

c(RS_AP_00120, RS_AP_00121, RS_AP_00130, RS_AP_00132, RS_AP_00154)

8.4.5 ExecErrorDomain class

The error handling requires an ara::core::ErrorDomain, which can be used to

check the errors returned via ara::core::Result.
[SWS_EM_02284] Definition of API class ara::exec::ExecErrorDomain d
Kind: class
Header file: #include "ara/exec/exec_error_domain.h"
Forwarding header file: #include "ara/exec/exec_fwd.h"
Scope: namespace ara::exec
Symbol: ExecErrorDomain
Base class: ara::core::ErrorDomain
Syntax: class ExecErrorDomain final : public ara::core::ErrorDomain {...};
Unique ID: 0x8000’0000’0000’0202
Description: Defines a class representing the Execution Management error domain.

c(RS_AP_00130, RS_AP_00122, RS_AP_00127, RS_AP_00154, RS_AP_00150)

8.4.5.1 ExecErrorDomain::ExecErrorDomain

[SWS_EM_02286] Definition of API function ara::exec::ExecErrorDomain::Exec

ErrorDomain d
Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: class ara::exec::ExecErrorDomain
5

150 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Symbol: ExecErrorDomain()
Syntax: ExecErrorDomain () noexcept;
Exception Safety: noexcept
Description: Constructs a new ExecErrorDomain object.

c(RS_AP_00120, RS_AP_00130, RS_AP_00132)

8.4.5.2 ExecErrorDomain::Name

[SWS_EM_02287] Definition of API function ara::exec::ExecErrorDomain::Name

d
Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: class ara::exec::ExecErrorDomain
Symbol: Name()
Syntax: const char * Name () const noexcept override;
Return value: const char * "Exec".
Exception Safety: noexcept
Description: Returns a string constant associated with ExecErrorDomain.

c(RS_AP_00120, RS_AP_00130, RS_AP_00132)

[SWS_EM_02292]{OBSOLETE} dExecErrorDomain::Name shall return the NULL-
terminated string "Exec".c(RS_AP_00128)

8.4.5.3 ExecErrorDomain::Message

[SWS_EM_02288] Definition of API function ara::exec::ExecErrorDo-

main::Message d
Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: class ara::exec::ExecErrorDomain
Symbol: Message(CodeType errorCode)
Syntax: const char * Message (CodeType errorCode) const noexcept override;
Parameters (in): errorCode The error code number.
Return value: const char * The message associated with the error code.
Exception Safety: noexcept
Description: Returns the message associated with errorCode.

c(RS_AP_00120, RS_AP_00121, RS_AP_00130, RS_AP_00132)

151 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

8.4.5.4 ExecErrorDomain::ThrowAsException

[SWS_EM_02289] Definition of API function ara::exec::ExecErrorDomain::Throw

AsException d
Kind: function
Header file: #include "ara/exec/exec_error_domain.h"
Scope: class ara::exec::ExecErrorDomain
Symbol: ThrowAsException(const ara::core::ErrorCode &errorCode)
Syntax: void ThrowAsException (const ara::core::ErrorCode &errorCode) const
noexcept(false) override;
Parameters (in): errorCode The error to throw.
Return value: None
Exception Safety: noexcept(false)
Description: Creates a new instance of ExecException from errorCode and throws it as a C++ exception.

c(RS_AP_00120, RS_AP_00121, RS_AP_00130)

152 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

9 Service Interfaces
This chapter lists all provided and required service interfaces of the Execution Man-
agement.
There are no service interfaces defined in this release.

153 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

A Mentioned Manifest Elements

For the sake of completeness, this chapter contains a set of class tables representing
meta-classes mentioned in the context of this document but which are not contained
directly in the scope of describing specific meta-model semantics.
Class Executable
Package M2::AUTOSARTemplates::AdaptivePlatform::ApplicationDesign::ApplicationStructure
Note This meta-class represents an executable program.
Tags: atp.recommendedPackage=Executables
Base ARElement, ARObject, AtpClassifier , CollectableElement, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable, UploadableDesignElement, UploadablePackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
buildType BuildTypeEnum 0..1 attr This attribute describes the buildType of a module and/or
platform implementation.
implementation Executable * aggr This aggregation contains the collection of
Props ImplementationProps implementation-specific properties necessary to properly
build the enclosing Executable.
minimumTimer TimeValue 0..1 attr This attribute describes the minimum timer resolution
Granularity (TimeValue of one tick) that is required by the Executable.
reporting ExecutionState 0..1 attr this attribute controls the execution state reporting
Behavior ReportingBehavior behavior of the enclosing Executable.
Enum
rootSw RootSwComponent 0..1 aggr This represents the root SwCompositionPrototype of the
Component Prototype Executable. This aggregation is required (in contrast to a
Prototype direct reference of a SwComponentType) in order to
support the definition of instanceRefs in Executable
context.
traceSwitch TraceSwitch * aggr Configuration of the MsgId based trace switch
Configuration Configuration
Tags: atp.Status=draft
version StrongRevisionLabel 0..1 attr Version of the executable.
String

Table A.1: Executable

Class ExecutionDependency
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This element defines a ProcessState in which a dependent process needs to be before the process that
aggregates the ExecutionDependency element can be started.
Base ARObject
Aggregated by StateDependentStartupConfig.executionDependency
Attribute Type Mult. Kind Note
processState ModeDeclaration 0..1 iref This represent the applicable modeDeclaration that
represents an ProcessState.
InstanceRef implemented by: ModeInProcessInstance
Ref
Table A.2: ExecutionDependency

154 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Enumeration ExecutionStateReportingBehaviorEnum
Package M2::AUTOSARTemplates::AdaptivePlatform::ApplicationDesign::ApplicationStructure
Note This enumeration provides options for controlling of how an Executable reports its execution state to
the Execution Management
Aggregated by Executable.reportingBehavior
Literal Description
doesNotReport The Executable shall not report its execution state to the Execution Management.
ExecutionState
Tags: atp.EnumerationLiteralIndex=1
reportsExecution The Executable shall report its execution state to the Execution Management.
State
Tags: atp.EnumerationLiteralIndex=0

Table A.3: ExecutionStateReportingBehaviorEnum

Class Machine
Package M2::AUTOSARTemplates::AdaptivePlatform::MachineManifest
Note Machine that represents an Adaptive Autosar Software Stack.
Tags: atp.recommendedPackage=Machines
Base ARElement, ARObject, AtpClassifier , AtpFeature, AtpStructureElement, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, UploadableDeployment
Element, UploadablePackageElement
Aggregated by ARPackage.element, AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
default EnterExitTimeout 0..1 aggr This aggregation defines a default timeout in the context
Application of a given Machine with respect to the launching and
Timeout termination of applications.
environment TagWithOptionalValue * aggr This aggregation represents the collection of environment
Variable variables that shall be added to the environment defined
on the level of the enclosing Machine.
Stereotypes: atpSplitable
Tags: atp.Splitkey=environmentVariable
machineDesign MachineDesign 0..1 ref Reference to the MachineDesign this Machine is
implementing.
module AdaptiveModule * aggr Configuration of Adaptive Autosar module instances that
Instantiation Instantiation are running on the machine.
Stereotypes: atpSplitable
Tags: atp.Splitkey=moduleInstantiation.shortName
processor Processor * aggr This represents the collection of processors owned by the
enclosing machine.
secure SecureCommunication * aggr Deployment of secure communication protocol
Communication Deployment configuration settings to crypto module entities.
Deployment
Stereotypes: atpSplitable
Tags: atp.Splitkey=secureCommunication
Deployment.shortName
trustedPlatform TrustedPlatform 0..1 attr This attribute controls the behavior of how authentication
Executable ExecutableLaunch affects the ability to launch for each Executable.
LaunchBehavior BehaviorEnum
Table A.4: Machine

155 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Class ModeDeclaration
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note Declaration of one Mode. The name and semantics of a specific mode is not defined in the meta-model.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by AtpClassifier .atpFeature, ModeDeclarationGroup.modeDeclaration
Attribute Type Mult. Kind Note
value PositiveInteger 0..1 attr The RTE shall take the value of this attribute for
generating the source code representation of this Mode
Declaration.
Table A.5: ModeDeclaration

Class ModeDeclarationGroup
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note A collection of Mode Declarations. Also, the initial mode is explicitly identified.
Tags: atp.recommendedPackage=ModeDeclarationGroups
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, UploadableDesignElement,
UploadablePackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
initialMode ModeDeclaration 0..1 ref The initial mode of the ModeDeclarationGroup. This
mode is active before any mode switches occurred.
mode ModeDeclaration * aggr The ModeDeclarations collected in this ModeDeclaration
Declaration Group.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeDeclaration.shortName, mode
Declaration.variationPoint.shortLabel
vh.latestBindingTime=blueprintDerivationTime

Table A.6: ModeDeclarationGroup

Class ModeDeclarationGroupPrototype
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note The ModeDeclarationGroupPrototype specifies a set of Modes (ModeDeclarationGroup) which is
provided or required in the given context.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, BswModuleDescription.providedModeGroup, BswModuleDescription.required
ModeGroup, FirewallStateSwitchInterface.firewallStateMachine, FunctionGroupSet.functionGroup, Mode
SwitchInterface.modeGroup, Process.processStateMachine, StateManagementStateNotification.state
Machine
Attribute Type Mult. Kind Note
type ModeDeclarationGroup 0..1 tref The "collection of ModeDeclarations" ( = ModeDeclaration
Group) supported by a component
Stereotypes: isOfType

Table A.7: ModeDeclarationGroupPrototype

156 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Primitive NormalizedInstruction
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This meta-class is used to describe runtime budget needs on the target system within Deterministic
Client::WaitForActivation cycles. NormalizedInstructions does not reflect the actual number of code
instructions, but allows the description of comparative resource needs. NormalizedInstructions is used for
configuration of computing resources at integration time.
NormalizedInstruction = runtime in sec * clock frequency in Hz
Tags:
atp.Status=draft
xml.xsd.customType=NORMALIZED-INSTRUCTION
xml.xsd.pattern=[1-9][0-9]*
xml.xsd.type=string

Table A.8: NormalizedInstruction

Class Process
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This meta-class provides information required to execute the referenced Executable.
Tags: atp.recommendedPackage=Processes
Base ARElement, ARObject, AbstractExecutionContext, AtpClassifier , CollectableElement, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable, UploadableDeploymentElement, Uploadable
PackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
design ProcessDesign 0..1 ref This reference represents the identification of the
design-time representation for the Process that owns the
reference.
executable Executable * ref Reference to executable that is executed in the process.
Stereotypes: atpUriDef
functionCluster String 0..1 attr This attribute specifies which functional cluster the
Affiliation Process is affiliated with.
numberOf PositiveInteger 0..1 attr This attribute defines how often a process shall be
RestartAttempts restarted if the start fails.
numberOfRestartAttempts = "0" OR Attribute not existing,
start once
numberOfRestartAttempts = "1", start a second time
preMapping Boolean 0..1 attr This attribute describes whether the executable is
preloaded into the memory.
processState ModeDeclarationGroup 0..1 aggr Set of Process States that are defined for the process.
Machine Prototype
securityEvent SecurityEventDefinition * ref The reference identifies the collection of SecurityEvents
that can be reported by the Process.
Stereotypes: atpSplitable; atpUriDef
Tags:
atp.Splitkey=securityEvent
atp.Status=candidate
stateDependent StateDependentStartup * aggr Applicable startup configurations.
StartupConfig Config

Table A.9: Process

157 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Class ProcessArgument
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This meta-class has the ability to define command line arguments for processing by the Main function.
Base ARObject
Aggregated by StartupConfig.processArgument
Attribute Type Mult. Kind Note
argument String 0..1 attr This represents one command-line argument to be
processed by the executable software.

Table A.10: ProcessArgument

Class ProcessToMachineMapping
Package M2::AUTOSARTemplates::AdaptivePlatform::MachineManifest
Note This meta-class has the ability to associate a Process with a Machine. This relation involves the definition
of further properties, e.g. timeouts.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ProcessToMachineMappingSet.processToMachineMapping
Attribute Type Mult. Kind Note
design ProcessDesignTo 0..1 ref This reference represents the identification of the
MachineDesignMapping design-time representation for the ProcessToMachine
Mapping that owns the reference.
machine Machine 0..1 ref This reference identifies the Machine in the context of the
ProcessToMachineMapping.
nonOsModule NonOsModule 0..1 ref This supports the optional case that the process
Instantiation Instantiation represents a platform module.
persistency UriString 0..1 attr This attribute identifies a central place for the mapped
CentralStorage Process to store the list of available storages and version
URI information.
process Process 0..1 ref This reference identifies the Process in the context of the
ProcessToMachineMapping.
shallNotRunOn ProcessorCore * ref This reference indicates a collection of cores onto which
the mapped process shall not be executing.
shallRunOn ProcessorCore * ref This reference indicates a collection of cores onto which
the mapped process shall be executing.

Table A.11: ProcessToMachineMapping

Class Referrable (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable
Note Instances of this class can be referred to by their identifier (while adhering to namespace borders).
Base ARObject
Subclasses AtpDefinition, BswDistinguishedPartition, BswModuleCallPoint, BswModuleClientServerEntry, Bsw
VariableAccess, CouplingPortTrafficClassAssignment, CppImplementationDataTypeContextTarget,
DiagnosticEnvModeElement, EthernetPriorityRegeneration, ExclusiveAreaNestingOrder, HwDescription
Entity , ImplementationProps, ModeTransition, MultilanguageReferrable, NmNetworkHandle, Pnc
MappingIdent, SingleLanguageReferrable, SoConIPduIdentifier, SocketConnectionBundle, Someip
RequiredEventGroup, TimeSyncServerConfiguration, TpConnectionIdent
Attribute Type Mult. Kind Note
5

158 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Class Referrable (abstract)
shortName Identifier 1 attr This specifies an identifying shortName for the object. It
needs to be unique within its context and is intended for
humans but even more for technical reference.
Stereotypes: atpIdentityContributor
Tags:
xml.enforceMinMultiplicity=true
xml.sequenceOffset=-100
shortName ShortNameFragment * aggr This specifies how the Referrable.shortName is
Fragment composed of several shortNameFragments.
Tags: xml.sequenceOffset=-90

Table A.12: Referrable

Class ResourceConsumption
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption
Note Description of consumed resources by one implementation of a software.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by EcuResourceEstimation.bswResourceEstimation, EcuResourceEstimation.rteResourceEstimation,
Implementation.resourceConsumption, StateDependentStartupConfig.resourceConsumption
Attribute Type Mult. Kind Note
memoryUsage MemoryUsage * aggr Collection of the memory allocated by the owner.
Stereotypes: atpSplitable
Tags: atp.Splitkey=memoryUsage.shortName

Table A.13: ResourceConsumption

Class ResourceGroup
Package M2::AUTOSARTemplates::AdaptivePlatform::PlatformModuleDeployment::AdaptiveModule
Implementation
Note This meta-class represents a resource group that limits the resource usage of a collection of processes.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by OsModuleInstantiation.resourceGroup
Attribute Type Mult. Kind Note
cpuUsage PositiveInteger 0..1 attr CPU resource limit in percentage of the total CPU
capacity on the machine.
memUsage PositiveInteger 0..1 attr Memory limit in bytes.

Table A.14: ResourceGroup

Class SoftwareCluster
Package M2::AUTOSARTemplates::AdaptivePlatform::SoftwareDistribution
Note This meta-class represents the ability to define an uploadable software-package, i.e. the SoftwareCluster
shall contain all software and configuration for a given purpose.
Tags: atp.recommendedPackage=SoftwareClusters
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, UploadableDeploymentElement, UploadablePackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
5

159 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Class SoftwareCluster
artifact ArtifactChecksum * aggr This aggregation carries the checksums for artifacts
Checksum contained in the enclosing SoftwareCluster. Please note
that the value of these checksums is only applicable at
the time of configuration.
Stereotypes: atpSplitable
Tags: atp.Splitkey=artifactChecksum.shortName, artifact
Checksum.uri
artifactLocator ArtifactLocator * aggr This aggregation represents the artifact locations that are
relevant in the context of the enclosing SoftwareCluster
claimed ModeDeclarationGroup * ref Each SoftwareCluster can reserve the usage of a given
FunctionGroup Prototype functionGroup such that no other SoftwareCluster is
allowed to use it
conflictsTo SoftwareCluster 0..1 aggr This aggregation handles conflicts. If it yields true then
DependencyFormula the SoftwareCluster shall not be installed.
Stereotypes: atpSplitable
Tags: atp.Splitkey=conflictsTo
contained ARElement * ref This reference represents the collection of model
ARElement elements that cannot derive from UploadablePackage
Element and that contribute to the completeness of the
definition of the SoftwareCluster.
Stereotypes: atpSplitable
Tags: atp.Splitkey=containedARElement
containedFibex FibexElement * ref This allows for referencing FibexElements that need to be
Element considered in the context of a SoftwareCluster.
contained UploadablePackage * ref This reference identifies model elements that are required
Package Element to complete the manifest content.
Element
Stereotypes: atpSplitable
Tags: atp.Splitkey=containedPackageElement
contained Process * ref This reference represent the processes contained in the
Process enclosing SoftwareCluster.
dependsOn SoftwareCluster 0..1 aggr This aggregation can be taken to identify a dependency
DependencyFormula for the enclosing SoftwareCluster.
Stereotypes: atpSplitable
Tags: atp.Splitkey=dependsOn
design SoftwareClusterDesign * ref This reference represents the identification of all Software
ClusterDesigns applicable for the enclosing Software
Cluster.
Stereotypes: atpUriDef
diagnostic SoftwareCluster 0..1 ref This reference identifies the applicable SoftwareCluster
Deployment DiagnosticDeployment DiagnosticDeploymentProps that are applicable for the
Props Props referencing SoftwareCluster.
installation SoftwareCluster 0..1 attr This attribute controls the behavior of the SoftwareCluster
Behavior InstallationBehavior in terms of installation.
Enum
license Documentation * ref This attribute allows for the inclusion of the full text of a
license of the enclosing SoftwareCluster. In many cases
open source licenses require the inclusion of the full
license text to any software that is released under the
respective license.
module AdaptiveModule * ref This reference identifies AdaptiveModuleInstantiations
Instantiation Instantiation that need to be included with the SoftwareCluster in order
to establish infrastructure required for the installation of
the SoftwareCluster.
Stereotypes: atpSplitable
Tags: atp.Splitkey=moduleInstantiation
5

160 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Class SoftwareCluster
releaseNotes Documentation 0..1 ref This attribute allows for the explanations of changes since
the previous version. The list of changes might require
the creation of multiple paragraphs of test.
typeApproval String 0..1 attr This attribute carries the homologation information that
may be specific for a given country.
vendorId PositiveInteger 0..1 attr Vendor ID of this Implementation according to the
AUTOSAR vendor list.
vendor CryptoService 0..1 ref This reference identifies the certificate that represents the
Signature Certificate vendor’s signature.
version StrongRevisionLabel 0..1 attr This attribute can be used to describe a version
String information for the enclosing SoftwareCluster.

Table A.15: SoftwareCluster

Class StartupConfig
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This meta-class represents a reusable startup configuration for processes..
Tags: atp.recommendedPackage=StartupConfigs
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, UploadableDeploymentElement, UploadablePackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
environment TagWithOptionalValue * aggr This aggregation represents the collection of environment
Variable variables that shall be added to the respective Process’s
environment prior to launch.
executionError ProcessExecutionError 0..1 ref this reference is used to identify the applicable execution
error
permissionTo Boolean 0..1 attr This attribute defines if Process is permitted to create
CreateChild child Processes. When setting this parameter to true two
Process things should be kept in mind: 1) safety and security
implication of this configuration, 2) the fact that Process
will assume management responsibilities for child
Processes (i.e. it will be responsible for terminating
Processes that it creates).
process ProcessArgument * aggr This aggregation represents the collection of
Argument command-line arguments applicable to the enclosing
(ordered) StartupConfig.
scheduling String 0..1 attr This attribute represents the ability to define the
Policy scheduling policy for the initial thread of the application.
scheduling Integer 0..1 attr This is the scheduling priority requested by the
Priority application itself.
termination TerminationBehavior 0..1 attr This attribute defines the termination behavior of the
Behavior Enum Process.
timeout EnterExitTimeout 0..1 aggr This aggregation can be used to specify the timeouts for
launching and terminating the process depending on the
StartupConfig.

Table A.16: StartupConfig

161 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

Class StateDependentStartupConfig
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This meta-class defines the startup configuration for the process depending on a collection of machine
states.
Base ARObject
Aggregated by Process.stateDependentStartupConfig
Attribute Type Mult. Kind Note
execution ExecutionDependency * aggr This attribute defines that all processes that are
Dependency referenced via the ExecutionDependency shall be
launched and shall reach a certain ProcessState before
the referencing process is started.
functionGroup ModeDeclaration * iref This represent the applicable functionGroupMode.
State
InstanceRef implemented by: FunctionGroupStateIn
FunctionGroupSetInstanceRef
resource ResourceConsumption 0..1 aggr This aggregation provides the ability to define resource
Consumption consumption boundaries on a per-process-startup-config
basis.
resourceGroup ResourceGroup 0..1 ref Reference to an applicable resource group.
startupConfig StartupConfig 0..1 ref Reference to a reusable startup configuration with startup
parameters.

Table A.17: StateDependentStartupConfig

Class TagWithOptionalValue
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::TagWithOptionalValue
Note A tagged value is a combination of a tag (key) and a value that gives supplementary information that is
attached to a model element. Please note that keys without a value are allowed.
Base ARObject
Aggregated by AbstractServiceInstance.capabilityRecord, Machine.environmentVariable, ProvidedSomeipService
Instance.capabilityRecord, RequiredSomeipServiceInstance.capabilityRecord, SdClientConfig.capability
Record, SdServerConfig.capabilityRecord, StartupConfig.environmentVariable
Attribute Type Mult. Kind Note
key String 0..1 attr Defines a key.
sequenceOffset Integer 0..1 attr The sequenceOffset attribute supports the use case
where TagWithOptionalValue is aggregated as splitable. If
multiple aggregations define the same value of attribute
key then the order in which the value collection is merged
might be significant. As an example consider the
modeling of the $PATH environment variable by means of
a meta class TagWithOptionalValue. The sequenceOffset
describes the relative position of each contribution in the
concatenated value. The contributions are sorted in
increasing integer order.
value String 0..1 attr Defines the corresponding value.

Table A.18: TagWithOptionalValue

Enumeration TerminationBehaviorEnum
Package M2::AUTOSARTemplates::AdaptivePlatform::ExecutionManifest
Note This enumeration provides options for controlling of how a Process terminates.
Aggregated by StartupConfig.terminationBehavior
Literal Description
5

162 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Enumeration TerminationBehaviorEnum
processIsNotSelf The Process terminates only on request from Execution Management.
Terminating
Tags: atp.EnumerationLiteralIndex=0
processIsSelf The Process is allowed to terminate without request from Execution Management.
Terminating
Tags: atp.EnumerationLiteralIndex=1

Table A.19: TerminationBehaviorEnum

Enumeration TrustedPlatformExecutableLaunchBehaviorEnum
Package M2::AUTOSARTemplates::AdaptivePlatform::MachineManifest
Note This enumeration provides options for controlling the behavior of how authentication affects the ability
to launch an Executable.
Aggregated by Machine.trustedPlatformExecutableLaunchBehavior
Literal Description
monitorMode An Executable shall always launch, even if the corresponding authentication fails
Tags: atp.EnumerationLiteralIndex=1
noTrustedPlatform This value shall be used if there is no TrustedPlatform support on the Machine
Support
Tags: atp.EnumerationLiteralIndex=2
strictMode An Executable shall not launch if the corresponding authentication fails.
Tags: atp.EnumerationLiteralIndex=0

Table A.20: TrustedPlatformExecutableLaunchBehaviorEnum

163 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B History of Constraints and Specification Items

Please note that the lists in this chapter also include constraints and specification items
that have been removed from the specification in a later version. These constraints and
specification items do not appear as hyperlinks in the document.

B.1 Constraint and Specification Item History of this document

according to AUTOSAR Release 17-03

B.1.1 Added Specification Items in 17-03

Number Heading
[SWS_EM_00017] Application Processes
[SWS_EM_01000] Startup order
[SWS_EM_01002] Idle Process State
[SWS_EM_01003] Starting Process State
[SWS_EM_01004] Running Process State
[SWS_EM_01005] Terminating Process State
[SWS_EM_01006] Terminated Process State
[SWS_EM_01012] Application Argument Passing
[SWS_EM_01013] Machine State
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01017] Application Binary Name
[SWS_EM_01023] Machine State Startup
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01026] Machine State change
[SWS_EM_01027] Rejection of Client Requests
[SWS_EM_01028] GetMachineState API
[SWS_EM_01029] SetMachineState API
[SWS_EM_01030] Start of Application execution
[SWS_EM_01033] Application start-up configuration
[SWS_EM_01034] Deny SetMachineState API Request
[SWS_EM_01035] Machine State Restart behavior
[SWS_EM_01036] Machine State Shutdown behavior
[SWS_EM_01037] Machine State Startup behavior
[SWS_EM_01039] Scheduling priority range for SCHED_FIFO and SCHED_RR
[SWS_EM_01040] Scheduling priority range for SCHED_OTHER
5

164 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01041] Scheduling FIFO
[SWS_EM_01042] Scheduling Round-Robin
[SWS_EM_01043] Scheduling Other
[SWS_EM_01050] Start dependent Application Executables
[SWS_EM_01051] Shutdown Application Executables
[SWS_EM_01052] Application State Initializing
[SWS_EM_01053] Application State Running
[SWS_EM_01055] Application State Termination
[SWS_EM_01056] Machine State Management Application
[SWS_EM_01057] Machine State Change arbitration
[SWS_EM_01058] Shutdown of the Operating System
[SWS_EM_01059] Restart of the Operating System
[SWS_EM_01060] Machine State change behavior
[SWS_EM_02000]
[SWS_EM_02001]
[SWS_EM_02002]
[SWS_EM_02003]
[SWS_EM_02005]
[SWS_EM_02006]
[SWS_EM_02007]
[SWS_EM_02008]
[SWS_EM_02009]
[SWS_EM_02014]
[SWS_EM_02019]
[SWS_EM_02030]
[SWS_EM_02031] Application State Reporting
[SWS_EM_99999]
[SWS_OSI_01007]
Table B.1: Added Specification Items in 17-03

B.1.2 Changed Specification Items in 17-03

none

B.1.3 Deleted Specification Items in 17-03

none

165 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.1.4 Added Constraints in 17-03

none

B.1.5 Changed Constraints in 17-03

none

B.1.6 Deleted Constraints in 17-03

none

B.2 Constraint and Specification Item History of this document

according to AUTOSAR Release 17-10

B.2.1 Added Specification Items in 17-10

Number Heading
[SWS_EM_01001] Execution Dependency error
[SWS_EM_01016] RestartProcess API
[SWS_EM_01018] OverrideState API
[SWS_EM_01032] Machine States
[SWS_EM_01061] OverrideState API interrupt
[SWS_EM_01062] RestartProcess behaviour
[SWS_EM_01107] Function Group name
[SWS_EM_01108] Function Group State
[SWS_EM_01109] State References
[SWS_EM_01110] Off States
[SWS_EM_01111] No reference to Off State
[SWS_EM_01112] StartupConfig
[SWS_EM_01201] Core Binding
[SWS_EM_02041] ResetCause Enumeration
[SWS_EM_02042] ApplicationClient::SetLastResetCause API
[SWS_EM_02043] ApplicationClient::GetLastResetCause API
[SWS_EM_02044] Machine State change in progress
[SWS_EM_02047] StateClient::GetState API
[SWS_EM_02048] Function Group State change in progress
[SWS_EM_02049] State change failed
5

166 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02050] State change successful
[SWS_EM_02051] Machine State change in progress
[SWS_EM_02054] StateClient::SetState API
[SWS_EM_02055] Function Group State change in progress
[SWS_EM_02056] State change failed
[SWS_EM_02057] State change successful
[SWS_EM_02070] ApplicationReturnType Enumeration
[SWS_EM_02071]
[SWS_EM_02072] Retrieving Machine State
[SWS_EM_02073] Retrieving Function Group State
[SWS_EM_02074] Setting Machine State
[SWS_EM_02075] Setting Function Group State
[SWS_EM_NA]
Table B.2: Added Specification Items in 17-10

B.2.2 Changed Specification Items in 17-10

Number Heading
[SWS_EM_01000] Startup order
[SWS_EM_01002] Idle Process State
[SWS_EM_01003] Starting Process State
[SWS_EM_01004] Running Process State
[SWS_EM_01005] Terminating Process State
[SWS_EM_01006] Terminated Process State
[SWS_EM_01012] Application Argument Passing
[SWS_EM_01013] Machine State and Function Group State
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01017] Application Binary Name
[SWS_EM_01023] Machine State Startup
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01026] State change
[SWS_EM_01028] GetState API
[SWS_EM_01030] Start of Application execution
[SWS_EM_01033] Application start-up configuration
5

167 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01034] Deny State change request
[SWS_EM_01035] Machine State Restart behavior
[SWS_EM_01036] Machine State Shutdown behavior
[SWS_EM_01037] Machine State Startup behavior
[SWS_EM_01039] Scheduling priority range for SCHED_FIFO and SCHED_RR
[SWS_EM_01040] Scheduling priority range for SCHED_OTHER
[SWS_EM_01041] Scheduling FIFO
[SWS_EM_01042] Scheduling Round-Robin
[SWS_EM_01043] Scheduling Other
[SWS_EM_01050] Start dependent Application Executables
[SWS_EM_01051] Shutdown Application Executables
[SWS_EM_01053] Application State Running
[SWS_EM_01055] Application State Termination
[SWS_EM_01056] State Manager
[SWS_EM_01058] Shutdown of the Operating System
[SWS_EM_01059] Restart of the Operating System
[SWS_EM_01060] State change behavior
[SWS_EM_02000] ApplicationState Enumeration
[SWS_EM_02001]
[SWS_EM_02002] ApplicationClient::~ApplicationClient API
[SWS_EM_02003] ApplicationClient::ReportApplicationState API
[SWS_EM_02005] StateReturnType Enumeration
[SWS_EM_02006]
[SWS_EM_02007] StateClient::StateClient API
[SWS_EM_02008] StateClient::~StateClient API
[SWS_EM_02030] ApplicationClient::ApplicationClient API
[SWS_EM_02031] Application State Reporting
Table B.3: Changed Specification Items in 17-10

B.2.3 Deleted Specification Items in 17-10

Number Heading
[SWS_EM_00017] Application Processes
[SWS_EM_01027] Rejection of Client Requests
[SWS_EM_01029] SetMachineState API
5

168 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01052] Application State Initializing
[SWS_EM_01057] Machine State Change arbitration
[SWS_EM_02009]
[SWS_EM_02014]
[SWS_EM_02019]
[SWS_EM_99999]
Table B.4: Deleted Specification Items in 17-10

B.2.4 Added Constraints in 17-10

none

B.2.5 Changed Constraints in 17-10

none

B.2.6 Deleted Constraints in 17-10

none

B.3 Constraint and Specification Item History of this document

according to AUTOSAR Release 18-03

B.3.1 Added Specification Items in 18-03

Number Heading
[SWS_EM_01044] Machine States Identification
[SWS_EM_01063] Process Restart Failed
[SWS_EM_01064] Process Restart Successful
[SWS_EM_01065] Shutdown state timeout monitoring behavior
[SWS_EM_01066] Start state change behavior
[SWS_EM_01067] Confirm State Changes
[SWS_EM_01068] Report start-up timeout
5

169 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01069] Self-terminating Process State
[SWS_EM_01070] Acknowledgement of termination request
[SWS_EM_01071] Initiation of Process self-termination
[SWS_EM_01072] Application Argument Zero
[SWS_EM_01073] Simple Arguments
[SWS_EM_01074] Short form arguments with option value
[SWS_EM_01075] Short form Arguments without option value
[SWS_EM_01076] Long form Arguments with option value
[SWS_EM_01077] Long form Arguments without option value
[SWS_EM_01301] Cyclic Execution
[SWS_EM_01302] Cyclic Execution Control
[SWS_EM_01305] Worker Pool
[SWS_EM_01308] Random Numbers
[SWS_EM_01310] Get Activation Time
[SWS_EM_01311] Activation Time Unknown
[SWS_EM_01312] Get Next Activation Time
[SWS_EM_01313] Next Activation Time Unknown
[SWS_EM_02058] State Transition Timeout
[SWS_EM_02102] Memory control
[SWS_EM_02103] CPU usage control
[SWS_EM_02104] Core affinity
[SWS_EM_02106] ResourceGroup assignment
[SWS_EM_02107] Maximum heap
[SWS_EM_02108] Maximum system memory usage
[SWS_EM_02109] Process pre-mapping
[SWS_EM_02201] ActivationReturnType Enumeration
[SWS_EM_02202] ActivationTimeStampReturnType Enumeration
[SWS_EM_02210]
[SWS_EM_02211] DeterministicClient::DeterministicClient API
[SWS_EM_02215] DeterministicClient::~DeterministicClient API
[SWS_EM_02216] DeterministicClient::WaitForNextActivation API
[SWS_EM_02220] DeterministicClient::RunWorkerPool API
[SWS_EM_02225] DeterministicClient::GetRandom API
[SWS_EM_02230] DeterministicClient::GetActivationTime API
[SWS_EM_02235] DeterministicClient::GetNextActivationTime API
Table B.5: Added Specification Items in 18-03

170 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.3.2 Changed Specification Items in 18-03

Number Heading
[SWS_EM_01000] Startup order
[SWS_EM_01001] Execution Dependency error
[SWS_EM_01002] Idle Process State
[SWS_EM_01003] Starting Process State
[SWS_EM_01004] Running Process State
[SWS_EM_01005] Terminating Process State
[SWS_EM_01006] Terminated Process State
[SWS_EM_01012] Application Argument Passing
[SWS_EM_01013] Machine State and Function Group State
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01016] Restart Process
[SWS_EM_01018] Override State
[SWS_EM_01023] Machine State Startup
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01026] State Change
[SWS_EM_01028] Get State Information
[SWS_EM_01030] Start of Process execution
[SWS_EM_01032] Machine States Obtainment
[SWS_EM_01033] Application start-up configuration
[SWS_EM_01034] Deny State Change Request
[SWS_EM_01035] Machine State Restart behavior
[SWS_EM_01036] Machine State Shutdown behavior
[SWS_EM_01037] Machine State Startup behavior
[SWS_EM_01041] Scheduling FIFO
[SWS_EM_01042] Scheduling Round-Robin
[SWS_EM_01043] Scheduling Other
[SWS_EM_01050] Start Dependent Processes
[SWS_EM_01051] Shutdown Processes
[SWS_EM_01053] Application State Running
[SWS_EM_01055] Initiation of Process termination
[SWS_EM_01058] Shutdown of the Operating System
[SWS_EM_01059] Restart of the Operating System
[SWS_EM_01060] Shutdown state change behavior
[SWS_EM_01061] Override State Interrupt
5

171 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01062] Restart Process Behavior
[SWS_EM_01107] Function Group name
[SWS_EM_01108] Function Group State
[SWS_EM_01109] State References
[SWS_EM_01110] Off States
[SWS_EM_02001]
[SWS_EM_02044] State Change in Progress
[SWS_EM_02049] State Change Failed
[SWS_EM_02050] State Information Success
[SWS_EM_02056] State Change Failed
[SWS_EM_02057] State Change Successful
[SWS_EM_NA]
Table B.6: Changed Specification Items in 18-03

B.3.3 Deleted Specification Items in 18-03

Number Heading
[SWS_EM_01017] Application Binary Name
[SWS_EM_01056] State Manager
[SWS_EM_01112] StartupConfig
[SWS_EM_01201] Core Binding
[SWS_EM_02005] StateReturnType Enumeration
[SWS_EM_02006]
[SWS_EM_02007] StateClient::StateClient API
[SWS_EM_02008] StateClient::~StateClient API
[SWS_EM_02031] Application State Reporting
[SWS_EM_02041] ResetCause Enumeration
[SWS_EM_02042] ApplicationClient::SetLastResetCause API
[SWS_EM_02043] ApplicationClient::GetLastResetCause API
[SWS_EM_02047] StateClient::GetState API
[SWS_EM_02048] Function Group State change in progress
[SWS_EM_02051] Machine State change in progress
[SWS_EM_02054] StateClient::SetState API
[SWS_EM_02055] Function Group State change in progress
[SWS_EM_02071]
[SWS_EM_02072] Retrieving Machine State
5

172 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02073] Retrieving Function Group State
[SWS_EM_02074] Setting Machine State
[SWS_EM_02075] Setting Function Group State
Table B.7: Deleted Specification Items in 18-03

B.3.4 Added Constraints in 18-03

none

B.3.5 Changed Constraints in 18-03

none

B.3.6 Deleted Constraints in 18-03

none

B.4 Constraint and Specification Item History of this document

according to AUTOSAR Release 18-10

B.4.1 Added Specification Items in 18-10

none

B.4.2 Changed Specification Items in 18-10

Number Heading
[SWS_EM_01000] Startup order
[SWS_EM_01001] Execution Dependency error
[SWS_EM_01004] Running Process State
[SWS_EM_01005] Terminating Process State
[SWS_EM_01012] Process Argument Passing
[SWS_EM_01013] Machine State and Function Group State
5

173 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01018] Override State
[SWS_EM_01023] Machine State Startup
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01026] State Change
[SWS_EM_01028] Get State Information
[SWS_EM_01033] Process start-up configuration
[SWS_EM_01034] Deny State Change Request
[SWS_EM_01035] Machine State Restart behavior
[SWS_EM_01036] Machine State Shutdown behavior
[SWS_EM_01037] Machine State Startup behavior
[SWS_EM_01039] Scheduling priority range for SCHED_FIFO and SCHED_RR
[SWS_EM_01040] Scheduling priority range for SCHED_OTHER
[SWS_EM_01041] Scheduling FIFO
[SWS_EM_01042] Scheduling Round-Robin
[SWS_EM_01043] Scheduling Other
[SWS_EM_01053] Execution State Running
[SWS_EM_01060] Shutdown state change behavior
[SWS_EM_01065] Shutdown state timeout monitoring behavior
[SWS_EM_01066] Start state change behavior
[SWS_EM_01067] Confirm State Changes
[SWS_EM_01069] Self-terminating Process State
[SWS_EM_01070] Acknowledgement of termination request
[SWS_EM_01071] Initiation of Process self-termination
[SWS_EM_01072] Process Argument Zero
[SWS_EM_01074] Short form arguments with option value
[SWS_EM_01075] Short form Arguments without option value
[SWS_EM_01076] Long form Arguments with option value
[SWS_EM_01077] Long form Arguments without option value
[SWS_EM_01107] Function Group configuration
[SWS_EM_01109] Misconfigured Process instances
[SWS_EM_01110] Off States
[SWS_EM_02000] ExecutionState Enumeration
[SWS_EM_02001]
[SWS_EM_02002] ExecutionClient::~ExecutionClient API
[SWS_EM_02003] ExecutionClient::ReportExecutionState API
5

174 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02030] ExecutionClient::ExecutionClient API
[SWS_EM_02044] State Change in Progress
[SWS_EM_02049] State Change Failed
[SWS_EM_02070] ExecutionReturnType Enumeration
[SWS_EM_02109] Process pre-mapping
[SWS_EM_02210]
[SWS_EM_NA]
Table B.8: Changed Specification Items in 18-10

B.4.3 Deleted Specification Items in 18-10

Number Heading
[SWS_EM_01044] Machine States Identification
[SWS_EM_01108] Function Group State
[SWS_EM_01111] No reference to Off State
Table B.9: Deleted Specification Items in 18-10

B.4.4 Added Constraints in 18-10

none

B.4.5 Changed Constraints in 18-10

none

B.4.6 Deleted Constraints in 18-10

none

175 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.5 Constraint and Specification Item History of this document

according to AUTOSAR Release 19-03

B.5.1 Added Specification Items in R19-03

Number Heading
[SWS_EM_02250] Machine State Startup
[SWS_EM_02251] State transition - restart behavior
[SWS_EM_02252] State transition - Process termination timeout reporting
[SWS_EM_02253] State transition - Process start-up timeout monitoring
[SWS_EM_02254] Misconfigured Process - assigned to more than one Function Group
[SWS_EM_02255] State transition - Process termination timeout reaction
[SWS_EM_02256] State transition - Process start-up timeout reaction
Table B.10: Added Specification Items in R19-03

B.5.2 Changed Specification Items in R19-03

Number Heading
[SWS_EM_01001] Execution Dependency error
[SWS_EM_01005] Terminating Process State
[SWS_EM_01012] Process Argument Passing
[SWS_EM_01013] Function Group State
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01023] Self initiation of Machine State Startup transition
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01060] State transition - termination behavior
[SWS_EM_01065] State transition - Process termination timeout monitoring
[SWS_EM_01066] State transition - start behavior
[SWS_EM_01067] Finish of a successful state transition
[SWS_EM_01068] State transition - Process start-up timeout reporting
[SWS_EM_01109] Misconfigured Process - not assigned to a Function Group
[SWS_EM_01110] Off States
[SWS_EM_01400] Execution Dependency resolution
[SWS_EM_02000]
[SWS_EM_02001]
[SWS_EM_02201]
5

176 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02202]
[SWS_EM_02210]
[SWS_EM_02241] Machine State Startup Completion
[SWS_EM_02245] Dependency resolution during state change
[SWS_EM_02246] Process specific Environment Variables
Table B.11: Changed Specification Items in R19-03

B.5.3 Deleted Specification Items in R19-03

Number Heading
[SWS_EM_01035] Machine State Restart behavior
[SWS_EM_01036] Machine State Shutdown behavior
[SWS_EM_02002] ExecutionClient::~ExecutionClient API
[SWS_EM_02003] ExecutionClient::ReportExecutionState API
[SWS_EM_02030] ExecutionClient::ExecutionClient API
[SWS_EM_02070] ExecutionReturnType Enumeration
[SWS_EM_02211] DeterministicClient::DeterministicClient API
[SWS_EM_02215] DeterministicClient::~DeterministicClient API
[SWS_EM_02216] DeterministicClient::WaitForNextActivation API
[SWS_EM_02220] DeterministicClient::RunWorkerPool API
[SWS_EM_02225] DeterministicClient::GetRandom API
[SWS_EM_02230] DeterministicClient::GetActivationTime API
[SWS_EM_02235] DeterministicClient::GetNextActivationTime API
Table B.12: Deleted Specification Items in R19-03

B.5.4 Added Constraints in R19-03

none

B.5.5 Changed Constraints in R19-03

none

177 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.5.6 Deleted Constraints in R19-03

none

B.6 Constraint and Specification Item History of this document

according to AUTOSAR Release R19-11

B.6.1 Added Specification Items in R19-11

Number Heading
[SWS_EM_01401] Process Self Reporting
[SWS_EM_01402] Implicit Running Process State
[SWS_EM_01403] Reporting Non-reporting Process
[SWS_EM_01404] Terminating Process State after Termination Request
[SWS_EM_01405] Terminating Process State after Terminating Report
[SWS_EM_02002]
[SWS_EM_02003]
[SWS_EM_02030]
[SWS_EM_02211]
[SWS_EM_02215]
[SWS_EM_02216]
[SWS_EM_02220]
[SWS_EM_02225]
[SWS_EM_02230]
[SWS_EM_02235]
[SWS_EM_02257] Recovery Action API Security
[SWS_EM_02258] State transition - Process termination timeout reporting
[SWS_EM_02259] State transition - Process start-up timeout reporting
[SWS_EM_02260] State transition - Process start-up timeout reaction
[SWS_EM_02261] Enter Unrecoverable State
[SWS_EM_02262] Enter Unrecoverable State Behavior
[SWS_EM_02263]
[SWS_EM_02264]
[SWS_EM_02265]
[SWS_EM_02266]
[SWS_EM_02267]
[SWS_EM_02268]
[SWS_EM_02269]
[SWS_EM_02270]
5

178 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02271]
[SWS_EM_02272]
[SWS_EM_02273]
[SWS_EM_02274]
[SWS_EM_02275]
[SWS_EM_02276]
[SWS_EM_02277]
[SWS_EM_02278]
[SWS_EM_02279]
[SWS_EM_02281]
[SWS_EM_02282]
[SWS_EM_02283]
[SWS_EM_02284]
[SWS_EM_02286]
[SWS_EM_02287]
[SWS_EM_02288]
[SWS_EM_02289]
[SWS_EM_02290]
[SWS_EM_02291]
[SWS_EM_02292]
[SWS_EM_02297] StateClient usage restriction
[SWS_EM_02298] Canceling ongoing state transition
[SWS_EM_02299] Availability of a Trust Anchor
[SWS_EM_02300] Integrity and Authenticity of processed Machine Manifest
[SWS_EM_02301] Integrity and Authenticity of each Executable
[SWS_EM_02302] Integrity and Authenticity of shared objects
[SWS_EM_02303] Integrity and Authenticity of processed Execution Manifests
[SWS_EM_02304] Integrity and Authenticity of processed Service Instance Manifests
[SWS_EM_02305] Failed authenticity checks
[SWS_EM_02306] Machine Manifest
[SWS_EM_02307] Strict Mode - Execution manifest
[SWS_EM_02308] Strict Mode - Service Instance manifests
[SWS_EM_02309] Strict Mode - Executables
Table B.13: Added Specification Items in R19-11

179 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.6.2 Changed Specification Items in R19-11

Number Heading
[SWS_EM_01000] Startup order
[SWS_EM_01001] Execution Dependency error
[SWS_EM_01002] Idle Process State
[SWS_EM_01003] Starting Process State
[SWS_EM_01004] Running Process State of Reporting Processes
[SWS_EM_01006] Terminated Process State
[SWS_EM_01012] Process Argument Passing
[SWS_EM_01013] Function Group State
[SWS_EM_01014] Scheduling policy
[SWS_EM_01015] Scheduling priority
[SWS_EM_01016] Process Restart
[SWS_EM_01023] Self initiation of Machine State Startup transition
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_01025] Machine State Restart
[SWS_EM_01030] Restriction of process creation right for Processes
[SWS_EM_01032] Machine States configuration
[SWS_EM_01033] Process start-up configuration
[SWS_EM_01041] Scheduling FIFO
[SWS_EM_01042] Scheduling Round-Robin
[SWS_EM_01043] Scheduling Other
[SWS_EM_01050] Start Dependent Processes
[SWS_EM_01051] Termination of Processes
[SWS_EM_01055] Initiation of Process termination
[SWS_EM_01060] State transition - termination behavior
[SWS_EM_01062] Process Restart Behavior
[SWS_EM_01063] Process Restart Failed
[SWS_EM_01064] Process Restart Successful
[SWS_EM_01065] State transition - Process termination timeout monitoring
[SWS_EM_01066] State transition - start behavior
[SWS_EM_01067] Finish of a successful state transition
[SWS_EM_01071] Premature Termination of a Reporting Process
[SWS_EM_01072] Process Argument Zero
[SWS_EM_01073] Simple Arguments
[SWS_EM_01074] Short form arguments with option value
[SWS_EM_01075] Short form Arguments without option value
[SWS_EM_01076] Long form Arguments with option value
5

180 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01077] Long form Arguments without option value
[SWS_EM_01107] Function Group configuration
[SWS_EM_01109] Misconfigured Process - not assigned to a Function Group
[SWS_EM_01110] Off States
[SWS_EM_01301] Cyclic Execution
[SWS_EM_01302] Cyclic Execution Control
[SWS_EM_01303] Cyclic Execution Control Sequence
[SWS_EM_01304] Service Modification
[SWS_EM_01305] Worker Pool
[SWS_EM_01306] Processing Container Objects
[SWS_EM_01308] Random Numbers
[SWS_EM_01310] Get Activation Time
[SWS_EM_01311] Activation Time Unknown
[SWS_EM_01312] Get Next Activation Time
[SWS_EM_01313] Next Activation Time Unknown
[SWS_EM_01351] Execution Cycle Time
[SWS_EM_01352] Execution Cycle Timeout
[SWS_EM_01353] Event-triggered Cycle Activation
[SWS_EM_02076] Get Process States Information
[SWS_EM_02077] Process State Transition Event
[SWS_EM_02102] Memory control
[SWS_EM_02103] CPU usage control
[SWS_EM_02104] Core affinity
[SWS_EM_02106] ResourceGroup assignment
[SWS_EM_02107] Maximum heap
[SWS_EM_02108] Maximum system memory usage
[SWS_EM_02109] Process pre-mapping
[SWS_EM_02241] Machine State Startup Completion
[SWS_EM_02242] Further Function Group State Changes
[SWS_EM_02243] Handling Execution State Running
[SWS_EM_02244] Handling Execution State Terminating
[SWS_EM_02245] Dependency resolution during state change
[SWS_EM_02246] Process specific Environment Variables
[SWS_EM_02247] Machine specific Environment Variables
[SWS_EM_02248] Environment Variables precedence
[SWS_EM_02249] Missing value from Environment Variable definition
[SWS_EM_02250] Machine State Startup
[SWS_EM_02251] State transition - restart behavior
[SWS_EM_02253] State transition - Process start-up timeout monitoring
5

181 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02254] Misconfigured Process - assigned to more than one Function Group
[SWS_EM_02255] State transition - Process termination timeout reaction
Table B.14: Changed Specification Items in R19-11

B.6.3 Deleted Specification Items in R19-11

Number Heading
[SWS_EM_01005] Terminating Process State
[SWS_EM_01018] Enter Safe State
[SWS_EM_01026] State Change
[SWS_EM_01028] Get State Information
[SWS_EM_01034] Deny State Change Request
[SWS_EM_01053] Execution State Running
[SWS_EM_01061] Enter Safe State Behavior
[SWS_EM_01068] State transition - Process start-up timeout reporting
[SWS_EM_01070] Acknowledgement of termination request
[SWS_EM_01400] Execution Dependency resolution
[SWS_EM_02044] State Change in Progress
[SWS_EM_02049] State Change Failed
[SWS_EM_02050] State Information Success
[SWS_EM_02056] State Change Failed
[SWS_EM_02057] State Change Successful
[SWS_EM_02058] State Transition Timeout
[SWS_EM_02252] State transition - Process termination timeout reporting
[SWS_EM_02256] State transition - Process start-up timeout reaction
Table B.15: Deleted Specification Items in R19-11

B.6.4 Added Constraints in R19-11

none

B.6.5 Changed Constraints in R19-11

none

182 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.6.6 Deleted Constraints in R19-11

none

B.7 Constraint and Specification Item History of this document

according to AUTOSAR Release R20-11

B.7.1 Added Specification Items in R20-11

Number Heading
[SWS_EM_01314] Default value for terminationBehavior
[SWS_EM_01309] Unexpected Termination of a process
[SWS_EM_01078] Process Argument strings
[SWS_EM_02311] Order of process termination timeout reaction
[SWS_EM_02310] State transition - process termination after start-up timeout reaction
[SWS_EM_02312] Order of process start-up timeout reaction
[SWS_EM_02280] Effect on Execution Dependency
Unexpected Termination of starting processes during Function Group State
[SWS_EM_02313]
transition
Unexpected Termination of terminating processes during Function Group
[SWS_EM_02314]
State transition
[SWS_EM_01320] Number of DeterministicClients
[SWS_EM_01321] Minimum number of required synchronization requests
[SWS_EM_01322] Calculation of the next cycle
[SWS_EM_01323] Total kRun loop count
[SWS_EM_01324] Infinite kRun loop
[SWS_EM_01325] Synchronization Request Message
[SWS_EM_01326] Synchronization Response Message
[SWS_EM_01327] Return of the wait point API
[SWS_EM_02032] On entry to the Unrecoverable State
[SWS_EM_02033] After execution of the pre-cleanup action
[SWS_EM_02034] After all processes managed by Execution Management terminated,
[SWS_EM_02400] Properties of IAM-configuration assigned to processes
[SWS_EM_02203] DeterministicClient::TimeStamp
[SWS_EM_02541] ExecutionError
[SWS_EM_02544] ExecutionErrorEvent
[SWS_EM_02545] ExecutionErrorEvent::executionError
[SWS_EM_02546] ExecutionErrorEvent::functionGroup
[SWS_EM_02510] WorkerRunnable class
[SWS_EM_02520] WorkerRunnable::Run
5

183 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02530] WorkerThread class
[SWS_EM_02531] WorkerThread::WorkerThread
[SWS_EM_02532] WorkerThread:: WorkerThread
[SWS_EM_02540] WorkerThread::GetRandom
[SWS_EM_02217] DeterministicClient::WaitForActivation
[SWS_EM_02221] DeterministicClient::RunWorkerPool
[SWS_EM_02226] DeterministicClient::SetRandomSeed
[SWS_EM_02231] DeterministicClient::GetActivationTime
[SWS_EM_02236] DeterministicClient::GetNextActivationTime
[SWS_EM_02542] StateClient::GetExecutionError
[SWS_EM_02543] Default value for ExecutionError
[SWS_EM_02290] GetExecErrorDomain
[SWS_EM_02291] MakeErrorCode
Table B.16: Added Specification Items in R20-11

B.7.2 Changed Specification Items in R20-11

Number Heading
[SWS_EM_02243] Handling Execution State Running
[SWS_EM_01405] Terminating Process State after Terminating Report
[SWS_EM_01073] Simple Arguments
[SWS_EM_01074] Short form arguments with option value
[SWS_EM_01075] Short form Arguments without option value
[SWS_EM_01076] Long form Arguments with option value
[SWS_EM_01077] Long form Arguments without option value
[SWS_EM_01032] Machine States configuration
[SWS_EM_02250] Machine State Startup
[SWS_EM_02258] State transition - Process termination timeout reporting
[SWS_EM_02260] State transition - Process start-up timeout reaction
[SWS_EM_02259] State transition - Process start-up timeout reporting
[SWS_EM_01067] Confirm State Changes
[SWS_EM_02297] StateClient usage restriction
[SWS_EM_02000] ExecutionState
[SWS_EM_02202] ActivationTimeStampReturnType
[SWS_EM_02216] DeterministicClient::WaitForNextActivation
[SWS_EM_02220] DeterministicClient::RunWorkerPool
5

184 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02230] DeterministicClient::GetActivationTime
[SWS_EM_02235] DeterministicClient::GetNextActivationTime
[SWS_EM_02263] FunctionGroup class
[SWS_EM_02264] FunctionGroup::Preconstruct
[SWS_EM_02265] FunctionGroup::FunctionGroup
[SWS_EM_02266] FunctionGroup:: FunctionGroup
[SWS_EM_02267] FunctionGroup::operator==
[SWS_EM_02268] FunctionGroup::operator!=
[SWS_EM_02269] FunctionGroupState class
[SWS_EM_02270] FunctionGroupState::Preconstruct
[SWS_EM_02271] FunctionGroupState::FunctionGroupState
[SWS_EM_02272] FunctionGroupState:: FunctionGroupState
[SWS_EM_02273] FunctionGroupState::operator==
[SWS_EM_02274] FunctionGroupState::operator!=
Table B.17: Changed Specification Items in R20-11

B.7.3 Deleted Specification Items in R20-11

Number Heading
[SWS_EM_01071] Premature Termination of a Reporting Process
[SWS_EM_02244] Handling Execution State Terminating
[SWS_EM_01024] Machine State Shutdown
[SWS_EM_02242] Further Function Group State Changes
[SWS_EM_02257] Recovery Action API Security
[SWS_EM_02076] Get Process States Information
[SWS_EM_02077] Process State Transition Event
[SWS_EM_01016] Process Restart
[SWS_EM_01062] Process Restart Behavior
[SWS_EM_01063] Process Restart Failed
[SWS_EM_01064] Process Restart Successful
[SWS_EM_02261] Enter Unrecoverable State
[SWS_EM_02262] Enter Unrecoverable State Behavior
Table B.18: Deleted Specification Items in R20-11

185 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.7.4 Added Constraints in R20-11

none

B.7.5 Changed Constraints in R20-11

none

B.7.6 Deleted Constraints in R20-11

none

B.8 Constraint and Specification Item History of this document

according to AUTOSAR Release R21-11

B.8.1 Added Specification Items in R21-11

Number Heading
[SWS_EM_02547] Obtain error information
[SWS_EM_02548] Create error information
[SWS_EM_CON-
Definition of process state in the context of the ExecutionDependency
STR_1744]
[SWS_EM_CON-
Modeling execution dependency for the Terminated state
STR_0001]
[SWS_EM_02549] MachineFG.Off handling
[SWS_EM_02551] Missing DeterministicClient
[SWS_EM_02550] Execution Cycle Termination
[SWS_EM_01328] Immediate return from wait point
[SWS_EM_02323] FunctionGroup::Create
[SWS_EM_02321] FunctionGroup::FunctionGroup
[SWS_EM_02322] FunctionGroup::FunctionGroup (Copy Constructor)
[SWS_EM_02328] FunctionGroup::FunctionGroup (Move Constructor)
[SWS_EM_02327] FunctionGroup::operator= (Copy assignment operator)
[SWS_EM_02329] FunctionGroup::operator= (Move assignment operator)
[SWS_EM_02326] FunctionGroupState::Create
[SWS_EM_02324] FunctionGroupState::FunctionGroupState
[SWS_EM_02325] FunctionGroupState::FunctionGroupState (Copy Constructor)
[SWS_EM_02331] FunctionGroupState::FunctionGroupState (Move Constructor)
5

186 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02330] FunctionGroupState::operator= (Copy assignment operator)
[SWS_EM_02332] FunctionGroupState::operator= (Move assignment operator)
Table B.19: Added Specification Items in R21-11

B.8.2 Changed Specification Items in R21-11

Number Heading
[SWS_EM_01309] Unexpected Termination of a process
[SWS_EM_02243] Handling Execution State Running
[SWS_EM_01032] Machine States configuration
[SWS_EM_02241] Machine State Startup Completion
[SWS_EM_02254] Misconfigured process - assigned to more than one Function Group
[SWS_EM_01060] State transition - termination behavior
[SWS_EM_02255] State transition - process termination timeout reaction
[SWS_EM_02258] State transition - process termination timeout reporting
Unexpected Termination of starting processes during Function Group State
[SWS_EM_02313]
transition
Unexpected Termination of terminating processes during Function Group
[SWS_EM_02314]
State transition
[SWS_EM_01351] Execution Cycle Time
[SWS_EM_01352] Execution Cycle Timeout
[SWS_EM_01353] Event-triggered Cycle Activation
[SWS_EM_01308] Random Numbers
[SWS_EM_01313] Next Activation Time Unknown
[SWS_EM_02102] Memory control
[SWS_EM_02103] CPU usage control
[SWS_EM_02104] Core affinity
[SWS_EM_01014] Scheduling policy
[SWS_EM_02107] Maximum heap
[SWS_EM_02108] Maximum system memory usage
[SWS_EM_02109] process pre-mapping
[SWS_EM_02300] Integrity and Authenticity of Machine configuration
[SWS_EM_02303] Integrity and Authenticity of processed Execution Manifest configurations
[SWS_EM_02304] Integrity and Authenticity of processed Service Instance Manifests
[SWS_EM_02305] Failed authenticity checks
[SWS_EM_02306] Launch Behavior Validation
[SWS_EM_02309] Strict Mode - Executables
5

187 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02276] StateClient::StateClient
[SWS_EM_02281] Execution Management error codes
Table B.20: Changed Specification Items in R21-11

B.8.3 Deleted Specification Items in R21-11

Number Heading
[SWS_EM_01405] Terminating Process State after Terminating Report
[SWS_EM_01073] Simple Arguments
[SWS_EM_01074] Short form arguments with option value
[SWS_EM_01075] Short form Arguments without option value
[SWS_EM_01076] Long form Arguments with option value
[SWS_EM_01077] Long form Arguments without option value
[SWS_EM_01109] Misconfigured Process - not assigned to a Function Group
[SWS_EM_01307] Worker Object
[SWS_EM_02202] ActivationTimeStampReturnType
[SWS_EM_02216] DeterministicClient::WaitForNextActivation
[SWS_EM_02220] DeterministicClient::RunWorkerPool
[SWS_EM_02230] DeterministicClient::GetActivationTime
[SWS_EM_02235] DeterministicClient::GetNextActivationTime
[SWS_EM_02264] FunctionGroup::Preconstruct
[SWS_EM_02265] FunctionGroup::FunctionGroup
[SWS_EM_02270] FunctionGroupState::Preconstruct
[SWS_EM_02271] FunctionGroupState::FunctionGroupState
Table B.21: Deleted Specification Items in R21-11

B.8.4 Added Constraints in R21-11

none

B.8.5 Changed Constraints in R21-11

none

188 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.8.6 Deleted Constraints in R21-11

none

B.9 Constraint and Specification Item History of this document

according to AUTOSAR Release R22-11

B.9.1 Added Specification Items in R22-11

Number Heading
[SWS_EM_01210] Report “kRunning received event” to Platform Health Management
[SWS_EM_01211] Report “initiating process termination” event to Platform Health Management
[SWS_EM_01212] Report “process terminated” event to Platform Health Management
[SWS_EM_02552] State transition - integrity or authenticity check failed
[SWS_EM_02553] Rejecting a state transition to a state that the FG is already in
[SWS_EM_02554] Rejecting a state transition to a state that the FG is already transition to
[SWS_EM_02555] Failure in Machine State Startup transition
[SWS_EM_-
Modeling execution dependency for the Terminated state
CONSTR_00001]
[SWS_EM_-
Definition of process state in the context of the ExecutionDependency
CONSTR_01744]
Table B.22: Added Specification Items in R22-11

B.9.2 Changed Specification Items in R22-11

Number Heading
[SWS_EM_01013] Function Group State
[SWS_EM_01067] Actions on Completion State Transition
[SWS_EM_01078] Process Argument strings
[SWS_EM_01107] Function Group configuration
[SWS_EM_01110] Off States
[SWS_EM_01314] Default value for terminationBehavior
[SWS_EM_01320] Number of DeterministicClients
[SWS_EM_01321] Minimum number of required synchronization requests
[SWS_EM_01322] Calculation of the next cycle
[SWS_EM_01323] Total kRun loop count
[SWS_EM_01324] Infinite kRun loop
5

189 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_01403] Reporting Non-reporting Process
[SWS_EM_02000]
[SWS_EM_02001]
[SWS_EM_02002]
[SWS_EM_02003]
[SWS_EM_02030]
[SWS_EM_02108] Maximum memory usage
[SWS_EM_02201]
[SWS_EM_02203]
[SWS_EM_02210]
[SWS_EM_02211]
[SWS_EM_02215]
[SWS_EM_02217]
[SWS_EM_02221]
[SWS_EM_02225]
[SWS_EM_02226]
[SWS_EM_02231]
[SWS_EM_02236]
[SWS_EM_02241] Machine State Startup Completion
[SWS_EM_02254] Misconfigured process - assigned to more than one Function Group
[SWS_EM_02263]
[SWS_EM_02266]
[SWS_EM_02267]
[SWS_EM_02268]
[SWS_EM_02269]
[SWS_EM_02272]
[SWS_EM_02273]
[SWS_EM_02274]
[SWS_EM_02275]
[SWS_EM_02276]
[SWS_EM_02277]
[SWS_EM_02278]
[SWS_EM_02279]
[SWS_EM_02280] Effect on Execution Dependency
[SWS_EM_02281]
[SWS_EM_02282]
[SWS_EM_02283]
[SWS_EM_02284]
[SWS_EM_02286]
5

190 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02287]
[SWS_EM_02288]
[SWS_EM_02289]
[SWS_EM_02290]
[SWS_EM_02291]
[SWS_EM_02292]
[SWS_EM_02297] StateClient usage restriction
[SWS_EM_02298] Canceling ongoing state transition
[SWS_EM_02299] Availability of a Trust Anchor
[SWS_EM_02306] Launch Behavior Validation
[SWS_EM_02321]
[SWS_EM_02322]
[SWS_EM_02323]
[SWS_EM_02324]
[SWS_EM_02325]
[SWS_EM_02326]
[SWS_EM_02327]
[SWS_EM_02328]
[SWS_EM_02329]
[SWS_EM_02330]
[SWS_EM_02331]
[SWS_EM_02332]
[SWS_EM_02400] Properties of IAM-configuration assigned to processes
[SWS_EM_02510]
[SWS_EM_02520]
[SWS_EM_02530]
[SWS_EM_02531]
[SWS_EM_02532]
[SWS_EM_02540]
[SWS_EM_02541]
[SWS_EM_02542]
[SWS_EM_02544]
[SWS_EM_02545]
[SWS_EM_02546]
Table B.23: Changed Specification Items in R22-11

191 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.9.3 Deleted Specification Items in R22-11

Number Heading
[SWS_EM_01308] Random Numbers
[SWS_EM_02107] Maximum heap
[SWS_EM_02304] Integrity and Authenticity of processed Service Instance Manifests
[SWS_EM_-
Modeling execution dependency for the Terminated state
CONSTR_0001]
[SWS_EM_-
Definition of process state in the context of the ExecutionDependency
CONSTR_1744]
Table B.24: Deleted Specification Items in R22-11

B.9.4 Added Constraints in R22-11

none

B.9.5 Changed Constraints in R22-11

none

B.9.6 Deleted Constraints in R22-11

none

B.10 Constraint and Specification Item History of this document

according to AUTOSAR Release R23-11

B.10.1 Added Specification Items in R23-11

Number Heading
Request of a state transition to a state that the Function Group is already
[SWS_EM_02295]
in
Request of a state transition to a state that the Function Group is already
[SWS_EM_02296]
in transition to
Unexpected Termination of processes configured for the
[SWS_EM_02315]
RequestedState during a Function Group State transition
5

192 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
Unexpected Termination of a process not configured for the
[SWS_EM_02316]
RequestedState during a Function Group State transition
[SWS_EM_02511] Definition of API function ara::exec::WorkerRunnable::WorkerRunnable
[SWS_EM_02512] Definition of API function ara::exec::WorkerRunnable::~WorkerRunnable
[SWS_EM_02513] Definition of API function ara::exec::WorkerRunnable::WorkerRunnable
[SWS_EM_02514] Definition of API function ara::exec::WorkerRunnable::WorkerRunnable
[SWS_EM_02515] Definition of API function ara::exec::WorkerRunnable::operator=
[SWS_EM_02533] Definition of API function ara::exec::WorkerThread::WorkerThread
[SWS_EM_02534] Definition of API function ara::exec::WorkerThread::WorkerThread
[SWS_EM_02535] Definition of API function ara::exec::WorkerThread::operator=
[SWS_EM_02556] Monitor Mode
[SWS_EM_02557]
[SWS_EM_02558] Default value for permissionToCreateChildProcess attribute
[SWS_EM_02559] Restriction of process creation right for processes
[SWS_EM_02560] Definition of API function ara::exec::ExecutionClient::ExecutionClient
[SWS_EM_02561] Definition of API function ara::exec::StateClient::StateClient
[SWS_EM_02562] Definition of API function ara::exec::ExecutionClient::Create
[SWS_EM_02563] Definition of API function ara::exec::ExecutionClient::ExecutionClient
[SWS_EM_02564] Definition of API function ara::exec::ExecutionClient::operator=
[SWS_EM_02565] Definition of API function ara::exec::StateClient::StateClient
[SWS_EM_02566] Definition of API function ara::exec::StateClient::StateClient
[SWS_EM_02567] Definition of API function ara::exec::StateClient::operator=
[SWS_EM_02568] Definition of API function ara::exec::StateClient::operator=
[SWS_EM_02569] LogMessage ProcessCreated
[SWS_EM_02570] LogMessage ProcessKRunningReceived
[SWS_EM_02571] LogMessage ProcessTerminationRequest
[SWS_EM_02572] LogMessage ProcessTerminated
[SWS_EM_02573] State Transition logging – process created
[SWS_EM_02574] State Transition logging – process kRunning received
[SWS_EM_02575] State Transition logging – process termination request
[SWS_EM_02576] State Transition logging – process terminated
[SWS_EM_02577] Call of Termination Handler
[SWS_EM_02578] Initial signal mask for Reporting Process
[SWS_EM_02579] Initial signal mask for Non-Reporting process
[SWS_EM_02580] Definition of API function ara::exec::ExecutionClient::ExecutionClient
[SWS_EM_02581] Definition of API function ara::exec::ExecutionClient::operator=
Table B.25: Added Specification Items in R23-11

193 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.10.2 Changed Specification Items in R23-11

Number Heading
[SWS_EM_01030] Restriction of process creation right for processes
[SWS_EM_01050] Start Dependent processes
[SWS_EM_01301] Cyclic Execution
[SWS_EM_01302] Cyclic Execution Control
[SWS_EM_01303] Cyclic Execution Control Sequence
[SWS_EM_01304] Service Modification
[SWS_EM_01305] Worker Pool
[SWS_EM_01306] processing Container Objects
[SWS_EM_01309] Unexpected Termination of a process
[SWS_EM_01310] Get Activation Time
[SWS_EM_01311] Activation Time Unknown
[SWS_EM_01312] Get Next Activation Time
[SWS_EM_01313] Next Activation Time Unknown
[SWS_EM_01320] Number of DeterministicClients
[SWS_EM_01321] Minimum number of required synchronization requests
[SWS_EM_01322] Calculation of the next cycle
[SWS_EM_01323] Total kRun loop count
[SWS_EM_01324] Infinite kRun loop
[SWS_EM_01325] Synchronization Request Message
[SWS_EM_01326] Synchronization Response Message
[SWS_EM_01327] Return of the wait point API
[SWS_EM_01328] Immediate return from wait point
[SWS_EM_01351] Execution Cycle Time
[SWS_EM_01352] Execution Cycle Timeout
[SWS_EM_01353] Event-triggered Cycle Activation
[SWS_EM_02000] Definition of API enum ara::exec::ExecutionState
[SWS_EM_02001] Definition of API class ara::exec::ExecutionClient
[SWS_EM_02002] Definition of API function ara::exec::ExecutionClient::~ExecutionClient
[SWS_EM_02003] Definition of API function ara::exec::ExecutionClient::ReportExecutionState
[SWS_EM_02032] On entry to the Unrecoverable State,
[SWS_EM_02033] After execution of the pre-cleanup action,
[SWS_EM_02034] After all processes managed by Execution Management terminated,
[SWS_EM_02108] Maximum memory usage
[SWS_EM_02109] process pre-mapping
[SWS_EM_02201] Definition of API enum ara::exec::ActivationReturnType
[SWS_EM_02203] Definition of API type ara::exec::DeterministicClient::TimeStamp
5

194 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
[SWS_EM_02210] Definition of API class ara::exec::DeterministicClient
[SWS_EM_02211] Definition of API function ara::exec::DeterministicClient::DeterministicClient
[SWS_EM_02215] Definition of API function ara::exec::DeterministicClient::~DeterministicClient
[SWS_EM_02217] Definition of API function ara::exec::DeterministicClient::WaitForActivation
[SWS_EM_02221] Definition of API function ara::exec::DeterministicClient::RunWorkerPool
[SWS_EM_02225] Definition of API function ara::exec::DeterministicClient::GetRandom
[SWS_EM_02226] Definition of API function ara::exec::DeterministicClient::SetRandomSeed
[SWS_EM_02231] Definition of API function ara::exec::DeterministicClient::GetActivationTime
Definition of API function ara::exec::DeterministicClient::GetNextActivation
[SWS_EM_02236]
Time
[SWS_EM_02250] Machine State Startup
[SWS_EM_02263] Definition of API class ara::exec::FunctionGroup
[SWS_EM_02266] Definition of API function ara::exec::FunctionGroup::~FunctionGroup
[SWS_EM_02267] Definition of API function ara::exec::FunctionGroup::operator==
[SWS_EM_02268] Definition of API function ara::exec::FunctionGroup::operator!=
[SWS_EM_02269] Definition of API class ara::exec::FunctionGroupState
Definition of API function ara::exec::FunctionGroupState::~FunctionGroup
[SWS_EM_02272]
State
[SWS_EM_02273] Definition of API function ara::exec::FunctionGroupState::operator==
[SWS_EM_02274] Definition of API function ara::exec::FunctionGroupState::operator!=
[SWS_EM_02275] Definition of API class ara::exec::StateClient
[SWS_EM_02276] Definition of API function ara::exec::StateClient::Create
[SWS_EM_02277] Definition of API function ara::exec::StateClient::~StateClient
[SWS_EM_02278] Definition of API function ara::exec::StateClient::SetState
Definition of API function ara::exec::StateClient::GetInitialMachineState
[SWS_EM_02279]
TransitionResult
[SWS_EM_02281] Definition of API enum ara::exec::ExecErrc
[SWS_EM_02282] Definition of API class ara::exec::ExecException
[SWS_EM_02283] Definition of API function ara::exec::ExecException::ExecException
[SWS_EM_02284] Definition of API class ara::exec::ExecErrorDomain
[SWS_EM_02286] Definition of API function ara::exec::ExecErrorDomain::ExecErrorDomain
[SWS_EM_02287] Definition of API function ara::exec::ExecErrorDomain::Name
[SWS_EM_02288] Definition of API function ara::exec::ExecErrorDomain::Message
[SWS_EM_02289] Definition of API function ara::exec::ExecErrorDomain::ThrowAsException
[SWS_EM_02290] Definition of API function ara::exec::GetExecErrorDomain
[SWS_EM_02291] Definition of API function ara::exec::MakeErrorCode
[SWS_EM_02292]
[SWS_EM_02306] Launch Behavior Validation
Unexpected Termination of starting processes during Function
[SWS_EM_02313]
Group State transition
5

195 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

4
Number Heading
Unexpected Termination of terminating processes during Function
[SWS_EM_02314]
Group State transition
[SWS_EM_02321] Definition of API function ara::exec::FunctionGroup::FunctionGroup
[SWS_EM_02322] Definition of API function ara::exec::FunctionGroup::FunctionGroup
[SWS_EM_02323] Definition of API function ara::exec::FunctionGroup::Create
Definition of API function ara::exec::FunctionGroupState::FunctionGroup
[SWS_EM_02324]
State
Definition of API function ara::exec::FunctionGroupState::FunctionGroup
[SWS_EM_02325]
State
[SWS_EM_02326] Definition of API function ara::exec::FunctionGroupState::Create
[SWS_EM_02327] Definition of API function ara::exec::FunctionGroup::operator=
[SWS_EM_02328] Definition of API function ara::exec::FunctionGroup::FunctionGroup
[SWS_EM_02329] Definition of API function ara::exec::FunctionGroup::operator=
[SWS_EM_02330] Definition of API function ara::exec::FunctionGroupState::operator=
Definition of API function ara::exec::FunctionGroupState::FunctionGroup
[SWS_EM_02331]
State
[SWS_EM_02332] Definition of API function ara::exec::FunctionGroupState::operator=
[SWS_EM_02510] Definition of API class ara::exec::WorkerRunnable
[SWS_EM_02520] Definition of API function ara::exec::WorkerRunnable::Run
[SWS_EM_02530] Definition of API class ara::exec::WorkerThread
[SWS_EM_02531] Definition of API function ara::exec::WorkerThread::WorkerThread
[SWS_EM_02532] Definition of API function ara::exec::WorkerThread::~WorkerThread
[SWS_EM_02540] Definition of API function ara::exec::WorkerThread::GetRandom
[SWS_EM_02541] Definition of API type ara::exec::ExecutionError
[SWS_EM_02542] Definition of API function ara::exec::StateClient::GetExecutionError
[SWS_EM_02544] Definition of API class ara::exec::ExecutionErrorEvent
[SWS_EM_02545] Definition of API variable ara::exec::ExecutionErrorEvent::executionError
[SWS_EM_02546] Definition of API variable ara::exec::ExecutionErrorEvent::functionGroup
[SWS_EM_02547] Obtain error information
[SWS_EM_02548] Create error information
[SWS_EM_02550] Execution Cycle Termination
[SWS_EM_02551] Missing DeterministicClient
Table B.26: Changed Specification Items in R23-11

196 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement

 Specification of Execution Management
AUTOSAR AP R23-11

B.10.3 Deleted Specification Items in R23-11

Number Heading
[SWS_EM_02030]
[SWS_EM_02553] Rejecting a state transition to a state that the FG is already in
[SWS_EM_02554] Rejecting a state transition to a state that the FG is already transition to
Table B.27: Deleted Specification Items in R23-11

B.10.4 Added Constraints in R23-11

Number Heading
[SWS_EM_-
CONSTR_- Mandatory states
02556]
[SWS_EM_-
CONSTR_- Scope of machine Function Group
02557]
[SWS_EM_-
CONSTR_- Ability to shut down
02558]
[SWS_EM_-
CONSTR_- Ability to restart
02559]
Table B.28: Added Constraints in R23-11

B.10.5 Changed Constraints in R23-11

none

B.10.6 Deleted Constraints in R23-11

none

197 of 197 Document ID 721: AUTOSAR_AP_SWS_ExecutionManagement