class <SI-Namespace>::skeleton::<SI>Skeleton

The method OfferService() is called on an instance of the skeleton class to offer a provided service in the system and make it discoverable for consumers via Service Discovery [SWS_CM_00101], ARAComAPI §6.5 “Service Discovery”. The call is parameterless and synchronous as soon as the service implementation has been fully instantiated and transitioned into an operational state AUTOSAR_AP_EXP_ARAComAPI §5.4.4 “Offering Service instance”. The function is declared as noexcept and returns a ara::core::Result<void> [SWS_CM_00101].

Offering is a mandatory prerequisite for functional communication via methods, events, fields, or triggers AUTOSAR_AP_EXP_ARAComAPI §4.2 “Means of Communication”. If, for example, an attempt is made to send a trigger without prior offering, this fails with ComErrc::kServiceNotOffered [SWS_CM_00721]. Regarding concurrency: As soon as OfferService() is called, incoming method calls can already be dispatched to the service instance — even if the call to OfferService() has not yet returned AUTOSAR_AP_EXP_ARAComAPI §5.4.4 “Offering Service instance”.

If offering fails, the returned ara::core::Result contains a corresponding error code from ComErrc [SWS_CM_00101], [SWS_CM_10432]:

• ComErrc::kFieldValueNotInitialized: At least one configured field value was not yet initialized prior to offering [SWS_CM_00101].
• ComErrc::kFieldSetHandlerNotSet: No handler has been registered via RegisterSetHandler() yet for a field with setter support [SWS_CM_00101].
• ComErrc::kCommunicationFailure: The network binding reports a recoverable communication error or failure of secure communication [SWS_CM_00101].

If the provision of the service is to be stopped, StopOfferService() must be called AUTOSAR_AP_EXP_ARAComAPI §5.4.4 “Offering Service instance”.

The method ProcessNextMethodCall() serves service providers in the skeleton to process incoming method calls deterministically in polling mode [SWS_CM_00199]. It may only be used if the skeleton instance was configured with mode ara::com::MethodCallProcessingMode::kPoll EXP ARAComAPI §2 “Polling”.

Usage and Semantics

The function takes no parameters and executes a pending method call request synchronously in the caller's thread context [SWS_CM_00199], [SWS_CM_00191]. This particularly allows real-time applications to process service requests without uncontrolled thread context switches within their allocated time budget EXP ARAComAPI §5.4 “ProcessNextMethodCall”. The return value signals the result of the retrieval:

• true: At least one pending request was in the queue and was processed [SWS_CM_00199].
• false: There was no pending request; the queue was empty [SWS_CM_00199]. A direct follow-up call after a false generally has no effect EXP ARAComAPI §5.4 “ProcessNextMethodCall”.

Error Handling and Boundary Conditions

The function is specified as noexcept and exception safe [SWS_CM_00199]. A call on a skeleton instantiated with kEvent or kEventSingleThread constitutes a violation (WrongMethodCallProcessingModeViolation) [SWS_CM_00199]. Interpretation: Since regular C++ exceptions are excluded by noexcept, such a violation is likely treated as a severe runtime error on the platform side. Question Q-61661dbd6cc37bc7 (open)

use

The function SetTransportFaultConditionHandler serves to register a callback of type ara::com::e2e::TransportFaultConditionHandler in the namespace of the skeleton class (<SI-Namespace>::skeleton::<SI>) [SWS_CM_00093]. Via this handler, transport errors are reported for all methods of the respective service instance AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 “End-to-end communication protection for SOMEIP”. The function takes the callable object handler and has no return value (void) [SWS_CM_00093].

Error handling

The operation is declared with noexcept and is exception-safe (exception safe) [SWS_CM_00093]. If the passed callable entity does not exist or is null, an InvalidHandlerViolation is thrown [SWS_CM_00093]. In case of an error, the configured handler reports occurred transport failures such as TransportFaultCondition::kSampleRejected when requests are dropped due to resource shortage or corruption in the transport layer AUTOSAR_AP_SWS_CommunicationManagement §7.4.2.3 “Methods”.

Concurrency and Limitations

Interpretation: Since this base interface does not accept an execution context, the callback is likely called synchronously from the internal thread of the Communication Management. Question Q-e4007fa72de6aa12 (open) If the handler is to be executed in a defined thread pool or worker, the overload with ExecutorT&& executor must be used [SWS_CM_00094].

Interaction

The registration centrally binds error handling to all methods of a skeleton instance [SWS_CM_00093]. It integrates into the overarching error handling of ara::com:

• While skeleton methods report transport errors via this handler, client methods signal transport failures asynchronously via their resulting ara::core::Future with ComErrc::kCommunicationFailure [SWS_CM_00090].
• Separate interfaces [SWS_CM_00096] exist for field operations (Get/Set) at the skeleton level.
• At the proxy level, analogous registration functions are available for events [SWS_CM_00099], triggers [SWS_CM_00106], and notifiers [SWS_CM_00109].

The template function SetTransportFaultConditionHandler in the namespace of the skeleton class serves to register an error handler for transport errors of all methods of a service instance [SWS_CM_00094]. It extends the parameterless base function [SWS_CM_00093] with an execution context:

• Call and parameters: A callable handler of type ara::com::e2e::TransportFaultConditionHandler and a universal reference executor [SWS_CM_00094] are passed. All asynchronous computations and callback executions must be started in this executor object. The function has no return value.
• Error handling: The interface is declared as noexcept and specified as exception-safe [SWS_CM_00094]. If the passed callable does not exist or is null, a InvalidHandlerViolation is present [SWS_CM_00094].
• Interaction: The scope covers all methods of the skeleton [SWS_CM_00094], while separate registration functions are available for field Get and Set operations ([SWS_CM_00096], [SWS_CM_00097]). In the DDS network binding, the configured handler reports transport errors such as TransportFaultCondition::kSampleRejected [SWS_CM_00216]; on the client side, however, such errors are signaled via ComErrc::kCommunicationFailure in the result futures [SWS_CM_00090].
• Concurrency: Interpretation: Passing the executor decouples error handling from the internal context of the communication layer; registration should presumably occur early during skeleton initialization before the arrival of initial method calls. Question Q-e56b2a1928cf32ad (open)

The constructor [SWS_CM_00130] instantiates a service skeleton based on a concrete ara::com::InstanceIdentifier. The skeleton connects the application-side service implementation to the transport layer of Communication Management so that distributed service consumers can access it (ARAComAPI §5.1 “Proxy Skeleton Pattern”).

The parameter mode defines how incoming method calls are processed. The event-based mode ara::com::MethodCallProcessingMode::kEvent is specified as the default value [SWS_CM_00130]. If a polling-based mode is selected instead, pending method calls are executed synchronously in the calling context of ProcessNextMethodCall() [SWS_CM_00199].

Error Handling and Boundary Conditions

The constructor function is declared with noexcept and throws no C++ exceptions [SWS_CM_00130]. Possible violations are signaled via the runtime system: If creation is denied by grant enforcement, a InsufficientPermissionsViolation is present; passing an invalid processing mode results in a WrongMethodCallProcessingModeViolation [SWS_CM_00130]. Interpretation: Validation of the processing mode is likely to take place directly during constructor execution. Question Q-80e02c0079757082 (open)

Copy operations are explicitly deleted for the skeleton [SWS_CM_00134], whereas move construction is supported [SWS_CM_00135]. For the service to become discoverable on the network, OfferService() must be called after instantiation [SWS_CM_00101] (ARAComAPI §6.5 “Service Discovery”). Before destroying the instance [SWS_CM_11370], provision can be terminated again using StopOfferService() [SWS_CM_00111].

The constructor instantiates a service skeleton based on an instance specifier [SWS_CM_00152]. It serves to bind a concrete service implementation to the transport layer of Communication Management. A ara::core::InstanceSpecifier and optionally the processing mode ara::com::MethodCallProcessingMode, which defaults to kEvent, are passed as parameters [SWS_CM_00152].

Regarding error handling and exception behavior, the constructor is declared as noexcept and exception safe [SWS_CM_00152]. For incorrect configurations or modeling deviations, the following violations are specified:

• InstanceSpecifierMappingIntegrityViolation, if the specifier cannot be resolved in the execution context or does not reference a PortPrototype [SWS_CM_00152].
• PortInterfaceMappingViolation and ProcessMappingViolation, if the mapping type and interface type do not match [SWS_CM_00152].
• InstanceSpecifierAlreadyInUseViolation, if the InstanceSpecifier is already in use [SWS_CM_00152].
• WrongMethodCallProcessingModeViolation and InsufficientPermissionsViolation in case of insufficient permissions [SWS_CM_00152].

Interpretation: Since the constructor is declared as noexcept, the specified violations are likely not propagated as thrown C++ exceptions at runtime, but are caught by platform-side checks or grant enforcement. Question Q-f1a1a0baeb56e482 (open)

