Figure 13: UML sequence diagram NvM_SetBlockProtection

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm (sd NvM_SetBlockProtection), formale Interaktionssicht (Interaction View).
• Architektur-Ebene: AUTOSAR Classic Platform, Basic Software (BSW), Schicht der Speicherdienste (Memory Services).
• Funktionaler Kontext: Modellierung des synchronen Kontrollflusses zur Laufzeitkonfiguration des Schreibschutzes (Write Protection) eines dedizierten NVRAM-Blocks durch eine übergeordnete Software-Komponente.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Akteure:
  • Generic Elements::NvM User: Aufrufende Benutzerentität (z. B. SW-C via RTE oder BSW-Dienst) innerhalb des Pakets Generic Elements.
  • «module» NvM::NvM: BSW-Modul NVRAM Manager mit Stereotyp «module» und Dekompositionssymbol oo.
• Schnittstellensignatur:
  • Aufruf: NvM_SetBlockProtection(BlockId, ProtectionEnabled)
    • BlockId (NvM_BlockIdType): Eindeutige numerische Kennung des logischen NVRAM-Blocks.
    • ProtectionEnabled (boolean): Boolesches Flag (TRUE = Schreibschutz aktivieren, FALSE = Schreibschutz deaktivieren).
  • Rücksprung: Synchrone Rückmeldung (NvM_SetBlockProtection), liefert typkonform Std_ReturnType (E_OK / E_NOT_OK).
• Zusätzliche Diagrammelemente:
  • Notizkasten mit Metadatenfeldern zur Spezifikationsverfolgung (Status: Proposed by TO as per NvM SWS 1.44, Description:, Comments:).

3. Dynamisches Verhalten & Sequenzablauf

1. Aufruf: Die SW Component führt den synchronen Funktionsaufruf NvM_SetBlockProtection(BlockID, ProtectionEnabled) aus und blockiert ihren lokalen Kontrollfluss für die Dauer der Bearbeitung.
2. Interne Zustandsänderung:
   • Die Ausführung erfolgt unmittelbar und blockierend im Task-Kontext des Aufrufers.
   • Der NvM reiht keinen Auftrag in die asynchrone Job-Queue ein und triggert keine Operationen in der darunterliegenden Memory Hardware Abstraction (MemIf, Fls, Eep).
   • Es wird ausschließlich das administrative Attributbit für den Schreibschutz im RAM-Verwaltungsblock (NvM_AdminBlockType) des adressierten Blocks gesetzt oder zurückgesetzt.
3. Abschluss & Rücksprung: Das Modul quittiert den Aufruf mit Rückgabe des Statuscodes (E_OK bzw. Fehlercode) und gibt den Thread an die SW Component zurück.
4. Fehlerbedingungen & DET-Checks:
   • Abweisung mit E_NOT_OK und DET-Meldung NVM_E_NOT_INITIALIZED, falls der NvM noch nicht initialisiert ist.
   • NVM_E_PARAM_BLOCK_ID, falls BlockID außerhalb des konfigurierten Wertebereichs liegt.
   • NVM_E_BLOCK_PENDING, falls für den adressierten Block zeitgleich ein asynchroner Lese-, Schreib- oder Löschauftrag aktiv ist.
   • Verhinderung der Deaktivierung (ProtectionEnabled = FALSE), wenn der Block per Konfiguration mit NvMWriteBlockOnce = TRUE definiert wurde und bereits mindestens einmal persistent geschrieben ist.

4. Normative Relevanz & Entwickler-Hinweise

• API-Eigenschaften: Reentrant für unterschiedliche BlockIDs, non-reentrant für dieselbe BlockID. Da rein synchron, entfällt das Polling über NvM_GetErrorStatus() sowie Callback-Mechanismen (JobEnd-/JobError-Notifications).
• Keine Kopplung an NvM_MainFunction: Der Schutzstatus ist unmittelbar nach Rückkehr der Funktion gültig und nicht an den Schedule-Zyklus der zyklischen BSW-Main-Function gebunden.
• Effekt auf Folgeoperationen:
  • Ist der Schutz aktiv (TRUE), schlagen nachfolgende Schreibaufträge (NvM_WriteBlock, NvM_WritePRAMBlock) bereits in der Validierungsphase mit E_NOT_OK fehl.
  • Beim Herunterfahren des Steuergeräts (NvM_WriteAll) werden schreibgeschützte Blöcke im NV-Speicher übersprungen.
• RTE-/SWC-Integration: Für Applikations-SWCs wird dieser Dienst über ein Client-Server-Interface (NvM_Admin bzw. NvM_Service mit Operation SetBlockProtection) angebunden. Der aufrufende RTE-Port muss synchron (Rte_Call) konfiguriert sein.