Figure 9.12: Users of the State Management interfaces

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm und Schnittstellenarchitektur der AUTOSAR Adaptive Platform (AP), das die Rolle des State Management (SM) als Dienstanbieter und Koordinator für übergeordnete Plattform-Funktionscluster abbildet. Das Diagramm zeigt die serviceorientierte und ereignisgestützte Integration von Update and Configuration Management (UCM) sowie Platform Health Management (PHM) zur Durchführung von Software-Updates, Rollbacks und Notfall-/Wiederherstellungsaktionen (Recovery Actions).

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» State Management: Dämonbasierter Funktionscluster (daemon-based), stellt den Service UpdateRequest bereit («aapProvidedPort») und nutzt die RecoveryAction («use»).
• «aapFunctionalCluster» Update and Configuration Management: Dämonbasierter Funktionscluster (daemon-based), benötigt den Service UpdateRequest («aapRequiredPort», «use»).
• «aapFunctionalCluster» Platform Health Management: Dämonbasierter Funktionscluster (daemon-based), realisiert die Schnittstelle RecoveryAction.
• «aapAraComServiceInterface,aapInterface» UpdateRequest: Serviceorientierte Schnittstelle (ara::com) zwischen UCM und SM mit Zugriffskontrolle. Enthält im Field-Bereich («aapAccessControlled, aapServiceField») das Feld/Event + ResetMachineNotifier sowie im Methoden-Bereich («aapAccessControlled, aapServiceMethod») die Methoden + PrepareRollback(), + PrepareUpdate(), + RequestUpdateSession(), + ResetMachine(), + StopUpdateSession() und + VerifyUpdate().
• «aapPortInterface,aapAPI» RecoveryAction: Schnittstelle zur Handhabung von Überwachungsfehlern, realisiert durch PHM und genutzt durch SM. Enthält die Methoden + Offer() und + StopOffer() sowie die Rückrufmethode («aapCallbackMethod») + RecoveryHandler().

3. Dynamisches Verhalten & Sequenzablauf

1. Update-Ablauf: UCM öffnet eine Aktualisierungssitzung via RequestUpdateSession() an SM. Anschließend koordiniert UCM Vorbereitung und Durchführung über PrepareUpdate(), VerifyUpdate() und ggf. PrepareRollback(). SM führt die notwendigen Funktionsgruppenumschaltungen durch.
2. System-Reset: Zur Aktivierung modifizierter Softwarepakete ruft UCM ResetMachine() auf. SM steuert das Herunterfahren und informiert betroffene Cluster über das Event ResetMachineNotifier; nach Abschluss beendet UCM die Sitzung mit StopUpdateSession().
3. Health- und Fehlerbehandlung: PHM bietet die Recovery-Funktionalität über Offer() an (beendet via StopOffer()). Erkennt PHM eine Verletzung von Überwachungsbedingungen (z. B. Alive-/Deadline-Supervision), löst es den registrierten RecoveryHandler() in SM aus, woraufhin SM vordefinierte Degradations- oder Wiederherstellungsstrategien einleitet.

4. Normative Relevanz & Entwickler-Hinweise

Die UpdateRequest-Schnittstelle ist zwingend mit rollenbasierter Zugriffskontrolle («aapAccessControlled») zu versehen, um unautorisierte Manipulationen an Maschinenzuständen abzuwehren. Als ara::com-Service erfolgt die Kommunikation über IPC/SOME/IP, während RecoveryAction eine lokale Port-Interface-Kopplung darstellt. Bei der Implementierung des RecoveryHandler() müssen harte Zeitschranken (Fault Handling Time Interval, FHTI nach ISO 26262) eingehalten werden, da hierüber funktionale Notlaufmaßnahmen der Adaptive Platform gesteuert werden.