Figure 5.2: Extended StateMachine TransitionRequestTable

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Tabellarische Zustandsübergangstabelle / Zustandsübergangsmatrix (Transition Request Table bzw. State Transition Table) zur Spezifikation eines erweiterten endlichen Zustandsautomaten (Extended Finite State Machine, EFSM).
• Funktionale Einordnung: Entwurfsmuster und Richtlinie innerhalb der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_InterfacesGuidelines, R23-11) zur standardisierten, deklarativen Implementierung von Zustandsübergängen auf Applikations- und Service-Ebene. Es modelliert das Verhalten zustandsbehafteter Komponenten (z. B. Subsysteme wie Kamerasysteme), deren Betriebsmodi deterministisch von externen Netzwerk- oder Systemtriggern (z. B. Network Management / State Management) abhängen.

2. Komponenten, Entitäten & Schnittstellen

• Tabellenstruktur / Datenmodell:
  • Transition Request: Eingangsvektor / Stimulus, welcher den Zustandswechsel anfordert.
  • Current State: Vorbedingung / Quellzustand vor Eintreffen des Triggers.
  • Next State: Folgezustand / Zielzustand nach erfolgreicher Transition.
• **Zustände (States):**
  • Off: Inaktiver Ruhezustand des Subsystems.
  • Camera Active: Aktiver Betriebsmodus des Kamerasystems.
  • Metamodell-Entsprechung: Abgebildet über ModeDeclarationGroup bzw. ModeDeclaration oder anwendungsspezifische Aufzählungstypen (enum class).
• Trigger-Entitäten:
  • Nh1_FullCom: Anforderungswert für „Network Handle 1 – Full Communication“.
  • Nh1_NoCom: Anforderungswert für „Network Handle 1 – No Communication“.
  • Schnittstellenbezug: Eintreffende Anforderung über Service-Schnittstellen (ara::com Field-Set, Event oder Method Call) oder Network-Management-/State-Management-Signale.
• Beziehungen & Kardinalitäten:
  • Eindeutige deterministische Relation: Jedes Tupel aus (Transition Request, Current State) wird auf genau einen Next State gemappt (1:1-Zuordnung).

3. Dynamisches Verhalten & Sequenzablauf

• Auslöser (Trigger) & Pfade:
  1. Transition 1: Befindet sich das System im Zustand Off und empfängt die Anforderung Nh1_FullCom, erfolgt der Zustandswechsel nach Camera Active.
  2. Transition 2: Befindet sich das System im Zustand Camera Active und empfängt die Anforderung Nh1_NoCom, wechselt es zurück in den Zustand Off.
• Synchronisations- & Ausführungscharakteristik:
  • Asynchroner Empfang: Trigger bzw. Requests treffen ereignisgesteuert (asynchron) über die Middleware-Schicht ein.
  • Synchrone Transition: Die TransitionRequestTable wird tabellenbasiert (z. B. Look-up) ausgewertet.
  • Undefinierte Zustände / Discard-Pfade: Trifft eine Anforderung ein, die für den aktuellen Zustand nicht in der Tabelle definiert ist (z. B. Nh1_NoCom im Zustand Off), liegt ein ungültiger Übergang vor. Dieser erfordert einen definierten Fallback (Ignorieren, Reject-Meldung oder Exception/Logging).

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus: Als Bestandteil der EXP-Serie (Explanation/Guidelines) ist das Pattern nicht unmittelbar funktional zwingend über SWS-Requirements normiert, definiert jedoch die empfohlene Architektur-Best-Practice für adaptive Applikationen und Service-Interfaces.
• Implementierungs-Empfehlung (C++14/C++17):
  • Bevorzugung tabellengesteuerter Implementierungen (std::array, flache Lookup-Tabellen oder constexpr-Hashtabellen) gegenüber tief verschachtelten switch-case-Strukturen zur Gewährleistung von O(1)-Laufzeitverhalten, Determinisierung und Testbarkeit.
• Vollständigkeit & Robustheit:
  • Embedded-Entwickler müssen für fehlende Tupel (Trigger, State) eine explizite Fehlerbehandlungsstrategie implementieren (z. B. Rückgabe eines Fehlercodes, Logging via ara::log oder Meldung an das Diagnosesystem / PHM).
• Zusammenspiel mit Adaptive State Management:
  • Soll der Zustandsübergang Prozesse oder Ressourcengruppen aktivieren/deaktivieren, muss die Tabelle direkt an ara::sm (State Management) bzw. ara::exec (Execution Management) angebunden werden, um Funktionsgruppen (Function Groups) konsistent umzuschalten.