Figure 4.2: ara::com event based communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (sd Dynamic View).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Kommunikationsmanagement (ara::com).
• Technischer Zweck: Spezifikation des standardisierten, ereignisbasierten Publish/Subscribe-Kommunikationsablaufs zwischen Service-Konsument (Client) und Service-Provider (Server). Das Diagramm illustriert die Entkopplung von Benachrichtigung (SetReceiveHandler) und Datenabruf (GetNewSamples) über Middleware- und Network-Binding-Schichten hinweg inklusive Pufferung und SamplePtr-basierter Zustellung.

2. Komponenten, Entitäten & Schnittstellen

• Lifelines & Architektur-Rollen:
  • Client Application: Service-Konsument (Adaptive Application, AA), interagiert ausschließlich über die typisierte Proxy-Schnittstelle.
  • Proxy: Generierte Service-Proxy-Instanz gemäß Service-Interface-Manifest; kapselt Event-Wrapper (ara::com::Proxy::Event).
  • Communication Management Middleware: Plattform-Kern von ara::com; verwaltet Ringpuffer, Subscription-Zustände, Callback-Dispatches und IPC/Transport-Abstraktion.
  • Network Binding: Protokollspezifische Serialisierungs- und Transportschicht (z. B. SOME/IP-Binding, DDS-Binding, POSIX Shared-Memory Binding).
  • Skeleton: Generierte Service-Skeleton-Instanz auf Providerseite (ara::com::Skeleton::Event).
  • Server application: Service-Provider (Adaptive Application, AA), erzeugt Nutzdaten und steuert die Publikationszeitpunkte.
• Schnittstellen & Interaktionspunkte:
  • Event::SetReceiveHandler() / RegisterReceiveHandler(): Registrierung der anwendungsspezifischen Benachrichtigungsfunktion (ara::com::EventReceiveHandler).
  • Event::Subscribe(size_t maxSampleCount) / Subscribe() / Register Subscriber(): Registrierung des Events an der Middleware und Initiierung des bindingspezifischen Subscriptions (z. B. SOME/IP SD Subscribe Eventgroup).
  • Send() / Send Event() / TransmitSample(): Übergabe der Payload durch die Server-Applikation an Skeleton, Middleware und Network Binding.
  • Receive() / StoreSamples(): Low-Level-Empfang und Einreihung der deserialisierten Samples in den typspezifischen Empfangspuffer.
  • Notify ReceiveHandler(): Asynchroner Benachrichtigungstrigger von der Middleware an die Client-Applikation.
  • Event::GetNewSamples(F&& f, size_t maxNumberOfSamples) / FetchSamples(): Bereitstellung von Samples an das übergebene Callable f.
  • User defined callable f per sample(std::move(SamplePtr)): Inversion of Control; sequenzielle Übergabe jedes verfügbaren Datensatzes gekapselt in einem ara::com::SamplePtr<const SampleType>.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Subscription (Client-Seite):
   • Die Client Application setzt via Event::SetReceiveHandler() den Benachrichtigungs-Callback im Proxy, welcher diesen an die Communication Management Middleware weiterreicht.
   • Die Client Application ruft synchron Event::Subscribe() auf. Der Aufruf wird über den Proxy und die Communication Management Middleware an das Network Binding propagiert (Register Subscriber()).
2. Event-Erzeugung & Übertragung (Server-Seite):
   • Die Server application stößt die Publikation mittels Skeleton::Send() an.
   • Das Skeleton ruft Send Event() an der Middleware auf, welche den Datensatz an das Network Binding übergibt (Send()).
   • Das Network Binding serialisiert und versendet das Sample (TransmitSample()).
3. Empfang & Benachrichtigung (alt [subscribed]):
   • Das Network Binding empfängt das Datenpaket (Receive()) und übergibt es an die Middleware.
   • Die Middleware speichert die Daten im internen Puffer (StoreSamples()).
   • Ist die Subscription aktiv ([subscribed]), setzt die Middleware einen asynchronen Trigger ab: Notify ReceiveHandler().
4. Datenübernahme via Callable (loop [All sample processed]):
   • Die Client Application reagiert (im Kontext des Handlers oder eines eigenen Worker-Threads) mit Event::GetNewSamples(F&& f, maxNumberOfSamples).
   • Der Proxy fordert die gepufferten Datensätze an (FetchSamples()).
   • Für jedes verfügbare Sample bis zur Obergrenze maxNumberOfSamples iteriert der Proxy (loop [All sample processed]) und führt das anwenderdefinierte Lambda/Callable f mit Move-Semantik aus (std::move(SamplePtr)).

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung von Benachrichtigung und Datenzugriff: Notify ReceiveHandler() transportiert keine Nutzdaten, sondern signalisiert lediglich deren Verfügbarkeit. Daten müssen aktiv via GetNewSamples() abgeholt werden.
• Lebenszeit- & Speichermanagement (SamplePtr):
  • Der Zugriff erfolgt über Zero-Copy bzw. Smart-Pointer (ara::com::SamplePtr<const SampleType>).
  • Solange eine SamplePtr-Instanz in der Client-Applikation existiert, bleibt der zugehörige Slot im Middleware-Speicher (z. B. Shared Memory) gesperrt. Eine verzögerte Freigabe blockiert den Ringpuffer des Binders.
• Threading- & Reentrancy-Regeln:
  • Der ReceiveHandler wird typischerweise aus dem Kontext des Middleware-Event-Loops aufgerufen.
  • Im Handler dürfen keine langlaufenden, blockierenden oder reentranten ara::com-Aufrufe erfolgen; komplexe Verarbeitung muss in thread-sichere Applikations-Queues ausgelagert werden.
• Puffer-Dimensionierung:
  • Der Parameter maxSampleCount bei Subscribe() muss exakt auf die Erzeugerrate und Verarbeitungszeit abgestimmt werden, um kSampleLost-Zustände oder Pufferüberläufe in der Middleware zu vermeiden.