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

Die Methode OfferService() wird auf einer Instanz der Skeleton-Klasse aufgerufen, um einen bereitgestellten Dienst im System anzubieten und für Konsumenten über die Service Discovery auffindbar zu machen [SWS_CM_00101], ARAComAPI §6.5 „Service Discovery“. Der Aufruf erfolgt parameterlos und synchron, sobald die Service-Implementierung vollständig instanziiert und in einen betriebsbereiten Zustand versetzt wurde AUTOSAR_AP_EXP_ARAComAPI §5.4.4 „Offering Service instance“. Die Funktion ist als noexcept deklariert und gibt ein ara::core::Result<void> zurück [SWS_CM_00101].

Das Anbieten ist zwingende Voraussetzung für die funktionale Kommunikation über Methoden, Events, Felder oder Trigger AUTOSAR_AP_EXP_ARAComAPI §4.2 „Means of Communication“. Wird beispielsweise versucht, einen Trigger ohne vorheriges Anbieten zu senden, schlägt dies mit ComErrc::kServiceNotOffered fehl [SWS_CM_00721]. Bezüglich der Nebenläufigkeit gilt: Sobald OfferService() aufgerufen wird, können eingehende Methodenaufrufe bereits an die Service-Instanz zugestellt werden – selbst wenn der Aufruf von OfferService() noch nicht zurückgekehrt ist AUTOSAR_AP_EXP_ARAComAPI §5.4.4 „Offering Service instance“.

Schlägt das Anbieten fehl, enthält das zurückgegebene ara::core::Result einen entsprechenden Fehlercode aus ComErrc [SWS_CM_00101], [SWS_CM_10432]:

• ComErrc::kFieldValueNotInitialized: Mindestens ein konfigurierter Feldwert wurde vor dem Anbieten noch nicht initialisiert [SWS_CM_00101].
• ComErrc::kFieldSetHandlerNotSet: Für ein Feld mit Setter-Unterstützung wurde noch kein Handler über RegisterSetHandler() registriert [SWS_CM_00101].
• ComErrc::kCommunicationFailure: Die Netzwerkbindung meldet einen behebbaren Kommunikationsfehler oder das Fehlschlagen sicherer Kommunikation [SWS_CM_00101].

Soll die Bereitstellung des Dienstes beendet werden, muss StopOfferService() aufgerufen werden AUTOSAR_AP_EXP_ARAComAPI §5.4.4 „Offering Service instance“.

Die Methode ProcessNextMethodCall() dient Service-Providern im Skeleton dazu, eingehende Methodenaufrufe im Polling-Modus deterministisch abzuarbeiten [SWS_CM_00199]. Sie darf ausschließlich verwendet werden, wenn die Skeleton-Instanz mit dem Modus ara::com::MethodCallProcessingMode::kPoll konfiguriert wurde EXP ARAComAPI §2 „Polling“.

Verwendung und Semantik

Die Funktion nimmt keine Parameter entgegen und führt eine anstehende Methodenaufruf-Anfrage synchron im Thread-Kontext des Aufrufers aus [SWS_CM_00199], [SWS_CM_00191]. Dies ermöglicht es insbesondere Echtzeitanwendungen, Serviceanfragen ohne unkontrollierte Thread-Kontextwechsel innerhalb ihres zugewiesenen Zeitbudgets zu verarbeiten EXP ARAComAPI §5.4 „ProcessNextMethodCall“. Der Rückgabewert signalisiert das Ergebnis des Abrufs:

• true: Mindestens eine ausstehende Anfrage befand sich in der Warteschlange und wurde abgearbeitet [SWS_CM_00199].
• false: Es lag keine ausstehende Anfrage vor; die Warteschlange war leer [SWS_CM_00199]. Ein direkter Folgeaufruf nach einem false bleibt in der Regel wirkungslos EXP ARAComAPI §5.4 „ProcessNextMethodCall“.

Fehlerbehandlung und Randbedingungen

