Figure 18: UML sequence diagram for cancellation of asynchronous call

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd Cancellation of a Multi-Block Request).
• Funktionale Einordnung: AUTOSAR Classic Platform, Basic Software (BSW), Services Layer, Speichermanagement (NvM) im Zusammenspiel mit dem System Management (EcuM) und dem OS/BSW-Scheduler.
• Technischer Zweck: Spezifikation des deterministischen und nicht-destruktiven Abbruchverhaltens eines laufenden asynchronen Multi-Block-Schreibvorgangs (NvM_WriteAll) infolge eines Abbruchtriggers (z. B. Wake-up-Event während der Shutdown-Phase der ECU).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • BSW Task (OS task or cyclic call): Zyklischer Ausführungskontext (OS-Task bzw. BSW-Scheduler / SchM) zur periodischen Abarbeitung der BSW-Zustandsmaschinen.
  • EcuM::EcuM: ECU State Manager (System Services); koordiniert ECU-Zustände (Startup, Run, PostRun, Sleep, Shutdown) und fungiert als Initiator der Multi-Block-Requests.
  • «module» NvM::NvM: NVRAM Manager; verwaltet NVRAM-Blockzustände, Schreib-/Lesequeues und die Interaktion mit dem Memory Abstraction Interface (MemIf).
• Schnittstellen & Funktionsaufrufe:
  • NvM_WriteAll(): Synchrone Service-Anforderung zur Einreihung des asynchronen Schreibauftrags aller validen RAM-Spiegel in den persistenten Speicher.
  • NvM_CancelWriteAll(): Synchroner Steueraufruf zum Request eines vorzeitigen Abbruchs des laufenden WriteAll-Vorgangs.
  • NvM_MainFunction(): Zyklischer Funktionsaufruf zur schrittweisen Weiterführung der internen NvM-Zustandsmaschine und Treiberansteuerung.
  • EcuM_CB_NfyNvMJobEnd(ServiceId,JobResult): Multi-Block-Ende-Callback an das EcuM zur Signalisierung des Job-Abschlusses mit Übergabe der Service-ID und des resultierenden Job-Ergebnisses (typischerweise NVM_REQ_CANCELED).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung WriteAll: EcuM ruft synchron NvM_WriteAll() auf. Der NvM registriert die Anforderung, setzt den globalen Multi-Block-Status auf NVM_REQ_PENDING und kehrt sofort zurück.
2. Start der Blockabarbeitung: Die BSW Task triggert die erste NvM_MainFunction(). Der NvM wechselt intern in die Schreibphase und initiiert das Schreiben des ersten fälligen NVRAM-Blocks über die unterlagerte Abstraktionsschicht (MemIf).
3. Abbruchanforderung: EcuM setzt den Aufruf NvM_CancelWriteAll(). Der NvM quittiert die Annahme des Abbruchwunsches synchron und setzt interne Abbruch-Flags.
4. Zyklische Weiterverarbeitung & Schutz vor Datenverlust (NvM_MainFunction):
   • Nicht-destruktiver Abschluss: Der zum Zeitpunkt des Abbruchs bereits in Abarbeitung befindliche NVRAM-Block wird vollständig und regulär bis zu seinem Ende geschrieben. Ein hartes Unterbrechen mitten im Schreibzugriff (Page-Programming auf Flash/EEPROM) ist ausgeschlossen.
   • Queue-Stopp: Nach erfolgreicher oder fehlerhafter Fertigstellung dieses aktuellen Blocks wird die Abarbeitung weiterer im Rahmen von NvM_WriteAll anstehender Blöcke verworfen.
5. Job-Terminierung & Benachrichtigung:
   • Sofern konfiguriert (NvMMultiBlockCallbackFunction), feuert der NvM aus dem Kontext der NvM_MainFunction() den Callback EcuM_CB_NfyNvMJobEnd(ServiceId,JobResult).
   • Die Rückmeldung signalisiert das Erreichen des Endzustands mit dem Statuswert NVM_REQ_CANCELED.
   • NvM_MainFunction() kehrt zur BSW-Task zurück; der Multi-Block-Job ist vollständig terminiert.

4. Normative Relevanz & Entwickler-Hinweise

• Keine Sofort-Terminierung / Latenz: NvM_CancelWriteAll() stoppt den Vorgang nicht unmittelbar. Entwickler dürfen die ECU nach dem Aufruf nicht direkt stromlos schalten oder resetten. Das EcuM muss aktiv auf das Callback EcuM_CB_NfyNvMJobEnd warten oder den Multi-Block-Status via NvM_GetErrorStatus(0, &Status) auf ungleich NVM_REQ_PENDING pollen.
• Worst-Case Shutdown-Delay: Die maximale Blockierschlupfzeit bis zum finalen Stopp entspricht der maximalen Schreib- und Verifikationsdauer des größten im Layout definierten NVRAM-Blocks inklusive Treiber-Overhead (MemIf/Fee/Fls bzw. Ea/Eep).
• Block-Inkonsistenz auf Datensatzebene: Blöcke, die vor dem Eintreffen von NvM_CancelWriteAll bereits verarbeitet wurden, enthalten persistiert neue Daten (NVM_REQ_OK). Noch nicht gestartete Blöcke behalten ihren vorherigen NV-Inhalt. Die Applikation bzw. das Systemdesign darf nach einem abgebrochenen Shutdown nicht von einem atomar einheitlichen Datensatzstand über alle Blöcke ausgehen.
• Konfigurationsabhängigkeit: Die Ausführung von EcuM_CB_NfyNvMJobEnd erfordert die korrekte Verknüpfung des Multi-Block-Callback-Parameters (NvMCommon/NvMMultiBlockCallbackFunction) in der NvM-Modulkonfiguration mit der entsprechenden EcuM-Callback-Routine.