module ara::com — Communication Management

The Functional Cluster Communication Management (ara::com) enables service-oriented interaction between Adaptive Applications via standardized proxy and skeleton interfaces (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). It governs dynamic service discovery by means of OfferService() and FindService() ([SWS_CM_00101], [SWS_CM_00122]) and provides synchronous as well as asynchronous methods, events, and fields with integrated E2E and SecOC protection ([SWS_CM_00141], [SWS_CM_90420]). In case of temporary loss of a service, the middleware intercepts connection interruptions and automatically updates existing proxy objects upon re-availability (ARAComAPI p. 32).

more ›

The Functional Cluster Communication Management (ara::com) forms the backbone of the service-oriented architecture (SOA) in the AUTOSAR Adaptive Platform and decouples application logic from concrete transmission protocols via the proxy-skeleton pattern (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Proxy classes generated from formal interface descriptions on the consumer side and skeleton classes on the provider side provide methods, events, and fields via type-safe C++ APIs ([SWS_CM_00130], [SWS_CM_00131]).

The provision and dynamic search of services is handled via Service Discovery (SWS_CommunicationManagement p. 67). A provider offers its service via OfferService() ([SWS_CM_00101]), while consumers determine matching instances synchronously via FindService() or asynchronously by means of StartFindService() ([SWS_CM_00122], [SWS_CM_00123]). In doing so, instances can be addressed model-based via ara::core::InstanceSpecifier and resolved into concrete ara::com::InstanceIdentifier at runtime ([SWS_CM_00118], [SWS_CM_00622]).

Sequence diagram: Sequence of service offering, asynchronous search, and proxy creation. Sources: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

For data transmission, ara::com supports request-response methods via ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]) as well as publish-subscribe patterns for events and fields (AUTOSAR_EXP_ARAComAPI p. 68). Subscribers register via Subscribe() ([SWS_CM_00141]) and read incoming data via GetNewSamples() ([SWS_CM_00701]). To increase performance, the provider provides data via Allocate() and transfers ownership via zero-copy via Send() ([SWS_CM_90437], [SWS_CM_90438]).

To protect transmission, the platform integrates End-to-End protection (E2E), cryptographic authentication (SecOC) via Freshness Value Management (FVM), and signal-to-service translation for classic networks ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement p. 222). Error conditions are signaled in a standardized manner via type-safe error domains such as ComErrorDomain and ComE2EErrorDomain ([SWS_CM_10432], [SWS_CM_10474]). If the connection to a service breaks, the status of the proxy changes to kSubscriptionPending; upon renewed availability, the middleware transparently updates the internal addressing so that communication continues without re-instantiation of the proxy (ARAComAPI p. 32).

more ›

Role and System Architecture of Service-Oriented Communication

The Functional Cluster Communication Management (ara::com) forms the information technology backbone of the AUTOSAR Adaptive Platform and realizes service-oriented communication (Service-Oriented Architecture, SOA) between isolated application processes as well as across ECU boundaries (SWS_CommunicationManagement p. 55). The core principle is the strict proxy-skeleton design pattern (ARAComAPI p. 1): from formal software interface descriptions (Service Interfaces), a model-based code generator generates typed proxy classes for service consumers and skeleton classes for service providers ([SWS_CM_00130], [SWS_CM_00131]). The application logic interacts exclusively with these abstractions, while protocol-specific bindings such as SOME/IP, IPC, or DDS and their serialization are attached only at integration and deployment time (AUTOSAR_AP_EXP_ARAComAPI p. 124).

To satisfy platform requirements, ara::com cooperates closely with other functional clusters (SWS_CommunicationManagement p. 34). At runtime, Execution Management monitors the process lifecycle, while Identity and Access Management (IAM) prevents unauthorized interactions at method, event, and field level via policy-based access checks (Policy Decision Point) (SWS_CommunicationManagement p. 215). In addition, security events are reported directly to the EventReporter of the Intrusion Detection System Manager (IdSM) (SWS_CommunicationManagement p. 34).

Context diagram: Embedding of ara::com and decoupling of application layers via bindings. Sources: SWS_CommunicationManagement p. 55, ARAComAPI p. 1

