DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_CommunicationManagement FIG-ac993fc77c10464b 919 × 439 px 2 Release(s)

Figure 7.12: Serialization of Structs without Length Fields (Example)

SHA-256 Inhalts-Fingerabdruck: ac993fc77c10464b661d9f0b1dde06c711e406cea95ab94b4e3dedfcddf7f348
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Datenlayout- und Serialisierungsdiagramm (Transformation In-Memory-Datenstruktur zu linearem PDU-/Wire-Payload-Stream).
  • Technischer Zweck: Spezifikation des SOME/IP-basierten Serialisierungsmechanismus in der AUTOSAR Adaptive Platform (ara::com / Communication Management) für hierarchisch geschachtelte Verbundtypen (struct / record) und statische Arrays bei Konfiguration ohne Längenindikatoren (lengthFieldSize = 0).
  • Funktionale Einordnung: Deterministische, bandbreitenoptimierte Byte-Serialisierung innerhalb des Bindings/Transport-Layers zur Payload-Generierung von Service-Events, Field-Notifiers und Methoden-Parametern ohne dynamischen Längen-Overhead.

2. Komponenten, Entitäten & Schnittstellen

  • Quell-Datenstrukturen (In-Memory C++ / AUTOSAR Application Data Types):
    • Struct_1 (Composite Type / Record):
      • uint32 a: 32-Bit-Ganzzahl (Primitivtyp, 4 Byte).
      • float32 b[2]: Statisches 1D-Array fester Länge (2 x IEEE 754 32-Bit Single Precision, je 4 Byte).
      • Struct_2 c: Geschachtelter komplexer Datentyp (Komposition 1:1).
    • Struct_2 (Composite Type / Record):
      • uint32 d: 32-Bit-Ganzzahl (Primitivtyp, 4 Byte).
      • float32 e[2]: Statisches 1D-Array fester Länge (2 x IEEE 754 32-Bit Single Precision, je 4 Byte).
      • Struct_3 f: Rekursiv eingebettete Folgestruktur (symbolisiert via ...).
  • Ziel-Entität (Serialisierter Wire-Stream):
    • Linearer Bytepuffer / Byte-Stream der Kommunikations-PDU mit lückenloser Aneinanderreihung: [uint32 a] | [float32 b_1] | [float32 b_2] | [uint32 d] | [float32 e_1] | [float32 e_2] | [...]
  • Beziehungen & Kardinalitäten:
    • Struct_1 enthält b[2] (Kardinalität fest = 2) und Struct_2 (Kardinalität fest = 1).
    • Struct_2 enthält e[2] (Kardinalität fest = 2) und Struct_3 (Kardinalität fest = 1).
    • Keine Metadaten-Header, keine Typ-Tags, keine Längenfelder im Zielstrom.

3. Dynamisches Verhalten & Sequenzablauf

  • Serialisierungs-Pipeline (Deep-Flattening):
    1. Linearer Traversal: Der Serializer prozessiert die Member von Struct_1 in der durch die ARXML-Definition festgelegten Reihenfolge.
    2. Array-Unrolling: Statische Arrays (b[2]) werden indexbasiert ohne Präfix entpackt (b[0] → b_1, b[1] → b_2).
    3. In-Place Struct-Inlining: Beim Erreichen von Member c (Struct_2) erfolgt kein Anfügen eines Struct-Headers. Der Serializer steigt rekursiv ab und serialisiert unmittelbar d, gefolgt vom entpackten Array e (e_1, e_2).
    4. Rekursionsfortführung: Nahtlose Fortführung mit Struct_3 f am aktuellen Byte-Offset.
  • Synchronität & Ausführungskontext: Synchroner Ausführungspfad im Serializer-Framework (Skeleton-Seite bei Events/Method-Replies bzw. Proxy-Seite bei Method-Requests) vor Übergabe an den Socket/Transport-Stack (z. B. TCP/UDP).

4. Normative Relevanz & Entwickler-Hinweise

  • Konfiguration (ARXML / Manifest):
    • Entspricht lengthFieldSize = 0 (respektive kein konfiguriertes Längenfeld im SomeipTransformationProps / SomeipFieldDeployment).
    • Geregelt über SWS_CM_10218, SWS_CM_10219 sowie RS_CM_00201/RS_CM_00202/RS_CM_00211.
  • Wire-Format-Restriktionen & Kompatibilität:
    • Keine Vorwärts-/Rückwärtskompatibilität: Da weder Längenfelder noch TLV-Tags existieren, ist das Überspringen unbekannter oder hinzugefügter Felder unmöglich. Sender und Empfänger müssen strikt dasselbe ARXML-Modell und Interface-Layout teilen.
    • Memory-Alignment vs. Wire-Format: Im C++ Memory-Layout eingefügtes Compiler-Padding (Structure Alignment / Packing) darf nicht in den Wire-Stream übertragen werden. Ein naives memcpy(&struct_1, buffer, sizeof(struct_1)) ist unzulässig; die Felder müssen memberweise (oder byteweise gepackt) serialisiert werden.
    • Byte Order: Gemäß SOME/IP-Spezifikation gilt standardmäßig Network Byte Order (Big-Endian), sofern nicht abweichend im Deployment-Manifest konfiguriert.
  • Ressourceneffizienz: Deterministische Payload-Größe zur Compile-Zeit ermöglicht statische Pufferallokation (Vermeidung von dynamischem Heap-Memory zur Laufzeit, MISRA-/Safety-Konformität).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R18-10_R4.4.0_R1.5.0 → R21-11 keine inhaltliche Änderung Vorgänger: FIG-12ccfd40498e7159

Keine inhaltlichen Änderungen erkennbar.

R23-11 → R24-11 keine inhaltliche Änderung Nachfolger: FIG-646993feb22a770a

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Struct_1 | uint32 a | float32 b[2] | Struct_2 c Struct_2 | uint32 d | float32 e[2] | Struct_3 f | serialization | uint32 a float32 b_1 float32 b_2 uint32 d float32 e_1 float32 e_2 | …

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_SWS_CommunicationManagement S. 149 7.29 Figure 7.29: Serialization of Structs without Length Fields (Example)
R21-11 AUTOSAR_SWS_CommunicationManagement S. 149 7.29 Figure 7.29: Serialization of Structs without Length Fields (Example)
R23-11 AUTOSAR_AP_SWS_CommunicationManagement S. 117 7.12 Figure 7.12: Serialization of Structs without Length Fields (Example)