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).
• GetE2EStateMachineStateNotifier(): Schnittstelle zum Erhalt eines Notifiers für Zustandsänderungen der E2E-Zustandsmaschine (ersetzt die frühere Abfrage GetE2EStateMachineState()).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Datenabholung:
   • Subscriber ruft synchron GetNewSamples(callback f, MaxNumberOfSamples) auf.
   • ara::com fragt die Transportschicht via GetMessage() ab, empfängt die serialisierten Datenpakete (serialized samples()) 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. Aggregation des Prüfergebnisses im Gesamtzustand der Zustandsmaschine (Store result in E2E SM state()), wobei die E2E-Zustandsmaschine die Einzelergebnisse validiert (E2E SM evaluates E2E results of single samples).
       7. Weitergabe des Zeigers an die Anwendung via Callback-Aufruf f(SamplePtr).
       8. Innerhalb des Callbacks fragt der Subscriber über SamplePtr->GetProfileCheckStatus() das profilbezogene Prüfergebnis des konkreten Samples ab.
3. Abschluss & Notifier-Registrierung:
   • Nach Beendigung der Repetitionsschleife (Repetition through received samples (end)) ruft der Subscriber GetE2EStateMachineStateNotifier() an ara::com auf, um die Benachrichtigungsschnittstelle für Zustandsänderungen der E2E-Zustandsmaschine abzurufen.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Verbindlichkeit: Das Sequenzdiagramm definiert das verbindliche Verhalten der Adaptive-Platform-Middleware (ara::com) beim ereignisbasierten Empfang abgesicherter Datenelemente (UPDATE Messages).
• Evolution zur Notifier-Schnittstelle: Die frühere synchrone Statusabfrage GetE2EStateMachineState() wurde durch GetE2EStateMachineStateNotifier() ersetzt. Dies überführt das Status-Monitoring der E2E-State-Machine in das asynchrone Notifier-/Callback-Modell der AUTOSAR Adaptive Platform.
• Zweistufige E2E-Absicherung: Es bleibt die strikte Trennung zwischen der Validierung des Einzelsamples (ProfileCheckStatus am SamplePtr) und der übergeordneten Zustandsüberwachung via Notifier bestehen.
• Null-Pointer-Handling bei Datenverlust: Das Ausführen von E2E_Check(dataID, null_ptr) im Zweig [no sample received] stellt sicher, dass auch bei ausbleibenden Nachrichten die Zustandsmaschine für Timeouts und Alive-Counter-Fehler aktualisiert wird.
• Speicher- und Concurrency-Hinweise: Das Callback-basierte In-Place-Muster f(SamplePtr) erfordert eine zügige, nicht-blockierende Verarbeitung durch den Subscriber, um eine Verzögerung nachfolgender Samples zu vermeiden.