Die Funktion ist als noexcept und exception safe spezifiziert [SWS_CM_00199]. Ein Aufruf an einem Skeleton, das mit kEvent oder kEventSingleThread instanziiert wurde, stellt eine Verletzung (WrongMethodCallProcessingModeViolation) dar [SWS_CM_00199]. Interpretation: Da reguläre C++-Exceptions durch noexcept ausgeschlossen sind, dürfte eine solche Verletzung platformseitig als schwerwiegender Laufzeitfehler behandelt werden. Frage Q-61661dbd6cc37bc7 (offen)

Verwendung

Die Funktion SetTransportFaultConditionHandler dient der Registrierung eines Callbacks vom Typ ara::com::e2e::TransportFaultConditionHandler im Namensraum der Skeleton-Klasse (<SI-Namespace>::skeleton::<SI>) [SWS_CM_00093]. Über diesen Handler werden Transportfehler für alle Methoden der jeweiligen Service-Instanz gemeldet AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 „End-to-end communication protection for SOMEIP“. Die Funktion übernimmt das aufrufbare Objekt handler und besitzt keinen Rückgabewert (void) [SWS_CM_00093].

Fehlerbehandlung

Die Operation ist mit noexcept deklariert und ausnahmesicher (exception safe) [SWS_CM_00093]. Falls die übergebene aufrufbare Einheit nicht existiert oder null ist, wird eine InvalidHandlerViolation ausgelöst [SWS_CM_00093]. Im Fehlerfall meldet der konfigurierte Handler aufgetretene Transportstörungen wie etwa TransportFaultCondition::kSampleRejected, wenn Anfragen durch Ressourcenmangel oder Korruption in der Transportschicht verworfen werden AUTOSAR_AP_SWS_CommunicationManagement §7.4.2.3 „Methods“.

Nebenläufigkeit und Einschränkungen

Interpretation: Da diese Basisschnittstelle keinen Ausführungskontext entgegennimmt, dürfte der Callback synchron aus dem internen Thread des Kommunikationsmanagements aufgerufen werden. Frage Q-e4007fa72de6aa12 (offen) Sofern die Ausführung des Handlers in einem definierten Thread-Pool oder Worker erfolgen soll, ist die Überladung mit ExecutorT&& executor zu nutzen [SWS_CM_00094].

Zusammenspiel

Die Registrierung bindet die Fehlerbehandlung zentral an alle Methoden einer Skeleton-Instanz [SWS_CM_00093]. Sie fügt sich in die übergeordnete Fehlerbehandlung von ara::com ein:

• Während Skeleton-Methoden Transportfehler über diesen Handler melden, signalisieren Client-Methoden Transportausfälle asynchron über ihren resultierenden ara::core::Future mit ComErrc::kCommunicationFailure [SWS_CM_00090].
• Für Feld-Operationen (Get/Set) auf Skeleton-Ebene existieren separate Schnittstellen [SWS_CM_00096].
• Auf Proxy-Ebene stehen analoge Registrierungsfunktionen für Events [SWS_CM_00099], Trigger [SWS_CM_00106] sowie Notifier [SWS_CM_00109] bereit.

Die Template-Funktion SetTransportFaultConditionHandler im Namensraum der Skeleton-Klasse dient der Registrierung eines Fehler-Handlers für Transportfehler aller Methoden einer Service-Instanz [SWS_CM_00094]. Sie erweitert die parameterlose Basisfunktion [SWS_CM_00093] um einen Ausführungskontext:

