module ara::core — Adaptive Platform Core

The module core provides the platform-wide basic types, PMR memory pools, and asynchronous synchronization primitives Future and Promise for the AUTOSAR Adaptive Platform (SWArchitecture p. 60, [SWS_CORE_00326]). To meet strict safety and real-time requirements, the sum type Result<T, E> replaces classic exceptions with deterministic return values ([SWS_CORE_00751]). In the event of irreparable system errors, the fail-fast function Abort() ensures immediate, controlled process termination ([SWS_CORE_00052]).

more ›

The module core functions as a basic functional cluster of the AUTOSAR Adaptive Platform and provides uniform data structures, asynchronous communication primitives, and memory management mechanisms for all platform services and applications (SWArchitecture p. 60). To guarantee deterministic execution and functional safety in POSIX operating system environments, core replaces conventional C++ exceptions with the type-safe result type Result<T, E> and controls dynamic memory allocations via polymorphic allocators ([SWS_CORE_00041], [SWS_CORE_00751]).

Context diagram: Embedding of the functional cluster ara::core and its interface areas into the Adaptive Platform. Sources: SWArchitecture p. 60, SWArchitecture p. 36

For concurrent synchronization, core implements the interplay between Future and Promise ([SWS_CORE_00326], [SWS_CORE_00344]). While the producer provides the computation status or errors via the Promise, Future allows the consumer both time-monitored queries via wait_for() and reactive forwardings by means of then() ([SWS_CORE_00329], [SWS_CORE_00331], TimeSynchronization p. 90).

Activity diagram: Deterministic evaluation path of a Result object in the error-free case and in the error case. Sources: [SWS_CORE_00751], [SWS_CORE_00755], [SWS_CORE_00757], [SWS_CORE_00766]

To avoid fragmentation, the module provides pool resources such as SynchronizedPoolResource and UnsynchronizedPoolResource that restrict allocations to fixed-size chunks ([SWS_CORE_00030], [SWS_CORE_00067], SWArchitecture p. 61). If an insurmountable error condition occurs, the platform enforces immediate fail-fast termination of the process via Abort() following the prior execution of a registered AbortHandler ([SWS_CORE_00051], [SWS_CORE_00052]).

more ›

System Role and Architectural Foundation of ara::core

The module core forms the fundamental foundation of the AUTOSAR Adaptive Platform and provides basic type definitions, memory management mechanisms, and basic interfaces for all functional clusters and Adaptive Applications (SWArchitecture p. 60). In contrast to application-specific services, core is designed to be process-local and defines the essential abstractions to realize portable, deterministic, and resource-efficient C++ software within POSIX operating system environments (SWArchitecture p. 36).

Architecturally, the module functions as a standardized interface between the low-level operating system functions and the higher layers of the Adaptive Platform (SWArchitecture p. 60). In doing so, core addresses key requirements for functional safety (ASIL) and real-time capability by making dynamic memory allocations controllable and dispensing with the pervasive use of C++ exceptions in regular control flow ([SWS_CORE_00052], [SWS_CORE_00751]). Providing platform-wide basic types prevents proprietary isolated solutions between middleware components such as ara::com or ara::ts (ARAComAPI p. 46, TimeSynchronization p. 90).

Context diagram: Embedding of the functional cluster ara::core and its interface areas into the Adaptive Platform. Sources: SWArchitecture p. 60, SWArchitecture p. 36

Asynchronous Control and Data Flows via Future and Promise

For concurrent and decoupled interaction, ara::core implements the producer-consumer pattern using Promise and Future ([SWS_CORE_00326], [SWS_CORE_00341]). A Promise represents the writing interface through which an asynchronous worker or a communication skeleton deposits the result or an error ([SWS_CORE_00345], [SWS_CORE_00353]). The consuming counterpart is Future, which monitors the shared state and encapsulates type-safe access to the return value (ARAComAPI p. 46, ARAComAPI p. 59).

