Modul ara::sm — State Management

Das adaptive Cluster State Management steuert die systemweiten Betriebsmodi, Funktionsgruppenzustände und Software-Update-Phasen einer Adaptive Machine im Verbund mit Execution Management und UCM EXP SWArchitecture S. 51. Es verarbeitet Transitionstrigger deterministisch über konfigurierte Tabellen und Aktionslisten, meldet Zwischenzustände via StateMachineNotification und orchestriert Suspend-to-RAM über ein Hub-Satellite-Muster [SWS_SM_91107], [SWS_SM_81110]. Randbedingungen wie die strikte Prüfung auf Update-Freigaben und obligatorische ANY-Fehlerauffangpfade sichern den robusten Plattformbetrieb ab [SWS_SM_91108].

mehr ›

Das funktionale Cluster State Management (SM) fungiert in der AUTOSAR Adaptive Platform als zentraler Plattform-Daemon zur Steuerung von Maschinen- und Funktionsgruppenzuständen sowie Ausführungsmodi EXP SWArchitecture S. 51. Es trennt die fahrzeugspezifische Entscheidungslogik in Steuerungsapplikationen (SMControlApplication) strikt von der tatsächlichen Prozessverwaltung durch das Execution Management (EM) EXP PlatformDesign S. 40. Neben herstellereigenen Implementierungen stellt AUTOSAR einen standardisierten StateMachine-Ansatz bereit, in dem Transitionen über tabellarische Metamodelle und konfigurierte Aktionslisten verarbeitet werden SWS StateManagement S. 42.

Zustandsübergänge werden über die Methode RequestTransition des StateMachineService initiiert [SWS_SM_91107] und gegen die TransitionRequestTable validiert SWS StateManagement S. 44. Während der Abarbeitung der zugehörigen ActionList signalisiert das Notifikationsfeld CurrentState den Übergangswert "inTransition" an konsumierende Applikationen, bevor der Zielzustand nach vollständiger Quittierung publiziert wird [SWS_SM_91109], SWS StateManagement S. 67.

Sequenzdiagramm: Ablauf einer regulären Zustandstransition über StateMachineService und Benachrichtigung via StateMachineNotification. Quellen: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement S. 51

Zur Durchführung von Software-Updates stellt das State Management das Interface UpdateRequest für das Update and Configuration Management (UCM) bereit [SWS_SM_91102], EXP SWArchitecture S. 56. Nach Prüfung des applikativen Feldes UpdateAllowed koordiniert das Modul Vorbereitungs- (PrepareUpdate), Verifikations- (VerifyUpdate) oder Rollback-Schritte (PrepareRollback) sowie Maschinen-Neustarts via ResetMachine [SWS_SM_91100], [SWS_SM_91103], [SWS_SM_91108]. Für Energiesparmodi wie Suspend-to-RAM synchronisieren S2RHub und S2RSatellite das Einfrieren und Wiederanlaufen von Applikationen und Betriebssystem [SWS_SM_81010], [SWS_SM_81110], [SWS_SM_71001].

Im Fehlerfall garantieren die SmErrorDomain [SWS_SM_81247] sowie ein zwingender ANY-Auffangeintrag in der ErrorRecoveryTable, dass unvorhergesehene Ausführungsfehler aus Execution Management oder Platform Health Management deterministisch abgefangen und laufende Aktionen sofort in definierte Wiederherstellungszustände überführt werden SWS StateManagement S. 42.

mehr ›

Rolle und funktionale Systemgrenzen im Plattform-Verbund

Das funktionale Cluster State Management (SM) bildet in der AUTOSAR Adaptive Platform die zentrale Instanz zur Orchestrierung der systemweiten Betriebsmodi, Funktionsgruppen und Prozess-Lebenszyklen EXP SWArchitecture S. 51. Als autonomer Plattform-Daemon ausgeführt, entkoppelt das State Management die plattforminterne Zustandsausführung von der fahrzeug- und herstellerspezifischen Kontrolllogik, die typischerweise in einer eigenständigen Steuerungsanwendung (SMControlApplication) gekapselt ist EXP PlatformDesign S. 40. Während das State Management die logischen Zustandsentscheidungen trifft und validiert, delegiert es das physische Starten, Terminieren und Umschalten von Prozessen über den StateClient an das Execution Management (EM) SWS StateManagement S. 40.