• Aufruf und Parameter: Übergeben werden ein Callable handler vom Typ ara::com::e2e::TransportFaultConditionHandler sowie eine universelle Referenz executor [SWS_CM_00094]. In diesem Executor-Objekt müssen jegliche asynchronen Berechnungen und Callback-Ausführungen gestartet werden. Die Funktion besitzt keinen Rückgabewert.
• Fehlerbehandlung: Die Schnittstelle ist als noexcept deklariert und als exceptionsicher spezifiziert [SWS_CM_00094]. Existiert das übergebene Callable nicht oder ist es null, liegt eine InvalidHandlerViolation vor [SWS_CM_00094].
• Zusammenspiel: Der Gültigkeitsbereich umfasst alle Methoden des Skeletons [SWS_CM_00094], während für Field-Get- und Set-Operationen separate Registrierfunktionen bereitstehen ([SWS_CM_00096], [SWS_CM_00097]). Im DDS-Netzwerk-Binding meldet der konfigurierte Handler Transportfehler wie TransportFaultCondition::kSampleRejected [SWS_CM_00216]; clientseitig werden solche Fehler hingegen über ComErrc::kCommunicationFailure in den Ergebnis-Futures signalisiert [SWS_CM_00090].
• Nebenläufigkeit: Interpretation: Die Übergabe des Executors entkoppelt die Fehlerbehandlung vom internen Kontext der Kommunikationsschicht; vermutlich sollte die Registrierung frühzeitig bei der Initialisierung des Skeletons vor dem Eintreffen erster Methodenaufrufe erfolgen. Frage Q-e56b2a1928cf32ad (offen)

Der Konstruktor [SWS_CM_00130] instanziiert ein Service-Skeleton anhand eines konkreten ara::com::InstanceIdentifier. Das Skeleton bindet die anwendungsseitige Service-Implementierung an die Transportschicht des Communication Managements an, damit verteilte Service-Consumer darauf zugreifen können (ARAComAPI §5.1 „Proxy Skeleton Pattern“).

Über den Parameter mode wird festgelegt, wie eingehende Methodenaufrufe abgearbeitet werden. Als Standardwert ist der ereignisbasierte Modus ara::com::MethodCallProcessingMode::kEvent vorgegeben [SWS_CM_00130]. Wird stattdessen ein polling-basierter Modus gewählt, erfolgt die Ausführung anstehender Methodenaufrufe synchron im Aufrufkontext von ProcessNextMethodCall() [SWS_CM_00199].

Fehlerbehandlung und Randbedingungen

Die Konstruktorfunktion ist mit noexcept deklariert und wirft keine C++-Exceptions [SWS_CM_00130]. Mögliche Verletzungen werden über das Laufzeitsystem signalisiert: Wird die Erzeugung durch das Grant-Enforcement verweigert, liegt eine InsufficientPermissionsViolation vor; bei Übergabe eines ungültigen Verarbeitungsmodus resultiert eine WrongMethodCallProcessingModeViolation [SWS_CM_00130]. Interpretation: Die Validierung des Verarbeitungsmodus dürfte unmittelbar während der Konstruktor-Ausführung stattfinden. Frage Q-80e02c0079757082 (offen)

Kopieroperationen sind für das Skeleton explizit gelöscht [SWS_CM_00134], während Move-Konstruktion unterstützt wird [SWS_CM_00135]. Damit der Service im Netzwerk auffindbar wird, muss nach der Instanziierung OfferService() aufgerufen werden [SWS_CM_00101] (ARAComAPI §6.5 „Service Discovery“). Vor der Zerstörung der Instanz [SWS_CM_11370] kann die Bereitstellung mittels StopOfferService() [SWS_CM_00111] wieder beendet werden.

Der Konstruktor instanziiert ein Service-Skeleton anhand eines Instanzbezeichners [SWS_CM_00152]. Er dient dazu, eine konkrete Service-Implementierung an die Transportschicht des Communication Management anzubinden. Als Parameter werden ein ara::core::InstanceSpecifier sowie optional der Verarbeitungsmodus ara::com::MethodCallProcessingMode übergeben, welcher standardmäßig auf kEvent voreingestellt ist [SWS_CM_00152].

Hinsichtlich Fehlerbehandlung und Ausnahmeverhalten ist der Konstruktor als noexcept und exception safe deklariert [SWS_CM_00152]. Bei fehlerhaften Konfigurationen oder Modellierungsabweichungen sind folgende Violations spezifiziert:

• InstanceSpecifierMappingIntegrityViolation, falls der Bezeichner im Ausführungskontext nicht aufgelöst werden kann oder nicht auf einen PortPrototype verweist [SWS_CM_00152].
• PortInterfaceMappingViolation und ProcessMappingViolation, wenn Mapping-Typ und Schnittstellentyp nicht übereinstimmen [SWS_CM_00152].
• InstanceSpecifierAlreadyInUseViolation, wenn der InstanceSpecifier bereits verwendet wird [SWS_CM_00152].
• WrongMethodCallProcessingModeViolation sowie InsufficientPermissionsViolation bei unzureichenden Rechten [SWS_CM_00152].

Interpretation: Da der Konstruktor als noexcept deklariert ist, dürften die spezifizierten Violations nicht als geworfene C++-Exceptions zur Laufzeit propagiert, sondern durch plattformseitige Prüfungen oder Grant Enforcement abgefangen werden. Frage Q-f1a1a0baeb56e482 (offen)

Für Lebenszyklus und Nebenläufigkeit gilt, dass der Kopierkonstruktor gelöscht ist [SWS_CM_00134], während ein Verschiebekonstruktor zur Verfügung steht [SWS_CM_00135]. Die Freigabe erfolgt über den virtuellen Destruktor [SWS_CM_11370]. Nach erfolgreicher Konstruktion wird der Service typischerweise über [SWS_CM_00101] (OfferService) im Netzwerk angeboten. Wurde als Verarbeitungsmodus kPoll gewählt, muss die Anwendung eingehende Aufrufe der Servicemethoden [SWS_CM_00191] explizit über [SWS_CM_00199] (ProcessNextMethodCall) verarbeiten.

Verwendung

Der Konstruktor instanziiert ein Service-Skelett anhand eines Containers von Instanzbezeichnern (instanceIDs) und verbindet die Service-Implementierung serverseitig mit der Transportschicht des Communication Managements [SWS_CM_00153], ARAComAPI §5.1 „Proxy Skeleton Pattern“. Über den Parameter mode wird festgelegt, wie eingehende Methodenaufrufe verarbeitet werden; standardmäßig erfolgt die Abwicklung ereignisgesteuert über kEvent [SWS_CM_00153]. Alternativ stehen Konstruktoren für einzelne Instanzbezeichner [SWS_CM_00130] oder Instanzspezifizierer [SWS_CM_00152] zur Verfügung.

Fehlerbehandlung und Nebenläufigkeit

Die Funktion ist als noexcept deklariert und ausnahmesicher (exception safe) spezifiziert [SWS_CM_00153]. Mögliche Verletzungen bei der Erzeugung sind WrongMethodCallProcessingModeViolation bei Übergabe eines unzulässigen Verarbeitungsmodus sowie InsufficientPermissionsViolation, falls die Berechtigungsprüfung (Grant Enforcement) fehlschlägt [SWS_CM_00153].

Wird für mode das Polling-Modell (kPoll) konfiguriert, muss die Serveranwendung anstehende Methodenaufrufe durch den Aufruf von ProcessNextMethodCall() synchron im eigenen Thread-Kontext abarbeiten [SWS_CM_00199]. Der Kopierkonstruktor der Skelett-Klasse ist gelöscht (delete) [SWS_CM_00134]; Verschiebungen werden hingegen über den Move-Konstruktor unterstützt [SWS_CM_00135].

Zusammenspiel

Nach erfolgreicher Instanziierung wird der Dienst über OfferService() für entfernte oder lokale Konsumenten bereitgestellt [SWS_CM_00101], ARAComAPI §6.5 „Service Discovery“. Vor dem Zerstören des Skeletts mittels Destruktor [SWS_CM_11370] sollte die Bereitstellung über StopOfferService() beendet werden [SWS_CM_00111]. Eingehende Methodenaufrufe liefern serverseitig jeweils ein ara::core::Future zurück [SWS_CM_00191].