To prevent client threads from blocking, Future provides time-bounded wait operations in addition to the synchronous, blocking query function get() ([SWS_CORE_00326]): wait_for() and wait_until() return a status indicator of type FutureStatus ([SWS_CORE_00329], [SWS_CORE_00330], ARAComAPI p. 1). Via the method then(), callbacks can be registered that are executed automatically upon arrival of the result; optionally, a user-specific Executor can be integrated here to direct execution to specific thread pools ([SWS_CORE_00024], [SWS_CORE_00331], [SWS_CORE_00337]). Copy operations are explicitly prohibited for Future and Promise to ensure exclusive ownership ([SWS_CORE_00334], [SWS_CORE_00350]).

Sequence diagram: Asynchronous value and error transmission between worker and application via Promise and Future. Sources: [SWS_CORE_00326], [SWS_CORE_00329], [SWS_CORE_00344], [SWS_CORE_00345], TimeSynchronization p. 90

Deterministic Error Management: Result, ErrorCode, and ErrorDomain

A core aspect of safety-oriented programming in the Adaptive Platform is the strict avoidance of uncontrolled exceptions during regular operation. ara::core::Result<T, E> functions as a type-safe sum type encapsulation that contains either a success payload value of type T or an error object of type E ([SWS_CORE_00721], [SWS_CORE_00723], [SWS_CORE_00751]). Specializations exist both for reference types Result<T&, E> and for operations without return values Result<void, E> ([SWS_CORE_00821], [SWS_CORE_00908]).

The contained state is checked via HasValue() or the explicit conversion operator operator bool() ([SWS_CORE_00751], [SWS_CORE_00752]). Payload data is accessed via Value() or operator*(), while errors are queried via Error() ([SWS_CORE_00755], [SWS_CORE_00757]). For functional further processing and error propagation, Result provides methods such as Bind(), ValueOr(), and Resolve() ([SWS_CORE_00761], [SWS_CORE_00768]). Errors are modeled via ErrorCode, which links a numerical error code CodeType with a unique domain identifier ErrorDomain as well as optional diagnostic additional data SupportDataType ([SWS_CORE_00121], [SWS_CORE_00122], [SWS_CORE_00512]). The method ValueOrThrow() exists as a bridge for environments with enabled exception handling, but throws the exception associated with the domain in the event of an error ([SWS_CORE_00154], [SWS_CORE_00766]).

Activity diagram: Deterministic evaluation path of a Result object in the error-free case and in the error case. Sources: [SWS_CORE_00751], [SWS_CORE_00755], [SWS_CORE_00757], [SWS_CORE_00766]

Polymorphic Memory Management via Pool Resources

Dynamic allocation on the default heap entails risks regarding non-determinism and memory fragmentation. ara::core therefore integrates memory management based on polymorphic memory resources (PMR), patterned after the C++ NVI pattern (Non-Virtual Interface) (SWArchitecture p. 61). The base class MemoryResource declares the public interfaces allocate() and deallocate(), which internally invoke the pure virtual methods do_allocate() and do_deallocate() ([SWS_CORE_00041], [SWS_CORE_00061]).

Specialized pool resources are available for real-time-critical allocation patterns: SynchronizedPoolResource provides thread-safe allocations from preconfigured chunks and block sizes via PoolOptions ([SWS_CORE_00027], [SWS_CORE_00030]). For strictly thread-local processing phases without synchronization overhead, UnsynchronizedPoolResource is used ([SWS_CORE_00046], [SWS_CORE_00067]). Via release(), the entire allocated memory area can be returned to the upstream upstream_resource() in a single step, which effectively prevents memory leaks in phase-oriented workflows ([SWS_CORE_00037], [SWS_CORE_00038], [SWS_CORE_00065]).

Class diagram: Hierarchy of polymorphic memory resources according to the Non-Virtual Interface (NVI) pattern. Sources: SWArchitecture p. 61, [SWS_CORE_00030], [SWS_CORE_00041], [SWS_CORE_00061]

