Figure 5.2: Interfaces required by State Management from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodellierung mit Profil-Stereotypen «aapFunctionalCluster», «aapAPI,aapPortInterface», «aapRequiredPort», «use» und UML-Interface-Realisierung).
• Technischer Zweck: Spezifikation der ausgehenden Abhängigkeiten (Required Interfaces / RPorts) des Functional Clusters State Management (SM) gegenüber anderen Functional Clusters der AUTOSAR Adaptive Platform (AP) gemäß AUTOSAR AP R23-11 (AUTOSAR_AP_SWS_StateManagement, Kapitel 5.2).
• Funktionale Einordnung: State Management fungiert als zentraler, daemon-basierter System-Orchestrator der Machine. Zur Ausführung koordinierter Zustandsübergänge (Function Group States, Machine States), zur Einhaltung von Sicherheitsanforderungen und zur Zustandskonsolidierung benötigt SM dedizierte Basisdienste:
  • Platform Health Management (PHM): Alive-/Deadline-/Logical-Supervision des SM-Prozesses selbst.
  • Network Management (NM): Synchronisation von Kommunikations- und Busnetzwerkzuständen (Partial Networking / Network Handles).
  • Persistency (PER): Nicht-flüchtige Speicherung von State-Flags, Wiederanlaufparametern oder Fehlerspeichern via Key-Value-Storage.

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Functional Clusters («aapFunctionalCluster»)

• State Management (daemon-based): Der Client/Konsument der Schnittstellen. Bindet diese über Required Ports ein («aapRequiredPort», Beziehungsstereotyp «use»).
• Platform Health Management (daemon-based): Stellt Schnittstellen zur Überwachung bereit (Interface-Realisierung, gestrichelte Linie mit geschlossener Dreiecksspitze).
• Network Management (daemon-based): Provider für Netzwerk-Zustandsabfragen und -anforderungen; explizit als prozessbasierter Plattform-Daemon spezifiziert.
• Persistency (Library-basiert): Provider für NVRAM-/Filesystem-Abstraktion.

Port Interfaces («aapAPI,aapPortInterface») und Operationen

• SupervisedEntity (bereitgestellt durch PHM):
  • + ReportCheckpoint(): Meldet das Erreichen definierter Checkpoints innerhalb der State-Management-Zustandsmaschine an den PHM-Daemon zur Alive-, Deadline- und Logical-Flow-Überwachung.
• NetworkHandle (bereitgestellt durch NM):
  • + GetNetworkState(): Synchrones Auslesen des aktuellen physikalischen/logischen Busnetzwerk-Status.
  • + GetNetworkRequestedState(): Auslesen des aktuell lokal angeforderten Netzwerkstatus.
  • + SetNetworkRequestedState(): Anfordern oder Freigeben eines aktiven Netzwerkzustands (z. B. Vollkommunikation vs. Busruhe).
  • + RegisterNetworkStateChangeNotifier() / + UnregisterNetworkStateChangeNotifier(): Registrierung/Deregistrierung asynchroner Callbacks für externe Netzwerkzustandswechsel.
  • + RegisterNetworkRequestedStateChangeNotifier() / + UnregisterNetworkRequestedStateChangeNotifier(): Registrierung/Deregistrierung asynchroner Benachrichtigungen für Änderungen des angeforderten Status.
• KeyValueStorage (bereitgestellt durch Persistency):
  • + DiscardPendingChanges(): Verwirft noch nicht persistierte Schreibvorgänge im Speicherpuffer.
  • + GetAllKeys(): Liefert eine Liste aller im Storage aktuell hinterlegten Schlüssel.
  • + GetCurrentValueSize(): Gibt die Größe des zu einem Schlüssel gespeicherten Datenwerts in Bytes zurück.
  • + GetValue(): Liest den Wert zu einem spezifizierten Schlüssel aus.
  • + KeyExists(): Prüft, ob ein gegebener Schlüssel im Storage existiert.
  • + RecoverKey(): Stellt einen beschädigten oder ungültigen Schlüsselwert wieder her.
  • + RemoveAllKeys(): Löscht alle im Key-Value-Storage enthaltenen Schlüssel und Werte.
  • + RemoveKey(): Entfernt einen einzelnen Schlüssel und dessen assoziierten Wert.
  • + ResetKey(): Setzt den Wert eines Schlüssels auf seinen konfigurierten Initialwert zurück.
  • + SetValue(): Speichert oder aktualisiert den Wert eines Schlüssels im Puffer.
  • + SyncToStorage(): Schreibt alle gepufferten Änderungen synchron auf das nicht-flüchtige Speichermedium.

3. Dynamisches Verhalten & Sequenzablauf

1. Bootstrapping & Initialisierung:
   • Nach dem Start durch Execution Management (EM) initialisiert SM seinen RPort auf KeyValueStorage (ara::per), prüft mit KeyExists() letzte Shutdown-/Reset-Ursachen oder Machine-State-Sollwerte (GetValue()) und entscheidet über den Ziel-Initialzustand.
   • SM registriert Event-Handler an NetworkHandle (RegisterNetworkStateChangeNotifier()) zur Überwachung externer Wakeup-Events.
2. Zyklischer Betrieb & Health Reporting:
   • In regulären Verarbeitungszyklen bzw. nach Abschluss kritischer Transitionsblöcke ruft SM synchron ReportCheckpoint() an SupervisedEntity (ara::phm) auf, um Deadlines einzuhalten.
3. Zustandsübergang (State Transition):
   • Trigger: Interne Trigger oder externe NM-Zustandsänderung (Signal über registrierten Notifier).
   • Aktion: SM fordert über SetNetworkRequestedState() die Busaktivierung bzw. Deaktivierung an.
   • Persistierung: Vor Transitionen in Low-Power-/Shutdown-Zustände schreibt SM Status-Flags via SetValue() und blockiert deterministisch auf SyncToStorage(), um Datenverlust bei Spannungsabfall zu verhindern.
   • Fehlerfall: Scheitert ein Zugriff auf den Storage (ara::core::Result enthält Fehlercode), erfolgt Fallback über RecoverKey() oder DiscardPendingChanges().

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und Manifest-Modellierung (ARXML):
  • Entwickler müssen im Adaptive Application Manifest des State Management Daemons drei RPortPrototypes modellieren, die auf die jeweiligen PortInterface-Definitionen typisiert sind (SupervisedEntityInterface, NetworkHandleInterface, PersistencyKeyValueDatabaseInterface).
  • Die Bindungen (ServiceInstanceToPortPrototypeMapping bzw. C++ Language Binding) erfolgen intern über Standard-ara::com-Mechanismen oder optimierte Shared-Memory/IPC-Implementierungen des Plattform-Herstellers.
• Thread-Safety & Blockierungsverhalten:
  • SyncToStorage() ist eine blockierende, I/O-intensive Operation; sie darf nicht im Kontext zeitkritischer Notifier-Callbacks von NM oder PHM aufgerufen werden, sondern erfordert ein asynchrones/entkoppeltes Worker-Thread-Design im SM.
  • ReportCheckpoint() besitzt harte Latenzanforderungen (Microsecond-Bereich) und ist vom PHM typischerweise lock-free via IPC/Shared Memory ausgelegt.
• Notifier-Lifecycle:
  • Jeder mit RegisterNetwork*Notifier() übergebene Callback muss vor Terminierung oder Deinitialisierung des SM explizit mittels UnregisterNetwork*Notifier() deregistriert werden, um Dangling-Pointer-Hazards im NM-Stack zu unterbinden.