Figure 14: UML sequence diagram NvM_GetErrorStatus

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (sd NvM_GetErrorStatus).
• Funktionale Einordnung: AUTOSAR Classic Platform, Basic Software (BSW), System Services Layer.
• Technischer Zweck: Visualisierung des synchronen Abfragedienstes für den Bearbeitungs- und Fehlerstatus eines NVRAM-Blocks (NvM_GetErrorStatus). Der NVRAM Manager (NvM) stellt damit oberen Schichten (Software Components bzw. BSW-Modulen) einen direkten Statuszugriff auf administrative Blockdaten bereit, ohne asynchrone Treiberoperationen (MemIf/FEE/EA) auszulösen.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Instanzen (Lifelines):
  • SW Component: Software-Komponente der Applikationsschicht (ASW) bzw. Service-Nutzer; gekoppelt über die RTE via Client-Server-Interface (NvMService bzw. NvM_Admin).
  • NvM::NvM: BSW-Modul NVRAM Manager (Kapselung der NVRAM-Dienste). Das Symbol in der unteren rechten Ecke der Lifeline-Kopfzeile kennzeichnet ein dekomponiertes bzw. verlinktes Teilsystem/Interaktionsfragment.
• Schnittstellen & Signaturen:
  • Aufruf: NvM_GetErrorStatus(NvM_BlockIdType BlockId, NvM_RequestResultType* RequestResultPtr)
    • BlockId (In): Eindeutige Kennung des NVRAM-Blocks (1 .. NvM_NumberOfBlockIds - 1; Block 0 ist Multi-Block).
    • RequestResultPtr (Out): Zeiger auf die Zielvariable zur Aufnahme des letzten Anfrageergebnisses (NvM_RequestResultType).
  • Rückgabewert (Return Message): Std_ReturnType (E_OK / E_NOT_OK).

3. Dynamisches Verhalten & Sequenzablauf

1. Aufruftrigger: Die SW Component initiiert den synchronen Funktionsaufruf NvM_GetErrorStatus blockierend über das RTE-Service-Interface (Client-Server) oder per direktem C-API-Call.
2. Interne Ausführung (NvM):
   • Prüfung: Validierung von Initialisierungszustand (NVM_UNINIT führt bei DET-Aktivierung zu NVM_E_UNINIT), Block-ID-Gültigkeit (NVM_E_PARAM_BLOCK_ID) und Gültigkeit des Übergabepointer (NVM_E_PARAM_DATA).
   • Datenzugriff: Direkter Lesezugriff auf das RAM-basierte administrative Block-Array (NvM_AdminBlockTable[BlockId].NvMResult). Es findet keine Kommunikation mit Hardware-Treibern (MemIf, Fee, Ea) statt.
   • Schreiboperation: Übertrag des aktuellen Status in die durch RequestResultPtr referenzierte Speicheradresse.
3. Rückkehr (Return Message): Synchrone Rückkehr der Ausführung an den Aufrufer mit Rückgabewert E_OK (bzw. E_NOT_OK bei fehlgeschlagener Plausibilisierung).

4. Normative Relevanz & Entwickler-Hinweise

• Synchroner Kontrakt: Die API ist strikt synchron und non-blocking bezüglich Flash/EEPROM-Laufzeiten. Sie darf aus Task-Kontexten aufgerufen werden, ohne Latenzen der Peripherietreiber zu erben.
• Mögliche Statuswerte (NvM_RequestResultType):
  • NVM_REQ_OK: Letzte asynchrone Operation (Read/Write/Restore/Validate) erfolgreich abgeschlossen.
  • NVM_REQ_NOT_OK: Letzte Operation fehlgeschlagen.
  • NVM_REQ_PENDING: Eine asynchrone Operation für diesen Block ist noch in der NvM-Queue oder in Bearbeitung.
  • NVM_REQ_INTEGRITY_FAILED: CRC-Fehler oder Redundanzprüfung fehlgeschlagen.
  • NVM_REQ_BLOCK_SKIPPED: Block wurde bei Multi-Block-Abarbeitung (NvM_ReadAll / NvM_WriteAll) übersprungen.
  • NVM_REQ_NV_INVALIDATED: Block wurde explizit über NvM_InvalidateNvBlock ungültig deklariert.
  • NVM_REQ_CANCELED: Anforderung wurde abgebrochen (z. B. via NvM_CancelJobs).
• Reentranz: Die Funktion ist reentrant ausgelegt. Bei nebenläufigem Zugriff auf denselben Block über unterschiedliche OS-Tasks muss der Aufrufer bzw. der NvM-Treiber atomare Lese-/Schreibzugriffe auf das administrative Zustandsfeld sicherstellen.
• Poling-Muster: Wird typischerweise zur Überwachung von asynchron gestarteten Aufträgen (NvM_ReadBlock, NvM_WriteBlock, NvM_EraseNvBlock) genutzt, falls keine asynchronen Job-Finished-Callbacks (NvM_SingleBlockCallbackFunction) konfiguriert sind.