Figure 7.14: Extended transition request table

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Tabellarische Spezifikations- und Konfigurationsdarstellung (Zustandsübergangstabelle / Decision Table für Mealy-/Moore-Mischautomaten) im Kontext des AUTOSAR Adaptive Platform (AP) State Management.
• Funktionale Einordnung: Kernbestandteil des Functional Clusters State Management (ara::sm, AUTOSAR_AP_SWS_StateManagement). Es definiert die deterministische Auswertung von Eingangs-Triggern zur Steuerung interner Zustandsmaschinen (StateMachine), welche funktionale Gruppen (Function Groups, ara::exec) und Netzwerkzustände koordinieren (RS_SM_00001, RS_SM_00401).
• Architektonischer Zweck: Gegenüber einer einfachen Übergangstabelle (reines Mapping Trigger Value → Next State) führt die Extended Transition Request Table den Ist-Zustand (Current State) als explizite Vorbedingung ein. Damit werden kontextsensitive, zyklische oder zustandsabhängige Transitionen bei identischen Triggern ermöglicht.

2. Komponenten, Entitäten & Schnittstellen

• Tabellenelemente & Datenstrukturen:
  • Transition Request (Spalte 1): Diskreter Eingangs-Request bzw. Modus-Trigger. Das Schaubild exemplifiziert dies anhand von Netzwerk-Zuständen eines Network Management Handles (NmNetworkHandle):
    • Nh1_FullCom: Anforderung/Indikation des Status Full Communication auf Kanal 1 (RS_SM_00005).
    • Nh1_NoCom: Anforderung/Indikation des Status No Communication auf Kanal 1.
  • Current State (Spalte 2): Gültiger Ausgangszustand der State Machine vor Eintritt der Transitionsanforderung (Werte: Off, Camera Active).
  • Next State (Spalte 3): Deterministischer Folge- bzw. Zielzustand der State Machine (Werte: Camera Active, Off).
• Modellierungssemantik der Zeilen:
  • Zeile 1: Bedingter Übergang: Wenn Transition Request == Nh1_FullCom und Current State == Off, wechselt der Automat nach Camera Active.
  • Zeile 2: Reversibler Gegenübergang: Wenn Transition Request == Nh1_NoCom und Current State == Camera Active, wechselt der Automat nach Off.
• Beziehungen & Metamodell-Mapping (ARXML):
  • Entspricht der Modellierung von StateManagementTransitionRequestTable in Relation zu StateManagementTrigger (Typ: NetworkHandle), StateManagementState und verknüpften ActionList-Entitäten.

3. Dynamisches Verhalten & Sequenzablauf

• Trigger-Evaluation (SWS_SM_00620):
  1. Eintreffen einer Transitionsanforderung (Transition Request) über Field-Update, Event oder API-Aufruf (Statusänderung des NmNetworkHandle Nh1 zwischen FullCom und NoCom).
  2. Tabellenprüfung: Abgleich des Wertepaares (Transition Request, Current State).
• Zustandswechsel & Aktionsausführung (SWS_SM_00621):
  1. Identifikation des Next State (im Zustand Off führt Nh1_FullCom zu Camera Active; im Zustand Camera Active führt Nh1_NoCom zu Off).
  2. Abbruchsemantik: Bei Akzeptanz einer neuen Transition werden laufende ActionListItems des verlassenen Zustands bzw. der vorherigen Transition unverzüglich abgebrochen bzw. invalidiert (kOperationCanceled an ausstehenden Future-Objekten).
  3. Zustandsaktualisierung auf den neuen Zustandswert.
  4. Triggerung der dem Next State zugeordneten ActionList (z. B. Anforderung von Function-Group-Zuständen via ara::exec::FunctionGroupState).
• Fehler- und Ausnahmepfade:
  • Trifft eine Anforderung ein, für die kein passender Eintrag zum aktuellen Zustand existiert, erfolgt kein Zustandswechsel und die Anforderung wird verworfen (Logging über ara::log).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationskonsistenz (ARXML / Execution Manifest):
  • Tabellen müssen konfliktfrei und deterministisch modelliert sein. Das Tupel (Trigger Value, Current State) muss eineindeutig auf genau einen Next State abbilden.
• Kopplung State Management & Network Management (RS_SM_00005, SWS_SM_00620):
  • Die direkte Verknüpfung von NmNetworkHandle-Zuständen mit State-Machine-Transitionen erfordert eine sorgfältige Vermeidung zirkulärer Abhängigkeiten (z. B. State Machine schaltet Process Group ab, die für NM-Kommunikation erforderlich ist, während NM-Status als Trigger dient).
• Applikations- und Stack-Design:
  • Applikationen, die Transitionen anfordern, müssen asynchron ausgelegt sein: Da externe Trigger (wie NM-Änderungen) laufende Transitionen unterbrechen können, dürfen Aufrufer nicht auf einer synchronen Vollendung verharren, sondern müssen Abbruchcodes (kOperationCanceled) fehlersicher behandeln.