Figure 6.2: Event Buffering Approaches

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Architektur- und Datenflussdiagramm / Laufzeit-Topologiemodell (Inter-Process Communication, IPC).
• Technischer Zweck: Visualisierung von Event-Pufferungsstrategien (Event Buffering Approaches) für die lokale Intra-ECU-Kommunikation in der AUTOSAR Adaptive Platform (ara::com).
• Funktionale Einordnung: Dargestellt ist das Entkopplungsmodell zwischen einem Service-Provider (Skeleton) und mehreren Service-Konsumenten (Proxy) auf einem gemeinsamen Steuergerät (ECU with AP product). Es adressiert die architektonische Fragestellung der Pufferallokation (Kernel-Space, Shared Memory oder IPC-Dämon) und die zweistufige Event-Verarbeitung via Event.Send() und Event.GetNewSamples().

2. Komponenten, Entitäten & Schnittstellen

• Prozess- & Laufzeitdomänen:
  • ECU with AP product: Physisches/virtuelles Steuergerät mit vollständigem Adaptive-Platform-Laufzeitstack.
  • ara::com App Skeleton: Eigener OS-Prozessraum der Provider-Applikation; kapselt die Instanz der Service-Implementierung.
  • ara::com App Proxy (Kardinalität 1:n, dargestellt 1:2): Unabhängige OS-Prozessräume der Consumer-Applikationen.
  • Kernel Space? Shared Mem? IPC Demon Space?: Zentraler Puffer-/Vermittlungsbereich der Middleware außerhalb des Adressraums der Applikationsprozesse (mögliche Implementierungsvarianten des Plattform-Vendors).
• Komponenten & Puffer:
  • Skeleton: Generierte ara::com-Dienstanbieter-Schnittstelle.
  • Proxy: Generierte ara::com-Dienstkonsumenten-Schnittstelle.
  • Middleware controlled Event Buffers: Zentral verwalteter Pufferbereich für Event-Samples im Systemkontext.
  • Local Event Cache: Prozesslokaler Ringspeicher/Cache innerhalb der Proxy-Laufzeitumgebung zur Entkopplung von Applikation und IPC-Schicht.
• Schnittstellen & Methoden:
  • Event.Send(): Provider-seitiger API-Aufruf (ara::com::skeleton) zur Weitergabe neuer Event-Payloads an die Middleware.
  • Event.GetNewSamples(): Consumer-seitiger API-Aufruf (ara::com::proxy) zur Synchronisation des prozesslokalen Event-Caches mit den Middleware-Puffern bzw. Abholung neuer Samples.

3. Dynamisches Verhalten & Sequenzablauf

1. Event-Erzeugung (Event.Send()):
   • Die Provider-Applikation ruft synchron auf der Event-Instanz des Skeletons Event.Send() auf.
   • Die Nutzdaten werden aus dem Adressraum der App Skeleton in die Middleware controlled Event Buffers übertragen (via Kernel-Syscall, IPC-Message-Queue, Unix Domain Socket oder Direktschreiben in Shared Memory).
2. Middleware-Pufferung & Verteilung:
   • Die Middleware nimmt das Sample entgegen, ordnet es den Pufferplätzen zu und signalisiert abonnierenden Proxies die Verfügbarkeit neuer Daten (z. B. via Event-FD, POSIX-Signal oder Notification-Thread).
3. Cache-Aktualisierung (Event.GetNewSamples()):
   • Die Consumer-Applikation ruft auf der Event-Instanz des Proxies Event.GetNewSamples() auf (zyklisch gepollt oder im Kontext eines zuvor registrierten SetReceiveHandler-Callbacks).
   • Die Methode holt neue Samples aus den Middleware controlled Event Buffers ab und schreibt bzw. bindet sie in den prozesslokalen Local Event Cache.
4. Applikatorischer Datenzugriff:
   • Die Proxy-Applikation greift anschließend deterministisch und ohne IPC-Blockade über Zeiger (z. B. ara::com::SamplePtr) auf die lokal im Cache liegenden Samples zu.

4. Normative Relevanz & Entwickler-Hinweise

• Zweistufiger API-Vertrag: Das Eintreffen eines Events über die Middleware aktualisiert nicht implizit die Anwendungsdaten. Erst der explizite Aufruf von Event.Update() commitet anstehende Samples in den Local Event Cache des Proxies.
• Speicher- und Kopierstrategien (Stack-Implementierer):
  • Shared Memory: Ermöglicht Zero-Copy- bzw. Single-Copy-Semantik; erfordert jedoch strenge Zugriffssynchronisation (Lock-free Ringbuffer) und Speicherschutzmaßnahmen.
  • IPC-Dämon / Sockets: Erfordert Prozess-Kontextwechsel und mehrfaches Kopieren/Serialisieren der Nutzdaten.
• Dimensionierung & Pufferüberläufe (Applikations-Entwickler):
  • Die maximale Tiefe des Local Event Cache (sampleLimit bzw. Konfiguration im Service Deployment) muss so dimensioniert sein, dass zwischen zwei Event.Update()-Aufrufen keine Samples verloren gehen (Drop Oldest- vs. Reject-Semantik).
  • Zeiger auf Daten (SamplePtr) sperren Pufferplätze im Local Event Cache, bis sie zerstört bzw. freigegeben werden; langlebige Referenzen blockieren den Cache für nachfolgende Update()-Operationen.