AUTOSAR Adaptive Architecture (ARA)
About 1510 wordsAbout 5 min
2026-03-25
ARA — AUTOSAR Runtime for Adaptive Applications
ARA (AUTOSAR Runtime for Adaptive Applications) is the collection of C++ APIs and platform services that Adaptive Applications use to interact with the platform. ARA is to Adaptive what the RTE is to Classic — the standardized interface between the application and the platform.
ARA has two functional groups:
ARA Architecture:
┌─────────────────────────────────────────────────────────────────┐
│ Adaptive Application │
│ #include <ara/com/com.h> │
│ #include <ara/exec/application_client.h> │
│ #include <ara/log/logging.h> │
└──────────────────────────┬──────────────────────────────────────┘
│
┌──────────────────────────┴──────────────────────────────────────┐
│ ARA Functional Clusters │
│ │
│ Communication: │
│ ara::com — Service-oriented communication │
│ ara::nm — Network Management │
│ ara::tsync — Time Synchronization │
│ │
│ Execution and Lifecycle: │
│ ara::exec — Execution Management client API │
│ ara::sm — State Management interface │
│ │
│ Diagnostics: │
│ ara::diag — Diagnostic Communication │
│ ara::phm — Platform Health Management │
│ │
│ Logging: │
│ ara::log — Logging and Tracing (DLT-based) │
│ │
│ Storage: │
│ ara::per — Persistency (key-value store, file access) │
│ │
│ Security: │
│ ara::crypto — Cryptographic operations │
│ ara::iam — Identity and Access Management │
│ │
│ Updates: │
│ ara::ucm — Update and Configuration Management client │
└─────────────────────────────────────────────────────────────────┘Functional Clusters in Detail
ara::com (Communication)
The core communication API. Provides publish/subscribe (events) and request/response (methods) via Skeleton (server side) and Proxy (client side) patterns.
→ Covered in full detail in autosar-05-ara-com.md
ara::exec (Execution Management)
The interface through which an Adaptive Application reports its state to the Execution Manager.
#include <ara/exec/application_client.h>
int main(int argc, char* argv[]) {
// Create the ApplicationClient — must be done first in main()
ara::exec::ApplicationClient app_client;
// Signal AUTOSAR ARA that initialization is complete;
// EM transitions app from kInitializing → kRunning
app_client.ReportApplicationState(ara::exec::ApplicationState::kRunning);
// ... main application loop ...
// Signal graceful termination
app_client.ReportApplicationState(ara::exec::ApplicationState::kTerminating);
return 0;
}ara::diag (Diagnostic Communication)
Provides UDS-based diagnostic services from within an Adaptive Application. Equivalent to DEM/DCM in Classic.
#include <ara/diag/uds_error_domain.h>
#include <ara/diag/monitor.h>
// Report a diagnostic fault event
ara::diag::Monitor my_monitor{"MonitorName",
ara::diag::DiagnosticMonitorInitialStatus::kPassedOrFailed};
my_monitor.ReportMonitorAction(ara::diag::MonitorAction::kFailed);ara::log (Logging and Tracing)
Standardized structured logging with DLT (Diagnostic Log and Trace) backend. All log entries have a: context ID, application ID, severity level, and optional payload.
#include <ara/log/logging.h>
// Create a logger context for this component
ara::log::Logger& logger = ara::log::CreateLogger("PERC", // context ID
"Perception module",
ara::log::LogLevel::kVerbose);
// Log a message with severity and data
logger.LogInfo() << "Perception pipeline started. FPS target: " << fps_target;
logger.LogWarn() << "Object confidence below threshold: " << confidence;
logger.LogError() << "Sensor timeout after " << timeout_ms << " ms";ara::per (Persistency)
Provides key-value storage and file access for persistent data within an application:
#include <ara/per/key_value_storage.h>
// Open a key-value store (defined in the Application Manifest)
auto kvs = ara::per::OpenKeyValueStorage("CalibrationStore");
// Read a value
auto result = kvs->GetValue<float>("TorqueSensorOffset");
if (result.HasValue()) {
float offset = result.Value();
}
// Write a value
kvs->SetValue<float>("TorqueSensorOffset", 0.045f);
kvs->SyncToStorage(); // flush to persistent storageara::crypto (Cryptographic Operations)
Provides hardware-backed cryptographic operations:
#include <ara/crypto/cryp/cryobj/crypto_context.h>
// Sign a firmware update signature with an internal private key
// (key never leaves the Hardware Security Module)
auto sig_context = crypto_provider->CreateMsgRecoveryPublicCtx(
kEcPrimeStarAlgo);
auto result = sig_context->Verify(message_span, signature_span);ara::phm (Platform Health Management)
Applications supervise their own checkpoints and report health to PHM:
#include <ara/phm/supervised_entity.h>
ara::phm::SupervisedEntity supervised_entity{"PerceptionApp"};
// Report alive supervision checkpoint (must be called within configured period)
supervised_entity.ReportCheckpoint(kAliveCheckpoint_ID);
// Report logical program flow checkpoint
supervised_entity.ReportCheckpoint(kLogicCheckpointA_ID);
// ... execute algorithm ...
supervised_entity.ReportCheckpoint(kLogicCheckpointB_ID);ara::ucm (Update and Configuration Management)
UCM handles OTA update orchestration. Applications request the UCM to install packages:
#include <ara/ucm/package_manager.h>
// Check available update packages
auto packages = ucm_client.GetSwPackages();
for (auto& package : packages) {
if (package.state == SoftwarePackageState::kTransferred) {
// Activate the package (requires machine state transition to Update mode)
ucm_client.ProcessSwPackage(package.id);
}
}Adaptive Platform Services (Below ARA)
Below the ARA API layer, the Adaptive Platform implements the functional clusters as system-level services. These services are themselves Adaptive Applications (or privileged platform processes) that provide functionality via ara::com.
Core Platform Services
Adaptive Platform Service Architecture:
┌─────────────────────────────────────────────────────────────────┐
│ Adaptive Applications │
│ (User-space POSIX processes) │
│ MyApp PerceptionService PathPlanningService │
└──────────┬───────────┬───────────┬──────────────────────────────┘
│ ara::com │ ara::exec │ ara::log
┌──────────┴───────────┴───────────┴──────────────────────────────┐
│ Platform Services │
│ │
│ ┌───────────────────────┐ ┌──────────────────────────────┐ │
│ │ Execution Manager │ │ Communication Management │ │
│ │ (Process lifecycle, │ │ (Service registry, SOME/IP │ │
│ │ state machine, │ │ or DDS routing, IPC) │ │
│ │ health reporting) │ └──────────────────────────────┘ │
│ └───────────────────────┘ │
│ ┌───────────────────────┐ ┌──────────────────────────────┐ │
│ │ Crypto Service │ │ Log and Trace Service │ │
│ │ (HSM-backed crypto, │ │ (DLT daemon; aggregates │ │
│ │ key management) │ │ all app log streams) │ │
│ └───────────────────────┘ └──────────────────────────────┘ │
│ ┌───────────────────────┐ ┌──────────────────────────────┐ │
│ │ Platform Health Mgr │ │ Identity and Access Mgr │ │
│ │ (Supervised entities,│ │ (AUTOSAR permissions model, │ │
│ │ recovery actions) │ │ service access control) │ │
│ └───────────────────────┘ └──────────────────────────────┘ │
│ ┌───────────────────────┐ ┌──────────────────────────────┐ │
│ │ UCM (Update Manager) │ │ State Manager │ │
│ │ (OTA coordination, │ │ (System-level state machine, │ │
│ │ package validation) │ │ power modes, drive modes) │ │
│ └───────────────────────┘ └──────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│ POSIX system calls
┌──────────┴──────────────────────────────────────────────────────┐
│ POSIX Operating System │
│ (Linux / QNX / PikeOS / INTEGRITY) │
└─────────────────────────────────────────────────────────────────┘Communication Middleware Architecture
ara::com is a language binding (C++) on top of a middleware layer. The actual inter-process and inter-ECU communication is handled by a pluggable transport binding.
ara::com Architecture with Transport Bindings:
Application uses ara::com API only (transport-independent)
─────────────────────────────────────────────────────────
MyApp:
proxy.CameraFeed.Subscribe(10); // ara::com call
auto result = proxy.GetObjectList.Call(); // ara::com call
─────────────────────────────────────────────────────────
ara::com generates calls to the configured transport binding:
Transport Binding Options:
┌─────────────────────────────────────────────────────────┐
│ SOME/IP (default for Ethernet in Adaptive Platform) │
│ RFC: AUTOSAR SOME/IP Protocol Specification │
│ Use: Service-to-service communication over UDP/TCP │
├─────────────────────────────────────────────────────────┤
│ DDS (Data Distribution Service — OMG standard) │
│ Use: High-throughput, low-latency data streaming │
│ (LiDAR point clouds, camera frames) │
├─────────────────────────────────────────────────────────┤
│ IPC (Intra-machine communication) │
│ Use: Communication between two AAs on the same SoC │
│ Often implemented via shared memory + semaphore │
│ or domain sockets │
├─────────────────────────────────────────────────────────┤
│ Custom transport (vendor-specific) │
│ Some vendors implement proprietary high-speed bindings │
└─────────────────────────────────────────────────────────┘Adaptive Application Lifecycle
An Adaptive Application goes through defined states managed by the Execution Manager:
Adaptive Application Lifecycle:
[ECU Power On]
│
│ EM reads Execution Manifest → determines FunctionGroup and startup condition
▼
┌─────────────┐
│ Initializing│ ← Application started by EM; performs initialization
│ │ (Initialize middleware, open service connections,
│ │ load persistent data from ara::per)
└──────┬──────┘
│ app_client.ReportApplicationState(kRunning)
▼
┌─────────────┐
│ Running │ ← Normal operation; application processes data, serves requests
│ │ EM monitors via PHM supervised entities (alive checkpoints)
│ │
│ │ ← State Manager may request state change (e.g., system to Parking mode)
│ │ SM calls Execution Management to terminate some applications
└──────┬──────┘
│ Termination requested by EM (SIGTERM or state change)
│ app_client.ReportApplicationState(kTerminating)
▼
┌─────────────┐
│ Terminating │ ← Graceful shutdown: flush buffers, un-offer services,
│ │ commit persistent data, close connections
└──────┬──────┘
│ Process exits (return 0)
▼
[Process terminated — EM confirms]Machine State vs. Function Group State
AUTOSAR Adaptive introduces a hierarchical state management concept:
Machine State
The machine-level lifecycle state managed by Execution Management:
Machine State transitions:
Startup ──► Driving ──► Parking ──► Shutdown ──► Off
│ │
└──► LowPower └──► Update (for OTA)Function Group State
A subset of applications can be grouped into a Function Group. The State Manager activates/deactivates Function Groups based on driving mode.
Function Group: "ADAS_Features"
States:
Off: No ADAS processes running
Standby: Perception initialized but not outputting actuation
Active: All ADAS features running, sending control to vehicle
State transition driven by:
- Vehicle speed > 5 km/h → transition from Standby → Active
- ADAS disable button pressed → transition Active → Standby
- System fault → transition Active → Off (recovery action)Applications declare in their Execution Manifest which Function Group state they should be active in:
<EXECUTION-MANIFEST>
<PROCESS-REF>/Processes/PerceptionProcess</PROCESS-REF>
<FUNCTION-GROUP-REF>/FunctionGroups/ADAS_Features</FUNCTION-GROUP-REF>
<FUNCTION-GROUP-STATE-DEPENDENT>
<FUNCTION-GROUP-STATE>Active</FUNCTION-GROUP-STATE>
</FUNCTION-GROUP-STATE-DEPENDENT>
</EXECUTION-MANIFEST>Intra-Cluster Communication (IPC on Same Machine)
When two Adaptive Applications on the same SoC communicate via ara::com with an IPC transport binding, the flow is:
PerceptionService (Process A) PathPlanningService (Process B)
│ │
ara::com Skeleton ara::com Proxy
→ Offers "ObjectList" event → Subscribes to "ObjectList"
│ │
│ Communication Management │
│ │
┌─────┴──────────────────────────────────────────┴─────┐
│ IPC Transport Binding │
│ (POSIX shared memory + eventfd) │
└──────────────────────────────────────────────────────┘
PerceptionService writes new ObjectList → shm segment
Signals eventfd → PathPlanningService woken up
PathPlanningService reads ObjectList from shm via Proxy
Latency: typically ~50-200 µs for large data (much lower than network)
Bandwidth: limited by RAM bandwidth (>10 GB/s on modern SoC)ARA Namespace C++ API Summary
// All ara:: includes and namespace structure
namespace ara {
namespace com { /* Service communication: proxy, skeleton, events, methods, fields */ }
namespace exec { /* Execution: ApplicationClient, ApplicationState */ }
namespace diag { /* Diagnostics: Monitor, DiagnosticServiceDataIdentifier */ }
namespace log { /* Logging: Logger, LogLevel, CreateLogger() */ }
namespace per { /* Persistency: KeyValueStorage, FileStorage */ }
namespace crypto { /* Cryptography: Provider, Key, CipherContext */ }
namespace phm { /* Health: SupervisedEntity, RecoveryAction */ }
namespace nm { /* Network Management: NetworkHandle */ }
namespace tsync { /* Time sync: LeapJumpCallback, SynchronizedTimeBaseConsumer */ }
namespace ucm { /* Update: PackageManager, SwPackage */ }
namespace iam { /* Identity: ServicePermission, ApplicationAccessRoleSet */ }
namespace rest { /* REST API: RequestHandlerClient, HttpMethod */ }
namespace sm { /* State Management: StateClient, FunctionalGroupState */ }
namespace core { /* Core types: Result<T,E>, ErrorCode, ErrorDomain, Future<T> */ }
}ara::core::Result and Error Handling
AUTOSAR Adaptive replaces traditional exception-based error handling with the Result pattern (similar to Rust's Result<T, E>):
#include <ara/core/result.h>
// Function returning Result instead of throwing exceptions
ara::core::Result<float> ReadTemperature(SensorId id) {
if (!IsSensorAvailable(id)) {
return ara::core::Result<float>::FromError(
ara::core::ErrorCode{SensorErrorDomain::kNotAvailable});
}
return ara::core::Result<float>::FromValue(ReadADC(id) * TEMP_GAIN);
}
// Caller handles both success and error
auto temp_result = ReadTemperature(SENSOR_A);
if (temp_result.HasValue()) {
float temp = temp_result.Value();
logger.LogInfo() << "Temperature: " << temp;
} else {
logger.LogError() << "Sensor read failed: " << temp_result.Error().Message();
}This pattern ensures errors are explicit, forces callers to handle failure cases, and avoids exception overhead — important for deterministic performance in automotive contexts.