Fundamental Utility and Container Types (Optional, Array, Vector, Map)

To avoid undefined behavior and ensure clear semantics, core standardizes elementary containers and utility types. ara::core::Optional<T> represents values that may or may not be present without having to resort to unsafe null pointers ([SWS_CORE_01103], [SWS_CORE_01104], ARAComAPI p. 1). The state is queried via has_value() or operator bool(), while access is performed via value(), value_or(), or operator*() ([SWS_CORE_01128], [SWS_CORE_01129], [SWS_CORE_01130], [SWS_CORE_01134]). Special reference overloads Optional<T&> allow optional references to be held safely ([SWS_CORE_01151], [SWS_CORE_01167]).

For fixed-size data structures, the module provides Array<T, N>, which supports direct indexing via operator[], bounds-checked access using at(), as well as standard iterators ([SWS_CORE_01250], [SWS_CORE_01265], [SWS_CORE_01273]). Comparison operators are implemented according to strict coding guidelines with bool return types and exception safety ([SWS_CORE_01290], CPP14Guidelines p. 241). Dynamically growing sequences and associative containers are covered by Vector<T, Allocator> and Map<Key, T, Compare, Allocator> ([SWS_CORE_01318], [SWS_CORE_01428]). Both types accept configurable allocators, allowing allocations to be handled seamlessly via the polymorphic MemoryResource pools ([SWS_CORE_00066], [SWS_CORE_01303], [SWS_CORE_01406]).

Error Behavior and Fail-Fast Termination

If a process cannot safely compensate for a severe error state, the fail-fast principle of the Adaptive Platform takes effect (SWArchitecture p. 60). Via the interface Abort(), immediate, unconditional termination of the running process is brought about ([SWS_CORE_00052]). The function is declared as [[noreturn]] and noexcept to ensure that no stack unwinding routines or destructors produce incorrect subsequent states ([SWS_CORE_00052], SWArchitecture p. 36).

To save volatile diagnostic information or execute final emergency logging actions prior to termination, applications can register user-specific callback functions via SetAbortHandler() or AddAbortHandler() ([SWS_CORE_00050], [SWS_CORE_00051], [SWS_CORE_00054]). A registered abort handler must satisfy the signature void() noexcept ([SWS_CORE_00053]). After execution of the handler, the platform enforces final termination of the process so that continued execution in an undefined memory state is not possible (SWArchitecture p. 60).

Activity diagram: Control flow of the fail-fast abort via Abort() with execution of the AbortHandler. Sources: SWArchitecture p. 60, [SWS_CORE_00051], [SWS_CORE_00052]

Further detailed evidence

The specification of core in release R25-11 is based on a series of normative requirements and architectural models. Constitutive for process lifecycle and emergency-stop behavior are Initialize(), Deinitialize() as well as Abort() and SetAbortHandler() ([SWS_CORE_00051], [SWS_CORE_00052], SWArchitecture p. 60). The asynchronous communication model relies significantly on Future ([SWS_CORE_00326], [SWS_CORE_00329]) and Promise ([SWS_CORE_00344], [SWS_CORE_00345]), whose interplay is verified in application-level clusters such as ara::com and ara::ts (ARAComAPI p. 46, TimeSynchronization p. 90).

Error-free data and memory management is standardized by the specifications for Result ([SWS_CORE_00751], [SWS_CORE_00766]), ErrorCode ([SWS_CORE_00512]), and the PMR memory classes SynchronizedPoolResource as well as UnsynchronizedPoolResource ([SWS_CORE_00030], [SWS_CORE_00046], SWArchitecture p. 61). In addition, container and comparison guidelines define deterministic data storage in safety-critical overall systems ([SWS_CORE_01103], [SWS_CORE_01250], [SWS_CORE_01318], CPP14Guidelines p. 241).