Figure 4.2: Overview of Implicit synchronization

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptuelles Datenfluss- und Architektur-Blockschaltbild (Prinzipdarstellung).
• Funktionale Einordnung: AUTOSAR Classic Platform (CP), Speichersubsystem (BSW Memory Stack / NvM).
• Technischer Zweck: Gegenüberstellung von Anwendungs- und Treiber-/BSW-Speicherdomänen zur Verdeutlichung der impliziten Synchronisation (NvMBlockUseSyncMechanism == FALSE). Dargestellt ist der direkte, ungepufferte Datenaustausch zwischen dem permanenten RAM-Puffer der Applikation (APPLICATION RAM) und dem nicht-flüchtigen Speicherblock (MEMORY STACK), im Gegensatz zur spiegelbasierten expliziten Synchronisation.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Speicherdomänen:
  • APPLICATION RAM (Domain): Adressraum der Applikationsebene (SW-C / RTE).
    • RAM (Datenstruktur): Permanenter Anwendungs-RAM-Block (Permanent RAM Block). Dieser ist im NvM-Modul über den Konfigurationsparameter NvMRamBlockDataAddress direkt referenziert bzw. wird über RTE-generierte Puffer der SW-C bereitgestellt.
  • MEMORY STACK (Domain): AUTOSAR BSW-Speicherstapel, bestehend aus NVRAM Manager (NvM), Memory Abstraction Interface (MemIf), Memory Extraction/EEPROM/Flash Drivers (Fee/Ea, Fls/Eep).
    • NV Block (Logische Entität): Abstrahierter, persistenter Datensatz im Flash/EEPROM, verwaltet durch die Block-Deskriptor-Tabelle des NvM.
• Schnittstellen & Datenpfade (Gerichtete Relationen):
  • Write (RAM → NV Block): Direkter Lesezugriff des Memory Stacks auf das Application-RAM zur asynchronen Programmierung des nicht-flüchtigen Speichers.
  • Read (NV Block → RAM): Direktes Schreiben der aus dem NV-Speicher gelesenen Nutzdaten durch den Memory Stack in den Application-RAM-Puffer.
  • Architekturelles Merkmal: Vollständiger Verzicht auf einen NvM-internen Spiegelpuffer (NvM Mirror) sowie Entfall der Synchronisations-Callbacks (NvM_ReadRamBlockFromNvM, NvM_WriteRamBlockToNvM).

3. Dynamisches Verhalten & Sequenzablauf

• Trigger & Auftragsinitiierung:
  • Read-Pfad: Ausgelöst durch NvM_ReadBlock() (Single Block) oder NvM_ReadAll() während des ECU-Startups (EcuM / BswM). Der NvM liest über MemIf die Rohdaten, validiert optionale CRCs/Header und schreibt die Nutzdaten direkt nach APPLICATION RAM.
  • Write-Pfad: Ausgelöst durch NvM_WriteBlock() (Single Block) oder NvM_WriteAll() während des Shutdowns. Der NvM greift während der Hintergrundprogrammierung zyklisch (NvM_MainFunction()) direkt auf APPLICATION RAM zu, berechnet die Prüfsumme und übergibt die Datenblöcke sequenziell an die unteren Treiber.
• Asynchroner Ablauf & Zustandsüberwachung:
  • Nach Übergabe des Auftrags wechselt der Blockstatus auf NVM_REQ_PENDING.
  • Die Terminierung erfolgt asynchron; Benachrichtigung über NvM_SingleBlockCallbackFunction oder Polling mittels NvM_GetErrorStatus().
• Abbruch- und Fehlerbedingungen:
  • Tritt ein Hardware-Fehler (z. B. Write/Read Verification Failure, CRC-Fehler) auf, bricht der Stack ab, meldet NVM_REQ_NOT_OK an den Aufrufer und setzt ggf. ein Dem-Event (NVM_E_REQ_FAILED).

4. Normative Relevanz & Entwickler-Hinweise

• NvM-Konfiguration:
  • Erfordert NvMBlockUseSyncMechanism = FALSE im betreffenden NvMBlockDescriptor.
  • NvMRamBlockDataAddress muss auf ein gültiges, dauerhaft allokiertes RAM-Segment zeigen (oder NULL_PTR, falls das RAM über temporäre API-Zeiger übergeben wird).
• Datenkonsistenz & Concurrency-Gefahr (Tearing):
  • Kritische Restriktion: Während ein Write-Auftrag aktiv ist (NVM_REQ_PENDING), darf die Applikation nicht schreibend auf den APPLICATION RAM-Block zugreifen.
  • Da Flash-Programmierzyklen viele Millisekunden dauern und preemption-fähig über NvM_MainFunction() ablaufen, führt eine Modifikation durch eine höherpriore SW-C-Task unweigerlich zu inkonsistenten Daten im Flash (Data Tearing) oder zu einem CRC-Fehlabgleich beim späteren Auslesen.
• Architektur-Entscheidung (Implicit vs. Explicit):
  • Implizit (dieses Diagramm): Minimaler RAM-Footprint (kein doppelter Puffer), keine Copy-Callbacks erforderlich. Geeignet für statische Kalibrierdaten, DTC-Records oder Blöcke, die nur bei ECU-Startup/Shutdown transferiert werden.
  • Explizit: Zwingend erforderlich, wenn SW-Cs den RAM-Puffer kontinuierlich nutzen und keine Schreibsperre während des asynchronen NvM-Schreibvorgangs tolerieren können.