DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_EEPROMAbstraction FIG-6f36a54eb3458c11 935 × 755 px 3 Release(s)

Figure 2: Virtual vs. physical memory layout

SHA-256 Inhalts-Fingerabdruck: 6f36a54eb3458c117b84629ce8d086acfb82eeeb3081a637143c7a47d67cad53
✦ 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: Speicherabbildungs- und Adress-Mapping-Diagramm (Memory Layout).
  • Technischer Zweck & Einordnung: Visualisierung der Adressraumtransformation im Modul EEPROM Abstraction (Ea, AUTOSAR Classic BSW, Memory Hardware Abstraction Layer).
  • Funktionale Einordnung:
    • Vermittelt zwischen der standardisierten, virtuellen Blockadressierung der oberen Schichten (NVRAM Manager / NvM via Memory Abstraction Interface / MemIf) und dem linearen, seitenorientierten Adressraum des zugrundeliegenden EEPROM Drivers (Eep).
    • Entkoppelt den 32-Bit-Zugriff (16-Bit Block Number + 16-Bit Block Offset) von der physischen Speicherorganisation und bildet variable Blockgrößen auf feste Page-Einheiten (EA_VIRTUAL_PAGE_SIZE) ab.

2. Komponenten, Entitäten & Schnittstellen

  • Virtueller Adressraum (Upper Layer Sicht / NvM):
    • 16-Bit Block Number: Logische Adresskomponente zur Selektion des Datenblocks (theoretischer Wertebereich: 1 … 65535).
    • 16-Bit Block Offset: Byte-Offset innerhalb eines logischen Blocks; limitiert die maximale Nutzdatenlänge eines Blocks auf 64\,KiB (2^16\,Bytes).
    • Virtuelle Blöcke (Sparse Mapping): Jeder logische Block spannt im virtuellen Adressraum bis zu 64\,KiB auf; ungenutzter Raum bleibt logisch allokiert, wird jedoch nicht physisch belegt.
  • Physischer Adressraum (Lower Layer Sicht / Eep):
    • Page-Alignment (EA_VIRTUAL_PAGE_SIZE): Konfigurierte Paginierungsgröße (im Diagramm: 8\,Bytes).
    • Block-Allokation & Page-Bedarf:
      • Block #1: 32\,Bytes → 4\,Pages (4 × 8\,Bytes = 32\,Bytes), kein Verschnitt (0 Bytes internal residue).
      • Block #5: 100\,Bytes → 13\,Pages (13 × 8\,Bytes = 104\,Bytes), Verschnitt: 4\,Bytes (internal residue).
      • Block #17: 38\,Bytes → 5\,Pages (5 × 8\,Bytes = 40\,Bytes), Verschnitt: 2\,Bytes (internal residue).
  • Mathematische & relationale Bindungen:
    • Page-Berechnung: $\text{Pages}(B) = \lceil \text{BlockSize}(B) / \text{EA\_VIRTUAL\_PAGE\_SIZE} \rceil$
    • Blocknummern-Fortschaltung: $BlockID_n+1 = BlockID_n + Pages(B_n)$ Daraus resultiert die Sperrung nachfolgender Blocknummern (z. B. blockiert Block #1 die IDs 2, 3, 4; Block #5 blockiert IDs 6 … 16).
    • Internal Residue (Verschnitt): $\text{Residue}(B) = (\text{Pages}(B) \times \text{EA\_VIRTUAL\_PAGE\_SIZE}) - \text{BlockSize}(B)$

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm definiert das statische Allokationsmodell, welches die Laufzeit-Adressberechnung deterministisch steuert:

  1. API-Aufruf: NvM ruft über MemIf die Schnittstelle Ea_Read, Ea_Write oder Ea_EraseImmediateBlock mit Parametern BlockNumber, BlockOffset und Length auf.
  2. Adressauflösung: Das Modul Ea berechnet die physische Basisadresse im EEPROM direkt ohne dynamische Allocation-Tables oder Wear-Leveling (im Gegensatz zu Fee): $$\text{Eep\_Address} = \text{Ea\_BaseAddress} + ((\text{BlockNumber} - 1) \times \text{EA\_VIRTUAL\_PAGE\_SIZE}) + \text{BlockOffset}$$
  3. Treiber-Delegation: Ea setzt die Lese-/Schreibanforderung in synchrone/asynchrone Aufrufe an den Treiber ab (Eep_Read, Eep_Write).
  4. Fehlerbehandlung:
    • Ist (BlockOffset + Length) > BlockSize, meldet Ea den Fehler EA_E_INVALID_BLOCK_LEN an das Default Error Tracer (Det).
    • Ist die BlockNumber ungültig oder nicht konfiguriert, erfolgt EA_E_INVALID_BLOCK_NO.

4. Normative Relevanz & Entwickler-Hinweise

  • Konfigurationsverpflichtung (Ea.bmd / BSW-Tooling):
    • EaVirtualPageSize: Muss zwingend ein ganzzahliges Vielfaches der hardwarebedingten EepWriteUnitSize / Eep_PageSize des EEPROMs sein.
    • Nicht-kontinuierliche Blocknummern: Konfiguratoren/Integratoren dürfen EaBlockNumber nicht fortlaufend inkrementieren (1, 2, 3 …). Jede Blocknummer reserviert N virtuelle Page-Indizes. Eine fälschliche Vergabe von Block #2 bei einem 32-Byte-Block #1 führt zu Adressraum-Kollisionen und Datenkorruption.
  • Speicherökonomie & Padding:
    • Jedes Datenobjekt im NvM sollte idealerweise auf ein Vielfaches von EA_VIRTUAL_PAGE_SIZE aligned werden, um ungenutzten Speicherverschnitt (internal residue) zu eliminieren.
    • Da die ungenutzten Bytes einer End-Page für Folgeblöcke unzugänglich sind, verringern unpassende Blockgrößen die Netto-Kapazität des physischen Speichers signifikant.
  • Architekturelle Grenzen:
    • Adressbereich pro Block fest auf maximal 65.535\,Bytes begrenzt.
    • Keine implizite Redundanzverwaltung oder Blockverschiebung; defekte Speicherzellen führen ohne übergeordnete NvM-Redundanzmechanismen (Redundant Blocks) zum Datenverlust.

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

R4.1.3 → R4.2.2 keine inhaltliche Änderung Vorgänger: FIG-38c6593ead6e4669

Keine inhaltlichen Änderungen erkennbar.

R18-10_R4.4.0_R1.5.0 → R19-11 keine inhaltliche Änderung Nachfolger: FIG-145c8b4514ffef45

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:

Block 1 | Block 2 | Block 3 | 32 Bytes | 100 Bytes | 38 Bytes | Note: Sizes not shown to scale | Virtual address space Page size: 64 KBytes | Physical address space Page size: 8 Bytes | 100 Bytes | 32 Bytes | 38 Bytes | 16 Bit Block Number | 16 Bit Block Offset | Block #1 with 32 byte uses 4 pages, no internal residue | Block #5 with 100 byte uses 13 pages, 4 byte internal residue | Block #17 with 38 byte uses 5 pages, 2 byte internal residue

Begleitender Spezifikationstext:

Example: The address alignment / virtual paging is configured to be eight bytes by setting the parameter EA_VIRTUAL_PAGE_SIZE accordingly. The logical block number 1 is configured to have a size of 32 bytes (see Figure 2). This logical block would use exactly 4 virtual pages. The next logical block thus would get the block number 5, since block numbers 2, 3 and 4 are “blocked” by the first logical block. This second block is configured to have a size of 100 bytes, taking up 13 virtual pages and leaving 4 bytes of the last page unused. The next available logical block number thus would be 17.

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.2.2 AUTOSAR_SWS_EEPROMAbstraction S. 23 3 Figure 3: Virtual vs. physical memory layout
R4.3.1 AUTOSAR_SWS_EEPROMAbstraction S. 23 3 Figure 3: Virtual vs. physical memory layout
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_EEPROMAbstraction S. 22 2 Figure 2: Virtual vs. physical memory layout