For lifecycle and concurrency, the copy constructor is deleted [SWS_CM_00134], while a move constructor is available [SWS_CM_00135]. Release occurs via the virtual destructor [SWS_CM_11370]. After successful construction, the service is typically offered on the network via [SWS_CM_00101] (OfferService). If kPoll was chosen as the processing mode, the application must explicitly process incoming calls to service methods [SWS_CM_00191] via [SWS_CM_00199] (ProcessNextMethodCall).

use

The constructor instantiates a service skeleton based on a container of instance identifiers (instanceIDs) and connects the service implementation on the server side to the transport layer of Communication Management [SWS_CM_00153], ARAComAPI §5.1 “Proxy Skeleton Pattern”. The parameter mode defines how incoming method calls are processed; by default, handling is event-driven via kEvent [SWS_CM_00153]. Alternatively, constructors for single instance identifiers [SWS_CM_00130] or instance specifiers [SWS_CM_00152] are available.

Error Handling and Concurrency

The function is declared as noexcept and specified as exception-safe (exception safe) [SWS_CM_00153]. Possible violations during creation are WrongMethodCallProcessingModeViolation when passing an invalid processing mode and InsufficientPermissionsViolation if grant enforcement (Grant Enforcement) fails [SWS_CM_00153].

If the polling model (kPoll) is configured for mode, the server application must process pending method calls synchronously in its own thread context by calling ProcessNextMethodCall() [SWS_CM_00199]. The copy constructor of the skeleton class is deleted (delete) [SWS_CM_00134]; moves, on the other hand, are supported via the move constructor [SWS_CM_00135].

Interaction

After successful instantiation, the service is offered via OfferService() for remote or local consumers [SWS_CM_00101], ARAComAPI §6.5 “Service Discovery”. Before destroying the skeleton via destructor [SWS_CM_11370], offering should be stopped via StopOfferService() [SWS_CM_00111]. Incoming method calls return a ara::core::Future on the server side [SWS_CM_00191].

The virtual destructor ~<SI>Skeleton() [SWS_CM_11370] terminates the lifecycle of a service skeleton instance. As a generated artifact, the service skeleton connects the concrete service implementation to the transport layer of Communication Management, allowing service consumers to access the offered methods and functionalities (ARAComAPI §5.1 “Proxy Skeleton Pattern”).

Destruction takes place synchronously when tearing down the derived implementation class. The method accepts no parameters and declares no return value. In contrast to constructors of the skeleton such as [SWS_CM_00130] or [SWS_CM_00152], the destructor is explicitly classified in the specification as not exception safe [SWS_CM_11370].

Regarding error handling and boundary conditions, it is defined that a DanglingSamplesViolation may occur if a precondition is violated [SWS_CM_11370]. If the service was previously offered externally by means of OfferService() [SWS_CM_00101] (ARAComAPI §6.5 “Service Discovery”), method StopOfferService() [SWS_CM_00111] will likely need to be called prior to the destructor call in order to cleanly terminate ongoing communication relationships. Question Q-c430a7f0fc838eba (open)

For the skeleton, the copy constructor is deleted [SWS_CM_00134], while move operations are supported [SWS_CM_00135]. Ongoing processing operations—such as handling pending calls via ProcessNextMethodCall() [SWS_CM_00199]—should be completed before destruction begins.

The method [SWS_CM_00111] stops offering a service instance by the service provider application in ara::com. The call is parameterless on the specific skeleton instance in namespace <SI-Namespace>::skeleton::<SI> and returns no value (EXP_ARAComAPI §5.4.1 “Skeleton Class API’s”).

The following conditions apply to usage and runtime behavior:

• Call context and precondition: The method is called when an instance previously provided by means of OfferService() is no longer to be available—for example as a result of state changes (EXP_ARAComAPI §5.4.4 “Offering Service instance”).
• Contract: As soon as StopOfferService() has returned, no further method calls are forwarded to this service instance according to the contract (EXP_ARAComAPI §5.4.4 “Offering Service instance”).
• Lifecycle and destructor: If a service instance is still actively offered when the destructor of the skeleton class is called, the destructor mandatorily executes StopOfferService() internally (EXP_ARAComAPI §5.4.4 “Offering Service instance”).
• Service Discovery: The call updates the local registry or the Service Discovery protocol of the middleware regarding the withdrawal of the service (EXP_ARAComAPI §7.2.1 “Central vs Distributed approach”).

The function is declared as noexcept and is considered exception-safe ([SWS_CM_00111]). It signals errors neither via exceptions nor via error messages or return codes.