Service Discovery and Instantiation via Proxies and Skeletons

Dynamic service brokering (Service Discovery) governs the establishment of local and distributed communication relationships (SWS_CommunicationManagement p. 67). A service provider signals its availability by calling OfferService() on the skeleton ([SWS_CM_00101]). If the service is terminated or provisioning is revoked, StopOfferService() withdraws the offer ([SWS_CM_00111]). Consumers determine matching service instances synchronously via FindService() or asynchronously via StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI p. 103). The latter registers a FindServiceHandler, which is notified upon every change in the instance landscape until the search is explicitly terminated using StopFindService() ([SWS_CM_00125], [SWS_CM_00383]).

To decouple source code from fixed network and instance IDs, the interface allows addressing via abstract model paths using ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI p. 124). The middleware resolves these specifiers into concrete ara::com::InstanceIdentifier via the stored Service Instance Manifest ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI p. 1). A discovered service is provided as a typed descriptor (HandleType) in a ServiceHandleContainer ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces p. 16). Via the static factory method Proxy::Create() or the constructor, the consumer creates a bound proxy instance for further functional use ([SWS_CM_10438], [SWS_CM_00131]).

Sequence diagram: Sequence of service offering, asynchronous search, and proxy creation. Sources: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Interaction Patterns: Method Calls and Asynchronous Processing

Method calls represent the synchronous and asynchronous request-response paradigm. The client triggers methods via the function call operator operator() on the proxy ([SWS_CM_00196]). A ara::core::Future serves as the standard return type, encapsulating the result or an error condition ([SWS_CM_00191], ARAComAPI p. 1). The consumer decides flexibly on the synchronization: by blocking retrieval via get(), time-monitored waiting via wait_for() or wait_until(), or by registering event-based callback routines using then() (ARAComAPI p. 1). For purely unidirectional notifications without feedback, fire-and-forget methods with a void return type exist ([SWS_CM_90434], [SWS_CM_90435]).

On the provider side, the MethodCallProcessingMode defines the execution strategy for incoming calls ([SWS_CM_00301], [SWS_CM_00130]). In event-driven mode (kEvent or kEventSingleThread), the method call takes place immediately within a worker thread managed by the middleware (AUTOSAR_SWS_CommunicationManagement p. 60). In polling mode (kPoll), the application controls the processing times deterministically itself by periodically calling ProcessNextMethodCall() ([SWS_CM_00199], EXP_SWArchitecture p. 68). The method implementation creates the result internally via a ara::core::Promise and returns the associated future (ARAComAPI p. 1).

Sequence diagram: Method call between proxy and skeleton under kPoll and kEvent dispatching. Sources: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement p. 60

Event and Field Communication in the Publish-Subscribe Pattern

The distribution of continuous data streams and state changes takes place via events and fields in the publish-subscribe pattern (SWS_CommunicationManagement p. 67). An active subscriber registers its interest in receiving data via Subscribe(), specifying the maximum number of samples to be held (maxSampleCount) ([SWS_CM_00141], [SWS_CM_12002]). The subscription state is queried via GetSubscriptionState() or monitored asynchronously via callbacks via SetSubscriptionStateChangeHandler() ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). Terminating the subscription is performed via Unsubscribe() ([SWS_CM_00151]).

Data reception can occur event-driven via SetReceiveHandler() or by periodically reading out the reception buffer ([SWS_CM_00181], [SWS_CM_11356]). With GetNewSamples(), the consumer passes a function object (lambda) that is called for each arrived sample with a typed SamplePtr ([SWS_CM_00701], [SWS_CM_11610]). To avoid copying overhead (zero-copy), the skeleton provides memory via Allocate() and sends the typed pointer SampleAllocateePtr to the transmission layer via Send() with complete transfer of ownership ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI p. 63, ARAComAPI p. 1).

A field extends the event concept by getter and setter semantics (AUTOSAR_EXP_ARAComAPI p. 68). Consumers read the field via Get() or write to it via Set() ([SWS_CM_00112], [SWS_CM_00113]). On the server side, these requests are served with RegisterGetHandler() and RegisterSetHandler(), respectively ([SWS_CM_00114], [SWS_CM_00116]). If the server updates the state via Update(), the field automatically acts as a notifier and distributes the change to all registered subscribers ([SWS_CM_00119], ARAComAPI p. 1).

