Figure 7.4: ROM block layout

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schematisches Speicher-Layout-Diagramm (Memory Block Layout) einer logischen AUTOSAR-Basissoftware-Speicherentität.
• Funktionale Einordnung: Verortet im NVRAM Manager (NvM) auf der Service-Ebene des AUTOSAR Classic Platform Basissoftware-Stacks (BSW).
• Technischer Zweck: Das Diagramm spezifiziert die interne Datenstruktur des ROM-Blocks als optionalen Bestandteil eines logischen NVRAM-Blocks (neben NV Block, RAM Block und Administrative Block nach SWS_NvM_00054). Es definiert den physischen Footprint für werkseitige Fallback- bzw. Initialisierungsdaten im nichtflüchtigen Programmspeicher (Flash/ROM).

2. Komponenten, Entitäten & Schnittstellen

• Dargestellte Entitäten:
  • ROM Block: Logische Speichereinheit im Flash- bzw. ROM-Bereich des Mikrocontrollers (SWS_NvM_00128).
  • ROM block data (default data): Reine Nutzdaten (Default-/Werksdaten) des NVRAM-Blocks.
• Architektonische Besonderheiten & Strukturgrenzen:
  • Keine Verwaltungsinformationen (Administrative Data): Im Gegensatz zum NV Block (Header, CRC) und RAM Block (optionaler RAM-CRC) enthält der ROM-Block weder Header noch Prüfsummen (CRC) (SWS_NvM_00136). Der Speicherbedarf im ROM entspricht exakt der konfigurierten Nutzdatenlänge NvMNvBlockLength (SWS_NvM_00135).
• Beziehungen & Kardinalitäten:
  • Existenz: Optional (0..1 je NVRAM-Block bei NVM_BLOCK_NATIVE und NVM_BLOCK_REDUNDANT; 0..N bei NVM_BLOCK_DATASET, gesteuert über NvMRomBlockNum) (SWS_NvM_00132).
  • Referenzierung: Statisch per Zeiger über den Konfigurationsparameter NvMRomBlockDataAddress im NvM-Deskriptor adressiert oder alternativ über NvMInitBlockCallback dynamisch synthetisiert.
  • Sharing: Ein ROM-Block darf von mehreren NVRAM-Blöcken geteilt werden (SWS_NvM_00134).

3. Dynamisches Verhalten & Sequenzablauf

Der ROM-Block nimmt nicht aktiv an Schreibzyklen teil, sondern dient ausschließlich als read-only Quelle zur Wiederherstellung von Datenkonsistenz:

1. Trigger zur Restauration in den RAM-Block:
   • Systemstart (NvM_ReadAll): Schlägt das Einlesen des NV-Blocks fehl (z. B. Integritätsfehler/CRC-Mismatch, NVRAM_BLOCK_CORRUPTED oder Block uninitialisiert NVRAM_BLOCK_INVALID), lädt der NvM automatisch die Daten aus dem ROM-Block in den zugeordneten RAM-Block (SWS_NvM_00133, SRS_Mem_08547).
   • Expliziter API-Request:
     • NvM_RestoreBlockDefaults(BlockId, NvM_DestPtr) (asynchron)
     • NvM_RestorePRAMBlockDefaults(BlockId) (asynchron für Permanent RAM Blocks)
   • Fehlertoleranz während Single-Block-Reads: Asynchroner Fallback bei Fehler in NvM_ReadBlock() bzw. NvM_ReadPRAMBlock(), wenn NvMBlockUseAutoValidation oder entsprechende Recovery-Mechanismen greifen.
2. Kopierpfad:
   • Liegt NvMRomBlockDataAddress != NULL vor, führt der NvM-Job einen synchronen Byte-Copy in den Arbeits-RAM-Puffer durch.
   • Ist stattdessen ein Callback konfiguriert (NvMInitBlockCallback), wird dieser aufgerufen, um den RAM-Block applikativ mit Default-Werten zu belegen.
3. Statusübergänge & Diagnoserückmeldung:
   • Bei erfolgreicher Restauration wechselt der Verwaltungsstatus des Blocks im Administrative Block auf NVRAM_VALID und NVRAM_CHANGED.
   • Bei unlesbarem ROM oder Zeigerkonfigurationsfehlern meldet der NvM NVM_REQ_NOT_OK an den Aufrufer sowie ggf. NVM_E_RESTORE_FAILED via DEM / DET.

4. Normative Relevanz & Entwickler-Hinweise

• Memory-Mapping & Compiler-Abstraktion:
  • ROM-Block-Datenstrukturen müssen im Linkerskript in ROM/Flash-Sektionen gemappt werden (z. B. via NVM_START_SEC_CONST_UNSPECIFIED).
  • Deklaration zwingend als const (bzw. CONST(..., NVM_CONST) gemäß AUTOSAR Memory Mapping).
• Alignment & Größenkongruenz:
  • Die Datenstruktur im ROM muss in Layout, Padding und Bytegröße exakt mit der Struktur des zugehörigen RAM-Blocks (NvMRamBlockDataAddress) übereinstimmen (sizeof(ROM_Data) == NvMNvBlockLength).
• RAM-Validierungs-Flagging beachten:
  • Nach Restauration aus dem ROM-Block gilt der Block im RAM als geändert (NVRAM_CHANGED). Beim nächsten NvM_WriteAll() (z. B. ECU-Shutdown) oder explizitem NvM_WriteBlock() werden diese Default-Werte persistent in das EEPROM/Flash geschrieben, um den defekten/uninitialisierten NV-Block permanent zu heilen.
• Speicheroptimierung (Design-Entscheidung):
  • Da keine Prüfsummen oder Block-IDs im ROM-Block hinterlegt sind, kann derselbe ROM-Default-Puffer über NvMRomBlockDataAddress von mehreren NVRAM-Blöcken referenziert werden, um Flash-Speicher zu sparen.