Execution Manager - Process Lifecycle - AUTOSAR Adaptive Platform

EM Role & Responsibilities

The Execution Manager (EM) is the privileged Adaptive Platform daemon responsible for launching, monitoring, and terminating all Adaptive Applications. It reads Application Manifests and Machine Manifests at boot and orchestrates the platform lifecycle.

EM Responsibility	Mechanism
Launch processes	`execve()` with environment from Application Manifest
Monitor liveness	ApplicationClient heartbeat + PHM alive supervision
Graceful termination	SIGTERM → wait shutdownTimeout → SIGKILL
State orchestration	Start/stop process sets per FunctionGroupState transition
Resource enforcement	cgroup configuration from Machine Manifest resourceGroup

Process State Machine

Process Lifecycle States

  ┌─────────┐  execve()  ┌──────────────┐  kRunning   ┌─────────┐
  │  Idle   │ ─────────► │ Initializing │ ──────────► │ Running │
  └─────────┘            └──────────────┘             └────┬────┘
                                                           │ SIGTERM
                                                     ┌─────▼──────┐
                                                     │Terminating │
                                                     └─────┬──────┘
                                                           │ exit()
                                                     ┌─────▼──────┐
                                                     │ Terminated │
                                                     └────────────┘

C++state_reporting.cpp

// Application reports each state transition to EM
ara::exec::ApplicationClient appClient;

// After all initialisation complete:
appClient.ReportApplicationState(ara::exec::ApplicationState::kRunning);

// On SIGTERM or application-triggered shutdown:
signal(SIGTERM, [](int) { shutdown_requested = true; });

// In main loop exit:
appClient.ReportApplicationState(
    ara::exec::ApplicationState::kTerminating);

Startup Dependencies

Application Manifests declare Function Group state membership. EM starts processes in dependency order using the startupConfig priority field — lower numeric value = started earlier. For explicit ordering, processes can declare a precondition listing services that must be in Running state before this process starts.

⚠️ Circular Dependencies

Circular startup dependencies (A waits for B, B waits for A) cause EM to time out both processes. Use PHM-monitored services and State Manager logic to break cycles rather than hard startup preconditions.

Graceful Shutdown

C++shutdown.cpp

// EM sends SIGTERM when Function Group transitions away from
// the state that includes this process.

std::atomic<bool> shutdown_requested{false};
signal(SIGTERM, [](int) { shutdown_requested.store(true); });

while (!shutdown_requested.load()) {
    DoWork();
}

// Perform cleanup
skel.StopOfferService();
CleanupResources();

// Report kTerminating BEFORE ara::core::Deinitialize()
appClient.ReportApplicationState(
    ara::exec::ApplicationState::kTerminating);
ara::core::Deinitialize();
// exit(0) follows — EM confirms Terminated state

💡 shutdownTimeout

If the process does not exit within shutdownTimeout ms after SIGTERM, EM sends SIGKILL. For processes with significant cleanup work (flushing NvM, sending final diagnostics), increase shutdownTimeout in the Application Manifest accordingly.

Summary

EM's process lifecycle management replaces Classic's EcuM task activation model. The ApplicationClient API is the process's reporting channel to EM. Correct state reporting and SIGTERM handling are mandatory for robust multi-process orchestration.

🔬 Adaptive Application Process States — Full Lifecycle

The Execution Manager (EM) in AUTOSAR Adaptive controls the lifecycle of every Adaptive Application (AA) process. Unlike Classic AUTOSAR where all SWCs share a single OS process, each AA runs as an independent Linux/QNX process. This has profound implications for safety, security, and startup sequencing:

