Figure 9.2: Sequence diagram of "Ea_Write" service

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit Aktivierungsbalken, synchronen Aufrufen, asynchronen Zyklen und kombiniertem Fragment loop).
• Funktionale Einordnung: AUTOSAR Classic Platform (Release R23-11), NVRAM-Stack / Memory-Subsystem. Das Diagramm spezifiziert den vollständigen Lebenszyklus eines asynchronen Schreibauftrags (Ea_Write) über die Schichten des modernisierten AUTOSAR-Speicherstapels (Einführung des MemAcc-Moduls als Vermittler zwischen Abstraktionsschicht und vereinheitlichten Mem-Treibern).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Software-Module:

• «module» NvM (Non-Volatile RAM Manager): Applikationsnaher BSW-Dienst (Service Layer); verwaltet NV-Datenblöcke, initiiert Aufträge und empfängt Fertigstellungsmeldungen.
• «module» MemIf (Memory Abstraction Interface): Abstraktionsschnittstelle (ECU Abstraction Layer); leitet Zugriffe anhand des konfigurierten DeviceIndex an die konkrete Abstraktionsinstanz (Ea oder Fee) weiter.
• «module» Ea (EEPROM Abstraction): Spezifische Abstraktionsschicht für EEPROM-Speicher; mappt logische Blocknummern auf virtuelle Adressen/Instanzen des Speicherbereichs.
• «module» MemAcc (Memory Access): Zentraler Arbitrierungs- und Adressierungs-Broker (ECU Abstraction Layer, eingeführt ab R21-11/R22-11); steuert hardwareunabhängig Zugriffe auf segmentierte Adressräume (AddressAreaId).
• «module» Mem: Einheitlicher MCAL-Treiber (Memory Driver); kapselt den direkten Hardwarezugriff auf den physikalischen Speicher.
• BSW Task (OS task or cyclic call): Präemptiver oder kooperativer Betriebssystem-Task-Kontext für die zyklische Ausführung der BSW-Main-Functions.

Dargestellte APIs & Signaturen:

• Auftragserteilung:
  • MemIf_Write(Std_ReturnType, uint16 DeviceIndex, uint16 BlockNumber, const uint8* DataPtr)
  • Ea_Write(Std_ReturnType, uint16 BlockNumber, const uint8* DataPtr)
  • MemAcc_Write(Std_ReturnType, MemAcc_AddressAreaIdType AddressAreaId, MemAcc_AddressType Address, const MemAcc_DataType* DataPtr, MemAcc_LengthType Length)
  • Mem_Write(Std_ReturnType, Mem_InstanceIdType InstanceId, Mem_AddressType Address, const Mem_DataType* DataPtr, Mem_LengthType Length)
• Zyklische Verarbeitung & Status-Abfrage:
  • Ea_MainFunction(void)
  • MemAcc_MainFunction(void)
  • Mem_MainFunction(void)
  • Mem_GetJobResult(Mem_JobResultType, Mem_InstanceIdType InstanceId)
• Asynchrone Rückmeldungen (Callbacks):
  • Ea_JobEndNotification(void)
  • NvM_JobEndNotification(void)

3. Dynamisches Verhalten & Sequenzablauf

1. Job-Initiierung (Synchroner Abstieg, Top-Down):
   • NvM ruft MemIf_Write() auf, welches den Aufruf an Ea_Write() delegiert.
   • Ea_Write() validiert den Request, puffert interne Metadaten, wechselt in den Zustand Busy und liefert unmittelbar E_OK via MemIf_Write() an NvM zurück (nicht-blockierende Annahme).
2. Auftragstranslation & Dispatch an MemAcc:
   • Der BSW Task triggert periodisch Ea_MainFunction().
   • Ea berechnet aus der logischen Blocknummer die Adressparameter und setzt den Schreibauftrag über MemAcc_Write() ab. MemAcc_Write() quittiert synchron mit E_OK.
3. Treiber-Interaktion & Polling-Schleife (loop MemAcc_MainFunction):
   • Der BSW Task ruft zyklisch MemAcc_MainFunction() auf.
   • Im ersten Zyklus leitet MemAcc die physische Transaktion via Mem_Write() an den MCAL-Treiber Mem weiter.
   • In Folgezyklen steuert MemAcc_MainFunction() die Treiberabarbeitung:
     • Aufruf von Mem_MainFunction() zur internen Zustandsfortschreibung der Hardware.
     • Polling des Verarbeitungsstatus über Mem_GetJobResult(InstanceId).
   • Der Loop terminiert, sobald Mem_GetJobResult() den Status MEM_JOB_OK (oder einen Fehlercode) zurückgibt.
4. Kaskadierte Fertigstellungs-Benachrichtigung (Bottom-Up):
   • Nach erfolgreichem Treiber-Abschluss ruft MemAcc_MainFunction() den Callback Ea_JobEndNotification() auf.
   • Ea aktualisiert seinen Blockstatus und benachrichtigt wiederum die Service-Schicht über NvM_JobEndNotification().
   • Rückkehr der Callbacks und finaler Abschluss des Zyklus von MemAcc_MainFunction().

4. Normative Relevanz & Entwickler-Hinweise

• Asynchroner API-Vertrag: Der Rückgabewert E_OK von Ea_Write() garantiert ausschließlich die Annahme des Auftrags in die Warteschlange, nicht den physikalischen Schreibvorgang.
• Puffer-Integrität (DataPtr): Da keine zwingende Kopie im RAM der Abstraktionsschichten erfolgt, muss der Applikations-/NvM-Datenpuffer (DataPtr) über den gesamten asynchronen Zyklus bis zum Eintreffen der NvM_JobEndNotification() statisch gültig und unverändert bleiben.
• Task-Scheduling & Latenzen:
  • Die Durchlaufzeit (Job Processing Time) hängt direkt von den Ausführungsperioden des BSW Task für Ea_MainFunction(), MemAcc_MainFunction() und der hardwareabhängigen Programmierzeit im Mem-Treiber ab.
  • Das Diagramm zeigt, dass MemAcc_MainFunction die Mem_MainFunction direkt aufrufen kann (oder sequenziell im gleichen Task eingebettet ist). Ist Mem_MainFunction separat im OS geschedult, verlängert sich die Latenz pro Schleifendurchlauf um die Task-Offset-Zeiten.
• R23-11 MemAcc-Architekturübergang: Klassische Architekturen (Direktkopplung Ea -> Eep) sind hier vollständig durch das standardisierte Subsystem MemAcc abgelöst. Ea adressiert keine MCAL-Treiber-APIs mehr direkt, sondern nutzt vereinheitlichte MemAcc_AddressAreaIdType-Identifier.
• Fehlerbehandlung: Bricht Mem_GetJobResult() mit einem Fehler (MEM_JOB_FAILED) ab, muss MemAcc entsprechend Ea_JobErrorNotification() (nicht im Erfolgsdiagramm dargestellt) triggern, um NvM den Fehlerzustand zwecks Retry oder Redundanzumschaltung zu signalisieren.