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):
  • NvM User: Nutzer des NVRAM Managers (vereinfachte Benennung ohne Paketpräfix).
  • «module» NvM: BSW-Modul NVRAM Manager mit Stereotyp «module» (ohne Namensraum-Präfix NvM::) und Dekompositionssymbol.
• Schnittstellen & Signaturen:
  • Aufruf: NvM_GetErrorStatus(NvM_BlockIdType, uint8*)
    • Parameter 1: NvM_BlockIdType (In) – Eindeutige Block-ID.
    • Parameter 2: uint8* (Out) – Zeiger auf eine 8-Bit-Variable zur Aufnahme des Fehlerstatus (Typbezeichnung uint8* anstelle von NvM_RequestResultType*).
  • Rückgabewert (Return Message): NvM_GetErrorStatus() – synchrone Rückmeldung an den Aufrufer mit Funktionsklammern ().
• Zusätzliche Diagrammelemente:
  • UML-Notiz (Note): Dokumentationsnotiz mit den Feldern Status: Proposed by TO as per NvM SWS 1.44, Description: und Comments:.

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.