Architektonisch stützt sich das Modul auf eine duale Integrationsphilosophie: Integratoren können entweder den standardisierten, manifestbasierten StateMachine-Ansatz des Plattform-Stacks einsetzen oder eine vollständig herstellereigene Zustandslogik implementieren, da die Schnittstellen zum State Management öffentlich gehalten sind SWS StateManagement S. 42. Im standardisierten Ansatz reagiert das State Management deterministisch auf externe Trigger aus Steuerungsanwendungen, Fehlermeldungen des Platform Health Management (PHM) sowie Netzzustandswechsel des Network Management (NM) SWS StateManagement S. 45. Zudem bildet das State Management die maßgebliche Kontrollinstanz für Software-Aktualisierungen durch das Update and Configuration Management (UCM) EXP SWArchitecture S. 56.

Kontextdiagramm: Einbettung des Functional Clusters State Management im AUTOSAR-Adaptive-Systemverbund. Quellen: EXP PlatformDesign S. 40, SWS StateManagement S. 28

Zustandsübergänge und Steuerung über die StateMachineService-Schnittstelle

Zur Initiierung von Zustandsänderungen stellt das State Management den dienstbasierten Service StateMachineService für jede konfigurierte Instanz einer StateMachine bereit SWS StateManagement S. 44. Die Applikation fordert eine Transition über die Servicemethode RequestTransition an [SWS_SM_91107]. Das State Management prüft diesen Request anhand einer statisch im Manifest hinterlegten TransitionRequestTable gegen den aktuellen Zustand der Zustandsmaschine SWS StateManagement S. 44. Ist der Übergang definiert, wird die Ausführung der aktuellen Aktionsliste (ActionList) gestoppt und der Wechsel zum Zielzustand eingeleitet SWS StateManagement S. 45.

Sobald eine Zustandstransition anläuft, setzt das State Management den Wert des Servicefeldes CurrentState der StateMachineNotification-Schnittstelle auf "inTransition" [SWS_SM_91109], SWS StateManagement S. 67. Dieser Übergangszustand signalisiert abhängigen Adaptive Applications über ara::com, dass eine Rekonfiguration des Systems im Gange ist EXP SWArchitecture S. 52. Innerhalb der Aktionslisten können Funktionsgruppen über SYNC-Elemente synchronisiert oder parallel geschaltet werden, um Abhängigkeiten exakt abzubilden SWS StateManagement S. 56. Erst nachdem alle ActionListItems vollständig abgearbeitet und die Ergebnisse gesammelt wurden, nimmt CurrentState den finalen Namen des neuen Zustands an SWS StateManagement S. 67.

Sequenzdiagramm: Ablauf einer regulären Zustandstransition über StateMachineService und Benachrichtigung via StateMachineNotification. Quellen: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement S. 51, EXP SWArchitecture S. 219

Zustandsdiagramm: Typischer Lebenszyklus und Übergangslogik einer StateMachine basierend auf der TransitionRequestTable. Quellen: EXP InterfacesGuidelines S. 22, SWS StateManagement S. 44

Orchestrierung von Software-Aktualisierungen im Zusammenspiel mit UCM

Im Rahmen von Software-Aktualisierungen übernimmt das State Management die Schnittstellenfunktion zwischen dem Update and Configuration Management (UCM) und den Ausführungszuständen der Maschine EXP SWArchitecture S. 142. Hierfür stellt das State Management das Interface UpdateRequest bereit, das pro Maschine maximal einmal instanziiert werden darf und exklusiv an den Prozess gebunden ist, der die Controller-Zustandsmaschine führt SWS StateManagement S. 79. Ein Update wird eingeleitet, indem UCM die Methode RequestUpdateSession aufruft [SWS_SM_91102]. Das State Management fällt die Entscheidung über die Zulässigkeit nicht autonom, sondern konsultiert das Servicefeld UpdateAllowed des UpdateAllowedService, das von der applikativen Kontrolllogik gesetzt wird [SWS_SM_91108], SWS StateManagement S. 81.

