Figure 7.2: NV Block layout

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Speicherlayout- und Datenstruktur-Diagramm (NV Block Frame / Serialization Layout).
• Architektur-Kontext: Spezifiziert die physische bzw. logische Kapselung eines NV blocks (Non-Volatile Block) im Adressraum des nichtflüchtigen Speichers (EEPROM/Flash via MemIf, Fee/Ea). Definiert das Format, in dem der NVRAM Manager (NvM) Nutzdaten, Metadaten und Integritätsprüfdaten serialisiert, bevor sie an unterlagerte Abstraktionsschichten übergeben werden.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm zeigt die drei Schichten/Felder, aus denen ein einzelner NV block zusammengesetzt ist:

• NV block Header (optional):
  • Metadaten-Präfix vor den Nutzdaten.
  • Enthält z. B. statische Block-Identifikationsdaten oder Prüfinformationen (relevant bei aktivierter Option NvMStaticBlockIdCheck, um Fehladressierungen im Flash/EEPROM zu erkennen).
• NV block data:
  • Obligatorischer Nutzdaten-Payload. Entspricht der per Konfiguration festgelegten Blockgröße NvMBlockLength der Applikations- bzw. BSW-Daten (z. B. Kalibrierdaten, Fehlerspeicher-/DTC-Snapshots).
• NV block CRC (optional):
  • Postfix-Integritätsfeld am Blockende.
  • Nimmt die berechnete Prüfsumme über die Nutzdaten (sowie den Header, falls vorhanden) auf. Konfiguriert über den Parameter NvMBlockUseCrc (TRUE/FALSE) und typisiert über NvMBlockCrcType (NVM_CRC16, NVM_CRC32, NVM_CRC8).
• Strukturelle Beziehung:
  • Der dargestellte NV block bildet zusammen mit dem RAM block (Arbeitskopie/Mirror), dem Administrative block (Status, Job-Ergebnis, Attribute) und dem optionalen ROM block (Default-Werte) die übergeordnete logische Einheit eines AUTOSAR NVRAM block.

3. Dynamisches Verhalten & Sequenzablauf

Schreiboperation (NvM_WriteBlock, NvM_WriteAll)

1. Assemblierung: Kopieren der Anwendungsdaten in den internen Arbeitsbereich; Generierung des Headers (falls konfiguriert).
2. CRC-Berechnung: Synchroner Aufruf der AUTOSAR Crc-Bibliothek (Crc_CalculateCRC8/16/32) über Payload (und Header).
3. Anhängen: Platzierung der berechneten Prüfsumme in das Feld NV block CRC.
4. Persistierung: Asynchrone Übergabe des Gesamtrahmens (Header + Data + CRC) an das Memory Abstraction Interface via MemIf_Write.

Leseoperation (NvM_ReadBlock, NvM_ReadAll)

1. Leseauftrag: Asynchrones Einlesen des vollständigen NV-Blocks via MemIf_Read.
2. Header-Validierung: Bei aktivem Header Prüfung auf korrekte BlockId. Bei Mismatch: Abbruch mit NVM_REQ_WRONG_BLOCK_ID / Det-Meldung.
3. Integritätsprüfung: Neuberechnung der CRC über Payload (und Header) und Abgleich mit dem gelesenen NV block CRC.
4. Abschluss:
   • Bei Übereinstimmung: Nutzdaten werden in den Ziel-RAM-Puffer transferiert, Job-Status wird auf NVM_REQ_OK gesetzt.
   • Bei Nichtübereinstimmung: Status NVM_REQ_INTEGRITY_FAILED, Dem-Fehlerbericht; automatisches Laden des korrespondierenden ROM blocks (sofern vorhanden).

4. Normative Relevanz & Entwickler-Hinweise

• Puffer- und Treiber-Dimensionierung:
  • Die an Fee bzw. Ea übergebene Länge ist nicht identisch mit NvMBlockLength, sondern NvMBlockLength + sizeof(Header) + sizeof(CRC). Konfiguratoren müssen die Blocklängen in der Peripherie (FeeBlockConfiguration / EaBlockConfiguration) exakt auf diese Bruttolänge anpassen.
• Interner NvM-Mirror:
  • Wird ein NvM-eigener Zwischenpuffer genutzt (NVM_BUFFER_SIZE), muss dieser für den größten im System konfigurierten Block inklusive Header und CRC dimensioniert sein.
• Hardware-Alignment & Fls-Restriktionen:
  • Flash-Treiber (Fls) erfordern seitenspezifisches Write-Alignment (z. B. 4, 8 oder 32 Bytes). Ergibt die Brutto-Gesamtlänge (Header + Data + CRC) kein Vielfaches der Page-Size, muss die unterlagerte Abstraktionsschicht (Fee) Padding anwenden, was bei der Sektorkapazitätsberechnung zwingend einzurechnen ist.