Figure 9.25: Generated Skeleton interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (C++ Language Binding / Native Interface Design) für Service-Provider (Skeletons).
• Technischer Zweck & Einordnung: Spezifikation der generierten C++-Schnittstellen für das AUTOSAR Adaptive Platform (AP) Functional Cluster Communication Management (ara::com). Das Diagramm definiert das serverseitige API-Muster, das der Service-Interface-Generator aus der formalen Service-Modellierung (ARXML) für Server-Applikationen (Adaptive Applications) erzeugt. Es abstrahiert transport- und IPC-spezifische Bindings (SOME/IP, Shared-Memory/IPC, DDS).

2. Komponenten, Entitäten & Schnittstellen

• Kontext-Container:
  • «aapFunctionalCluster» Communication Management: Architekturelle Zuordnung zur Kommunikations-Middleware (gekennzeichnet als daemon-based Bindeglied/Prozessarchitektur).
• Hauptklasse (Service Skeleton):
  • «aapAPI, aapNativeInterface» {<service-interface-name-upper-camel>}Skeleton: Abstrakte Basisklasse für die Server-Instanz eines definierten Service-Interface.
    • Methoden (Lifecycle/SD): OfferService(), StopOfferService() steuern die Service-Discovery-Sichtbarkeit im Netzwerk/Host.
    • Methoden (Dispatching): ProcessNextMethodCall() für ereignisgesteuertes oder manuelles Polling eintreffender Methodenaufrufe.
    • Methoden (Service Execution): Reinvirtuelle Funktionsschnittstellen {<method-name-upper-camel>}() (Request-Response) und {<fnfmethod-name-upper-camel>}() (Fire-and-Forget).
    • Methoden (Fehler- & Transportmanagement): E2EErrorHandler(), SetTransportFaultConditionHandler(), UnsetTransportFaultConditionHandler().
• Aggregierte Sub-Entitäten (Kompositionen 1 : 1 als Member):
  • «aapAPI, aapNativeInterface» {<event-name-upper-camel>}:
    • Assoziationsname: +{<event-name-upper-camel>} (1 : 1 Komposition).
    • Operationen: Allocate() (Zero-Copy Pufferallokation), Send() (Publikation), GetSubscriptionState(), SetSubscriptionStateChangeHandler(), UnsetSubscriptionStateChangeHandler().
  • «aapAPI, aapNativeInterface» {<field-name-upper-camel>}:
    • Assoziationsname: +{<field-name-upper-camel>} (1 : 1 Komposition).
    • Operationen: Update() (Wertaktualisierung + Notification-Event an Subscriber), RegisterGetHandler() (Callback für Lesezugriffe), RegisterSetHandler() (Callback für Schreibzugriffe inkl. Validierung), SetTransportFaultConditionHandler(), UnsetTransportFaultConditionHandler().
  • «aapAPI, aapNativeInterface» {<trigger-name-upper-camel>}:
    • Assoziationsname: +{<trigger-name-upper-camel>} (1 : 1 Komposition).
    • Operationen: Send() (Ausschütten eines synchronisierenden Trigger-Signals ohne Nutzdaten-Payload).

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung & Registrierung:
   • Die Applikation instanziiert die abgeleitete Subklasse des Skeletons.
   • Zwingende Registrierung aller Handler vor Service-Start: RegisterGetHandler() und RegisterSetHandler() für Felder sowie applikative Transport-Fault-Handler.
2. Service Offering:
   • Aufruf von OfferService(): Middleware aktiviert die Endpunkte, initiiert Service Discovery (z. B. SOME/IP SD Offer Service) und signalisiert Verfügbarkeit für Clients.
3. Methodenabarbeitung:
   • Client sendet Methodenaufruf:
     • Im standardmäßigen Event-Loop-Modus ruft die Middleware die überladene Methode {<method-name>}() auf.
     • Im deterministischen Polling-Modus holt die Applikation die Ausführung explizit über ProcessNextMethodCall() ab.
   • Rückgabe erfolgt asynchron über ara::core::Future oder synchron via ara::core::Result.
4. Event- / Trigger-Bereitstellung:
   • Event: Allocate() reserviert Speicher im IPC/Shared-Memory-Segment (SampleAllocateePtr) → Applikation befüllt Daten → Send() übermittelt Daten pointer-basiert (Zero-Copy) oder serialisiert.
   • Field: Änderung des Server-Status via Update() aktualisiert den internen Feld-Wert und sendet simultan ein Notification-Event an abonnierende Clients.
5. Teardown:
   • Aufruf von StopOfferService() zieht die Service-Ankündigung zurück; danach folgt der sichere Abriss der Skeleton-Instanz.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturmuster (Skeleton Pattern): Entwickler implementieren das Server-Verhalten über Ableitung und Überschreibung der reinen virtuellen Methoden (pure virtual) der generierten Skeleton-Klasse.
• Thread-Safety & Nebenläufigkeit: Sofern ProcessNextMethodCall() nicht für Single-Threaded Polling genutzt wird, erfolgen Methodenaufrufe nebenläufig aus dem Thread-Pool der ara::com-Laufzeitumgebung. Der Applikationscode innerhalb von {<method-name>}() und den Field-Handlern muss reentrant und synchronisiert sein.
• Initialisierungs-Reihenfolge: Field-Handler (RegisterGetHandler, RegisterSetHandler) müssen zwingend vor OfferService() registriert werden. Das Eintreffen eines Get/Set-Requests bei unvollständiger Registrierung führt zu Laufzeitfehlern oder abgewiesenen Requests.
• Zero-Copy & Allokation: Die Verwendung von Allocate() ist essenziell für latenzkritische und datenintensive Events (z. B. Kamera-, Lidar- und Radar-Streams). Sie verhindert redundante Kopierzyklen und Serialisierungs-Overhead über Shared-Memory-Transportschichten.
• Fehlerbehandlung: Methoden nutzen die AUTOSAR Adaptive Core Typen (ara::core::Result, ara::core::ErrorCode), um C++ Exceptions im Embedded-Umfeld strikt zu vermeiden. Transport- und E2E-Fehler werden über die dedizierten Handler (E2EErrorHandler, SetTransportFaultConditionHandler) entkoppelt vom Nutzdatenpfad gemeldet.