namespace <SI-Namespace>::skeleton::fields

The namespace encapsulates the server-side field classes for each field declared in a ServiceInterface within the skeleton architecture of module com. Service providers use these generated classes to manage the current field value and transmit it to connected clients upon value changes. The instantiation and lifetime of the field objects are likely tied directly to the parent skeleton instance. Question Q-bd1d4d2cab97eada (open) When updating and providing the data, synchronization according to the threading model of the service skeleton must be observed.

more ›

Context

The namespace <SI-Namespace>::skeleton::fields is part of the communication architecture (module com) of the AUTOSAR Adaptive Platform in Release R25-11. It contains the server-side generated classes for all fields modeled in a ServiceInterface in the role field. For each field defined in the interface, there is a corresponding service skeleton field class following the generic naming scheme <Field>. These classes form the link between the application-specific implementation of a service and the underlying communication layer in order to offer field-related data structures in a structured manner.

In service-oriented architectures, fields represent properties of a service that can typically consist of a combination of read accesses (getters), write accesses (setters), and event-based notifications (notifiers). While corresponding interfaces for consuming access are generated on the client side in the proxy namespace, skeleton::fields provides the classes with which the service provider (server) manages the internal state and exposes it to the outside. The classes in namespace <SI-Namespace>::skeleton::fields encapsulate communication and protocol-specific transmission, allowing the application developer to focus on the functional logic of the service.

Lifecycle

Regarding creation and ownership, the lifetime of a field class in namespace skeleton::fields is likely directly bound to the parent skeleton class of the service interface. Question Q-375f07429819a937 (open) In C++-based implementations of the Adaptive Platform, field instances are typically instantiated as direct member objects within the generated skeleton. Consequently, the lifecycle of field objects begins with the constructor call of the service skeleton and ends automatically with its destruction.

During the operational phase, the field object resides in the memory of the service provider. Before or during the offering of the service on the network (e.g., prior to service registration or immediately thereafter), the field instance is initialized with a valid initial value. Because the skeleton remains available for queries and updates throughout its entire lifetime, the field instance also remains persistently available.

Regarding concurrency and threading, the handling of field accesses is likely to depend heavily on the chosen processing model of the skeleton. Question Q-d3456f67c7a4ba8d (open) If the field class provides callback mechanisms for incoming write or read requests or offers methods for updating the field value, concurrent accesses must be synchronized by the consuming service implementation to prevent race conditions during concurrent execution.

Usage Path

The typical usage path for the classes from <SI-Namespace>::skeleton::fields begins during the initialization of the service provider. When setting up the skeleton instance, the respective field object is created for each configured field. The implementation of the service typically assigns an initial valid starting value to the field class so that requesting clients encounter consistent data from the start.

During ongoing operation, interaction occurs primarily via value updates. As soon as internal states, sensor values, or calculation data change in the service application, the skeleton calls the corresponding update method of the field instance. The field class then takes over distribution of the new data to the communication framework, which sends the values as notifier messages to all interested and subscribed service proxies in the network.

If the field is configured for write accesses by clients, the field class processes incoming update requests (set operations). The service implementation receives the changed values, validates them, and updates the internal state. Through this purposeful sequence of initialization, periodic or event-based value transmission, and controlled termination at the end of the skeleton lifetime, the field classes integrate seamlessly into the interaction patterns of the AUTOSAR Adaptive service layer.