Figure 7.12: 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): Diskreter Identifikator einer Transition (numerischer Wert bzw. Enumeration des Service-Parameters).
    • 1001: Anforderungs-ID für den Übergang in einen aktiven Betriebsmodus (z. B. Start-/Run-Anforderung).
    • 1000: Anforderungs-ID für die Rückführung/den Shutdown in den Grundzustand (z. B. Safe-State-, Standby- oder Off-Anforderung).
  • Current State (Ausgangszustand): Diskreter interner Zustand der State Machine (s ∈ 0, 1, 2, 3, 4):
    • 0: Initiale Ruhe-/Inaktiv-Phase (z. B. Off, Safe State, Standby).
    • 1, 2, 3, 4: Spezifische Betriebs-, Funktions- oder Subsystem-Modi.
  • Next State (Folgezustand): Resultierender Zielzustand nach erfolgreicher Auswertung (s' ∈ 0, 1).
• 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 (z. B. NetworkHandle Statusänderungen NoCom ↔ FullCom).
  • Metamodell (TPS Manifest Specification): Deklaration im Plattform-Manifest unterhalb des Metaklassen-Elements StateMachine als TransitionRequestTable (gekoppelt mit korrespondierenden ActionList- und ErrorRecoveryTable-Referenzen).
• Relationen & Übergangslogik im Schaubild:
  • 0 –1001→ 1: Exklusiver Vorwärts-Übergang von Ruhezustand 0 in Betriebszustand 1.
  • 1, 2, 3, 4 –1000→ 0: Mehr-zu-Eins-Konvergenz (Rücksetz-/Deaktivierungspfade aller aktiven Modi 1 bis 4 direkt zurück in Zustand 0).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering: Eine Client-Applikation (SMControlApplication) setzt über ara::com einen Methodenaufruf RequestTransition(reqId) ab oder ein Netzwerk-Event (z. B. NM-Statuswechsel) triggert die State Machine.
2. Evaluierung & Tabellen-Lookup:
   • Die State Management Engine liest den aktuellen Zustand Current State aus und sucht nach dem Tupel (Transition Request, Current State).
   • Positiver Pfad: Existiert das Tupel (z. B. Request 1000 in Zustand 3), wird der Zielzustand Next State = 0 übernommen.
   • Negativer Pfad: Ist das Tupel in der Tabelle nicht definiert (z. B. Request 1001 im Zustand 2), wird der Übergang 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 ActionList, die dem bisherigen Current State zugeordnet war.
   • Atomare Umschaltung des internen Zustandsregisters auf Next State.
   • Triggerung der neuen ActionList, welche über das Execution Management (ara::exec::FunctionGroupState) Applikationsprozesse startet, stoppt oder rekonfiguriert.
4. Fehlerbehandlung: Scheitert eine abhängige Aktion während des Phasenwechsels, greift die komplementäre 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-/Generierzeit in ein direkt indiziertes 2D-Lookup-Array oder eine dichte Zustandsübergangsmatrix ohne dynamische Heap-Allokation überführt werden.
  • Vollständigkeit: Nicht deklarierte Zellen stellen implizit verbotene Übergänge dar; eine defensive Default-Behandlung für undefinierte IDs 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 führt zu keinerlei Statusänderung der Plattform.
  • Synchronisationsverträge: Die Anforderer-Applikation darf erst nach erfolgreichem Future-Return bzw. Zustands-Event davon ausgehen, dass der Next State aktiv ist.
• Integrations- & Manifest-Konfiguration:
  • Die Tabelle bildet die Sicherheitsarchitektur ab: Durch das Fehlen von Querverbindungen (z. B. von 2 nach 3 oder von 0 nach 2..4) erzwingt die Konfiguration, dass jeder Systemneuanlauf ausschließlich über Zustand 1 und jeder Systemstopp direkt über Zustand 0 geführt wird.