Figure 7.5: NV block layout with Static Block ID enabled

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Speicherlayout- / PDU-Strukturdiagramm (Darstellung der physischen Byte-Segmentierung eines persistenten Speicherblocks).
• Technischer Zweck & Einordnung:
  • Das Diagramm spezifiziert die interne Datenorganisation eines Nichtflüchtigen Speicherblocks (NV Block) im NVRAM Manager (NvM) der AUTOSAR Classic Platform (Releases R21-11, R22-11, R23-11).
  • Es definiert die strukturelle Kapselung der Nutzdaten auf Treiber- und Hardwareabstraktionsebene (MemIf / Fee / Ea), wenn das Sicherheitsfeature Static Block ID Check über den Konfigurationsparameter NvMStaticBlockIDCheck == TRUE aktiviert ist ([SWS_NvM_00522]).
  • Zweck ist der Schutz vor Adressierungsfehlern, Blockverwechslungen und falscher Zuordnung im physikalischen Speicher (Flash/EEPROM).

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm visualisiert die drei logischen Segmente eines persistenten Speicherblocks:

1. NV block header (Header-Segment):
   • Inhalt: Enthält die statische 16-Bit Block-Identifikationsnummer (Static Block ID, uint16), korrespondierend zur konfigurierten NvMBlockId.
   • Kardinalität: 1 (zwingend vorhanden und an Offset 0 vorangestellt, sobald NvMStaticBlockIDCheck == TRUE).
   • Schnittstellen-Eigenschaft: Modulinternes Datum; für anwendende Software-Components (SWC) unsichtbar (wird im NvM erzeugt/geprüft und nicht in den RAM-Spiegel übernommen).
2. NV block data (Payload-Segment):
   • Inhalt: Reine Applikations- oder BSW-Nutzdaten.
   • Kardinalität: 1 (Länge entspricht exakt dem Konfigurationswert NvMNvBlockLength).
   • Schnittstellen-Eigenschaft: Bildet das exakte 1:1-Äquivalent zum Anwendungs-RAM-Block (NvMRamBlockDataAddress) bzw. PRAM-Block.
3. NV block CRC (optional) (Trailer-Segment):
   • Inhalt: Prüfsumme zur Erkennung von Datenkorruption (CRC8, CRC16 oder CRC32 via CRC-Bibliothek).
   • Kardinalität: 0..1 (vorhanden, wenn NvMBlockUseCrc == TRUE; Typ bestimmt durch NvMBlockCrcType).

Abbildung auf NVRAM-Blockverwaltungstypen ([SWS_NvM_00137]):

• NVM_BLOCK_NATIVE ([SWS_NvM_00557]): Besteht aus genau 1 NV-Block (welcher exakt diesem Layout folgt), 1 RAM-Block, 0..1 ROM-Block und 1 Administrative Block.
• NVM_BLOCK_REDUNDANT ([SWS_NvM_00558]): Besteht aus 2 NV-Blöcken (beide besitzen identisch dieses 3-teilige Layout mit jeweils identischer Static Block ID), 1 RAM-Block, 0..1 ROM-Block und 1 Administrative Block.
• NVM_BLOCK_DATASET: Besteht aus 1..N NV-Blöcken (jeder Datensatz besitzt dieses Layout), 1 RAM-Block, 0..M ROM-Blöcken und 1 Administrative Block.

3. Dynamisches Verhalten & Sequenzablauf

Schreibpfad (NvM_WriteBlock, NvM_WritePRAMBlock, NvM_WriteAll):

1. Serialisierung: NvM fügt im internen Arbeits- oder Sektorpuffer vor die Nutzdaten (NV block data) den 2 Byte breiten NV block header mit der konfigurierten NvMBlockId ein.
2. CRC-Berechnung: Falls NvMBlockUseCrc == TRUE, berechnet NvM die Prüfsumme über Header und Nutzdaten und hängt diese als NV block CRC an.
3. Persistierung: Der vollständige Block (Header + Payload + CRC) wird asynchron über MemIf_Write(DeviceIndex, BlockNumber, Buffer) an Fee/Ea übergeben.

Lesepfad (NvM_ReadBlock, NvM_ReadPRAMBlock, NvM_ReadAll):

1. Leseoperation: NvM liest den gesamten physischen Block via MemIf_Read(...) in seinen Puffer ein.
2. CRC-Verifikation: Validierung der NV block CRC. Schlägt diese fehl, wird NVM_REQ_INTEGRITY_FAILED gesetzt und die Error-Recovery gestartet.
3. Static Block ID Check: NvM extrahiert die ID aus dem NV block header und vergleicht sie mit der Ziel-NvMBlockId:
   • Mismatch (ID fehlerhaft / ungleich Ziel-BlockId):
     • NvM meldet den Diagnosefehler NVM_E_WRONG_BLOCK_ID an das Dem (Dem_SetEventStatus).
     • Abbruch der Nutzdatenübernahme in den RAM-Block.
     • Read Error Recovery:
       • Bei NVM_BLOCK_REDUNDANT: Automatischer Fallback auf den zweiten redundanten NV-Block ([SWS_NvM_00558]).
       • Falls Recovery fehlschlägt oder Block Native: Laden von Standardwerten aus dem ROM-Block (NvMRomBlockDataAddress), sofern vorhanden; sonst Markierung als ungültig (NVM_REQ_NV_INVALIDATED).
   • Match (Erfolg):
     • Header und CRC werden verworfen (Stripping).
     • NV block data wird in den konfigurierten RAM-Block kopiert; Status wird auf NVM_REQ_OK gesetzt.

4. Normative Relevanz & Entwickler-Hinweise

• Blockdimensionierung in Fee / Ea (Kritische Kopplung):
  • Das Treiber-Layout unterhalb des MemIf (FeeBlockConfiguration bzw. EaBlockConfiguration) muss die Gesamtgröße abbilden: $$\text{Physische Blockgröße} = \text{sizeof(NV Block Header [2 Byte])} + \text{NvMNvBlockLength} + \text{sizeof(CRC [0/1/2/4 Byte])}$$
  • Eine Fehlkonfiguration der virtuellen Blocklängen in Fee/Ea führt zu Pufferüberläufen oder Driver-Rejections (MEMIF_JOB_FAILED).
• Transparenz für Applikations-Entwickler:
  • Der Anwendungs-RAM-Puffer allokiert ausschließlich NvMNvBlockLength. Header-Verwaltung und CRC-Handling sind für SWCs und PRAM-Buffer vollständig unsichtbar und stack-gekapselt.
• Lebenszyklus- & Upgrade-Restriktion (NvMResistantToChangedSw):
  • Der Parameter NvMStaticBlockIDCheck darf nach Serienanlauf / Flashen von Kundendaten nicht mehr geändert werden (Konsistenzanforderung der AUTOSAR NV Data Handling Guidelines).
  • Eine nachträgliche Aktivierung verschiebt die Nutzdaten-Payload um 2 Byte; bereits im Feld geschriebene Bestandsdaten werden inkompatibel und führen zwingend zu NVM_E_WRONG_BLOCK_ID oder CRC-Fehlern.
• Funktionale Sicherheit (ISO 26262):
  • Dient als normative Maßnahme zur Beherrschung systematischer und zufälliger Hardwarefehler (Address Line Corruption, Aliasing, fehlerhafte Flash-Emulations-Routingtabellen) für Sicherheitsziele bis ASIL D.