State machine: EM transitions each process through: Idle → Starting → Running → Terminating → Terminated. The EM reads the Execution Manifest (execution.json / .arxml) to determine trigger conditions for each state.
Function Groups: Processes are grouped into Function Groups (FGs). A FG state change (e.g., kDriving → kParking) triggers EM to start/stop all processes in that FG. This replaces BswM mode management from Classic AUTOSAR.
Report to EM: Each AA must call ara::exec::ApplicationClient::ReportApplicationState(kRunning) within a configurable timeout after launch. If it doesn't, EM treats the process as failed and may restart it or declare a platform fault. This timeout is the schedulingPolicy.startupTimeout_ms in the manifest.
Termination sequence: EM sends SIGTERM to the process. The AA must handle SIGTERM, perform graceful shutdown (flush persistent state, release ara::com service instances), then exit with code 0 within terminationTimeout_ms. A forced SIGKILL follows if the timeout expires — this can corrupt persistent storage.

🏭 Practical Execution Manager Patterns

HPC / Central Compute Platform: On an Nvidia Orin or Qualcomm SA8540 based domain controller, 40–80 Adaptive Applications may run simultaneously. EM startup order matters — a navigation AA that starts before the map-storage AA will fail to access map data and crash. Dependency ordering in the Machine Manifest is essential.
Health Management integration: EM integrates with Platform Health Management (PHM). If an AA fails to report kRunning in time, PHM can trigger a supervised entity failure — escalating to a system recovery action defined in the PHM configuration (restart process, restart FG, or reset machine).
OTA update interaction: During an OTA update, UCM stops specific Function Groups, updates the software package, then EM restarts the affected FGs. Processes that hold file locks or shared memory must implement clean shutdown or the UCM update pipeline stalls.

⚠️ Execution Manager Integration Pitfalls

Calling ReportApplicationState too late: If your AA performs heavy initialization (loading ML model, connecting to database) before reporting kRunning, it will exceed the startupTimeout. The EM will kill and restart it — creating a boot loop. Move heavy init to a background thread after reporting kRunning.
Not handling SIGTERM: An AA that ignores SIGTERM forces EM to send SIGKILL after terminationTimeout. SIGKILL cannot be caught — ara::per persistent storage writes in progress are corrupted. Always register a SIGTERM handler with proper flush/close logic.
Function Group state dependency not declared: If AA-B depends on a service offered by AA-A, and they are in the same Function Group, EM may start them in any order. Declare a service dependency in the Process Manifest, or use ara::com find_service with a retry loop.
Wrong scheduling policy in manifest: SCHED_FIFO at priority 50 for a non-critical process can starve SCHED_OTHER processes including the OS network stack. Real-time scheduling priorities must be budgeted system-wide — not set independently per AA.

📊 Industry Note

The Execution Manager concept comes from POSIX process management, but the AUTOSAR R21-11+ specification adds formal safety properties on top of it. For ASIL-B+ systems, the EM itself must run in a memory-protected partition and its own availability must be monitored by a watchdog external to the software stack.

🧠 Knowledge Check — Click each question to reveal the answer

❓ What happens if an Adaptive Application does not call ReportApplicationState(kRunning) within the configured timeout?

✅ The Execution Manager treats the process as failed. Depending on the recovery action configured in the Execution Manifest or PHM Supervision, it will either: (a) kill and restart the process, (b) transition the Function Group to a failed state, or (c) trigger a PHM health alarm that may escalate to a machine reset. The exact behaviour depends on the FG recovery action configuration.

❓ What is the purpose of Function Groups in AUTOSAR Adaptive, and what Classic AUTOSAR concept do they replace?

✅ Function Groups are named sets of processes that are started and stopped together as a unit. They replace the BswM + EcuM mode management concept from Classic AUTOSAR. A Function Group state change (e.g., Driving → Parking) is the Adaptive equivalent of a BswM mode rule firing. State Manager (SM) requests FG state transitions; EM executes them.

❓ An AA must load a 200 MB ML model at startup. How should this be architected to avoid EM timeout issues?

✅ The AA should: (1) Start up, (2) Immediately call ReportApplicationState(kRunning) to satisfy EM, (3) Begin loading the ML model in a background thread, (4) Offer its ara::com service only after the model is loaded (or offer a degraded service with a 'not-ready' status during loading). This pattern ensures EM is satisfied while allowing long initialization to complete safely.