Manifest Structure and ARA Requirements

Manifest Structure and ARA Requirements

This page is the Adaptive-AUTOSAR doctrine behind Theia, and how Theia realizes it. The concepts here are canonical AUTOSAR; the realization column is Theia. For the concrete generation commands see Deployment-Manifest-Generation-and-Serialization.

What Adaptive AUTOSAR is

Adaptive AUTOSAR is a standardized middleware/architecture for high-performance automotive ECUs. Unlike Classic AUTOSAR it does not fix a concrete design — it leaves freedom for development. The model is:

High-performance multi-core SoC + Automotive Ethernet + POSIX OS (PSE51) + Service-Oriented Architecture.

Key vocabulary:

• Adaptive Application (AA) — user-level component implementing project/ECU-specific functionality, running on top of ARA (the C++ APIs the platform exposes).
• Functional Cluster (FC) — a logical group of platform functionality, implemented as a library or a process.
• ARA — the collection of FC public C++ APIs exposed to AAs via headers/libraries.

Planned dynamics — the manifest-restricted runtime

Adaptive AUTOSAR has flexibility at development and deployment time but planned dynamics at runtime: the system integrator restricts dynamic behavior through the deployment manifest. The classic constraints:

• Pre-determined service discovery (no open-ended runtime discovery).
• Dynamic memory allocation restricted to the startup phase only.
• Fair scheduling supplementing priority-based scheduling.
• Fixed allocation of processes to CPU cores.
• Access to pre-existing files only.
• Constraints on Adaptive Platform API usage by applications.
• Authenticated code execution.

These are declared in the manifest and enforced by the runtime (primarily Execution Management) — not hard-coded.

The four manifest kinds

A Manifest is a formal specification of configuration content, combined with the binaries it applies to, providing specific functionality. Adaptive AUTOSAR defines four categories:

Manifest	Scope	Describes
Application Manifest	per-application	software-component / composition design, executable description, process design, startup config, SOA communication endpoints
Machine Manifest	per-machine (ECU/VM)	network interfaces, available hardware resources and machine states
Service Manifest	per-process	service-oriented communication bindings, transport endpoints, platform data types, service interface definitions
Execution Manifest	per-process	executable→process binding with timing/priority/resource attributes, startup config, inter-process dependencies and state relationships

Together these answer: what processes exist, how they talk, and on what machine they live.

Execution Management and its startup sequence

Execution Management (EM) is the control plane for the platform's own processes (Foundation/Service FCs) and the Adaptive Applications.

Startup sequence:

1. The OS or hypervisor initializes the machine.
2. The OS starts EM as the first Adaptive AUTOSAR process.
3. EM starts the other FCs and AAs per the manifest, in dependency order.
4. If configured, authenticated boot is performed along the way.
5. EM reports each started process's state to PHM (Platform Health Management) for supervision.

The three nested state levels

EM tracks three nested levels of state, consumed by State Management. Each level is just a curated set of processes (plus lifecycle hooks) declared in the manifest.

Level	Meaning	Examples
Machine Functional Group (FG) State	processes available in a given Machine State	Startup, Running, Shutdown
FG State	processes available in a Function-Group state requested by State Management	Startup, Driving, Restart, Parking
Process / Execution State	state of a single process	Initializing, Running, Terminating

Design → Deploy serialization

A manifest exists in two phases:

• Design phase — the manifest is ARXML (the primary AUTOSAR exchange medium: software, network topology, communication, configuration).
• Deployment phase — the manifest takes deploy forms: JSON loaded by FCs at runtime, .conf loaded by kernel modules, or generated .h/.cpp included at build time.

The transformation from design manifest to deployment manifest is called SERIALIZATION (the ARXML → JSON step).

How Theia realizes ARA

Theia maps these AUTOSAR concepts onto its own primitives:

AUTOSAR concept	Theia realization
Execution Management	the supervisor (platform/supervisor/) — fork/exec, FG-state ownership, heartbeat watchdog. There is no separate exec process.
Design manifest (ARXML)	the .art model under system/ + services/ — the design-time source of truth
Serialization (ARXML → JSON)	artheia generate-manifest emitting the four deploy manifests as JSON
The four deploy manifests	dist/manifest/<machine>/{machine,application,service,execution}.json
Service Manifest bindings	TIPC type/instance addresses declared on each .art node
Process / Execution State	the supervisor's per-child lifecycle state
PHM supervision	the supervisor's heartbeat watchdog
ARA C++ APIs	the GenServer / GenStateM / GenRunnable runtime base classes and RemoteRef / RemoteCodec

In short: the .art tree is the design manifest, generate-manifest is the serialization step, the per-machine JSON files are the deploy manifests, and the supervisor is EM. See Deployment-Manifest-Generation-and-Serialization for the commands and Architecture for the runtime.