Figure 7.5: Serialization of Structs with Length Fields (Example)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Datenstruktur- und Serialisierungs-Layout (PDU-/Wire-Format-Mapping).
• Technischer Zweck: Spezifikation des Byte-Stream-Layouts bei der Transformation geschachtelter C++-Strukturen (struct) in ein standardisiertes On-Wire-Serialisierungsformat (vorrangig SOME/IP Data Serialization gemäß RS_CM_00201, RS_CM_00202, RS_CM_00211).
• Architektur-Einordnung: Verortet im Binding-Layer von AUTOSAR Adaptive ara::com (Communication Management). Es definiert, wie zusammengesetzte strukturierte Datentypen bei IPC- und Netzwerk-Bindings (Skeleton-zu-Proxy / Service Deployment) paketiert werden, wenn Längenfelder (lengthFieldSize) zur Typdekodierung, Vorwärtskompatibilität und Payload-Begrenzung konfiguriert sind (SWS_CM_10218, SWS_CM_10219).

2. Komponenten, Entitäten & Schnittstellen

• Logische Datentypen (In-Memory / Application Model):
  • Struct_1: Root-Datenstruktur, bestehend aus:
    • uint32 a: 32-Bit Ganzzahl (Primitivtyp).
    • float32 b[2]: Statisches 1D-Array aus zwei IEEE 754 32-Bit Gleitkommawerten (b_1, b_2).
    • Struct_2 c: Eingebettete Instanz der Unterstruktur Struct_2.
  • Struct_2: Verschachtelte Struktur, bestehend aus:
    • uint32 d: 32-Bit Ganzzahl.
    • float32 e[2]: Statisches Array aus zwei 32-Bit Gleitkommawerten (e_1, e_2).
    • Struct_3 f: Weitere hierarchisch eingebettete Struktur Struct_3.
• Wire-Format / Serialisierte Entitäten (PDU Stream):
  • uint16 lf1: Explizites 16-Bit-Längenfeld für Struct_1 (präfigiert vor die serialisierten Member von Struct_1).
  • uint16 lf2: Explizites 16-Bit-Längenfeld für das geschachtelte Element Struct_2 c (präfigiert vor die Member von Struct_2).
  • uint16 lf3: Explizites 16-Bit-Längenfeld für das Sub-Element Struct_3 f (präfigiert vor die Member von Struct_3).
  • Flache Sequenz serialisierter Payload-Felder: [lf1] [a] [b_1] [b_2] [lf2] [d] [e_1] [e_2] [lf3] [...].
• Beziehungen & Strukturhierarchie:
  • Komposition: Struct_1 aggregiert Struct_2 (1:1 per-value); Struct_2 aggregiert Struct_3 (1:1 per-value).
  • Jedes konfigurierte Struct-Längenfeld kapselt transitiv die vollständige Byte-Länge aller eigenen Attribute sowie sämtlicher darin rekursiv enthaltener Sub-Strukturen (inklusive deren jeweiliger Längenfelder).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Serialisierungs-Mapping handelt, erfolgt der Ablauf rein funktional während der Serialisierung (Sender) bzw. Deserialisierung (Empfänger):

1. Serialisierungsphase (Sender-seitig via SOME/IP-Serializer / ara::com):
   • Reservierung/Allokation des Headers für lf1 (2 Bytes).
   • Direktes binäres Schreiben von Member a (4 Bytes) gefolgt von Array b (b_1: 4 Bytes, b_2: 4 Bytes) in konfigurierter Network-Endianness (üblicherweise Big-Endian/Network Byte Order).
   • Beginn der Serialisierung des Members c: Reservierung des Headers für lf2 (2 Bytes).
   • Schreiben von d (4 Bytes), e_1 (4 Bytes), e_2 (4 Bytes).
   • Beginn von Member f: Schreiben/Reservierung von lf3 (2 Bytes) und nachfolgender Struct_3-Payload.
   • Backpatching / Größenberechnung:
     • lf3 = Gesamtgröße der serialisierten Payload von Struct_3.
     • lf2 = sizeof(d) + sizeof(e_1) + sizeof(e_2) + sizeof(lf3) + length(Struct_3) (in Bytes: 4 + 4 + 4 + 2 + Payload_Struct_3).
     • lf1 = sizeof(a) + sizeof(b_1) + sizeof(b_2) + sizeof(lf2) + length(Struct_2) (in Bytes: 4 + 4 + 4 + 2 + Payload_Struct_2).
2. Deserialisierungsphase (Empfänger-seitig via ara::com Binding):
   • Auslesen von lf1: Überprüfung, ob mindestens lf1 Bytes im Buffer verfügbar sind (Bound-Check).
   • Parsen von a, b_1, b_2.
   • Treffen auf Struct_2: Auslesen von lf2; Überprüfung, ob lf2 konsistent in den Scope von lf1 passt.
   • Parsen von d, e_1, e_2 und rekursives Parsen von Struct_3 über lf3.
   • Fehlerfälle: Bei PDU-Abschneidung (available_bytes < length_field) oder Inkonsistenz von Sub-Längenfeldern (lf2 > lf1 - offset) verwirft der Stack das Paket deterministisch und meldet einen Deserialisierungs-/Unmarshalling-Fehler.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung & Deployment:
  • Das Vorhandensein und die Bitbreite der Längenfelder (lf1, lf2, lf3) wird im ARXML-Manifest über das Service-Interface-Deployment konfiguriert (Parameter SomeipTransformationProps / SomeipFieldDeployment bzw. lengthFieldSize = 16 Bit gem. SWS_CM_10218).
  • Steht lengthFieldSize auf 0, entfällt das jeweilige Prefix; die Strukturgröße muss dann zur Compile-Zeit statisch bekannt und zwischen Client und Server identisch sein.
• Vorwärts- und Rückwärtskompatibilität (E2E / Schema Evolution):
  • Das Längenfeld erlaubt es Empfängern mit älterem Datenmodell, unbekannte zusätzliche Felder am Ende einer Struktur sicher zu überspringen (Seek um Length - bereits_gelesene_Bytes), ohne den Gesamtparser zu blockieren (RS_CM_00211).
• Alignment & Padding:
  • Im gezeigten Format ist kein implizites Compiler-Padding enthalten. Alle Datenfelder folgen packed/dicht aufeinander, sofern nicht explizit Alignment-Padding konfiguriert ist (SWS_CM_10219). Entwickler dürfen C++ Memory-Dumps (reinterpret_cast) nicht direkt auf das Wire-Format übertragen, da Host-Alignment (z. B. 64-Bit Alignment von Floats/Doubles) die Daten korrumpieren würde.
• Stack-Laufzeit & Zero-Copy:
  • Dynamische Längenberechnung bei tief geschachtelten Strukturen erfordert entweder einen Two-Pass-Serializer oder Streaming mit reservierten Längenfeld-Offsets (Backpatching im PDU-Ringbuffer). Dies ist kritisch für Latenz und deterministisches Speicher-Management im Embedded-Umfeld.