Figure 5.2: Interfaces provided by Execution Management to State Management

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodell-Mapping).
• Technischer Zweck: Spezifikation der Schnittstellenbeziehung zwischen den beiden daemon-basierten funktionalen Clustern State Management (SM) und Execution Management (EM) gemäß AUTOSAR_AP_SWS_ExecutionManagement (R23-11).
• Architektonische Einordnung: EM stellt den Ausführungsmechanismus bereit (Prozess-Lifecycle, Ressourcenüberwachung, Zustandswechselausführung), während SM die deterministische Kontrollinstanz (Policy Manager) darstellt. SM triggert Zustandswechsel für Funktionsgruppen und Maschinenstati ausschließlich über die von EM bereitgestellten Schnittstellen.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• State Management («aapFunctionalCluster», daemon-based): Konsument der Steuerungsschnittstellen; initiiert Transitionen und wertet Fehlerzustände aus.
• Execution Management («aapFunctionalCluster», daemon-based): Anbieter und Implementierer der Schnittstellen; kontrolliert Betriebssystemprozesse (Process, ProcessExecutionManifest).
• StateClient («aapAPI,aapNativeInterface»): C++-API (ara::exec::StateClient) mit folgenden Methoden:
  • + Create(function) (statische Factory-Methode): Instanziierung des Clients mit Übergabe eines Callback-Funktors (z. B. für asynchrone Transition-Notifications / Error-Handling).
  • + GetExecutionError(): Synchrone Statusabfrage des letzten aufgetretenen Ausführungsfehlers im Funktionsgruppenkontext.
  • + GetInitialMachineStateTransitionResult(): Liefert das Ergebnis der initialen Maschinenstatus-Transition nach Plattform-Boot.
  • + SetState(FunctionGroupState): Future: Asynchrone Anforderung eines Wechsels in den spezifizierten Zustand einer Funktionsgruppe.
• FunctionGroup («aapAPI,aapPortInterface»): Port-basiertes Metamodell-Interface zur Repräsentation konfigurierter Funktionsgruppen mit folgender Methode:
  • + Create() (statische Factory-Methode): Instanziierung bzw. Auflösung des Funktionsgruppen-Repräsentanten.
• FunctionGroupState («aapAPI,aapNativeInterface»): Native C++-Programmierschnittstelle (ara::exec::FunctionGroupState) zur Adressierung von Zielzuständen einer Funktionsgruppe mit folgender Methode:
  • + Create() (statische Factory-Methode): Typsichere Erzeugung einer Zielzustandskonfiguration.

Beziehungen & Abhängigkeiten

• Realisierung (InterfaceRealization / gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze):
  • Execution Management realisiert StateClient (Native C++ API Provider).
  • Execution Management realisiert FunctionGroup (Bereitstellung der Port-Interface-Semantik auf Plattformebene).
  • Execution Management realisiert FunctionGroupState (Bereitstellung der nativen C++-Implementierung).
• Nutzungsabhängigkeit («use» / gestrichelte offene Pfeillinie):
  • State Management nutzt StateClient für imperative Steuerungsaufrufe.
  • State Management nutzt FunctionGroupState als native Programmierschnittstelle.
• Port-Nutzungsabhängigkeit («use», «aapRequiredPort» / gestrichelte offene Pfeillinie):
  • State Management besitzt einen typisierten Required Port (RPortPrototype) gegen das FunctionGroup-PortInterface zur modellbasierten Bindung.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung:
   • SM instanziiert den Client über ara::exec::StateClient::Create(callback).
   • SM prüft via GetInitialMachineStateTransitionResult(), ob der initiale Systemboot (z. B. MachineState = Startup) durch EM erfolgreich abgeschlossen wurde.
2. Zustandsübergang (Asynchroner Pfad):
   • SM instanziiert bzw. adressiert die Ziel-Funktionsgruppe über FunctionGroup::Create().
   • SM erzeugt die Zielzustands-Instanz über FunctionGroupState::Create().
   • SM ruft SetState(targetState) mit der erzeugten FunctionGroupState-Referenz auf.
   • Der Aufruf blockiert nicht, sondern liefert sofort ein ara::core::Future<void>.
   • EM bestimmt alle abhängigen Prozesse, terminiert veraltete Prozesse (SIGTERM / SIGKILL nach Timeout), startet neu erforderliche Prozesse und wartet auf deren ReportExecutionState(kRunning).
   • Sobald die Transition vollständig abgeschlossen oder fehlgeschlagen ist, setzt EM das korrespondierende ara::core::Promise.
3. Fehlerbehandlung:
   • Scheitert ein Prozessstart oder die Zustandsverifikation, wird das Future fehlerhaft aufgelöst. SM ermittelt über GetExecutionError() bzw. den registrierten Callback die Fehlerursache (ExecErrc) und initiiert Fail-Safe- oder Degradations-Strategien.

4. Normative Relevanz & Entwickler-Hinweise

• Zugriffsbeschränkung & IAM: StateClient ist ein geschütztes Systeminterface. In der Manifest-Modellierung muss dem SM-Prozess über Prozess-Rechte (ExecutionClientPermission bzw. StateClientAuthorization) das exklusive Recht zur Instanziierung eingeräumt werden. Standard-Applikationen (AdaptiveApplications) dürfen StateClient nicht einbinden.
• Asynchronitäts-Paradigma (ara::core::Future): SetState() darf innerhalb des SM-Haupt-Eventloops niemals blockierend (Future::get() / Future::wait()) behandelt werden, um Deadlocks bei mehrstufigen Transitionen und Timeout-Überwachungen im SM-Daemon zu verhindern. Verwendung von .then()-Continuations oder Polling via wait_for().
• Modellierungs-Konsistenz (ARXML) & Schnittstellentrennung:
  • FunctionGroup fungiert als «aapPortInterface» und definiert die vertragliche Basis zwischen dem Systementwurf (ARXML) und der Bindung an State Management via «aapRequiredPort».
  • FunctionGroupState ist als native C++-Schnittstelle («aapNativeInterface») modelliert; Instanzen werden typsicher über Create() erzeugt und dem StateClient übergeben, anstatt als separates Metamodell-PortInterface modelliert zu sein.