module ara::exec — Execution Management

As a central platform daemon, the Execution Management module manages the deterministic lifecycle of POSIX processes on the AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement p. 18). It receives execution states via the ExecutionClient ([SWS_EM_02003]) and asynchronously implements function group transitions requested by State Management by starting and terminating processes ([SWS_EM_02278]). Key constraints are the prohibition of cross-function-group startup dependencies and strict error escalation upon deadline violations (SWS ExecutionManagement p. 65).

more ›

The functional cluster Execution Management (EM) forms the central platform daemon of the AUTOSAR Adaptive Platform for deterministic process management and life-cycle control in POSIX user space (AUTOSAR AP SWS ExecutionManagement p. 18). It strictly separates policy decision from technical mechanism: while State Management specifies the target states, EM controls process creation, sequences, and signal handling (AUTOSAR AP EXP SWArchitecture p. 56). Via the [SWS_EM_02562] ExecutionClient, applications and platform services report their state [SWS_EM_02000] kRunning via [SWS_EM_02003] ReportExecutionState(), while State Management requests state changes via the [SWS_EM_02276] StateClient (AUTOSAR AP EXP SWArchitecture p. 48).

Context diagram: Embedding of Execution Management as a central daemon between State Management, POSIX operating system, and client processes. Sources: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

After being started by the operating system, EM initiates State Management and synchronizes it via [SWS_EM_02279] GetInitialMachineStateTransitionResult() to the machine state Startup (AUTOSAR AP SWS ExecutionManagement p. 52). Subsequent transitions of [SWS_EM_02586] FunctionGroup states are triggered asynchronously with [SWS_EM_02278] SetState(): EM terminates processes that are no longer required in an orderly manner via SIGTERM, starts subsequent processes taking local startup dependencies into account, and resolves the resulting Future as soon as all processes are ready for operation (AUTOSAR AP SWS ExecutionManagement p. 53, SWS ExecutionManagement p. 71).

Sequence diagram: Successful state change of a Function Group with orderly process termination and process restart. Sources: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

To ensure real-time requirements, EM supports deterministic process pre-mapping to prevent page faults (SWS ExecutionManagement p. 82) as well as deterministic worker pools and synchronization mechanisms (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 92). If a process violates its startup time window, error handling takes effect: EM terminates the process, transitions the Function Group into an Undefined State, invokes the registered callback ([SWS_EM_02276]), and provides error details via [SWS_EM_02542] GetExecutionError() and the module error domain [SWS_EM_02281] ExecErrc (AUTOSAR AP SWS ExecutionManagement p. 54).

more ›

System Boundaries and Functional Role of Execution Management

The module exec (Execution Management, EM) forms the central platform service of the AUTOSAR Adaptive Platform for deterministic process and life-cycle management in POSIX-based user space (AUTOSAR AP SWS ExecutionManagement p. 18). Defining for the architecture is the strict separation between control decision (policy) and technical enforcement (mechanism): while the functional cluster State Management makes higher-level operating mode and transition decisions, Execution Management acts as the executing instance for process allocation, startup sequences, monitoring, and termination (AUTOSAR AP EXP SWArchitecture p. 56).

Execution Management implements native C++ runtime interfaces for two complementary roles: via the class [SWS_EM_02562] ara::exec::ExecutionClient, application processes as well as platform-internal daemons (such as Diagnostic Management, Platform Health Management, or Communication Management) report their execution state to the daemon (AUTOSAR AP EXP SWArchitecture p. 48, AUTOSAR AP SWS CommunicationManagement p. 34). Via the interface [SWS_EM_02276] ara::exec::StateClient, State Management interacts with the daemon to request Function Group and machine transitions and to query status messages (AUTOSAR AP SWS ExecutionManagement p. 17).

Context diagram: Embedding of Execution Management as a central daemon between State Management, POSIX operating system, and client processes. Sources: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

State Architecture and Multi-Level Life-Cycle Model

State management in Execution Management operates on three correlated hierarchy levels: the higher-level Function Group states (Function Group States), the external operating system life-cycle states from the daemon's perspective (Process States), and the process-internal states (Execution States) (AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 62). At the daemon level, a configured process typically traverses the chain Idle, Starting, Running, Terminating, and Terminated (AUTOSAR AP SWS StateManagement p. 32).

