class <SI-Namespace>::skeleton::fields::<Field>

use

The method RegisterGetHandler is called server-side on the field object of a skeleton ([SWS_CM_00114]). It exists in the generated code exclusively if a getter was configured for the respective field in the interface description (Field.hasGetter == TRUE) (EXP ARAComAPI §5.4.8.1 “Registering Getters”). A callback handler of type std::function<ara::core::Future<FieldType>()> is passed, which is called by the binding implementation upon an incoming Get() request from a proxy.

Registering such a handler is entirely optional (EXP ARAComAPI §5.4.8.1 “Registering Getters”). Typically, the service implementation does not require a getter handler because Communication Management caches the value most recently set via Update() and answers proxy requests autonomously. A handler is particularly useful when determining the field value is time-consuming or computationally intensive and should therefore only occur asynchronously via the promise/future pattern when actually required.

Error Handling and Boundary Conditions

The function has no return value, is declared as noexcept, and is exception-safe (exception safe) ([SWS_CM_00114]). If the passed callable does not exist or is null, the error InvalidHandlerViolation occurs ([SWS_CM_00114]).

Interaction

In contrast to RegisterSetHandler, whose invocation is mandatory when a setter is present (EXP ARAComAPI §5.4.8.2 “Registering Setters”), RegisterGetHandler remains purely optional. If the handler is to be processed asynchronously in a specific execution context, the overloaded template function with ExecutorT is additionally available ([SWS_CM_11360]).

use

The method RegisterGetHandler in namespace <SI-Namespace>::skeleton::fields::<Field> registers an application-side callback (handler) that is called by the communication binding upon an incoming Get() call from a proxy ([SWS_CM_11360], EXP ARAComAPI §5.4.8.1 “Registering Getters”). In contrast to the parameterless base overload [SWS_CM_00114], the method accepts an execution context executor of type ExecutorT in which callback execution takes place asynchronously ([SWS_CM_11360]). The standardized ara::core::Executor or a user-specific type with the same interface can be used as the executor ([SWS_CM_11360]).

The registered handler returns a ara::core::Future<FieldType>, decoupling the calculation of the field value via the promise/future pattern ([SWS_CM_11360], EXP ARAComAPI §5.4.8.1 “Registering Getters”). Registration is completely optional: If no handler is registered, Communication Management answers requests autonomously with the value last set via Update() (EXP ARAComAPI §5.4.8.1 “Registering Getters”). A getter handler is primarily suitable for on-demand calculation of complex or time-consuming field values (EXP ARAComAPI §5.4.8.1 “Registering Getters”).

Restrictions and Error Handling

The method exists in the skeleton only if a getter was configured for the field in the IDL (Field.hasGetter == TRUE, [SWS_CM_00114], EXP ARAComAPI §5.4.8.1 “Registering Getters”). RegisterGetHandler is declared as noexcept; however, if an invalid or empty callable is passed, a InvalidHandlerViolation is present ([SWS_CM_11360]). Interpretation: The passed executor is likely required to remain valid throughout the entire period of use of the handler, as incoming requests are dispatched asynchronously into its context. Question Q-c58eb22b06a8c27c (open)

use

Method RegisterSetHandler serves on the server side (skeleton) to register a callback function that is called upon arrival of a Set() request from a client for a field [SWS_CM_00116]. The method exists exclusively when the offered field is configured with setter support (Field.hasSetter == TRUE) [SWS_CM_00116]. In contrast to getter registration, calling RegisterSetHandler is mandatory, as the server implementation must validate new or updated field values from anonymous clients in advance EXP ARAComAPI §5.4.8.2 “Registering Setters”.

The registered handler receives the new value as an argument and returns a ara::core::Future<FieldType> containing the effective, possibly corrected value [SWS_CM_00116], EXP ARAComAPI §5.4.8.2 “Registering Setters”. This effective value is implicitly accepted by Communication Management and published to clients; an explicit call to Update() inside the handler is therefore redundant EXP ARAComAPI §5.4.8.2 “Registering Setters”.

Error Handling and Boundary Conditions

