Figure 7.2: Big Endian (HIGH_BYTE_FIRST) byte ordering

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Speichermodell- und Byte-Mapping-Diagramm (Memory-Layout / Endianness-Mapping).
• Technischer Zweck: Normative Veranschaulichung der Speicherorganisation für Multi-Byte-Datentypen bei Architekturen mit Big-Endian-Byte-Reihenfolge (HIGH_BYTE_FIRST).
• Einordnung im AUTOSAR-Gesamtsystem: Verankert in der Basis-Spezifikation Platform_Types.h (AUTOSAR CP). Es definiert die semantische Abbildung zwischen der arithmetisch-logischen Informationsebene (CPU-Register/Datenelement) und dem physikalischen Adressraum (Hardware-Speicher) zur Erfüllung von SRS_BSW_00161, SWS_Platform_00050 und SWS_Platform_00051.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm trennt das System über eine vertikale Schnittstellenlinie in zwei semantische Domänen:

• Domäne „Information“ (Logische Datenebene):
  • 16-Bit-Wort (16 bit width): Repräsentation eines vorzeichenlosen oder vorzeichenbehafteten 2-Byte-Basisdatentyps (z. B. uint16, sint16).
  • MS Byte (Byte1): Most Significant Byte (höchstwertiges Byte, Bits [15:8]).
  • LS Byte (Byte0): Least Significant Byte (niederwertigstes Byte, Bits [7:0]).
• Domäne „Hardware“ (Physikalischer Speicher / Adressraum):
  • Memory: Linearer, byte-adressierter Arbeitsspeicher (RAM/ROM).
  • Adress n: Basisadresse der 16-Bit-Variable (niedrigere Speicheradresse).
  • Adress n+1: Nachfolgende Speicheradresse (höhere Speicheradresse).
• Relationen & Mapping:
  • MS Byte (Byte1) → gemappt auf Basisadresse Adress n.
  • LS Byte (Byte0) → gemappt auf Folgeadresse Adress n+1.
  • Kardinalität: Streng bijektive 1:1-Zuordnung der Datenbytes auf fortlaufende physikalische Speicherzellen bei strikter Einhaltung von HIGH_BYTE_FIRST.

3. Dynamisches Verhalten & Sequenzablauf

• Statische Abbildung: Es existiert kein dynamischer Kontrollfluss. Die Darstellung beschreibt das statische Hardware-Verhalten bei Lese- und Schreiboperationen (Load/Store) der CPU.
• Speicherzugriffscharakteristik:
  • Bei atomaren 16-Bit-Lese-/Schreibzugriffen liest/schreibt das Memory-Interface der CPU das höherwertige Datenbyte an die numerisch kleinere Adresse n.
  • Bei byteweiser Serialisierung (z. B. Streaming, PDU-Packing im AUTOSAR COM oder Übertragung via SPI/CAN) bestimmt diese Reihenfolge die native Reihenfolge im Speicherpuffer.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsmakros (Platform_Types.h):
  • Gemäß SWS_Platform_00050 und SWS_Platform_00051 muss für die Zielarchitektur das Präprozessor-Symbol CPU_BYTE_ORDER zwingend auf den normativen Bezeichner HIGH_BYTE_FIRST (Wert 0x01 bzw. implementationsabhängig) konfiguriert werden.
• Auswirkungen auf MCAL- und BSW-Entwickler:
  • Type-Punning & Zeigerarithmetik: Casts von uint16* auf uint8* referenzieren an Adresse n das MSB (Byte1). Code, der implizit von Little-Endian ausgeht (Index 0 = LSB), führt zu sofortiger Datenkorruption.
  • Bitfelder (struct mit Bitfeldern): Compiler-spezifisches Layout für Bitfelder hängt oft von der Endianness ab; die Bit-Zuordnung innerhalb von Bytes muss hardware- und compilerspezifisch validiert werden.
• COM / PDU-Serialisierung:
  • Der AUTOSAR COM-Stack unterscheidet Signalkonfigurationen in Big Endian („Motorola“) und Little Endian („Intel“). Bei nativer CPU-Architektur mit HIGH_BYTE_FIRST entfällt für Motorola-Signale das Byte-Swapping; für Intel-Signale ist zwingend eine Invertierung der Byte-Reihenfolge erforderlich.
• Portabilität (SRS_BSW_00161):
  • Plattformunabhängiger Code darf niemals von einer nativen Byte-Reihenfolge ausgehen, sondern muss standardisierte Konvertierungsmakros oder den COM-PDU-Packer nutzen.