Figure 6.18: Event Allocate/Send sample

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: C++11/C++14 Code-Listing / API-Verwendungsbeispiel (Skeleton-seitiges Event-Publishing).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Teilsystem ara::com (Communication Management).
• Technischer Zweck: Demonstration des optimierten Zero-Copy- bzw. In-Place-Allokationsmusters für Service-Events auf der Provider-/Skeleton-Seite (Allocate() / Send()-Pattern), um redundante Speicherkopien bei großen Datensätzen (z. B. Radar-Objektlisten) zwischen Applikation und IPC-/Netzwerk-Binding zu eliminieren.

2. Komponenten, Entitäten & Schnittstellen

• Service Skeleton / Service-Instanz:
  • myRadarService: Lokale Instanz einer generierten Skeleton-Klasse (Service-Provider).
  • BrakeEvent: Service-Event-Member der Skeleton-Instanz (Typ: ara::com::skeleton::Event<SampleType>).
• Speicher- und Zeigertypen:
  • SampleAllocateePtr<BrakeEvent::SampleType>: Spezieller Move-Only-Smart-Pointer von ara::com (konzeptionell analog zu std::unique_ptr), der den exklusiven Besitz eines durch das Binding verwalteten Puffers kapselt.
  • BrakeEvent::SampleType: Generierte Datenstruktur / Payload des Events (enthält Member active [bool] und objects [Container/Vector]).
• Schnittstellen & Methoden:
  • BrakeEvent.Allocate(): Binding-spezifische Speicheranforderung (z. B. Shared Memory Puffer oder SOME/IP-Serialisierungspuffer).
  • BrakeEvent.Send(SampleAllocateePtr<SampleType>&&): Asynchrone/synchrone Verteilungs-API mit Ownership-Transfer.
  • std::move(): Standard-C++-Utility zur expliziten Übertragung der Eigentümerschaft an die Middleware.

3. Dynamisches Verhalten & Sequenzablauf

1. Puffer-Allokation (Allocate):
   • Die Applikation triggert myRadarService.BrakeEvent.Allocate().
   • Das darunterliegende Binding (IPC/Shared Memory oder Transport-Stack) reserviert einen geeigneten Speicherbereich aus dem vorkonfigurierten Pufferpool und gibt ihn gekapselt in curSamplePtr zurück.
2. In-Place Nutzdaten-Initialisierung:
   • Der Applikations-Thread schreibt die Nutzdaten direkt in den allokierten Speicherbereich (curSamplePtr->active = true, fillVector(curSamplePtr->objects)). Es findet keine Zwischenspeicherung im applikationseigenen Heap/Stack statt.
3. Eigentumsübergabe & Dispatch (Send):
   • Aufruf von myRadarService.BrakeEvent.Send(std::move(curSamplePtr)).
   • Durch std::move geht die exklusive Eigentümerschaft an das Binding über. Die Middleware übernimmt die Verteilung (z. B. Benachrichtigung lokaler Subscriber via IPC / Shared Memory Pointer Exchange oder Serialisierung ins Netzwerk via SOME/IP).
4. Invalidierung des lokalen Zeigers:
   • Nach dem Move befindet sich curSamplePtr im Zustand moved-from (nullptr).
   • Jeder nachfolgende Zugriff führt zu Null-Pointer-Dereferenzierung / Segmentierungsfehler (Compile- und Runtime-Schutz gegen Data-Races).

4. Normative Relevanz & Entwickler-Hinweise

• Zero-Copy IPC-Optimierung:
  • Für plattforminterne Kommunikation (IPC) allokiert das Binding Speicher direkt im Shared-Memory-Segment. Dadurch können Consumer denselben Speicherbereich (ReadOnly via SamplePtr) einhängen, ohne dass Nutzdaten im Kernel oder User-Space kopiert werden müssen.
• Lebenszyklus & Move-Semantik:
  • Der Entwickler muss die Move-Semantik zwingend einhalten. Zugriff auf curSamplePtr nach Send() ist verboten (Use-After-Move).
• Fehlerbehandlung bei Allokationsengpässen:
  • Allocate() kann bei Pool-Erschöpfung fehlschlagen (Rückgabe von nullptr in R17-03/R18-03 bzw. später ara::core::Result). Für ASIL-konforme Software ist eine Überprüfung des Pointers vor Dereferenzierung architektonisch zwingend erforderlich (im Beispiel zugunsten der Lesbarkeit ausgelassen).
• Konfigurationsabhängigkeit:
  • Die maximale Sample-Größe und Anzahl verfügbarer Puffer müssen im Execution- und Service-Instance-Manifest (CommunicationDeployment) präzise auf die Systemlast und Latenzanforderungen abgestimmt sein.