Figure 2: Logical Structure of Different Block Types

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Strukturdiagramm (Rahmen: id Component Model).
• Technischer Zweck: Spezifikation der logischen Dekomposition eines NVRAM Block innerhalb des AUTOSAR Basic Software Moduls NVRAM Manager (NvM, Memory Services Layer). Es definiert die strukturellen Teilkomponenten, deren Bindung an Nutzdaten sowie die Realisierung auf den physikalisch-logischen Speichereinheiten (Basic Storage Object) in Abhängigkeit vom Block-Management-Typ.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Stereotypen:
  • «abstract» NVRAM Block: Übergeordnete, logische Verwaltungseinheit.
    • Attribut: - Block Management Type: (NVM_BLOCK_NATIVE, NVM_BLOCK_REDUNDANT, NVM_BLOCK_DATASET).
    • Constraints: {exact composition depends on Management type}, {handling depends on Block Management Type}.
  • NV Block: Logischer nichtflüchtiger Speicherblock zur persistenten Ablage im Speicher (Flash/EEPROM via MemIf/Fee/Ea). Beinhaltet Nutzdaten sowie optional CRC und Block-Header.
  • RAM Block: Flüchtiger Speicherbereich (Permanent RAM Block oder Referenz auf Temporary RAM Block) zur Laufzeit für unterbrechungsfreie Lese-/Schreibzugriffe der Applikation.
  • ROM Block: Optionaler, nichtflüchtiger Festwertspeicher (Flash/ROM) zur Bereitstellung von hardcodierten Standardwerten (Default Data).
  • Administrative Block: Obligatorischer, NvM-interner RAM-Verwaltungsblock. Hält Laufzeitattribute (Job-Ergebnis NvM_RequestResultType, Validitätsflags, Write-Protection-Flags, Queue-Zustände).
  • «user data» NV Data: Die anwendungsspezifischen Nutzdaten, die zwischen RAM, ROM und NV transferiert werden.
  • Basic Storage Object: Abstrakte physische/treiberseitige Speichereinheit auf Hardware- bzw. Abstraktionsebene (z. B. RAM-Variable, ROM-Konstante, Fee/Ea-Record).
• Beziehungen:
  • Komposition (schwarze Raute): NVRAM Block besteht aus NV Block, RAM Block, ROM Block (optional) und Administrative Block.
  • Komposition zu Nutzdaten: NV Block, RAM Block und ROM Block kapseln bzw. spiegeln jeweils das identische Datenelement «user data» NV Data.
  • Realisierung («realize», gestrichelte Pfeile): Alle vier logischen Blöcke (NV Block, RAM Block, ROM Block, Administrative Block) werden auf jeweils eigene Basic Storage Object-Instanzen im Adressraum/Treiber abgebildet.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Obgleich ein statisches Strukturmodell dargestellt ist, definieren die annotierten Constraints das dynamische Laufzeitverhalten der Blöcke:

• Initialisierung / Lesen (NvM_ReadAll / NvM_ReadBlock):
  1. Transfer der Nutzdaten vom NV Block (über MemIf) in den RAM Block.
  2. Integritätsprüfung (CRC). Bei Fehler oder uninitialisiertem NV-Speicher: Fallback-Laden der Default-Werte aus dem ROM Block in den RAM Block (NvM_RestoreBlockDefaults).
  3. Synchrone Aktualisierung des Status im Administrative Block (NVM_REQ_OK, NVM_REQ_INTEGRITY_FAILED etc.).
• Schreiben (NvM_WriteBlock / NvM_WriteAll):
  1. Modifikation erfolgt synchron im RAM Block durch den Anrufer.
  2. Asynchroner Transfer der Nutzdaten («user data» NV Data) vom RAM Block in den/die NV Block(s).
  3. Statusverfolgung (z. B. NVM_REQ_PENDING) und Job-Abschluss-Signalisierung über den Administrative Block.

4. Normative Relevanz & Entwickler-Hinweise

• Auswirkung der Management-Typen auf die Multiplizität:
  • NVM_BLOCK_NATIVE: Exakt 1 NV Block, 1 RAM Block, 0..1 ROM Block, 1 Administrative Block.
  • NVM_BLOCK_REDUNDANT: 2 identische NV Blöcke (Primär/Sekundär zur Absicherung gegen Schreibabbrüche/Bitkipper), 1 RAM Block, 0..1 ROM Block, 1 Administrative Block.
  • NVM_BLOCK_DATASET: N NV Blöcke (1 ≤ N ≤ 255) plus optional M ROM Blöcke, selektierbar über NvM_SetDataIndex(), aggregiert durch 1 gemeinsamen RAM Block und 1 Administrative Block.
• Linker- & Speicherkonfiguration:
  • Jeder Administrative Block erfordert RAM-Zuweisung innerhalb der BSW-internen Linker-Sektionen (vom NvM-Generator automatisch alloziert).
  • Konfigurierte ROM Blöcke müssen zwingend auf gültige Flash-Konstanten-Symbole im Code verweisen (NvM facilities / Initialisierungsvektoren).
• API- & Konsistenzverträge:
  • Wird ein temporärer RAM-Puffer verwendet (kein permanenter RAM Block konfiguriert), muss der übergebene Pointer bis zur Beendigung des asynchronen NvM-Jobs unverändert und gültig bleiben.
  • Schreibschutz (NvM_SetBlockProtection) manipuliert ausschließlich Bits im Administrative Block und verhindert Schreibjobs, bevor diese an Treiber (Fee/Ea) dispatcht werden.