Der virtuelle Destruktor ~<SI>Skeleton() [SWS_CM_11370] beendet den Lebenszyklus einer Service-Skeleton-Instanz. Das Service-Skeleton verbindet als generiertes Artefakt die konkrete Dienstimplementierung mit der Transportschicht des Communication Managements, sodass Service-Konsumenten die angebotenen Methoden und Funktionalitäten erreichen können (ARAComAPI §5.1 „Proxy Skeleton Pattern“).

Die Zerstörung erfolgt synchron beim Abbau der abgeleiteten Implementierungsklasse. Die Methode nimmt keine Parameter entgegen und deklariert keinen Rückgabewert. Im Gegensatz zu den Konstruktoren des Skeletons wie [SWS_CM_00130] oder [SWS_CM_00152] ist der Destruktor in der Spezifikation explizit als not exception safe eingestuft [SWS_CM_11370].

Hinsichtlich der Fehlerbehandlung und Randbedingungen ist festgelegt, dass bei verletzter Vorbedingung eine DanglingSamplesViolation eintreten kann [SWS_CM_11370]. Wurde der Dienst zuvor mittels OfferService() [SWS_CM_00101] nach außen hin angeboten (ARAComAPI §6.5 „Service Discovery“), dürfte vor dem Destruktoraufruf vermutlich die Methode StopOfferService() [SWS_CM_00111] aufgerufen werden müssen, um laufende Kommunikationsbeziehungen sauber zu beenden. Frage Q-c430a7f0fc838eba (offen)

Für das Skeleton ist der Kopierkonstruktor gelöscht [SWS_CM_00134], während Move-Operationen unterstützt werden [SWS_CM_00135]. Laufende Verarbeitungsvorgänge – etwa die Abarbeitung anstehender Aufrufe über ProcessNextMethodCall() [SWS_CM_00199] – sollten vor Beginn der Zerstörung abgeschlossen sein.

Die Methode [SWS_CM_00111] beendet das Anbieten einer Service-Instanz durch die Service-Provider-Anwendung in ara::com. Der Aufruf erfolgt parameterlos auf der konkreten Skeleton-Instanz im Namensraum <SI-Namespace>::skeleton::<SI> und liefert keinen Rückgabewert (EXP_ARAComAPI §5.4.1 „Skeleton Class API’s“).

Für den Einsatz und das Laufzeitverhalten gelten folgende Bedingungen:

• Aufrufkontext und Vorbedingung: Die Methode wird aufgerufen, wenn eine zuvor mittels OfferService() bereitgestellte Instanz – beispielsweise infolge von Zustandsänderungen – nicht mehr zur Verfügung stehen soll (EXP_ARAComAPI §5.4.4 „Offering Service instance“).
• Zusicherung (Contract): Sobald StopOfferService() zurückgekehrt ist, werden vertragsgemäß keine weiteren Methodenaufrufe mehr an diese Service-Instanz weitergeleitet (EXP_ARAComAPI §5.4.4 „Offering Service instance“).
• Lebenszyklus und Destruktor: Falls eine Service-Instanz beim Aufruf des Destruktors der Skeleton-Klasse noch aktiv angeboten wird, führt der Destruktor StopOfferService() intern verpflichtend aus (EXP_ARAComAPI §5.4.4 „Offering Service instance“).
• Service Discovery: Durch den Aufruf wird die lokale Registry beziehungsweise das Service-Discovery-Protokoll der Middleware über das Zurückziehen des Services aktualisiert (EXP_ARAComAPI §7.2.1 „Central vs Distributed approach“).

Die Funktion ist als noexcept deklariert und gilt als ausnahmesicher ([SWS_CM_00111]). Sie signalisiert Fehler weder über Exceptions noch über Fehlermeldungen oder Rückgabecodes.