Sequence diagram: Zero-copy allocation, event publishing, subscription, and GetNewSamples consumption. Sources: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI p. 63

Protection, Service Translation, and Platform Integration

For safety-related and deterministic data flows, ara::com integrates End-to-End protection (E2E) and authentication in accordance with AUTOSAR standards (AUTOSAR_AP_TR_SystemTests p. 132). Via GetProfileCheckStatus() and GetE2EStateMachineState(), consumers can check the integrity and validation status of received data ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). On the server side, the application registers error handling routines via SetTransportFaultConditionHandler() in order to react to E2E and transport defects at method level in a standardized manner ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture p. 68).

The cryptographic integrity and authenticity of external messages is ensured by Secure Onboard Communication (SecOC) (SWS_CommunicationManagement p. 222). For this purpose, the middleware integrates an exchangeable Freshness Value Management library (FVM), which manages freshness values via GetRxFreshness(), GetTxFreshness(), and Initialize() ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement p. 226). Diagnostic and security functions monitor or control verification via specific interfaces such as SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture p. 70).

For interoperability with the AUTOSAR Classic Platform, ara::com supports signal-based communication (Signal-to-Service Translation) (SWS_CommunicationManagement p. 146, TPS_ManifestSpecification p. 476). According to [SWS_CM_10174] and [SWS_CM_80001], classic signal IPDUs and SOME/IP messages can be transported over the same socket. If a signal-based SecOC configuration is present, the middleware reads the protection parameters directly from the PDU triggering of the manifest ([SWS_CM_11346], SWS_CommunicationManagement p. 228).

Activity diagram: E2E and SecOC protection pipeline for incoming messages. Sources: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement p. 222

Behavior in the event of an error

The error management of ara::com is based on type-safe error domains and return codes of the AUTOSAR core framework ([SWS_CM_11334], [SWS_CM_11335]). Errors of the general communication layer are aggregated in ComErrorDomain and encoded via the enumerator ComErrc ([SWS_CM_10432]). In the event of E2E check errors, ComE2EErrorDomain signals specific check errors such as checksum deviations or invalid counters via the enumeration value ComE2EErrc ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). For SecOC freshness errors, ComSecOcFvmErrorDomain with ComSecOcFvmErrc exists analogously ([SWS_CM_12521], [SWS_CM_12522]).

If a connection loss occurs during runtime, the subscription state of the proxy changes from kSubscribed to kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32). Method calls fail with an error during this phase. If the service provider subsequently returns via Service Discovery, the middleware updates the internal addressing of the proxy transparently without requiring the consumer to reinstantiate the proxy object; after successful re-synchronization, the state automatically returns to kSubscribed (ARAComAPI p. 32). According to the system specification, the application software itself is responsible for time limits and deadline monitoring (TPS_ManifestSpecification p. 504).

State diagram: Lifecycle and connection states of a proxy instance during provider availability changes. Sources: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32

Further detailed evidence

The essential requirements and system interfaces are structured into the AUTOSAR specifications as follows:

• Service lifecycle and discovery: Service provision and discovery mechanisms are based on [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122], and [SWS_CM_00123], detailed in the software architecture guide (ARAComAPI p. 103).
• Interaction paradigms: Methods and asynchronous future values are standardized in [SWS_CM_00191] and [SWS_CM_00196]; event subscriptions and sample transmissions follow [SWS_CM_00141], [SWS_CM_00701], and [SWS_CM_90437] (SWS_CommunicationManagement p. 67).
• Security and serialization: Protection concepts for E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]), and signal-to-service translation ([SWS_CM_10174]) govern system-wide data exchange (SWS_CommunicationManagement p. 146, SWS_CommunicationManagement p. 222).
• Manifest and type definitions: The mapping of structured data types, optional fields, and instance specifiers is anchored in the manifest specification (TPS_ManifestSpecification p. 161, TPS_ManifestSpecification p. 458).