PARA Overview

PARA (PopcornSAR AUTOSAR Runtime for Adaptive Application) is an Adaptive AUTOSAR (AP) runtime developed by PopcornSAR, targeting the standard AUTOSAR Adaptive Platform R25-11. It provides runtime libraries, daemons, and a configuration framework so that Adaptive Applications running on high-performance automotive ECUs can use service-oriented communication, execution management, logging, and more through the standard AUTOSAR AP APIs (ara::*).

Provided Functional Clusters

PARA consists of Functional Cluster libraries (lib/libpara_*.so) that correspond to the standard ara:: namespaces. The main clusters are as follows.

Library	ara:: namespace	Role	Runtime daemon
libpara_core	ara::core	Foundational types such as Result, Future, ErrorCode, and containers	—
libpara_com	ara::com	Service-oriented communication (SOME/IP, DDS, and IPC bindings)	CM
libpara_exec	ara::exec	Execution management (process lifecycle and state reporting)	EM
libpara_log	ara::log	Logging and tracing (DLT backend)	(dlt-daemon)
libpara_crypto	ara::crypto	Cryptographic operations, key management, and certificate handling	—
libpara_diag	ara::diag	Diagnostics (UDS-based diagnostic server)	DM
(part of libpara_com)	ara::iam	Identity and access management (access control declared in the manifest)	—
libpara_idsm	ara::idsm	Intrusion detection (reporting and collection of security events)	IDSM
libpara_phm	ara::phm	Platform health management (supervision and recovery actions)	PHM
libpara_rds	ara::rds	Raw data streams (unserialized byte streams, IEEE 1722)	—
libpara_sm	ara::sm	State management (Function Group state transitions)	SM
libpara_tsync	ara::tsync	Time synchronization (synchronized time bases)	TBM

libpara_com provides three bindings: SOME/IP and DDS carry service communication over the network, while IPC carries it between processes on the same machine. Which one an instance uses is declared per service instance with service-protocol (someip / dds / ipc) in the communication manifest, not chosen in application code. The DDS binding is available on runtimes built with the DDS implementation (Fast DDS) enabled.

ara::iam has no library of its own. AUTOSAR does not specify an application-facing C++ API for it; access rights are declared in the manifest, and PARA enforces them inside libpara_com when communication is established.

Runtime Operation Model

The PARA runtime is driven by manifest-based startup. When the machine powers on, EM comes up first and transitions MachineFG to Startup; that transition is what brings up the Platform Functional Cluster daemons. Understanding this model first makes the subsequent installation, example, and configuration documents much easier to follow.

Daemon	Name	Role
Execution Manager	EM	The entry point of the runtime. It scans manifests to build a dependency graph and starts/stops processes.
Communication Manager	CM	Handles service-oriented communication (service discovery, and the SOME/IP, DDS, and IPC bindings).
Diagnostic Manager	DM	Serves UDS diagnostic requests and relays them to the application.
Intrusion Detection System Manager	IDSM	Collects and processes reported security events.
Platform Health Manager	PHM	Supervises processes and triggers recovery actions on failure.
State Manager	SM	Decides Function Group state transitions and requests them from EM. It is a service-level application, so its implementation differs from project to project.
Time Base Manager	TBM	Maintains the synchronized time bases shared with other ECUs.

Which of these daemons actually run is determined by the machine's manifests.

The startup flow is as follows.

1. Configure the environment and run EM.
2. EM transitions MachineFG (Machine Function Group) from Off → Startup.
3. Each process declares, via state-dependencies in its execution manifest, "in which state of which Function Group it should start." The Platform Functional Cluster daemons (CM, DM, SM, …) and applications bound to MachineFG:Startup are started.
4. In other words, what to launch and when is decided by the manifest, not by code.

A Function Group is a bundle of processes that start/stop together and serves as a unit of state transition, while a manifest is the JSON configuration that holds those declarations. Details are covered in Function Group configuration and Execution configuration.

Next Steps

• Installation & Environment Setup — start with the prerequisites
• First Application — get started with examples