Figure 4.1: Proxy Skeleton Pattern

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Architektur- und Entwurfsmuster-Diagramm (Pattern-Schichtenmodell).
• Technischer Zweck: Darstellung des Proxy-Skeleton-Entwurfsmusters (nach POSA / GoF) als fundamentales Kommunikationsparadigma der AUTOSAR Adaptive Platform (ara::com).
• Funktionale Einordnung: Entkopplung der anwendungsspezifischen Geschäftslogik (Service Consumer Implementation, Service Implementation) von der zugrunde liegenden Kommunikations- und Serialisierungsmechanik (Middleware Transport Layer, z. B. SOME/IP, IPC, DDS) über plattformgenerierte C++-Schnittstellenklassen.

2. Komponenten, Entitäten & Schnittstellen

• Service Interface Definition (Modellierungsartefakt):
  • Formale ARXML-Beschreibung eines AUTOSAR-ServiceInterface (beinhaltet Events, Methods und Fields).
  • Fungiert als herstellerunabhängige Single Source of Truth für den ara::com-Codegenerator.
• Client Application (Prozess-/OS-Domain):
  • Service Consumer Implementation: Applikativer C++-Code des Service-Konsumenten. Greift ausschließlich auf die Schnittstelle des Proxys zu.
  • Service Proxy: Generierte typsichere C++-Klasse (<Service>Proxy). Realisiert das Stellvertreter-Objekt im Adressraum des Clients. Kapselt Marshalling/Serialisierung von Methodenaufrufen, Demarshalling von Event-Payloads und Binding-Dispatching.
• Service Application (Prozess-/OS-Domain):
  • Service Implementation: Applikativer C++-Code des Service-Providers (Servant). Implementiert die konkrete Geschäftslogik durch Spezialisierung (Vererbung/Delegation) der Skeleton-Klasse.
  • Service Skeleton: Generierte typsichere C++-Basisklasse (<Service>Skeleton). Realisiert die serverseitige Dispatcher-Einheit. Kapselt Demarshalling von Request-Parametern, Aufruf der Servanten-Methoden sowie Marshalling und Aussenden von Events/Responses.
• Middleware Transport Layer (Laufzeit-Stack):
  • Protokollspezifische Bindings (z. B. SOME/IP via UDP/TCP, POSIX Shared Memory / Kernel-IPC für Node-lokale Kommunikation).
  • Bildet die transparente Transportschicht, über welche Proxy und Skeleton paket- bzw. nachrichtenbasiert kommunizieren.
• Beziehungen & Abhängigkeiten:
  • generated from: Gerichtete Modell-zu-Code-Generierungsbeziehung (AOT-Compiler / AUTOSAR-Toolchain) von der Service Interface Definition auf Service Proxy und Service Skeleton.
  • Schichtung: Service Consumer Implementation bindet Service Proxy; Service Implementation realisiert Service Skeleton. Beide Adapter sitzen unmittelbar auf dem Middleware Transport Layer auf.

3. Dynamisches Verhalten & Sequenzablauf

1. Design- & Build-Zeit:
   • Definition des ServiceInterface in ARXML.
   • Toolchain generiert Header und Quellcodedateien für Proxy- und Skeleton-Klassen (inkl. Bindings).
2. Initialisierung & Service Discovery:
   • Provider-Seite: Service Implementation instanziiert das Service Skeleton und ruft OfferService() auf. Der Transport Layer registriert den Dienst (z. B. SOME/IP-SD Offer).
   • Consumer-Seite: Service Consumer Implementation startet Service-Suche via Proxy-API (StartFindService() / FindService()), erhält Service-Handles und instanziiert die Service Proxy-Klasse.
3. Laufzeit-Kommunikation (Methoden, Events, Fields):
   • Methodenaufruf (Client → Server): Client ruft Methode auf dem Proxy auf → Proxy serialisiert Argumente → Transport Layer überträgt PDU → Skeleton deserialisiert und ruft Methode in Service Implementation auf → Skeleton serialisiert Rückgabewert → Proxy liefert Ergebnis asynchron an Client via ara::core::Future.
   • Event-Distribution (Server → Client): Service Implementation aktualisiert Event → Skeleton publiziert Event via Transport Layer → Proxy empfängt PDU, deserialisiert und notifiziert Client via registriertem Callback (SetReceiveHandler) oder Polling (GetNewSamples).

4. Normative Relevanz & Entwickler-Hinweise

• API-Isolation & Protokoll-Agnostizismus:
  • Applikationscode bindet ausschließlich standardisierte ara::com-Typen und generierte Proxy/Skeleton-Header ein. Der Wechsel des Transportprotokolls (z. B. von IPC auf SOME/IP) erfordert keine Änderungen am C++-Anwendungscode, sondern lediglich eine Neukonfiguration der Deployments (Mapping im Manifest) und Neu-Generierung des Bindings.
• Synchronizitätsmodell & Exception-Freiheit:
  • ara::com verzichtet auf blockierende RPC-Aufrufe und klassische C++-Exceptions. Methoden liefern typischerweise ara::core::Future<ara::core::Result<Output>> zurück. Entwickler müssen mit ara::core::ErrorCode und Futures arbeiten.
• Lifecycle & Speicherverwaltung:
  • Bei lokaler IPC-Kommunikation nutzen Skeleton und Proxy Shared-Memory-Pools für Zero-Copy-Transfers (SamplePtr). Der Lebenszyklus der Datenpuffer wird über Ref-Counting gesteuert; Freigaben im Client-Code müssen zeitnah erfolgen, um den Buffer-Pool des Providers nicht zu blockieren.
• ABI-/API-Striktheit:
  • Jede Modifikation an der Service Interface Definition bricht die Binärkompatibilität. Proxy und Skeleton müssen zwingend gegen denselben Interface-Release-Stand kompiliert werden.