The function is defined as noexcept and is exception-safe [SWS_CM_00116]. If a non-existent or invalid (null) callable is passed, a specification violation in the form of a InvalidHandlerViolation occurs [SWS_CM_00116]. Interpretation: Registration likely needs to take place prior to offering the service via OfferService() in order to be able to accept incoming client requests from the start. Question Q-d45be0a899ddb6dd (open)

Interaction

In addition to the basic method, a template overload [SWS_CM_11362] exists, with which execution of the handler can be bound to a specific execution context (ExecutorT according to [SWS_CM_11360]) EXP ARAComAPI.

The template function RegisterSetHandler registers a callback function at the server or skeleton level of a field, which is called as soon as a client transmits a Set() request ([SWS_CM_11362], [SWS_CM_00116]). The interface exists only if the configured service field provides setter support (Field.hasSetter == TRUE) ([SWS_CM_00116]). In contrast to get registration, registering a set handler is mandatory because the server implementation must always validate new field values from anonymous clients (EXP ARAComAPI §5.4.8.2 “Registering Setters”).

Compared to the standard registration according to [SWS_CM_00116], this overload additionally takes an execution context executor of type ExecutorT&& ([SWS_CM_11362], [SWS_CM_11360]). Interpretation: The executor is likely to control in which thread or task scheduler context the callback is executed. Question Q-6dec4c0005c388dd (open) The passed handler has the signature std::function<ara::core::Future<FieldType>(<SFieldDerivedType> value)>; it receives the value set by the client and asynchronously returns the effective – possibly validated or corrected – value via ara::core::Future ([SWS_CM_11362], EXP ARAComAPI §5.4.8.2 “Registering Setters”).

Communication Management implicitly adopts the effective value returned by the handler as if the server application itself had called Update(); a manual call to Update() within the handler is therefore superfluous (EXP ARAComAPI §5.4.8.2 “Registering Setters”, EXP ARAComAPI §4.6 “Data Type Abstractions”).

Error handling and concurrency:

• Exception safety: The function is declared as noexcept and specified as exception safe ([SWS_CM_11362]).
• Violations: If the passed callable setHandler does not exist or is nullptr, the violation InvalidHandlerViolation is present ([SWS_CM_11362]).
• Context: The method ensures that execution of the handler takes place in the provided context of the executor ([SWS_CM_11362]).

The function SetTransportFaultConditionHandler is used to register an error handler of type ara::com::e2e::TransportFaultConditionHandler for Get and Set requests of a field at skeleton level in namespace <SI-Namespace>::skeleton::fields::<Field> [SWS_CM_00096]. The call is executed synchronously, has no return value (void), and guarantees exception safety through specification as noexcept [SWS_CM_00096]. For scenarios where handler execution is to be delegated to an explicit execution context, the template overload with an executor object ExecutorT&& executor is available [SWS_CM_00097].

The violation InvalidHandlerViolation is defined as an error condition; it occurs if the passed callable handler does not exist or is null [SWS_CM_00096]. While client-side errors for method and field requests are reported via ComErrc::kCommunicationFailure in the respective ara::core::Future instances [SWS_CM_00090], this function enables the server instance to receive transport errors on incoming Get and Set calls [SWS_CM_00096].

The concept corresponds to respective registration mechanisms for all methods of a skeleton service instance [SWS_CM_00093] as well as proxy-side handlers for events [SWS_CM_00099], triggers [SWS_CM_00106], and field notifiers [SWS_CM_00109]. Interpretation: The registration of the handler should reasonably take place during the initialization phase prior to offering the skeleton in order to be able to seamlessly capture errors during initial field accesses. Question Q-627229896b666532 (open)

The function SetTransportFaultConditionHandler in namespace <SI-Namespace>::skeleton::fields::<Field> registers an error handler for transport disruptions during Get and Set requests of a field at skeleton level [SWS_CM_00097]. It is included via header <SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h [SWS_CM_00097].

Usage and Parameters

