Figure 3.1: Relationship between the acronyms defined in the table in chapter 3

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Metamodell-Strukturdiagramm (Komponenten-Strukturmodell, Frame id Component Model).
• Architektur-Kontext: AUTOSAR Classic Platform, Memory Services (AUTOSAR_CP_RS_MemoryServices, Referenz zu AUTOSAR_CP_SWS_NVRAMManager).
• Technischer Zweck: Formale Strukturdefinition und Begriffsabgrenzung des logischen Konzepts NVRAM Block. Es visualisiert die Zerlegung eines NVRAM-Blocks in seine physischen Speicher- und Verwaltungsanteile im flüchtigen, nicht-flüchtigen und Festwertspeicher sowie deren Bezug zu Anwendungsnutzdaten (NV Data) und elementaren Speicherobjekten (Basic Storage Object).

2. Komponenten, Entitäten & Schnittstellen

• «abstract» NVRAM Block:
  • Abstrakte Wurzel- und Aggregationsentität, repräsentiert die konfigurierte logische NVRAM-Verwaltungseinheit (identifiziert über BlockId).
  • Attribute: - BlockManagement Type (definiert die Managementstrategie: NATIVE, REDUNDANT oder DATASET).
  • Constraints:
    • {exact composition depends on Management type} (Zusammensetzung und Anzahl der Teilblöcke hängen vom konfigurierten Typ ab).
    • {handling depends on BlockManagement Type} (Zugriffs- und Redundanzstrategien variieren je nach Typ).
• Teilblöcke (Bestandteile via strikter Komposition NVRAM Block ◆):
  • NV Block: Enthält persistente Nutzdaten sowie NvM-Overhead (Header, Prüfsumme/CRC). Responsibility: stored in NV memory (Flash/EEPROM via Fee/Ea).
  • RAM Block: Flüchtigen Speicherbereich zur Laufzeitbedienung (permanent oder über temporäre Puffer bereitgestellt). Responsibility: stored in RAM.
  • ROM Block: Optionaler Festwertbereich für Rückfall-/Defaultdaten. Responsibility: stored in ROM.
  • Administrative Block: Interner NvM-Verwaltungsdatensatz pro Block. Responsibility: stored in RAM. Führt Zustand, Schutzflags und Ergebnisstatus.
• Nutzdaten & Speicherobjekt-Abstraktion:
  • «user data» NV Data: Repräsentiert die reinen Anwendungs-Nutzdaten. Steht in Kompositionsbeziehung (◆) zu NV Block, RAM Block und ROM Block. Der Administrative Block besitzt keine Beziehung zu NV Data.
  • Basic Storage Object: Kleinste atomare, hardware-/mediumspezifische Speichereinheit. Alle vier Teilblöcke (NV Block, RAM Block, ROM Block, Administrative Block) implementieren diese Entität über Realisierungsbeziehungen («realize», gestrichelte Pfeile).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Klassifikation: Statisches Modell; kein Sequenzablauf direkt im Diagramm enthalten.
• Statischer Laufzeitbezug der Entitäten:
  • Startup (NvM_ReadAll): NV Data wird aus dem NV Block (über das zugrunde liegende Basic Storage Object) verifiziert und in das Basic Storage Object des RAM Block transferiert. Bei Integritätsfehlern erfolgt optional ein Restore aus dem ROM Block.
  • Laufzeit-Verwaltung: Der Administrative Block hält flüchtige Attribute (NvM_RequestResultType, Dynamic Write Protection, Valid/Invalid-, Changed/Unchanged-Flags). Job-Queuing und Zustandsüberwachung finden ausschließlich hier statt.
  • Persistierung (NvM_WriteBlock, NvM_WriteAll): Überträgt geänderte NV Data aus dem RAM Block asynchron über die Abstraktionsschicht (MemIf → Fee/Ea) in das Basic Storage Object des NV Block.

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration (NvMBlockDescriptor):
  • NvMBlockManagementType:
    • NVM_BLOCK_NATIVE: Genau 1 NV Block, 1 RAM Block (optional permanent), max. 1 ROM Block, 1 Administrative Block.
    • NVM_BLOCK_REDUNDANT: 2 NV Blocks zur Fehlertoleranz, 1 RAM Block, max. 1 ROM Block, 1 Administrative Block.
    • NVM_BLOCK_DATASET: N NV Blocks (Multi-Record-Szenarien), 1 RAM Block, M ROM Blocks, 1 Administrative Block.
• RAM-Footprint & Allokation:
  • Für jeden konfigurierten NVRAM-Block wird zwingend RAM-Speicher für den Administrative Block reserviert (Array in der NvM-BSW), unabhängig davon, ob ein permanenter RAM Block konfiguriert ist.
  • Fehlt ein permanenter RAM Block (NvMRamBlockDataAddress == NULL), muss die Applikation bei Lese-/Schreib-APIs einen validen Puffer auf ein temporäres Basic Storage Object übergeben.
• API-Vertrag & Zugriffsschutz:
  • Applikationen (SWCs) dürfen ausschließlich auf das Basic Storage Object des RAM Block zugreifen. Direkte Zugriffe auf den NV Block verletzen die Schichtenarchitektur (Bypass des MemIf/NvM).
  • Der Administrative Block ist für Applikationen gekapselt; sein Status kann nur indirekt via NvM_GetErrorStatus() abgefragt bzw. über Verwaltungs-APIs (NvM_SetRamBlockStatus(), NvM_SetBlockProtection()) modifiziert werden.