Figure 9.11: NvM interraction with BswM for a multiblock operation

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaction Diagram / zeitlicher Ablauf mit Loops und Interaktionsrahmen).
• Technischer Zweck & Einordnung: Spezifikation des Zusammenspiels zwischen NVRAM Manager (NvM), Basic Software Manager (BswM) und dem NvM-Benutzer (z. B. EcuM, BswM selbst oder Anwendungs-SWCs) während der asynchronen Abarbeitung einer Multi-Block-Operation (z. B. NvM_ReadAll, NvM_WriteAll, NvM_ValidateAll, NvM_FirstInitAll).
• Architektur-Kontext: Dient der Synchronisation des BSW-Modusmanagements (BswM Mode Arbitration / Rule Evaluation) mit dem Fortschritt der nicht-flüchtigen Speicherverwaltung auf Gesamtjob- sowie Einzelblockebene zur Steuerung von ECU-Zustandsübergängen (z. B. Startup Phase II, Shutdown, Sleep).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Entitäten (Lifelines)

• BSW Task (OS task or cyclic call): Periodischer Betriebssystem-Task-Kontext zur zyklischen Ausführung der BSW-Main-Funktionen.
• «module» BswM: AUTOSAR Basic Software Manager (Mode Management, Regelauswertung und Aktionsausführung).
• «module» NvM: AUTOSAR NVRAM Manager (Verwaltung des nicht-flüchtigen Speichers).
• NvM User: Aufrufer der Multi-Block-Anforderung (z. B. EcuM während Startup/Shutdown oder Diagnosedienst).

Verwendete Schnittstellen & APIs

• User → NvM (Synchroner Request):
  • Multi Block Request(): Repräsentiert asynchrone Multi-Block-APIs wie NvM_ReadAll(), NvM_WriteAll(), NvM_CancelWriteAll() etc.
• NvM → BswM (Modus-Indikationen / Status-Updates):
  • BswM_NvM_CurrentJobMode(MultiBlockRequest, JobResult): Meldet den Status des Gesamtjobs an den BswM (NVM_REQ_PENDING bei Start, MultiBlockJobResult wie NVM_REQ_OK, NVM_REQ_NOT_OK etc. bei Fertigstellung).
  • BswM_NvM_CurrentBlockMode(Block, JobResult): Meldet den Status eines individuellen NVRAM-Blocks an den BswM (NVM_REQ_PENDING zu Beginn der Blockverarbeitung, JobResult bei Abschluss des Blocks).
• BSW Task → NvM (Zyklische Ablaufsteuerung):
  • NvM_MainFunction(): Zyklischer Scheduler-Einsprungpunkt zur Weiterschaltung der internen NvM-Zustandsmaschine und Treiber-Interaktion (MemIf → Fee/Ea → Fls/Eep).
• NvM → NvM User (Callback):
  • SingleBlockCallback(BlockRequest, JobResult): Optionaler, blockbezogener Benachrichtigungs-Callback (NvMSingleBlockCallbackFunction), explizit beschränkt auf NvM_ReadAll.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialer Request (Synchrone Phase):
   • NvM User ruft Multi Block Request() auf.
   • NvM akzeptiert den Auftrag in die interne Warteschlange und setzt die Job-Indikation ab: BswM_NvM_CurrentJobMode(MultiBlockRequest, NVM_REQ_PENDING).
   • Rückkehr zum Aufrufer; der Auftrag verbleibt asynchron im Zustand Pending.
2. Äußere Schleife – Block-Iteration (loop For each block to be processed):
   • Für jeden konfigurierten Block, der Teil der Multi-Block-Anforderung ist:
     • Block-Start: NvM_MainFunction() wird durch den BSW-Task aufgerufen. NvM signalisiert dem BswM den Start des Blocks via BswM_NvM_CurrentBlockMode(Block, NVM_REQ_PENDING).
     • Innere Schleife – Asynchrone Treiberabarbeitung (loop While block is still being processed):
       • Wiederholte Aufrufe von NvM_MainFunction(). Die Low-Level-Treiber (EEPROM/Flash-Emulation) transferieren Daten schrittweise; der NvM verbleibt im blockinternen Wartezustand.
     • **Block-Abschluss (Block processing finishes in this call):**
       • In diesem NvM_MainFunction()-Zyklus detektiert der NvM das Ende der Blockoperation.
       • NvM meldet das Einzelergebnis an BswM via BswM_NvM_CurrentBlockMode(Block, JobResult).
       • NvM triggert (ausschließlich bei NvM_ReadAll) den konfigurierten Benutzer-Callback SingleBlockCallback(BlockRequest, JobResult).
3. **Multi-Block-Abschluss (Multi block operation finishes in this call):**
   • Nach Abarbeitung des letzten Blocks führt ein nachfolgender Aufruf von NvM_MainFunction() zum Gesamtabschluss.
   • NvM meldet das Gesamtresultat an den BswM via BswM_NvM_CurrentJobMode(MultiBlockRequest, MultiBlockJobResult).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsschalter (BswM-Kopplung):
  • Das Aufrufen von BswM_NvM_CurrentJobMode erfordert NvMBswMMultiBlockJobStatusInformation == TRUE.
  • Das Aufrufen von BswM_NvM_CurrentBlockMode erfordert NvMBswMBlockStatusInformation == TRUE am jeweiligen Blockdescriptor (NvMBlockDescriptor).
• BswM-Regelwerk & Mode Arbitration:
  • BswM nutzt diese Callbacks zur Auswertung von BswMNvMJobModeIndication und BswMNvMBlockModeIndication. Erst nach Empfang von BswM_NvM_CurrentJobMode(..., NVM_REQ_OK) darf der BswM beispielsweise von Startup zu Normalbetrieb (z. B. nach NvM_ReadAll) oder in die Sleep-/Power-Off-Sequenz (nach NvM_WriteAll) schalten.
• Task-Kontext & Reentranz-Restriktionen:
  • NvM_MainFunction() und die daraus synchron getriggerten Callbacks (BswM_NvM_*, SingleBlockCallback) laufen synchron im Kontext des BSW Task.
  • Achtung vor Blockaden: Weder BswM_NvM_* noch der SingleBlockCallback dürfen blockierende Operationen ausführen oder synchron blockierend auf weitere NvM-Jobs warten.
• Einschränkung von SingleBlockCallback bei Multi-Block-Jobs:
  • Durch die Notiz Only for NvM_ReadAll wird normativ festgelegt, dass SingleBlockCallback(BlockRequest, JobResult) während einer Multi-Block-Operation ausschließlich für NvM_ReadAll aufgerufen wird (nicht für Schreib- oder Validierungsoperationen). Zudem führt der Callback nun die konkrete Dienstanforderung (BlockRequest) als Parameter.
• Laufzeitverhalten & Granularität:
  • Jeder Block beansprucht mindestens zwei bis mehrere Zyklen der NvM_MainFunction(). Die Task-Zykluszeit der NvM_MainFunction bestimmt direkt die Gesamtlaufzeit von Multi-Block-Jobs (kritisch für Startup- und Shutdown-Budgets der ECU).