Figure 9.14: Interfaces required by State Management

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm / Komponentenarchitektur-Diagramm der AUTOSAR Adaptive Platform (AAP). Das Diagramm modelliert die Port- und API-Schnittstellenbeziehungen, die vom Functional Cluster State Management gegenüber anderen Functional Clustern der Plattform konsumiert und implementiert bzw. bereitgestellt werden.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst fünf funktionale Cluster und vier Schnittstellenelemente:

• State Management («aapFunctionalCluster», daemon-based): Konsumierende Instanz; bindet über Abhängigkeitspfeile («use» / «aapRequiredPort») vier Schnittstellen ein:
  • SupervisedEntity («aapAPI,aapPortInterface»): Operation + ReportCheckpoint().
  • NetworkState_{NetworkHandle} («aapAraComServiceInterface,aapAPI»): Enthält die Service-Felder («aapAccessControlled, aapServiceField») + NetworkCurrentState und + NetworkRequestedState.
  • CommunicationControl («aapPortInterface,aapAPI»): Definiert die Operationen + CommCtrlRequest(), + Offer() und + StopOffer().
  • KeyValueStorage («aapAPI,aapPortInterface»): Definiert Operationen für die persistente Schlüssel-Wert-Speicherung: + DiscardPendingChanges(), + GetAllKeys(), + GetValue(), + KeyExists(), + RecoverKey(), + RemoveAllKeys(), + RemoveKey(), + ResetKey(), + SetValue(), + SyncToStorage().
• Gegenüberliegende Functional Cluster:
  • Platform Health Management («aapFunctionalCluster», daemon-based): Realisiert SupervisedEntity (gestrichelter Realisierungspfeil).
  • Network Management («aapFunctionalCluster»): Stellt über «aapProvidedPort» die Schnittstelle NetworkState_{NetworkHandle} bereit.
  • Diagnostic Management («aapFunctionalCluster...», daemon-based): Konsumiert über «use» / «aapRequiredPort» die Schnittstelle CommunicationControl.
  • Persistency («aapFunctionalClust...»): Realisiert KeyValueStorage (gestrichelter Realisierungspfeil).

3. Dynamisches Verhalten & Sequenzablauf

Statische Schnittstellendefinition ohne Sequenzablauf:

• State Management überwacht seine interne Ausführung durch periodisches oder ereignisbasiertes Melden von Kontrollpunkten (ReportCheckpoint()) an Platform Health Management.
• Das Cluster interagiert über NetworkState_{NetworkHandle} mit Network Management, um den aktuellen Netzwerkstatus (NetworkCurrentState) abzufragen und Zustandsänderungen (NetworkRequestedState) anzufordern.
• Über CommunicationControl werden Diagnose- und Kommunikationssteuerungsanfragen (CommCtrlRequest) gehandhabt sowie Dienste angeboten (Offer) bzw. beendet (StopOffer).
• Über KeyValueStorage werden Konfigurationsdaten und interne Zustände persistent abgelegt, synchronisiert (SyncToStorage) oder wiederhergestellt.

4. Normative Relevanz & Entwickler-Hinweise

Architekturvorgaben für Implementierer des State Management Daemons:

• Erfordert Schnittstellenanbindungen an Plattformdienste für Überwachung, Diagnose, Netzwerkverwaltung und Persistenz.
• Unterscheidung zwischen ara::com-basierten Service-Interfaces (NetworkState_{NetworkHandle}) und direkten C++- bzw. Port-APIs (SupervisedEntity, KeyValueStorage, CommunicationControl).
• State Management fungiert bei SupervisedEntity, NetworkState_{NetworkHandle} und KeyValueStorage als Client («aapRequiredPort»), während die Schnittstelle CommunicationControl zwischen State Management und Diagnostic Management genutzt wird.