Figure 7.18: Completeness of controlled Function Groups

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Timing- und Zustandsablaufdiagramm (State Transition Chronogram) auf einer kontinuierlichen Zeitachse t.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R22-11), Spezifikation AUTOSAR_SWS_StateManagement (SM). Das Diagramm visualisiert das normative Architekturprinzip der Vollständigkeit gesteuerter Funktionsgruppen (Completeness of controlled Function Groups) bei Zustandsübergängen von State-Machines gegenüber dem Execution Management (ara::exec).
• Technischer Zweck: Nachweis, dass jede einer Zustandsmaschine zugeordnete ActionList zu jedem Zeitpunkt und bei jedem Zustandswechsel ein vollständig determiniertes Abbild aller kontrollierten Funktionsgruppen erzwingen muss – inklusive derjenigen Funktionsgruppen, deren Sollzustand unverändert bleibt.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Metamodell-Entitäten:
  • StateMachine1: Logischer Zustandsautomat innerhalb des State Management (SM), repräsentiert über diskrete Systemzustände (SM1:Off, SM1:Running).
  • FunctionGroup (FG1, FG2, FG3, FG4): Durch das Execution Management (EM) verwaltete logische Gruppierungen von Adaptive Applications und deren Prozessen.
  • FunctionGroupState: Diskrete Zielzustände der Funktionsgruppen (dargestellt: Off, Running, Fallback).
  • ActionList: Metamodell-Container im SM, der die bei Eintritt in einen Zustand oder bei einer Transition auszuführenden Aktionen bündelt.
  • Aktion SetFunctionGroupState: Schnittstellenaufruf des SM an den ara::exec::StateClient zur Transition einer bestimmten FunctionGroup.
• Beziehungen & Kardinalitäten:
  • 1 : N Steuerungsbeziehung: Eine StateMachine kontrolliert eine feste Menge von N Funktionsgruppen (im Schaubild: N = 4).
  • 1 : 1 Vollständigkeitsabdeckung: Jede ActionList eines State-Machine-Zustands muss für alle N kontrollierten Funktionsgruppen eine explizite Zustandszuweisung enthalten ($\forall i \in \{1..4\}: \text{TargetState}(FG_i) \in \text{ActionList}$).
  • Hervorhebung FG4 : Off (rot): Markiert die statische Invariante. Obwohl FG4 beim Übergang SM1:Off → SM1:Running im Zustand Off verbleibt, ist die explizite Deklaration in der ActionList normativ vorgeschrieben.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialer Zustand (SM1:Off):
   • Alle Funktionsgruppen befinden sich im Zustand Off: $\{FG_1\text{:Off}, FG_2\text{:Off}, FG_3\text{:Off}, FG_4\text{:Off}\}$.
2. Transitionstrigger (t = t_trans, gestrichelte Vertikale):
   • Die Auswertung einer Bedingung (Rule / Event-Trigger) feuert; StateMachine1 initiiert den Zustandswechsel von SM1:Off nach SM1:Running.
3. Ausführung der ActionList (asynchrone Prozessanforderungen via ara::exec):
   • FG1, FG2, FG3: Erhalten über SetFunctionGroupState den Zielzustand Running. Die ansteigenden Flanken repräsentieren den asynchronen Prozessstart- und Initialisierungsverlauf (Ramp-up, Rückmeldung über ara::core::Future).
   • FG4: Erhält explizit den Zielzustand Off. Da der Istzustand bereits Off ist, erfolgt die Quittierung durch EM idempotent ohne Prozessneustart oder Zustandsänderung.
4. Zustandskonsolidierung (zweite gestrichelte Vertikale):
   • Der Zustand SM1:Running ist erst dann vollständig eingenommen und stabil, wenn alle asynchronen SetFunctionGroupState-Anforderungen erfolgreich von EM quittiert wurden.

4. Normative Relevanz & Entwickler-Hinweise

• SWS_SM_00612 / RS_SM_00001, RS_SM_00005:
  • Verbot partieller Zustandslisten: Es ist unzulässig, in einer ActionList lediglich Delta-Änderungen zu modellieren. "Don't care"-Lücken bezüglich gesteuerter Funktionsgruppen führen zu inkonsistenten Zwischenzuständen und sind spezielisationswidrig.
  • Konfiguration & ARXML-Modellierung: Bei der Definition von StateManagementPortInterfaces, Rules und ActionLists im AUTOSAR-Modell muss der System-Integrator sicherstellen, dass jede dem Funktionsbereich zugeordnete FunctionGroup in jeder ActionList der Zielzustände referenziert wird.
  • Drift- & Recovery-Prävention: Die explizite Anforderung unveränderter Zustände garantiert, dass nach unvorhergesehenen Prozessabbrüchen, Safe-State-Fallbacks (Fallback) oder asynchronen Fehlern stets der globale Sollzustand deterministisch wiederhergestellt wird.
  • API-Vertrag (ara::exec::StateClient): Das State Management muss Fehlerschläge (kSetStateError) einzelner Funktionsgruppen aggregieren; verbleibt eine FG in Fallback oder schlägt fehl, kann die übergeordnete StateMachine nicht in den stabilen Zielzustand übergehen.

Die Hintergrundabfrage der Spezifikationsmetadaten bestätigt den Befund exakt:

• Spezifikation: AUTOSAR_SWS_StateManagement.pdf (AP R22-11), Kapitel 7, Seite 51.
• Normative Verankerung: [SWS_SM_00612] in Verbindung mit [RS_SM_00001] und [RS_SM_00005].
• Kernanforderung: Jede ActionList eines Zustandsautomaten muss für sämtliche durch diesen Automaten kontrollierten Funktionsgruppen (FunctionGroup) einen definierten Zielzustand vorgeben, um zu jedem Zeitpunkt einen deterministischen Gesamtzustand sicherzustellen.