Figure 7.31: Receive an UPDATE Message

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt und Pseudo-loop/Repetition).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com), spezifiziert in AUTOSAR_SWS_CommunicationManagement (Release R21-11).
• Technischer Zweck: Detaillierung des Empfangspfads eines ereignisbasierten Kommunikationsmusters (Event Reception / UPDATE Message) unter Einbindung der End-to-End-Absicherung (E2E-Protection / E2E-State-Machine). Es beschreibt das Zusammenspiel zwischen synchronem Abruf durch die Applikation, Puffer-/Treiberabfrage, E2E-Prüfung bei vorhandenen sowie ausbleibenden Samples und Übergabe an den anwendungsspezifischen Callback.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Lifelines

• Subscriber: Applikative Entität (Adaptive Application / Service Consumer), die eine Event-Instanz (ara::com::Event) abonniert hat.
• ara::com: Middleware-Laufzeitschicht (Service Proxy / Event-Klasse), die Deserialisierung, Speicherverwaltung (SamplePtr) und E2E-Handling kapselt.
• Transmission: Protokoll- und transportspezifisches Binding (z. B. SOME/IP-, IPC- oder DDS-Transport-Layer).

Methoden & Schnittstellen (APIs)

• GetNewSamples(callback f, MaxNumberOfSamples): Polling-basierte API der Event-Klasse zur Verarbeitung eingehender Daten via Übergabe eines Callable f.
• GetMessage(): Interne Schnittstelle des Bindings zur Abholung vorliegender Roh-Frames (serialized samples).
• E2E_Check(dataID, null_ptr) / E2E_Check(...): Aufruf des AUTOSAR-E2E-Bibliotheksmoduls zur Validierung von CRC, Sequenzzähler und Alive-Zähler.
• f(SamplePtr): Anwendungsspezifischer Callback zur In-Place-Konsumierung des deserialisierten Datentyps (ara::com::SamplePtr<SampleType>).
• SamplePtr->GetProfileCheckStatus(): Attributabfrage des SamplePtr auf den Zustand der profilbezogenen Einzelprüfung (ProfileCheckStatus).
• GetE2EStateMachineState(): Abfrage des aggregierten Zustands der E2E-Zustandsmaschine (z. B. Valid, NoNewData, Error).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Datenabholung:
   • Subscriber ruft synchron GetNewSamples(f, MaxNumberOfSamples) auf.
   • ara::com fragt die Transportschicht via GetMessage() ab, empfängt die serialisierten Datenpakete und aggregiert diese intern (Collect received samples).
2. Verzweigung via alt-Fragment:
   • Zweig [no sample received] (Timeout- / No-Data-Erkennung):
     • ara::com ruft E2E_Check(dataID, null_ptr) explizit ohne Nutzdaten auf, um dem E2E-Algorithmus das Ausbleiben eines erwarteten Datenelements zu signalisieren.
     • Aktualisierung und Speicherung des resultierenden Status in der E2E-State-Machine (Store result in E2E SM state()).
   • Zweig [at least 1 sample received] (Verarbeitungsschleife je Sample):
     • Iteration über alle empfangenen Roh-Samples (Repetition through received samples):
       1. Vorverarbeitung nicht-gesicherter Metadaten/Felder (Process non protected data()).
       2. Ausführung von E2E_Check() auf dem gesicherten PDU-Bereich.
       3. Verarbeitung ungesicherter Header-Daten (Process non protected header()).
       4. Deserialisierung der Nutzdaten in das C++-Zielobjekt (Deserialize data()).
       5. Speichern des Prüfergebnisses im Metadatenblock des Sample-Zeigers (Store result in ProfileCheckStatus of SamplePtr()).
       6. Zustandsaktualisierung der E2E-State-Machine basierend auf der Historie (Store result in E2E SM state()).
       7. Weiterleitung an den Subscriber via Aufruf des übergebenen Callbacks f(SamplePtr).
       8. Der Subscriber kann innerhalb des Callbacks SamplePtr->GetProfileCheckStatus() auslesen.
3. Statusabfrage nach Entleerung:
   • Außerhalb der Schleife fragt der Subscriber über GetE2EStateMachineState() den übergeordneten E2E-Zustand des Events ab.

4. Normative Relevanz & Entwickler-Hinweise

• E2E-Alive-Monitoring bei fehlenden Daten: Werden keine Samples empfangen, muss der Middleware-Stack zwingend E2E_Check(..., null_ptr) triggern. Entwickler von Custom-Bindings oder Mock-Frameworks dürfen leere Empfangspuffer nicht stillschweigend ignorieren, da sonst die E2E-Zustandsmaschine Timeouts/Alive-Fehler nicht erkennt.
• Zero-Copy- und Gültigkeitsgrenzen (SamplePtr): Das übergebene SamplePtr hält den Speicher gesperrt (z. B. im Shared Memory / POSIX Shm). Das Auslesen des E2E-Status (GetProfileCheckStatus()) muss pro Sample erfolgen; fehlerhafte Samples (z. B. CRC-Mismatch) werden dennoch an f durchgereicht, damit die Applikation kontextspezifisch reagieren kann.
• Deserialisierungsreihenfolge: Deserialisierung findet erst nach erfolgreicher Auswertung der E2E-Prüfdaten und Header-Validierung statt, um Parsing-Schwachstellen (Malformed Data Exploits / Out-of-Bounds) bei korrumpierten Paketen zu minimieren.
• Synchronizität: GetNewSamples blockiert bis zum Abarbeiten der maximal MaxNumberOfSamples oder bis der Puffer leer ist. Zeitintensive Logik im Callback f blockiert direkt die Ausführung des Middleware-Empfangspfads.