Figure 9.2: Write job

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit synchronen/asynchronen Funktionsaufrufen und Rückgaben).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Memory Stack (NVRAM Management).
• Funktionaler Zweck: Darstellung der asynchronen Auftragsabwicklung eines Schreibvorgangs (Write Job) über die Schichten Service Layer (NvM), Memory Abstraction Layer (Ea) und Microcontroller Abstraction Layer (Eep), getrieben durch einen zyklischen OS/BSW-Task.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Module:
  • BSW Task (OS task or cyclic call): Trägerkontext / Scheduler (SchM/OS) für die zyklische Ausführung des Treibers.
  • «module» NvM (NVRAM Manager): Applikationsnaher Dienst zur Verwaltung nichtflüchtiger Daten.
  • «module» Ea (EEPROM Abstraction): Speicherabstraktion (Teil des Memory Hardware Abstraction Layer / MemIf-Router), abstrahiert logische Blöcke auf physikalische Adressen.
  • «module» Eep (EEPROM Driver): MCAL-Treiber zur direkten Ansteuerung des internen/externen EEPROM-Controllers.
• Schnittstellen (APIs):
  • Ea_Write(uint16 BlockNumber, const uint8* DataBufferPtr): Initiiert Block-Schreiboperation in der Abstraktionsschicht.
  • Eep_Write(Eep_AddressType TargetAddress, const uint8* SourceAddressPtr, Eep_LengthType Length): Niederflurige Treiberschnittstelle zur Übergabe von Zieladresse, Quellpuffer und Datenlänge.
  • Eep_MainFunction(): Zyklische Scheduling-Funktion des EEPROM-Treibers zur schrittweisen Ausführung des Treibers.
  • Ea_JobEndNotification(): Callback vom Eep-Treiber an das Abstraktionsmodul Ea bei erfolgreichem Auftragsabschluss.
  • NvM_JobEndNotification(): Callback von Ea an den NvM zur Signalisierung des Gesamtauftragsendes.

3. Dynamisches Verhalten & Sequenzablauf

1. Auftragsinitiierung (synchron, nicht-blockierend):
   • NvM ruft synchron Ea_Write() auf, welches die Anfrage in physische Parameter übersetzt und synchron Eep_Write() aufruft.
   • Eep validiert die Parameter, speichert die Auftragsdaten intern, schaltet den Modulzustand auf MEMIF_BUSY und das Auftragsergebnis auf MEMIF_JOB_PENDING.
   • Eep_Write() quittiert mit E_OK und kehrt sofort über Ea an den NvM zurück. Der Aufruf blockiert die Aufrufer-Task nicht für die physische Schreibdauer.
2. Asynchrone Auftragsverarbeitung (zyklisch):
   • Der BSW Task ruft wiederholt in festem Raster Eep_MainFunction() auf.
   • Innerhalb jeder Iteration wird eine konfigurierte/hardwareabhängige Dateneinheit (Data Unit, z. B. Page-Size, 1 Byte, SPI/I2C-Burst) physikalisch an das EEPROM übertragen.
   • Bis zum Schreiben des letzten Datenpakets bleibt der Treiberstatus MEMIF_BUSY und das Ergebnis MEMIF_JOB_PENDING.
3. Auftragsabschluss & Benachrichtigungskette (im Kontext der letzten Eep_MainFunction()):
   • Nach Fertigstellung der finalen Dateneinheit (n) setzt Eep den Zustand zurück auf MEMIF_IDLE und das Ergebnis auf MEMIF_JOB_OK.
   • Sofern konfiguriert (EepJobEndNotification), ruft Eep synchron im Kontext der MainFunction den Callback Ea_JobEndNotification() auf.
   • Ea leitet die Benachrichtigung synchron über NvM_JobEndNotification() an den NvM weiter.
   • Die Rückkaskade schließt ab und Eep_MainFunction() terminiert.

4. Normative Relevanz & Entwickler-Hinweise

• Puffergültigkeit: Der an Eep_Write() übergebene Quellzeiger (const uint8* SourceAddressPtr) muss über die gesamte asynchrone Laufzeit bis zum Empfang der JobEndNotification unverändert und gültig im RAM verbleiben (keine transienten Stack-Variablen).
• Task-Kontext & Latenzen: Ea_JobEndNotification() und NvM_JobEndNotification() laufen direkt im Kontext des BSW Task (Scheduler der Eep_MainFunction()). Innerhalb dieser Callbacks dürfen keine langwierigen oder blockierenden Operationen ausgeführt werden, um das Task-Timing nicht zu verletzen.
• Konfigurationsabhängigkeit: Die Callback-Kette erfordert aktivierte Parameter (EepJobEndNotification bzw. EaJobEndNotification). Bei Deaktivierung (Polling-Modus) fragt der NvM den Status alternativ über MemIf_GetJobResult() ab.
• Reentrancy & Zustand: Solange der Treiber im Zustand MEMIF_BUSY ist, lehnen nachfolgende Aufrufe von Eep_Write(), Eep_Read() oder Eep_Erase() weitere Anfragen sofort mit E_NOT_OK ab und triggern ggf. den Det-Fehler EEP_E_BUSY.