Wird die Sitzung genehmigt, markiert der Controller die betroffenen Zustandsautomaten als ImpactedByUpdate SWS StateManagement S. 81. Vor dem eigentlichen Einspielen ruft UCM PrepareUpdate mit der Liste der betroffenen Funktionsgruppen auf, woraufhin diese in inaktive Zustände überführt werden [SWS_SM_91103], PlatformDesign S. 58. Falls das Update einen Neustart erfordert, fordert UCM über die Fire-and-Forget-Methode ResetMachine einen geordneten Reset an, bei dem zuvor alle Daten gesichert werden müssen [SWS_SM_91100]. Das State Management informiert UCM über Statusänderungen während des Resets über das Feld ResetMachineNotifier [SWS_SM_91106], SWS StateManagement S. 92. Nach dem Neustart oder Update folgt die Verifikation über VerifyUpdate [SWS_SM_91104], SWS StateManagement S. 87. Schlägt die Prüfung fehl, bereitet PrepareRollback das Zurückrollen vor [SWS_SM_91105], SWS StateManagement S. 88. Der Abschluss des gesamten Zyklus wird mit StopUpdateSession quittiert [SWS_SM_91101], SWS StateManagement S. 79.

Sequenzdiagramm: Interaktionsablauf einer Software-Update-Sitzung zwischen UCM, State Management und Steuerungslogik. Quellen: [SWS_SM_91100], [SWS_SM_91102], [SWS_SM_91103], [SWS_SM_91104], SWS StateManagement S. 78

Energiemanagement und Suspend-to-RAM im Hub-Satellite-Verbund

Für erweiterte Energiemanagement-Funktionen wie Suspend-to-RAM (S2R) implementiert das State Management ein Hub-Satellite-Architekturmuster EXP SWArchitecture S. 54. Die zentrale Steuerungsinstanz im Plattform-Daemon nutzt die Klasse S2RHub [SWS_SM_81103], während partizipierende Adaptive Applications in ihrem eigenen Prozessraum Instanzen von S2RSatellite einbinden [SWS_SM_81003], [SWS_SM_81014], SWS StateManagement S. 35. Satelliten aktivieren ihre Bereitschaft zur Entgegennahme von Moduswechseln über Offer [SWS_SM_81012] bzw. deaktivieren sie via StopOffer [SWS_SM_81013]. Sie implementieren die rein virtuellen Methoden EnterSuspendMode [SWS_SM_81010] und LeaveSuspendMode [SWS_SM_81011] als Callback-Mechanismus zur Vorbereitung und Nachbereitung des Ruhezustands.

Wird ein Suspend-Vorgang eingeleitet, adressiert der S2RHub alle registrierten Satelliten asynchron über RequestToEnterSuspendMode mit einem konfigurierbaren Timeout [SWS_SM_81110]. Haben alle Satelliten ihre Ruhezustandsvorbereitungen erfolgreich abgeschlossen, veranlasst der Hub über EnterSuspendToRamOs den Eintritt des Betriebssystems in den Zustand des RAM-Erhaltens [SWS_SM_81112], SWS StateManagement S. 101. Auf der hardwarenahen OS-Wrapper-Ebene greift das State Management auf die apext::sm::PowerStateInterface zurück: Sie ermöglicht das Setzen hardwarenaher Betriebszustände über SetPowerState [SWS_SM_71001] anhand der Enumeration PowerState [SWS_SM_71002] sowie die Registrierung und Deregistrierung autonomer Aufweck-Handler über RegisterWakeUpHandler [SWS_SM_71003] und UnregisterWakeUpHandler [SWS_SM_71005] mit dem Funktionstyp WakeUpHandler [SWS_SM_71004], SWS StateManagement S. 105. Nach dem Aufwachen fordert der Hub über RequestToLeaveSuspendMode das koordinierte Wiederanlaufen aller Satelliten an [SWS_SM_81111].

