Figure 9.12: Users of the State Management interfaces

1. Diagrammtyp & Architektur-Kontext

UML-Komponentendiagramm / Schnittstellenspezifikation der AUTOSAR Adaptive Platform (Release R23-11) mit dem Titel „Users of the State Management interfaces“. Das Diagramm zeigt die konsolidierten Dienstnutzer-Schnittstellen zwischen dem State Management (SM) und den interagierenden Plattform-Clustern Diagnostic Management (DM), Update and Configuration Management (UCM) sowie Platform Health Management (PHM).

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Functional Clusters:
  • Diagnostic Management («aapFunctionalCluster», daemon-based): Diagnose-Daemon, nun ausschließlich über Port-API an SM angebunden.
  • Update and Configuration Management («aapFunctionalCluster», daemon-based): Vollständig als Functional Cluster typisiert (ersetzt die frühere Bezeichnung UCM Subordinate).
  • Platform Health Management («aapFunctionalCluster», daemon-based): Daemon zur Plattformüberwachung.
  • State Management («aapFunctionalCluster», daemon-based): Zentraler Provider aller angebotenen Schnittstellen via «aapProvidedPort».
• Schnittstellen & Operationen:
  • EcuResetRequest («aapPortInterface,aapAPI»): Port-Interface für DM mit:
    • + EnableRapidShutdown()
    • + ExecuteReset()
    • + Offer()
    • + RequestReset()
    • + StopOffer()
  • UpdateRequest («aapAraComServiceInterface,aapInterface»): Dienstschnittstelle («aapAccessControlled, aapServiceMethods») für UCM mit:
    • + PrepareRollback(), + PrepareUpdate(), + RequestUpdateSession(), + ResetMachine(), + StopUpdateSession(), + VerifyUpdate()
  • RecoveryAction («aapPortInterface,aapAPI»): Reduziertes Port-Interface für PHM mit:
    • + Offer(), + StopOffer()
    • «aapCallbackMethod» + RecoveryHandler()
    • (Hinweis: GetGlobalSupervisionStatus() entfällt gegenüber R22-11).
• Port-Beziehungen:
  • DM nutzt EcuResetRequest über «use» / «aapRequiredPort».
  • UCM nutzt UpdateRequest über «use» / «aapRequiredPort».
  • PHM nutzt RecoveryAction über «use» / «aapRequiredPort».
  • SM stellt alle Schnittstellen über «aapProvidedPort» bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Diagnose-Reset: DM leitet externe Diagnose-Reset-Anfragen über EcuResetRequest::RequestReset() oder ExecuteReset() an SM weiter. SM fährt Prozesse und Funktionsgruppen herunter und vollzieht den Reset.
2. Software-Update: UCM fordert via UpdateRequest::RequestUpdateSession() eine Update-Session an, bereitet Software-Container über PrepareUpdate() vor und validiert diese über VerifyUpdate(). Der Systemneustart wird über ResetMachine() getriggert; bei Fehlern initiiert PrepareRollback() das Zurücksetzen.
3. Fehlererholung: Bei Überwachungsausfällen ruft PHM die Callback-Methode RecoveryAction::RecoveryHandler() auf. SM führt die konfigurierte Erholungsmaßnahme (z. B. Zustandswechsel oder Prozessneustart) durch.

4. Normative Relevanz & Entwickler-Hinweise

• Die redundante Schnittstelle DiagnosticReset (ara::com) wurde gestrichen; Reset-Anforderungen aus der Diagnose laufen nun normativ einheitlich über das API-Port-Interface EcuResetRequest.
• In RecoveryAction entfällt die Polling-Methode GetGlobalSupervisionStatus(); die Fehlerbehandlung zwischen PHM und SM ist nun rein reaktiv bzw. eventgetrieben über den Callback RecoveryHandler().
• Die formale Aufwertung von UCM zum vollständigen «aapFunctionalCluster» Update and Configuration Management schließt die Standardisierung der Nomenklatur ab. UpdateRequest erfordert unverändert strikte Zugriffskontrolle («aapAccessControlled») via IAM.