struct <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output
struct <Method>Output {...};
Structure wrapping the out arguments for a method
| Header-Datei | #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h" |
|---|---|
| Forwarding-Header | #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton/<SiShortname>_skeleton_fwd.h" |
| Scope | class <SI-Namespace>::skeleton::<SI>Skeleton |
User GuideKI-GENERIERT
Bündelt als generierte Datenstruktur sämtliche Ausgabeargumente einer Servicemethode für die Rückgabe im Skeleton.
Bündelt als generierte Datenstruktur sämtliche Ausgabeargumente einer Servicemethode für die Rückgabe im Skeleton.
Die Struktur bündelt sämtliche Ausgabeargumente einer Service-Interface-Methode auf Serverseite für die Übertragung an den Aufrufer. Bei der Ausführung einer Skeleton-Methode instanziiert die Service-Implementierung diese Datenstruktur, befüllt deren Attribute mit den berechneten Resultaten und übergibt sie an die Kommunikationsschicht zurück. Die Middleware serialisiert anschließend die enthaltenen Parameter und überträgt das Antwortpaket an den aufrufenden Proxy. Da keine expliziten Spezifikationsanforderungen im Payload hinterlegt sind, dürften die Elementtypen direkt den im Service-Interface modellierten Datentypen der Ausgabeparameter entsprechen. Frage Q-55d242e98cd76967 (offen)
Kontext
Die C++-Struktur <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output ist ein generierter Bestandteil des Serviceteils im Modul com der AUTOSAR Adaptive Platform (Release R25-11). Innerhalb der Service-Schnittstelle bündelt dieser Typ sämtliche Ausgabeargumente (Out-Parameter) einer definierten Servicemethode auf Anbieterseite. Die Struktur fungiert als Vermittlungsschicht zwischen der konkreten Service-Implementierung des Dienstanbieters und der Kommunikations-Middleware ara::com. Da C++-Funktionssignaturen üblicherweise nur einen einzelnen Rückgabewert unterstützen, stellt dieser Typ ein strukturiertes Aggregat bereit, um Methoden mit mehreren Ausgabeparametern typsicher an die aufrufende Laufzeitumgebung zurückzugeben.
Lebenszyklus
Die Erzeugung einer Instanz von <Method>Output erfolgt im Anwendungskontext des Dienstanbieters, sobald eine Service-Methode die geforderten Berechnungen abgeschlossen hat. Die Service-Implementierung instanziiert das Datenaggregat lokal, initialisiert die darin deklarierten Member-Variablen mit den ermittelten Werten und übergibt die Instanz anschließend an die Kommunikationsschicht. Mit der Übergabe an das Framework enden die unmittelbaren Besitzrechte der anwendungsspezifischen Methodenimplementierung; das Objekt wird in den Verantwortungsbereich der Middleware überführt. Die Lebensdauer der Instanz ist transient und endet, sobald die Kommunikationsschicht die enthaltenen Parameter in die nachgelagerten Protokoll-Payloads serialisiert und den Puffer freigegeben hat. Hinsichtlich der Nebenläufigkeit ist jeder Methodenaufruf isoliert: Jeder Aufrufkontext operiert auf einer eigenen Instanz, sodass keine Synchronisationsmechanismen auf Klassenebene erforderlich sind, solange die transportierten Werte keine ungeschützten gemeinsamen Ressourcen teilen.
Nutzungspfad
Der typische Ablauf bei der Verwendung von <Method>Output vollzieht sich in einer festen Interaktionsfolge zwischen der Laufzeitumgebung, der Skeleton-Methodenimplementierung und der Ausgabestruktur. Nach dem Eintreffen einer Methodenabfrage leitet die Middleware den Aufruf an die implementierte Skeleton-Klasse weiter. Die Anwendungslogik führt die Verarbeitung durch, erzeugt die Struktur <Method>Output und füllt alle Ausgabeparameter ab. Anschließend wird die Instanz an das Laufzeitsystem übermittelt, welches die Serialisierung vornimmt und die Antwortnachricht über das Netzwerk an den anfordernden Proxy versendet.
Sequenzdiagramm: Aufruf- und Rückgabepfad bei Verwendung der Output-Struktur im Skeleton. Quellen: Keine Belege im Payload spezifiziert.
Fehlerszenarien
Als reines Datenaggregat verfügt <Method>Output über keine eigenen Fehlerbehandlungsroutinen oder Statusmethoden. Fehlerhafte Zustände entstehen primär an den Schnittstellen durch unvollständige Initialisierung oder Vorbedingungsverletzungen. Versäumt es die anwendungsseitige Implementierung, einzelne Member-Variablen vor der Rückgabe korrekt zu belegen, können uninitialisierte Werte oder Null-Zustände serialisiert werden. Scheitert die fachliche Berechnung der Servicemethode bereits im Vorfeld, wird im regulären Kontrollfluss keine gültige <Method>Output-Instanz übertragen; stattdessen meldet die Implementierung den aufgetretenen Fehler über die dafür vorgesehenen Fehlerkanäle der Service-Schnittstelle. Treten bei dynamischen Datenstrukturen innerhalb der Ausgabeargumente Speicherallokationsfehler auf, müssen diese innerhalb der aufgerufenen Methode abgefangen werden, bevor eine Übergabe an die Middleware erfolgt.
Dieser Leitfaden basiert auf den strukturellen Angaben des Payloads der Adaptive Platform (Release R25-11, Modul com). Da im Payload keine spezifischen SWS-Anforderungsbelege hinterlegt sind, wurden funktionale Abläufe anhand der deklarierten Schnittstellensyntax neutral beschrieben.
gemini-3.8-flash-medium· 2026-10-13