namespace <SI-Namespace>::skeleton::fields
User GuideKI-GENERIERT
Definiert serverseitige Feld-Klassen für Service-Skelette zur Bereitstellung und Aktualisierung von Schnittstellenfeldern.
Definiert serverseitige Feld-Klassen für Service-Skelette zur Bereitstellung und Aktualisierung von Schnittstellenfeldern.
Der Namensraum kapselt die serverseitigen Feld-Klassen für jedes in einem ServiceInterface deklarierte Feld innerhalb der Skeleton-Architektur des Moduls com. Dienstanbieter nutzen diese generierten Klassen, um den aktuellen Feldwert zu verwalten und bei Wertänderungen an verbundene Clients zu übermitteln. Die Instanziierung und Lebensdauer der Feld-Objekte dürfte dabei direkt an die übergeordnete Skeleton-Instanz gebunden sein. Frage Q-bd1d4d2cab97eada (offen) Bei der Aktualisierung und Bereitstellung der Daten ist auf die Synchronisation gemäß dem Threading-Modell des Service-Skeletts zu achten.
Kontext
Der Namensraum <SI-Namespace>::skeleton::fields ist Bestandteil der Kommunikationsarchitektur (Modul com) der AUTOSAR Adaptive Platform im Release R25-11. Er beinhaltet die serverseitig generierten Klassen für alle Felder, die in einem ServiceInterface in der Rolle field modelliert wurden. Für jedes im Interface definierte Feld existiert hierbei eine korrespondierende Service-Skeleton-Feld-Klasse, die dem generischen Namensschema <Field> folgt. Diese Klassen bilden das Bindeglied zwischen der anwendungsspezifischen Implementierung eines Dienstes und der zugrundeliegenden Kommunikationsschicht, um feldbezogene Datenstrukturen strukturiert anzubieten.
In serviceorientierten Architekturen repräsentieren Felder Eigenschaften eines Dienstes, die sich typischerweise aus einer Kombination von Lesezugriffen (Gettern), Schreibzugriffen (Settern) und ereignisbasierten Benachrichtigungen (Notifiern) zusammensetzen können. Während auf Client-Seite im Proxy-Namensraum entsprechende Schnittstellen für den konsumierenden Zugriff generiert werden, stellt skeleton::fields die Klassen bereit, mit denen der Dienstanbieter (Server) den internen Status verwaltet und nach außen exponiert. Die Klassen im Namensraum <SI-Namespace>::skeleton::fields kapseln dabei die Kommunikation und protokollspezifische Übertragung, sodass sich der Anwendungsentwickler auf die funktionale Logik des Dienstes konzentrieren kann.
Lebenszyklus
Hinsichtlich der Erzeugung und der Besitzverhältnisse dürfte die Lebensdauer einer Feld-Klasse im Namensraum skeleton::fields unmittelbar an die übergeordnete Skeleton-Klasse des Service-Interfaces gebunden sein. Frage Q-375f07429819a937 (offen) In C++-basierten Implementierungen der Adaptive Platform werden die Feld-Instanzen typischerweise als direkte Member-Objekte innerhalb des generierten Skeletons instanziiert. Folglich beginnt der Lebenszyklus der Feld-Objekte mit dem Konstruktoraufruf des Service-Skeletts und endet automatisch mit dessen Destruktion.
Während der Betriebsphase verweilt das Feld-Objekt im Speicher des Dienstanbieters. Vor oder während des Angebots des Dienstes im Netzwerk (etwa vor der Dienst-Registrierung oder unmittelbar danach) wird die Feld-Instanz mit einem validen Startwert initialisiert. Da das Skeleton über seine gesamte Lebensdauer hinweg für Abfragen und Aktualisierungen zur Verfügung steht, bleibt auch die Feld-Instanz persistent verfügbar.
Bezüglich der Nebenläufigkeit und des Threadings dürfte die Handhabung von Feld-Zugriffen stark vom gewählten Verarbeitungsmodell des Skeletons abhängen. Frage Q-d3456f67c7a4ba8d (offen) Sofern die Feld-Klasse Callback-Mechanismen für eingehende Schreib- oder Leseanfragen bereitstellt oder Methoden zur Aktualisierung des Feldwerts anbietet, müssen konkurrierende Zugriffe durch die anwendende Dienst-Implementierung synchronisiert werden, um Race Conditions bei nebenläufiger Abarbeitung zu verhindern.
Nutzungspfad
Der typische Nutzungspfad für die Klassen aus <SI-Namespace>::skeleton::fields beginnt im Rahmen der Initialisierung des Dienstanbieters. Beim Aufbau der Skeleton-Instanz wird für jedes konfigurierte Feld das jeweilige Feld-Objekt erzeugt. Die Implementierung des Dienstes weist der Feld-Klasse typischerweise initial einen gültigen Startwert zu, damit anfragende Clients von Beginn an konsistente Daten vorfinden.
Im laufenden Betrieb erfolgt die Interaktion primär über Wertaktualisierungen. Sobald sich interne Zustände, Sensorwerte oder Berechnungsdaten in der Dienstanwendung ändern, ruft das Skeleton die entsprechende Aktualisierungsmethode der Feld-Instanz auf. Die Feld-Klasse übernimmt daraufhin die Verteilung der neuen Daten an das Kommunikations-Framework, welches die Werte als Notifier-Nachrichten an alle interessierten und abonnierten Service-Proxys im Netzwerk versendet.
Sofern das Feld für schreibende Zugriffe durch Clients konfiguriert ist, verarbeitet die Feld-Klasse eingehende Aktualisierungsanfragen (Set-Operationen). Die Service-Implementierung nimmt die geänderten Werte entgegen, validiert diese und aktualisiert den internen Zustand. Durch diesen zweckgerichteten Ablauf von Initialisierung, periodischer oder ereignisbasierter Werteübermittlung und kontrollierter Beendigung mit dem Skeleton-Lebensende fügen sich die Feld-Klassen nahtlos in das Interaktionsmuster der AUTOSAR-Adaptive-Dienstebene ein.
Dieser Leitfaden basiert auf dem AUTOSAR-Release R25-11 für die Adaptive Platform (Modul com). Da der Dokumentations-Payload keine Spezifikations-Records oder Dokumentstellen für diesen Namensraum enthält, beschränkt sich die Darstellung auf eine neutrale architektonische Einordnung und explizit gekennzeichnete Interpretationen.
Für dieses Release liegen keine Elementdaten vor
Klassen
Service skeleton Field class, one for each Field defined in the ServiceInterface in the role field.
Klassendiagramm
Abgerundete Rahmen = Namespace- bzw. Klassen-Scopes; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = namespace-fremde bzw. externe Basisklassen. Klicken öffnet die jeweilige Klassen- bzw. cppreference-Seite.
gemini-3.8-flash-medium· 2026-10-13