Figure 7.30: Send an UPDATE Message

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit Iterationsrahmen).
• Technischer Zweck: Spezifikation des ausgehenden Sendepfads für ein Field-Notifier-Ereignis (UPDATE-Nachricht) im ara::com-Service-Provider-Kontext.
• Architektur-Einordnung: AUTOSAR Adaptive Platform (AP, R21-11), Schicht ara::com (Communication Management). Das Diagramm definiert das Zusammenspiel zwischen anwendungsspezifischem Service-Skeleton, der Middleware-internen Serialisierungs- und Safety-Pipeline (E2E Protection Wrapper) und der Transportschicht (Binding, z. B. SOME/IP über UDP/TCP oder IPC).

2. Komponenten, Entitäten & Schnittstellen

• Lifelines & Akteure:
  • Publisher: Adaptive Application (AA), die eine Service-Instanz über die generierte Skeleton-Klasse bereitstellt.
  • ara::com: Communication-Management-Laufzeitumgebung inklusive Binding-Implementierung, Serializer und E2E-Transformationsmodul.
  • Transmission: Unterlagerte Transportschicht bzw. OS-Netzwerk-Subsystem (Socket-Interface, IPC-Queue).
• Interaktionsrahmen:
  • Repetition for every subscriber (begin/end): Iterations-Block (loop) über alle registrierten Abonnenten des entsprechenden Fields.
• Operationen & Schnittstellen:
  • skeletonField.update(field value): Generierte Skeleton-Methode der Klasse ara::com::skm::Field zur Aktualisierung des Feldwerts und Auslösen des Notifiers.
  • Serialize return value(): Interne Routine zur Konvertierung des typisierten C++-Feldwerts in das lineare Byte-Array (z. B. SOME/IP-Serialisierung).
  • Add E2E protected header(): Injektion derjenigen Header-Anteile, die durch die nachfolgende E2E-Prüfsumme abgedeckt werden.
  • E2E_Protect(): Berechnung des Safety-Trailers/Headers (CRC, Sequence Counter, Data ID) gemäß E2E-Profilspezifikation (u. a. PRS_E2E_00597).
  • Add non protected header(): Voranstellen des Transport-/Protokoll-Headers (z. B. ungeschützte SOME/IP-Headerfelder wie Message Type = NOTIFICATION, Message ID).
  • Send(): Übergabe des fertig zusammengestellten PDU-Puffers an den physischen/logischen Übertragungskanal.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Die Applikation (Publisher) stößt das Update durch den Aufruf von skeletonField.update(...) an.
2. Subscriber-Dispatch (Schleife): Für jeden aktiven Subscriber wird die Sende-Pipeline separat durchlaufen:
   • Stufe 1 (Serialisierung): ara::com serialisiert den Nutzdatenwert (Serialize return value()).
   • Stufe 2 (E2E-Header-Vorbereitung): Einbau des protokollspezifischen E2E-Headers (Add E2E protected header()).
   • Stufe 3 (Safety-Absicherung): Ausführung von E2E_Protect(). Aktualisiert den monoton steigenden Alive-Counter und generiert die CRC über Data-ID, geschützte Header und Payload.
   • Stufe 4 (Transport-Framing): Anhängen der ungeschützten Header-Elemente (Add non protected header()).
   • Stufe 5 (Dispatch): Asynchroner oder synchroner Aufruf von Send() an die Transmission-Instanz zur physikalischen Übertragung.
3. Abschluss: Die Schleife terminiert nach der Benachrichtigung des letzten Subscribers; die Kontrolle kehrt zum Publisher zurück.

4. Normative Relevanz & Entwickler-Hinweise

• E2E-Schutzprofil (PRS_E2E_00597): Die Reihenfolge der PDU-Assemblierung ist strikt normativ: Payload-Serialisierung → E2E-Header → Schutzberechnung → Ungeschützter Header. Entwickler von Custom-Bindings oder E2E-Transformern dürfen diese Reihenfolge nicht vertauschen, da die CRC-Validierung auf Empfängerseite (Proxy) andernfalls fehlschlägt.
• Performance- und Latenzimplikation: Das Schaubild spezifiziert eine Iteration je Subscriber. Bei Unicast-Endpunkten oder Subscriber-spezifischen E2E-Zuständen (State-Machines je Verbindung) skaliert der Berechnungs- und Serialisierungsaufwand linear (O(N)). Für latenzkritische Pfade mit vielen Empfängern muss geprüft werden, ob das Binding Multicast unterstützt und E2E-Profile mit geteilten Countern zulässig sind.
• Puffer- und Speichermanagement: ara::com-Implementierungen müssen für Serialize return value() und Header-Zusammenstellungen Zero-Copy- oder statisch vorallokierte Buffer-Pools nutzen, um Heap-Allokationen im deterministischen Echtzeitkontext (ASIL) zu vermeiden.
• Fehlerbehandlung: Scheitert E2E_Protect() (z. B. ungültige State-Machine oder Zählerüberlauf) oder Send(), darf die Nachricht nicht ungeschützt oder korrupt übertragen werden; der Fehler muss stack-intern protokolliert und ggf. als ara::core::Result-Fehlerklasse gemeldet werden.