namespace ara::sm

Der Namespace ara::sm stellt die domänenspezifische Fehlerbehandlung und Koordinationsstrukturen für das State Management in AUTOSAR Adaptive bereit (AUTOSAR_AP_SWS_StateManagement §7.5 S. 34). Er definiert über SmErrc, SmErrorDomain und MakeErrorCode standardisierte Mechanismen zur Erfassung von Kommunikationsfehlern, Timeouts und Ablehnungen bei synchronisierten Zustandsübergängen wie Suspend-to-RAM ([SWS_SM_81240], [SWS_SM_81244]). Eine maßgebliche Randbedingung ist die wechselseitige Ausschließlichkeit zwischen automatisierter Zustandsmaschinensteuerung und direktem API-Zugriff auf Koordinationsinstanzen ([SWS_SM_00684]).

mehr ›

Kontext

Der Namespace ara::sm bildet die fundamentale Schnittstelle für das Zustandsmanagement (State Management) der AUTOSAR Adaptive Platform und stellt Typen zur Fehlerbehandlung sowie zur Steuerung maschinenweiter Zustandskonfigurationen bereit. Neben der zentralen Fehlerdomäne SmErrorDomain und dem zugehörigen Ausnahmetyp SmException umfasst das Modul funktionale Mechanismen zur Synchronisation von Systemzuständen, insbesondere im Rahmen der Suspend-to-RAM-Funktionalität gemäß AUTOSAR_AP_SWS_StateManagement §7.5 „Interaction with Suspend-to-RAM Functionality“ S. 34. Zu den maßgeblichen Interaktionspartnern zählen Steuerungsanwendungen wie die SMControlApplication, der interne StateMachine-Controller des State-Management-Dämons sowie über Satelliten angebundene Prozesse (AUTOSAR_AP_SWS_StateManagement §7.5.1 „S2R Hub“ S. 35).

Die Architektur trennt strikt zwischen deklarativen Zustandsautomaten und programmatischer Steuerung: Folgt das System dem StateMachine-Ansatz, integriert die Steuerungsinstanz die Koordination intern, sodass externen Anwendungen der direkte Zugriff auf die C++-API des S2RHub verwehrt ist ([SWS_SM_00684]; AUTOSAR_AP_SWS_StateManagement §7.7.15 S. 96). Sicherheitsrelevante Interaktionen unterliegen zudem Prüfungen des Identity and Access Management (IAM), um sicherzustellen, dass nur autorisierte Prozesse Registrierungen vornehmen oder Zustandsänderungen anfordern dürfen ([SWS_SM_00706], [SWS_SM_00714], [SWS_SM_00715]).

Kontextdiagramm: Rollenverteilung und Interaktionspfade zwischen Steuerungsanwendung, State-Management-Daemon, Satelliten und Fehlerdomäne. Quellen: [SWS_SM_00684], [SWS_SM_00701], [SWS_SM_00710], [SWS_SM_81240], [SWS_SM_81251].

Nutzungspfad

Die typische Nutzung des Namespace gliedert sich in die Registrierung anwendungsseitiger Prozesse, die Auslösung koordinierter Übergänge und die Auswertung resultierender Fehlercodes. Für Prozesse, die über Suspend-to-RAM-Fähigkeiten verfügen, beginnt der Zyklus mit der Bereitstellung ihrer Schnittstelle über Offer ([SWS_SM_00710]). Vor dem Übergang des Betriebssystems in den Ruhezustand sendet die steuernde Instanz mittels RequestToEnterSuspendMode eine Aufforderung an alle registrierten Satelliten, woraufhin deren Callback EnterSuspendMode ausgelöst wird ([SWS_SM_00701], [SWS_SM_00711]).

Die koordinierende Funktion blockiert bzw. überwacht den Übergang, bis alle beteiligten Satelliten geantwortet haben oder abgemeldet wurden ([SWS_SM_00702]). Beim Aufwachen erfolgt analog der Aufruf von RequestToLeaveSuspendMode, welcher über LeaveSuspendMode den Normalbetrieb wiederherstellt ([SWS_SM_00703], [SWS_SM_00711]). Treten bei der Kommunikation oder den Zustandswechseln Abbrüche auf, greift das Modul auf die freie Funktion MakeErrorCode zurück ([SWS_SM_81244]), um spezifische ara::core::ErrorCode-Instanzen auf Basis der Aufzählung SmErrc zu erzeugen und der aufrufenden Applikation bereitzustellen.

Sequenzdiagramm: Typischer Ablauf der Suspend-Koordination mit Satelliten und Fehlerbehandlung. Quellen: [SWS_SM_00701], [SWS_SM_00702], [SWS_SM_00707], [SWS_SM_81240], [SWS_SM_81244].

Fehlerszenarien

Die Fehlerbehandlung in ara::sm ist strikt typisiert und basiert auf der Enumeration SmErrc ([SWS_SM_81240]). Zu den definierten Fehlercodes gehören:

• kOfferFailed: Der Dienst konnte nicht angeboten werden, da die Kommunikation mit dem State-Management-Dämon fehlgeschlagen ist ([SWS_SM_81240]).
• kCommunicationFailed: Fehler auf den unteren Transportschichten bei der Kommunikation mit Satelliten ([SWS_SM_81240]).
• kCommunicationTimeout: Ein angesprochener Satellit hat die vorgegebene Antwortzeit überschritten ([SWS_SM_81240], [SWS_SM_00707]).
• kAtLeastOneRejected: Mindestens ein Satellit konnte den Suspend-Zustand nicht ordnungsgemäß einnehmen ([SWS_SM_81240]).
• kAtLeastOneHadIssuesToLeave: Mindestens ein Satellit meldete beim Verlassen des Suspend-Modus kRejected ([SWS_SM_81240], [SWS_SM_00707]).
• kAuthenticationRequired: Die IAM-Authentifizierung wird erzwungen und verlangt eine explizite Identitätsüberprüfung des Satelliten ([SWS_SM_81240], [SWS_SM_00716]).

Die Bereitstellung der globalen Fehlerdomäne über GetSmDomain ([SWS_SM_81251]) und die Erzeugung von Fehlercodes über MakeErrorCode ([SWS_SM_81244]) sind als noexcept deklariert und garantieren Ausnahme- sowie Threadsicherheit. Interpretation: Das Werfen einer SmException dürfte primär dann Anwendung finden, wenn Aufrufer Fehlercodes der SmErrorDomain in ausnahmebasierte Kontrollflüsse überführen möchten, während funktionale Schnittstellen im Fehlerfall regulär ara::core::ErrorCode zurückliefern. Frage Q-5afcc13f11bdf19b (offen)