Sequenzdiagramm: Zweiphasiger Ablauf beim Versetzen des Systems in Suspend-to-RAM und nachfolgendes Wiederaufwachen. Quellen: [SWS_SM_71001], [SWS_SM_81110], [SWS_SM_81112], SWS StateManagement S. 101

Verhalten im Fehlerfall

Das Modul definiert für eigene operationelle Fehler die SmErrorDomain [SWS_SM_81247], die über GetSmDomain abgerufen wird [SWS_SM_81251] und den Bezeichner "Sm" trägt [SWS_SM_81248]. Sie stellt Fehlerbeschreibungen bereit [SWS_SM_81249] und wandelt Codes im Ausnahmefall via ThrowAsException in eine SmException um [SWS_SM_81243], [SWS_SM_81250]. Über die Enumeration SmErrc werden spezifische Ausfallgründe typisiert, darunter kOfferFailed für Verbindungsabbrüche zum Plattform-Daemon und kCommunicationFailed für fehlschlagende Satellitenkommunikation [SWS_SM_81240], erzeugbar mittels MakeErrorCode [SWS_SM_81244].

Im Bereich der logischen Zustandsautomaten erzwingt das State Management eine lückenlose Fehlerbehandlung über die ErrorRecoveryTable SWS StateManagement S. 69. Jede Tabelle muss zwingend genau einen Eintrag mit dem Wert ANY aufweisen, der als deterministischer Auffangpfad für alle nicht explizit gemappten Ausführungsfehler dient SWS StateManagement S. 42, SWS StateManagement S. 69. Wird ein Fehler durch das Platform Health Management oder Execution Management gemeldet und ist die betroffene Zustandsmaschine nicht als ImpactedByUpdate markiert, setzt sie ein internes Flag für laufende Fehlerbehebung, bricht die aktuelle Aktionsliste unverzüglich ab und schaltet sofort in den parametrierten Wiederherstellungszustand um SWS StateManagement S. 42. Bei kritischen Fehlern des Execution Managements wie kIntegrityOrAuthenticityCheckFailed geht das State Management davon aus, dass die Vertrauenswürdigkeit der Plattform kompromittiert ist und nachfolgende Requests fehlschlagen, weshalb Korrekturmaßnahmen außerhalb des Clusters liegen SWS StateManagement S. 40.

Aktivitätsdiagramm: Entscheidungs- und Verarbeitungsablauf bei eingehenden Ausführungsfehlern und Auswertung der ErrorRecoveryTable. Quellen: SWS StateManagement S. 42, SWS StateManagement S. 69

Weiterführende Detailbelege

Die Architektur und die Interaktionspfade des State Management sind durch die folgenden normativen Anforderungen und Designfestlegungen belegt:

• Systemsteuerung und Transitionen: [SWS_SM_91107] definiert die serviceorientierte Transitionsanforderung, während [SWS_SM_91109] das Notifikationsfeld zur Entkopplung von Applikationen regelt. Die tabellarische Steuerung wird durch SWS StateManagement S. 44 untermauert.
• Software-Update-Integration: Die Methoden zur Sitzungsführung [SWS_SM_91102], Vorbereitung [SWS_SM_91103], Verifikation [SWS_SM_91104], Rollback-Vorbereitung [SWS_SM_91105] und Beendigung [SWS_SM_91101] sowie Maschinen-Resets [SWS_SM_91100] und Freigabefelder [SWS_SM_91106], [SWS_SM_91108] fixieren das Zusammenwirken mit UCM gemäß EXP SWArchitecture S. 56.
• Suspend-to-RAM und Power-Management: Die native Klassen- und Schnittstellenhierarchie um S2RHub [SWS_SM_81103], [SWS_SM_81110], S2RSatellite [SWS_SM_81003], [SWS_SM_81010] und das Betriebssystem-Interface [SWS_SM_71001], [SWS_SM_71003] bilden das normative Fundament des Energiesparens EXP SWArchitecture S. 54.
• Fehlerraum: Die Ausgestaltung der standardisierten Fehlerdomäne mit Exception- und ErrorCode-Generatoren stützt sich auf [SWS_SM_81240], [SWS_SM_81244] und [SWS_SM_81247].