Figure 7.8: TransitionRequestTable

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Tabellarische Zustandsübergangsmatrix / Transition Lookup Table (Zustandsübergangstabelle eines deterministischen endlichen Automaten / DFA).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) gemäß Spezifikation AUTOSAR_SWS_StateManagement (Release R22-11).
• Funktionaler Zweck:
  • Umsetzung von [RS_SM_00001] (Koordination und Steuerung von Applikationsmengen via Function Groups) und [RS_SM_00005] (Zustandswechsel interner State Machines basierend auf externen Triggern).
  • Formale Definition der zulässigen Zustandsübergänge einer im State Management instanziierten State Machine. Die Tabelle dient als normativer Filter und Zuordnungsfunktion (s_current, request) ↦ s_next, um unzulässige Zustandswechsel abzuwehren und deterministische Zielzustände zu erzwingen.

2. Komponenten, Entitäten & Schnittstellen

• Tabellen-Entitäten & Attribute:
  • Transition Request (Eingangs-Trigger / Request ID): Numerischer Identifikator der Transitionsanforderung (Parameter der Schnittstelle RequestTransition).
    • 1000: Anforderungs-ID für Standard-Rückführung bzw. Reaktivierung (On → Off, Suspend → On, Recovery → Off).
    • 1001: Anforderungs-ID für Aktivierung bzw. Abbruch (Off → On, Startup → Off).
    • 1002: Spezifische Anforderungs-ID für die Rückführung nach Fehlerbehandlung (Recovery → Off).
  • Current State (Ausgangszustand): Diskreter interner Betriebszustand der State Machine ($s \in \{\text{Off}, \text{On}, \text{Recovery}, \text{Startup}, \text{Suspend}\}$):
    • Off: Inaktiver Grundzustand / Ruhezustand.
    • On: Regulärer aktiver Betriebszustand.
    • Startup: Hochlauf- und Initialisierungsphase.
    • Suspend: Energiespar- / Standby-Zustand.
    • Recovery: Fehlerbehandlungs- und Wiederherstellungsphase.
  • Next State (Folgezustand): Resultierender Zielzustand nach erfolgreicher Auswertung (s' ∈ Off, On).
• Schnittstellen & Metamodell-Bezug:
  • Service-Interface: ara::sm::StateMachineService (definiert unter [SWS_SM_00600]).
  • Service-Methode: RequestTransition(TransitionRequest) – aufgerufen von berechtigten Client-Applikationen (SMControlApplication) oder internen Triggern.
  • Metamodell (TPS Manifest Specification): Deklaration im Plattform-Manifest unterhalb des Metaklassen-Elements StateMachine als TransitionRequestTable mit Bindung an zugeordnete ActionList-Definitionen.
• Relationen & Übergangslogik im Schaubild:
  • Off –1001→ On: Aktivierung des Systems aus dem Ruhezustand in den regulären Betrieb.
  • On –1000→ Off: Reguläres Herunterfahren des aktiven Systems in den Ruhezustand.
  • Recovery –1002→ Off: Spezifische Fehlerbeendigung und Rückführung in den Grundzustand.
  • Startup –1001→ Off: Abbruch der Initialisierung und Rückfall in den Ruhezustand.
  • Suspend –1000→ On: Reaktivierung / Aufwecken aus dem Energiesparmodus in den Betrieb.
  • Recovery –1000→ Off: Standard-Rückführung aus dem Fehlerzustand in den Ruhezustand.

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering: Eine Client-Applikation (SMControlApplication) setzt über ara::com einen Methodenaufruf RequestTransition(reqId) ab oder ein internes Plattform-Ereignis (z. B. Netzwerk-Statuswechsel) triggert die State Machine.
2. Evaluierung & Tabellen-Lookup:
   • Die State Management Engine liest den aktuellen internen Zustand Current State aus und führt einen Lookup nach dem Tupel (Transition Request, Current State) durch.
   • Positiver Pfad: Existiert das Tupel in der Tabelle (z. B. Request 1000 im Zustand Suspend → Next State = On, oder Request 1002 im Zustand Recovery → Next State = Off), wird der definierte Folgezustand als Zielzustand übernommen.
   • Negativer Pfad: Ist das Tupel in der Tabelle nicht definiert (z. B. Request 1002 im Zustand Off oder Request 1001 im Zustand On), wird die Anforderung verworfen. Die Methode quittiert den Aufruf mit einem Fehlercode (z. B. kTransitionNotAllowed oder kInvalidValue).
3. Ausführung des Zustandswechsels:
   • Vor Beginn der Transition stoppt das State Management die Abarbeitung laufender ActionListItems der bisherigen ActionList des Current State.
   • Atomare Umschaltung des internen Zustandsregisters auf Next State.
   • Ausführung der neuen ActionList, welche über das Execution Management (ara::exec::FunctionGroupState) die Prozesse der zugeordneten Function Group startet, stoppt oder rekonfiguriert.
4. Fehlerbehandlung: Scheitert eine abhängige Aktion während des Phasenwechsels, greift die komplementäre Fehlerbehandlungslogik (ErrorRecoveryTable).

4. Normative Relevanz & Entwickler-Hinweise

• Plattform- & SM-Entwickler (Stack Implementation):
  • O(1) Validierung: Zur Gewährleistung harter Echtzeit und Determinismus sollte die TransitionRequestTable zur Compile- bzw. Generierzeit in eine dichte Matrix oder ein direkt indiziertes Lookup-Array abgebildet werden (Mapping der symbolischen Zustands-Enums und Request-IDs auf Speicherindizes).
  • Vollständigkeit & Fehlersicherheit: Nicht deklarierte Tupel stellen implizit verbotene Übergänge dar; eine defensive Default-Behandlung für undefinierte Trigger-Zustands-Paare ist zwingend bereitzustellen.
• Applikations-Entwickler (SMControlApplication):
  • API-Vertrag: RequestTransition() arbeitet asynchron via ara::core::Future. Applikationen müssen den Rückgabewert explizit auf Transitionsfehler prüfen; ein abgelehnter Aufruf bewirkt keine Zustandsänderung.
  • Zwei-Phasen-Konvergenz: Alle Zielzustände der Tabelle münden ausschließlich in Off oder On. Zwischenzustände (Startup, Suspend, Recovery) können nie direkt als Zielzustand einer Transition angefordert werden, sondern dienen als kontrollierte Ausgangszustände.
• Integrations- & Manifest-Konfiguration:
  • Strikte Ablaufarchitektur: Durch die expliziten Regeln wird sichergestellt, dass aus Startup nur ein Abbruch nach Off möglich ist, aus Suspend nur die Reaktivierung nach On führt und Recovery über zwei getrennte Trigger (1000 und 1002) sicher nach Off zurückgeführt werden kann.