DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_CommunicationManagement FIG-cba90f60da394486 938 × 250 px 4 Release(s)

Figure 7.23: Multi-dimensional arrays (Example)

SHA-256 Inhalts-Fingerabdruck: cba90f60da3944867fc364d8b436ce55ce3eddd8bf00bd685845ed43499cfd90
✦ 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

Serialisierungs- und Datenstrom-Layoutdiagramm im Kontext des AUTOSAR Adaptive Platform Communication Management (SOME/IP-Serialisierung). Das Schaubild stellt das lineare Byte-Layout bei der Serialisierung mehrdimensionaler Arrays (Multi-dimensional arrays) im Protokoll-Payload dar.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst folgende Datenstrukturen und Felder:

  • Äußeres Längenfeld: Box „Length n“ mit konfigurierbarer Breite von „8, 16 or 32 bit“.
  • Übergeordnete Array-Elemente: Sequenz von verschachtelten Elementen, beispielhaft dargestellt durch „Element_a[1][j…k_1]“ und „Element_a[2][j…k_2]“, gefolgt von Fortsetzungspunkten („…“).
  • Innere Längenfelder: Jedes Unter-Array besitzt ein eigenes Längenfeld, bezeichnet mit „L_1“ bzw. „L_2“.
  • Nutzdaten-Elemente der Unter-Arrays: Fortlaufende Elemente „E1,1“, „E1,2“ bis „E1,k_1“ (für das erste Element) bzw. „E1,k_2“ (für das zweite Element).
  • Längenbemaßungen: Längenpfeil „n [byte]“ über die gesamte Struktur einschließlich des äußeren Längenfelds sowie individuelle Längenpfeile „L_1 [byte]“ und „L_2 [byte]“ über die Nutzdatenblöcke (exklusive des jeweiligen inneren Längenfeldes).

3. Dynamisches Verhalten & Sequenzablauf

Die Serialisierung erfolgt sequenziell in Tiefensuche (Depth-First-Order):

  1. Voranstellen des Gesamtlängenfeldes „Length n“.
  2. Serialisierung des ersten übergeordneten Elements „Element_a[1]“: Zuerst das innere Längenfeld „L_1“, unmittelbar gefolgt von der geordneten Konkatenation der inneren Array-Elemente „E1,1“, „E1,2“ bis „E1,k_1“.
  3. Serialisierung nachfolgender übergeordneter Elemente wie „Element_a[2]“ im identischen Schema mit eigenem Längenfeld „L_2“ und Elementen bis „E1,k_2“.
  4. Fortsetzung weiterer Dimensionen bzw. Elemente entlang des Bytestroms.

4. Normative Relevanz & Entwickler-Hinweise

Normative Vorgabe für SOME/IP-Serialisierer und Deserialisierer:

  • Mehrdimensionale Arrays müssen in Depth-First-Reihenfolge serialisiert werden.
  • Jedes Unter-Array (als SOME/IP-Array behandelt) erfordert ein eigenes, vorgelagertes Längenfeld („L_1“, „L_2“).
  • Die Bemaßung „L_1 [byte]“ bzw. „L_2 [byte]“ bemisst exakt die aggregierte Bytegröße der Nutzdatenelemente des jeweiligen Unter-Arrays, während „n [byte]“ die Gesamtlänge des Bytestroms ab dem äußeren Längenfeld angibt.
  • Die Bitbreite des Längenfeldes ist gemäß Manifest auf 8, 16 oder 32 Bit parametrierbar.

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

R18-03_R1.4.0 → R18-10-1 keine inhaltliche Änderung Vorgänger: FIG-12edd6fc36a72574

Keine inhaltlichen Änderungen erkennbar.

R18-10_R4.4.0_R1.5.0 → R19-03 keine inhaltliche Änderung Nachfolger: FIG-49ffbb3e79489b08

Keine inhaltlichen Änderungen erkennbar.

R19-03 → R19-11 keine inhaltliche Änderung Vorgänger: FIG-49ffbb3e79489b08

Keine inhaltlichen Änderungen erkennbar.

R20-11 → R21-11 keine inhaltliche Änderung Nachfolger: FIG-9963d8d5c8d9bd49

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:

Element_a[1][j…k_1] | L_1 [byte] | Length n | 8,16 or 32 bit | E1,1 E1,2 E1,k_1 … L_1 | Element_a[2][j…k_2] | E1,1 E1,2 E1,k_2 … L_2 … | L_2 [byte] | n [byte]

Begleitender Spezifikationstext:

Specification of Communication Management AUTOSAR AP R20-11 [SWS_CM_10222] ⌈The serializing SOME/IP network binding shall write the size (in bytes) of the serialized array (without the size of the length field) into the length field.⌋ (RS_CM_00204, RS_CM_00201, RS_CM_00202, RS_CM_00211) The layout of arrays with dynamic length is shown in 7.22 and Figure 7.23 where L_1 and L_2 denote the length in bytes. The serialization of one- and multi-dimensional dynamic length arrays is described in the next two subchapters. One-dimensional A one-dimensional array carries a number of elements of the same type. Element_1 … element size e n [byte] Length n 8,16 or 32 bit Element_2 Element_3 Element_n Figure 7.22: One-dimensional arrays (Example) [SWS_CM_10070] ⌈A one-dimensional array shall be serialized by concatenating the arrays elements in order.⌋(RS_CM_00204, RS_CM_00201, RS_CM_00202, RS_CM_00211) Multi-dimensional [SWS_CM_10072] ⌈The serialization of multi-dimensional arrays shall happen in depth-first order.⌋(RS_CM_00204, RS_CM_00201, RS_CM_00202, RS_CM_00211) Element_a[1][j…k_1] L_1 [byte] Length n 8,16 or 32 bit E1,1 E1,2 E1,k_1 … L_1 Element_a[2][j…k_2] E1,1 E1,2 E1,k_2 … L_2 … L_2 [byte] n [byte] Figure 7.23: Multi-dimensional arrays (Example) In case of multi-dimensional dynamic length arrays, each array (serialized as SOME/IP array) needs to have its own length field. See L_1 and L_2 in Figure 7.23. 133 of 451 Document ID 717: AUTOSAR_SWS_CommunicationManagement

Vorkommen in AUTOSAR-Releases (7)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_CommunicationManagement S. 85 7.9 Figure 7.9: Multi-dimensional arrays (Example)
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_CommunicationManagement S. 85 7.9 Figure 7.9: Multi-dimensional arrays (Example)
R18-10-1 AUTOSAR_SWS_CommunicationManagement S. 85 7.9 Figure 7.9: Multi-dimensional arrays (Example)
R19-11 AUTOSAR_SWS_CommunicationManagement S. 111 7.13 Figure 7.13: Multi-dimensional arrays (Example)
R19-11 AUTOSAR_SWS_CommunicationManagement S. 111 7.13 Figure 7.13: Multi-dimensional arrays (Example)
R20-11 AUTOSAR_SWS_CommunicationManagement S. 133 7.23 Figure 7.23: Multi-dimensional arrays (Example)
R20-11 AUTOSAR_SWS_CommunicationManagement S. 133 7.23 Figure 7.23: Multi-dimensional arrays (Example)