For the process-internal perspective, the module defines the enumeration [SWS_EM_02000] ara::exec::ExecutionState. Normatively reportable to Execution Management is the state kRunning via the member function [SWS_EM_02003] ReportExecutionState(). Preceding phases such as Initializing are implicit states for Execution Management that begin immediately with the first scheduling of the POSIX process prior to the execution of user code ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines p. 11). Application operating and power modes (PowerModes) do not represent operating system states, but are logically coupled to the active life-cycle phase Running (AUTOSAR AP SWS StateManagement p. 32).

State diagram: Correlation of the Function Group states with the life-cycle phases in Execution Management and the internal process states. Sources: AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 32, [SWS_EM_02000].

Deterministic Platform Startup and Initialization

The startup of the AUTOSAR Adaptive Platform occurs in a strictly coordinated sequence originating from the operating system kernel (AUTOSAR EXP SWArchitecture p. 148). The operating system starts Execution Management via its program entry point main() (AUTOSAR AP SWS ExecutionManagement p. 52). Immediately after self-initialization, Execution Management creates the State Management process (AUTOSAR AP SWS StateManagement p. 25).

As soon as State Management is initialized, it reports its operational readiness with [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) via ExecutionClient to Execution Management (AUTOSAR AP SWS ExecutionManagement p. 52). Subsequently, State Management synchronizes via [SWS_EM_02279] GetInitialMachineStateTransitionResult() to the completion of the initial machine transition into state Startup; this method returns a ara::core::Future<void> ([SWS_EM_02279], AUTOSAR EXP SWArchitecture p. 151). Only after this future is successfully fulfilled does State Management request the transition into subsequent Function Group states (AUTOSAR AP SWS StateManagement p. 24).

Sequence diagram: Platform startup from operating system initiation through the start of State Management to the release of the subsequent state. Sources: AUTOSAR AP SWS ExecutionManagement p. 52, AUTOSAR AP SWS StateManagement p. 25, [SWS_EM_02279], [SWS_EM_02003].

Control of Function Groups and Asynchronous State Transitions

State changes are modeled on the application side via representatives of the classes [SWS_EM_02586] ara::exec::FunctionGroup and [SWS_EM_02324] ara::exec::FunctionGroupState. To ensure deterministic resource management, FunctionGroup is not copyable ([SWS_EM_02322], [SWS_EM_02327]), but exclusively movable ([SWS_EM_02328], [SWS_EM_02329]) and evaluable via instance comparisons ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState binds a Function Group to a target state ([SWS_EM_02324]) and supports both copy and move semantics ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

State Management initiates a transition by calling [SWS_EM_02278] StateClient::SetState(), which synchronously returns a ara::core::Future<void> (AUTOSAR AP SWS StateManagement p. 31). Execution Management then executes the transition chain: running processes that are no longer configured in the target state receive a SIGTERM signal (AUTOSAR AP SWS ExecutionManagement p. 53). After their termination, EM starts the processes designated for the target state and waits for their status report via [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement p. 26, AUTOSAR SWS ExecutionManagement p. 49). Only when all involved processes have started successfully is the future of SetState() fulfilled positively (AUTOSAR AP SWS ExecutionManagement p. 53).

Startup dependencies (Execution Dependencies) must never be defined across the boundaries of a single Function Group or across different states (SWS ExecutionManagement p. 65). During state changes, Execution Management resolves startup dependencies strictly for the processes of the requested target state (RequestedState) (SWS ExecutionManagement p. 71). If the startup configurations of a process differ between the initial and target states, Execution Management forces its restart (SWS ExecutionManagement p. 65).

Sequence diagram: Successful state change of a Function Group with orderly process termination and process restart. Sources: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Process Configuration, Memory Allocation, and Pre-Mapping

In real-world systems, non-reporting processes (Non-reporting Processes) exist alongside standard applications. Such processes automatically transition to the execution state Running after startup (SWS ExecutionManagement p. 44). To nevertheless safeguard dependency chains, a project-specific companion process (Companion Process) can be upstreamed, which evaluates the functional operational readiness of the non-reporting process and vicariously reports [SWS_EM_02003] kRunning before dependent subsequent processes are started (SWS ExecutionManagement p. 44, SWS ExecutionManagement p. 48).

Regarding resource requirements, the parameter resourceConsumption.memoryUsage limits the main memory allocatable by the process itself, which on POSIX systems is typically implemented via RLIMIT_AS (SWS ExecutionManagement p. 82, SWS ExecutionManagement p. 104). To ensure temporal determinism and functional safety, Execution Management supports pre-mapping (Pre-mapping): if Process.preMapping is enabled in the manifest, EM fully pre-maps the code and data regions of the process into physical memory (SWS ExecutionManagement p. 82). This prevents delays caused by demand loading upon initial access, ensures the continuous availability of safety-critical error handling routines, and protects against subsequent errors caused by corrupted file systems (SWS ExecutionManagement p. 82).

