Figure 9.9: Interfaces for triggering state changes

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Service-Schnittstellendiagramm (Service Interface Blueprints) der AUTOSAR Adaptive Platform (AP R21-11).
• Architektonische Einordnung: Spezifikation der standardisierten Kommunikationsmuster zwischen Adaptive Applications (Consumer) und dem Functional Cluster State Management (Provider).
• Technischer Zweck: Definition normativer Service-Blueprints (TriggerIn, TriggerOut, TriggerInOut) zur Entkopplung von applikationsseitigen Zustandsanforderungen (State Triggers) und Zustandssignalisierungen (State Notifications) über die Middleware ara::com. Das State Management übersetzt diese Anforderungen in Schaltbefehle für Function Groups an das Execution Management (ara::exec).

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Stereotypen

• Adaptive Application (UML Component): Standard-Anwendungsprozess im POSIX-User-Space; agiert in allen drei Interaktionsmustern als Service-Consumer.
• «aapFunctionalCluster» State Management (UML Component, Kennzeichnung daemon-based): Zentraler Plattform-Daemon zur Steuerung des Gesamtsystemzustands. Besitzt den Sonderstatus, dass dessen Kernlogik projektspezifisch implementiert und konfiguriert werden muss (kein rein generischer COTS-Stack-Bestandteil).

Service-Interface-Blueprints («aapAraComServiceInterface, aapAPI»)

Die Schnittstellen dienen als Templates ({StateGroup} fungiert als Platzhalter für konkrete Funktionsgruppen bzw. Domänen):

1. TriggerIn_{StateGroup}:
   • Element: «aapAccessControlled, aapServiceField» + Trigger
   • Semantik: Unidirektionale Steuerung. Ermöglicht der Applikation das Einstellen/Triggern von Soll-Zuständen in das State Management.
2. TriggerOut_{StateGroup}:
   • Element: «aapAccessControlled, aapServiceField» + Notifier
   • Semantik: Unidirektionale Beobachtung. State Management publiziert Ist-Zustände bzw. Zustandswechsel an abonnierende Applikationen.
3. TriggerInOut_{StateGroup}:
   • Elemente: «aapAccessControlled, aapServiceField» + Notifier, + Trigger
   • Semantik: Bidirektionale Steuerung und Quittierung/Rückmeldung über ein konsolidiertes Service-Interface.

Port-Rollen & Beziehungen

• Provider: State Management realisiert die Interfaces ausnahmslos über «aapProvidedPort» (PPort).
• Consumer: Adaptive Applications binden die Interfaces über «use» «aapRequiredPort» (RPort).
• Sicherheits-Stereotyp «aapAccessControlled»: Alle Felder unterliegen der Absicherung durch Identity and Access Management (IAM). Zugriffe (Get/Set/Sub) erfordern deklarierte Zugriffsrechte im Software-Manifest.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger-Pfad (Anforderung eines Zustandswechsels):
   • Die Adaptive Application schreibt über den generierten Proxy (ara::com) auf das Feld Trigger (TriggerIn oder TriggerInOut).
   • Die AP-Middleware prüft über IAM die Prozessberechtigung für den Schreibzugriff.
   • Das State Management empfängt den Request, evaluiert interne Abhängigkeiten und leitet die Transition ein, indem es per API (ara::exec::FunctionGroupState) das Execution Management zur Prozessumschaltung anweist.
2. Notifier-Pfad (Zustandsrückmeldung & Broadcasting):
   • Nach Vollzug oder Statusänderung aktualisiert das State Management den Feldwert Notifier (TriggerOut oder TriggerInOut).
   • ara::com verteilt das Field-Event asynchron an alle registrierten Subscriber (Adaptive Applications).
3. Synchronisationscharakter:
   • Die Interaktion über Felder ist lose gekoppelt und asynchron: Ein gesetzter Trigger garantiert keinen sofortigen Vollzug. Applikationen dürfen Zustandswechsel erst als abgeschlossen betrachten, wenn die entsprechende Quittierung über den Notifier empfangen wurde.

4. Normative Relevanz & Entwickler-Hinweise

• Blueprint-Instanziierung (ARXML):
  • {StateGroup} muss in der Software-Architektur zu konkreten Modell-Elementen instanziiert werden (z. B. TriggerIn_MachineState, TriggerInOut_Powertrain).
  • Die Interface-Namen und Feld-Strukturen müssen exakt den generierten ara::com-Klassennamen entsprechen.
• Implementierungsverantwortung:
  • Da State Management laut Spezifikation projektspezifisch implementiert wird, bildet dieses Diagramm den verbindlichen Schnittstellenvertrag zwischen OEM-/Tier-1-spezifischer SM-Logik und den Zuliefer-Applikationen.
• IAM / Access Control:
  • Durch «aapAccessControlled» schlagen Aufrufe von Set() oder Subscribe() zur Laufzeit fehl, wenn im ServiceInstanceManifest keine entsprechende AccessPolicy bzw. Security-Identity konfiguriert ist (Sicherheitsrisiko unautorisierter System-Shutdowns/State-Changes).
• Design Pattern:
  • Bevorzugung von TriggerInOut bei zustandsabhängigen Applikationen, um Race Conditions zwischen Anforderung und asynchroner Transition durch lokale Zustandsüberwachung via Notifier auf demselben Kommunikationskanal zu verhindern.