Figure 11.5: Scenario: Reject Trigger Input

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation eines Negativ-/Alternativ-Szenarios bei der Zustandssteuerung in der AUTOSAR Adaptive Platform (AP R22-11). Dargestellt wird das Verwerfen bzw. Nichthandeln auf einen eingehenden Trigger-Wert (Reject Trigger Input) durch das State Management (SM).
• Funktionale Einordnung: Verortet im Functional Cluster State Management (SM) im Zusammenspiel mit einer Adaptive Application (AA). Das Diagramm illustriert die Entkopplung von externer Trigger-Anforderung und tatsächlicher Funktionsgruppen-Zustandsänderung (Function Group State Transition): Neue Trigger-Daten führen nicht zwangsläufig zu einem Zustandsübergang, wenn die interne Arbitrierungslogik ermittelt, dass der Zielzustand dem Ist-Zustand entspricht.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • app: Adaptive Application: Anwendungsinstanz im User Space / POSIX-Prozesskontext, die als Service-Consumer auftritt.
  • :State Management: Instanz des Functional Clusters der Plattform mit Stereotyp «aapFunctionalCluster» (Core Infrastructure Component).
• Schnittstellen & Service-Elemente:
  • TriggerIn_{StateGroup} (bzw. TriggerInOut_{StateGroup}): Service Interface (ara::com), über das Applikationen Zustandsanforderungen oder Umgebungsbedingungen an das State Management übermitteln.
  • TriggerIn_{StateGroup}::Set(value): Setter-Methode eines ara::com::Field (oder generischer Method-Call) zur Modifikation des Input-Werts für die spezifizierte State Group.
• Interne Funktionen & Constraints:
  • determineDesiredFGState(): desiredState: Interne Arbitrierungs- und Regellogik des State Management zur Ermittlung des geforderten Zustands (desiredState) aller betroffenen Function Groups (FG).
  • {desiredState = currentState}: UML-Constraint / Notiz, welche die Guard-Bedingung beschreibt: Der ermittelte Sollzustand ist identisch mit dem aktuellen System-/Function-Group-Zustand.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger-Aufruf: Die Adaptive Application ruft TriggerIn_{StateGroup}::Set(value) synchron oder über ara::com Future-basiert auf, um einen neuen Eingangswert an das State Management zu übermitteln.
2. Interne Zustandsevaluation: Das State Management führt einen internen Selbstaufruf determineDesiredFGState(): desiredState aus. Anhand konfigurierter State-Machine-Regeln, Abhängigkeiten und Prioritäten wird der resultierende Zielzustand berechnet.
3. Abbruchbedingung / Verwerfung:
   • Die Auswertung ergibt die Bedingung {desiredState = currentState}.
   • Konsequenz: Die Transition wird verworfen. Es erfolgt keine Interaktion mit dem Cluster Execution Management (ara::exec::FunctionGroupStateControl) und kein Request für einen Prozesswechsel. Der Aufruf terminiert ohne weitere Plattform-Aktionen.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::com & State Management):
  • Der erfolgreiche Aufruf von Set(value) an einem TriggerIn-Interface bestätigt ausschließlich die Entgegennahme des Trigger-Inputs durch das State Management, nicht den Vollzug oder die Initiierung eines Zustandswechsels.
  • Ein Aufrufer darf keine impliziten Annahmen über resultierende Prozesslebenszyklen oder Function-Group-Zustände aus dem Setter-Return ableiten.
• Applikations-Design:
  • Statusrückmeldungen müssen asynchron über dedizierte Notifier (z. B. TriggerOut_{StateGroup} oder Feld-Events) überwacht werden, falls die Applikation auf die tatsächliche Bestätigung des Systemzustands angewiesen ist.
• Entwicklung des State Management:
  • Die Logik in determineDesiredFGState() muss idempotent sein: Identische Zielzustände dürfen keine redundanten IPC-Aufrufe an das Execution Management auslösen, um unnötigen Prozess-Jitter und Overhead zu vermeiden.