The call is synchronous and has no return value (void) [SWS_CM_00097]. Passed as parameters are the callable error callback handler of type ara::com::e2e::TransportFaultConditionHandler and a forwarding reference executor of generic type ExecutorT&& [SWS_CM_00097]. The parameter executor designates the execution object in whose context any asynchronous computations are executed [SWS_CM_00097].

Error Handling and Concurrency

The method is declared as noexcept and guarantees complete exception safety (exception safe) [SWS_CM_00097]. If the passed handler callable does not exist or is null, an InvalidHandlerViolation is thrown [SWS_CM_00097]. Interpretation: The passed executor object is presumably used to determine in which thread or task context the asynchronous notification in case of transport errors is processed. Question Q-4101faaa8d6a3130 (open)

Interaction

The method extends the standard registration [SWS_CM_00096] by a dedicated execution context for skeleton fields [SWS_CM_00097]. Corresponding overloads with an executor also exist for skeleton methods ([SWS_CM_00094]) as well as on the client or proxy side for events ([SWS_CM_00100]) and field notifiers ([SWS_CM_00110]).

The function UnsetTransportFaultConditionHandler is used on the skeleton side of a service interface to cancel a previously registered ara::com::e2e::TransportFaultConditionHandler for get and set requests of a field ([SWS_CM_00098]). It is defined in namespace <SI-Namespace>::skeleton::fields::<Field> and included via header <SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h (AUTOSAR_AP_SWS_CommunicationManagement §8.4.3.2.1.3 “UnsetTransportFaultConditionHandler”). The call is synchronous, accepts no passing parameters, and provides no return value (void).

Canceling deactivates the application-specific callback for transport error conditions in field requests (AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 “End-to-end communication protection for SOMEIP”). The interface is declared as noexcept and guarantees exception safety (exception safe) ([SWS_CM_00098]). Error codes or specific error messages via DET or DEM are not specified; the operation is designed to complete without error.

Regarding concurrency and reentrancy, the specification contains no separate requirements. Consequently, deregistration is likely best performed during deinitialization phases or outside concurrent get/set processing to avoid inconsistencies during ongoing communication operations. Question Q-06bc8d90f1891904 (open)

The operation is part of the end-to-end communication protection for service instances (AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 “End-to-end communication protection for SOMEIP”). It constitutes the field-specific counterpart to [SWS_CM_00095], which deregisters the handler for all methods of a skeleton. On the proxy side, it corresponds to respective deregistrations for events ([SWS_CM_00105]), triggers ([SWS_CM_00108]), and field notifiers ([SWS_CM_00126]).

The method Update() is called server-side in scope <SI-Namespace>::skeleton::fields::<Field> to update the internal value of a field and initiate the transmission of the new data to subscribed clients ([SWS_CM_00119], AUTOSAR_AP_EXP_ARAComAPI §4.6 “Data Type Abstractions”). A notification is sent to subscribers if hasNotifier == TRUE is configured for the field ([SWS_CM_00119], [SWS_CM_00120], [SWS_CM_00162]). The parameter value is passed by reference; during the call, the binding implementation creates a typically serialized copy, allowing the application data to be modified or freed on the caller side after return (AUTOSAR_EXP_ARAComAPI “UpdateRate Class”).

The function is defined as noexcept and exception safe and synchronously returns a ara::core::Result<void> ([SWS_CM_00119]). If an error occurs, the result contains an error code from ara::com::ComErrc ([SWS_CM_00119], [SWS_CM_10432]). Specifically, ComErrc::kMinimumSendIntervalViolationError is returned with rollback semantics if send requests occur faster than specified by the configured minimum send interval ServiceInterfaceDeploymentElement.minimumSendInterval ([SWS_CM_00119]).

In the service lifecycle, an initial call to Update() is required prior to offering the service: If OfferService() is called before the field value has been initialized, offering fails with ComErrc::kFieldValueNotInitialized ([SWS_CM_00101], [SWS_CM_00128]). Due to the lack of an explicit reentrancy guarantee in the standard, concurrent calls on the same field instance are expected to be synchronized on the application side. Question Q-67b174ef05867989 (open)