Deterministic Execution Time and Synchronization Models

For real-time-critical applications, Execution Management provides mechanisms for deterministic execution (SWS ExecutionManagement p. 79). Cyclic processes interact with the client via a wait point API that controls modes such as service discovery, initialization, execution, and termination (SWS ExecutionManagement p. 79). Parallel data processing is abstracted via worker pools: to ensure data determinism, data exchange between concurrent instances of WorkerRunnable is prohibited (SWS ExecutionManagement p. 86).

To synchronize multiple redundant or distributed processes, the DeterministicSyncMaster is used (SWS ExecutionManagement p. 92). In event-driven activation, a configurable policy (such as an M-out-of-N majority decision) determines when synchronization responses are sent (SWS ExecutionManagement p. 92). In periodic activation, a one-time synchronization occurs at the beginning, after which a global timestamp buffer defines the start cycle and subsequent cycles are controlled autonomously via local counters and deadline monitoring (SWS ExecutionManagement p. 92). The sync master can either be deployed as an independent process or integrated as a library within a software lockstep framework (SWS ExecutionManagement p. 94, SWS ExecutionManagement p. 95).

Behavior in the event of an error

In the event of an error, the architecture is structured according to the general fault tolerance scheme into error detection (Error Detection) and subsequent error recovery (Error Recovery) (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 107). If a startup timeout occurs during a Function Group state change—for example because a starting process does not issue [SWS_EM_02003] ReportExecutionState(kRunning) within the configured deadline—Execution Management aborts the regular sequence (AUTOSAR AP SWS ExecutionManagement p. 54).

Internal escalation in this case presumably comprises the forced termination of the faulty process via SIGKILL; after exhausting configured restart attempts, the affected Function Group transitions into an undefined state (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02542]). Question Q-5a8b6ad2e9e22eb4 (open) Upon entering an undefined state, Execution Management triggers the callback undefinedStateCallback passed during instantiation of StateClient ([SWS_EM_02276], [SWS_EM_02561]). State Management can then query the associated event ara::exec::ExecutionErrorEvent via [SWS_EM_02542] GetExecutionError(), which provides the faulty Function Group ([SWS_EM_02546]) and the error code [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) ([SWS_EM_02542]). If the Function Group is once again in a defined state, GetExecutionError() fails ([SWS_EM_02542]).

Sequence diagram: Error handling during a startup timeout of a process during a state transition. Sources: AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

For standardized error handling, the module features the error domain [SWS_EM_02286] ara::exec::ExecErrorDomain (retrievable via [SWS_EM_02290] GetExecErrorDomain(), identification name via [SWS_EM_02287] Name(), text messages via [SWS_EM_02288] Message()). Specific execution errors are represented by the enumeration code [SWS_EM_02281] ExecErrc (such as kNoCommunication) and constructed via [SWS_EM_02291] MakeErrorCode(). When exception handling is enabled, errors can be thrown via [SWS_EM_02289] ThrowAsException() as [SWS_EM_02283] ExecException. In addition, the destructor [SWS_EM_02002] ~ExecutionClient() ensures that previously adopted handlers for SIGTERM are reset to their original value, while termination callbacks passed during process creation take effect upon receipt of a termination signal ([SWS_EM_02560], [SWS_EM_02562]). Further recovery actions (such as process restart or fallback to degraded operation) are orchestrated in cooperation with Platform Health Management (AUTOSAR SWS ExecutionManagement p. 54).

Further detailed evidence

The following overview maps the decisive specification requirements and references to the addressed topic areas:

Subject Area	Essential References	Functional Significance
Process State Reporting	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Defines ExecutionState, creation of ExecutionClient, and reporting of kRunning.
Function Group Control	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Asynchronous state transition via SetState(), instantiation of FunctionGroup and FunctionGroupState.
Platform Startup	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Synchronization of State Management to the initial machine state Startup.
Error Handling & Callbacks	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Registration of undefinedStateCallback, query of ExecutionErrorEvent, error domain ExecErrc.
Memory Determinism	SWS ExecutionManagement S. 82	Complete pre-mapping of processes to avoid latencies caused by demand loading.