AUTOSAR_AP_SWS_CommunicationManagement FIG-963fc0a4f68f9723 914 × 293 px 1 Release(s)

Figure 7.8: Multi-dimensional arrays (Example)

SHA-256 Inhalts-Fingerabdruck: 963fc0a4f68f97230efad00441ce0d6434468a583a37ffc17ad9724a3af228ad

✦ 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 der Zusatzbezeichnung „LengthField (optional)“ und einer konfigurierbaren 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 Längenfeld „L_1“ bzw. „L_2“, jeweils annotiert mit „LengthField (optional)“.
Nutzdaten-Elemente der Unter-Arrays: Fortlaufende Elemente „E1,1“, „E1,2“ bis „E1,k_1“ bzw. „E1,k_2“.
Längenbemaßungen:
- Bemaßung „L_1 [byte]“ und „L_2 [byte]“ über die Nutzdatenblöcke des jeweiligen inneren Arrays (exklusive des inneren Längenfeldes).
- Bemaßung „n [byte]“ über die Gesamtheit der Array-Elemente ohne das äußere Längenfeld.
- Gesamtlängenbemaßung „LengthField + n [byte]“ über das äußere Längenfeld und sämtliche Array-Elemente.

3. Dynamisches Verhalten & Sequenzablauf

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

Optionales Voranstellen des äußeren Längenfeldes („LengthField (optional)“ mit Länge n).
Serialisierung des ersten übergeordneten Elements „Element_a[1]“: Voranstellen des optionalen inneren Längenfeldes „L_1“, gefolgt von den Elementen „E1,1“ bis „E1,k_1“.
Serialisierung nachfolgender übergeordneter Elemente wie „Element_a[2]“ mit optionalem Längenfeld „L_2“ und Elementen bis „E1,k_2“.
Fortsetzung der weiteren Array-Elemente entlang des Bytestroms.

4. Normative Relevanz & Entwickler-Hinweise

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

Mehrdimensionale Arrays werden in Depth-First-Reihenfolge serialisiert.
Sowohl das äußere Längenfeld als auch die inneren Längenfelder („L_1“, „L_2“) sind optional konfigurierbar („LengthField (optional)“).
Bei vorhandenem äußerem Längenfeld gibt der Wert n die Byteanzahl der nachfolgenden Array-Elemente an; die gesamte Bytegröße des Konstrukts beträgt LengthField + n [byte].
Die internen Bemaßungen „L_1 [byte]“ und „L_2 [byte]“ beziehen sich ausschließlich auf die Nutzdaten der Unter-Arrays.
Die Bitbreite von Längenfeldern ist auf 8, 16 oder 32 Bit parametrierbar.

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

R23-11 → R24-11 normative Änderung Vorgänger: FIG-825716b811b39947

Äußeres Längenfeld: Kennzeichnung um den Textzusatz „LengthField (optional)“ ergänzt.
Innere Längenfelder (L_1, L_2): Jeweils um die Beschriftung „LengthField (optional)“ unterhalb des Bezeichners ergänzt.
Gesamtlängenbemaßung: Pfeilbereich für n [byte] beginnt erst nach dem äußeren Längenfeld (deckt nur die Payload der äußeren Array-Elemente ab).
Neue Gesamtlängenbemaßung: Maßpfeil LengthField + n [byte] unterhalb von n [byte] eingefügt, der das äußere Längenfeld und die Payload umfasst.
Rechter Rand: Auslassungspunkte ... nach L_2 [byte] auf Elementebene entfernt.

R24-11 → R25-11 keine inhaltliche Änderung Nachfolger: FIG-6bf9d9a6d91d4381

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

RS_CM_00201 RS_CM_00202 RS_CM_00211 SWS_CM_10070 SWS_CM_10072 SWS_LBAP_00023

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Begleitender Spezifikationstext:

Specification of Communication Management AUTOSAR AP R24-11 [SWS_CM_10070] Serializing one-dimentional array Upstream requirements: RS_CM_00201, RS_CM_00202, RS_CM_00211 ⌈A one-dimensional array shall be serialized by concatenating the arrays elements in order.⌋ Multi-dimensional [SWS_CM_10072] Serializing multi-dimentional array Upstream requirements: RS_CM_00201, RS_CM_00202, RS_CM_00211 ⌈The serialization of multi-dimensional arrays shall happen in depth-first order.⌋ Element_a[1][j…k_1] L_1 [byte] Length n LengthField (optional) 8,16 or 32 bit E1,1 E1,2 E1,k_1 … L_1 LengthField (optional) … n [byte] Element_a[2][j…k_2] L_2 [byte] E1,1 E1,2 E1,k_2 … L_2 LengthField (optional) LengthField + n [byte] Figure 7.8: 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.8. 7.2.1.9.7 Associative Maps Associative map is modeled as StdCppImplementationDataType with category ASSOCIATIVE_MAP in the Manifest. As stated in the AUTOSAR Manifest Specification [5] the “natural” language binding in C++ for an associative map is ara::core:: Map<key_type,value_type> where key_type is the data type used for the key of a map element and value_type is the data type for the value of a map element. Hereby key_type and value_type are derived from defined CppTemplateArguments aggregated by the Associative Map Cpp Implementation Data Type. Please see [SWS_LBAP_0002

Vorkommen in AUTOSAR-Releases (1)

Release	Dokument	Seite	Nr.	Bildunterschrift im Dokument
R24-11	AUTOSAR_AP_SWS_CommunicationManagement	S. 133	7.8	Figure 7.8: Multi-dimensional arrays (Example)