POSIX OS & Execution Model

Each Adaptive Application runs as an independent POSIX process with its own virtual address space. The Execution Manager (EM) launches each process via execve() using the parameters in the Application Manifest. Processes do not share BSS or data segments — spatial isolation is enforced by the MMU.

The ara::core::Initialize() call (required before any other ara:: API call) connects the process to the Execution Manager via an IPC channel, registers the process identity, and sets up the internal ara::com communication middleware. ara::core::Deinitialize() must be called before process exit to cleanly release all middleware resources.

#include <ara/core/initialization.h>
#include "my_service_skeleton.h"

int main() {
    // Mandatory: connect to EM and initialise all FCs
    if (auto res = ara::core::Initialize(); !res) {
        return EXIT_FAILURE;
    }

    // Offer the service via ara::com skeleton
    MyServiceSkeleton skeleton(
        ara::core::InstanceSpecifier{"MyApp/MyService/Instance0"});
    skeleton.OfferService();

    // Application event loop
    while (running) {
        skeleton.MyEvent.Send(ReadSensor());
        std::this_thread::sleep_for(std::chrono::milliseconds(10));
    }

    skeleton.StopOfferService();
    ara::core::Deinitialize();
    return EXIT_SUCCESS;
}

Adaptive Applications run on the host OS scheduler. The scheduling policy and priority for each process are declared in the Application Manifest under schedulingPolicy.

{
  "startupConfig": {
    "schedulingPolicy": "FIFO",
    "schedulingPriority": 50,
    "resourceGroup": "adas_group"
  }
}

The ara::com API abstracts the transport entirely. Under the hood, on a single machine:

• UNIX domain sockets are used for method calls (request/reply) and subscription management.
• Shared memory is used for zero-copy event data transfer when both processes are on the same SoC — the SamplePtr points directly into a shared memory segment without copying.

For cross-ECU communication, the binding layer serialises to SOME/IP over UDP/TCP Ethernet or to DDS. The application code does not change — only the Service Instance Manifest binding changes.

  Provider Process                   Consumer Process
  ┌─────────────────────┐            ┌─────────────────────┐
  │ skeleton.Event.Send │            │ proxy.Event.         │
  │   (SamplePtr)       │            │  GetNewSamples(cb)   │
  └────────┬────────────┘            └──────────┬──────────┘
           │ ara::com middleware                 │
           │ (shared memory segment)             │
           └──────── mmap'd region ─────────────┘
              Zero-copy: SamplePtr references
              the buffer directly

Linux cgroups constrain CPU and memory per process group. The resourceGroup field in the Application Manifest maps the process to a named cgroup defined in the Machine Manifest.

{
  "resourceGroups": [
    {
      "shortName": "adas_group",
      "cpuShares": 1024,
      "memoryLimit": "2G"
    }
  ]
}

The POSIX execution model gives Adaptive Applications full OS capability — multi-threading, dynamic memory, shared libraries — while Execution Management and PHM provide the lifecycle governance that safety-critical systems require. Spatial isolation via process boundaries replaces Classic's compile-time partitioning.