Figure 7.15: Example of one NmNetworkHandle influencing multiple StateMachines

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Architektur-/Strukturdiagramm (Informatives Entwurfsmuster in Anlehnung an UML-Komponenten- und Verhaltensmodelle).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) (AUTOSAR_AP_SWS_StateManagement, Kapitel 7 Functional Specification).
• Technischer Zweck: Das Diagramm spezifiziert die zulässige 1:n-Beziehung zwischen einem Netzwerkknoten- bzw. Teilnetzwerk-Zustandsindikator (<<NmNetworkHandle>>) und mehreren unabhängigen Zustandsautomaten (<<StateMachine>>). Es legitimiert das Entwurfsmuster, bei dem eine Statusänderung eines logischen Teilnetzwerks als synchroner oder asynchroner Eingangstrigger in den Transitionstabellen (TransitionRequestTable) mehrerer paralleler State Machines fungiert (z. B. simultanes Aufwecken/Umschalten von Funktionsgruppen für Kamera, Sensorik und UI bei Aktivierung eines Parkassistenz-Teilnetzwerks). Die grünen „Thumbs-up“-Symbole kennzeichnen dieses Muster explizit als normativ gültiges, konfliktfreies Entwurfskonzept (im Gegensatz zur unzulässigen Mehrfach-Rücksteuerung eines Handles durch konkurrierende Automaten).

2. Komponenten, Entitäten & Schnittstellen

• <<NmNetworkHandle>> Partial Network Y (Quelle):
  • Stereotyp: <<NmNetworkHandle>> (Abstraktion eines logischen Kommunikationskanals bzw. Teilnetzwerks aus dem Cluster Network Management, ara::nm).
  • Repräsentiert den Kommunikationsstatus (z. B. kFullCom, kNoCom) eines definierten Netzsegments.
• <<StateMachine>> State Machine X, Y, Z (Ziele):
  • Stereotyp: <<StateMachine>> (Deklarierte Zustandslogik innerhalb von State Management zur Überwachung und Steuerung von Plattform- und Anwendungszuständen bzw. FunctionGroup-Zuständen).
  • Enthaltene Datenstruktur: TransitionRequestTable (TRT). Tabellarisches Metamodell-Konstrukt, welches Triggerbedingungen (u. a. Werte von Netzwerk-Handles, externe Requests, Timeouts) auf Zielzustände (TargetState) abbildet.
• Beziehungen & Kardinalitäten:
  • 1:n-Trigger-Abhängigkeit: Ein NmNetworkHandle wirkt auf n StateMachines (n ≥ 1; hier exemplarisch X, Y, Z).
  • Kopplungsart: Gerichtete, entkoppelte Assoziation (gestrichelte Pfeile). Das NmNetworkHandle publiziert seinen Status an die TransitionRequestTable der jeweiligen State Machine (realisiert über das Metamodell-Element NmInteractsWithSmMapping bzw. StateManagementStateRequest).
  • Semantik der Icons: Grünes „Thumbs-up“ signalisiert Konformität: Ein Zustandssignal darf beliebig viele State Machines triggern, da lesende Zugriffe/Trigger-Evaluierungen seiteneffektfrei und deterministisch parallelisierbar sind.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger-Erzeugung (NM-Ebene):
   • Das Network Management detektiert eine Netzwerkstatusänderung auf dem physikalischen/logischen Bus (z. B. Eintritt in FullCom für Partial Network Y via NM-PDU oder lokalen Request).
   • Das NmNetworkHandle aktualisiert seinen Zustand im SM-Kontext (z. B. über das Service-Interface NetworkState bzw. ara::nm::NetworkHandle::GetNetworkState).
2. Parallele Trigger-Auswertung (SM-Ebene):
   • Die Zustandsänderung trifft als Eingangsereignis bei den registrierten Zustandsautomaten ein.
   • State Machine X, State Machine Y und State Machine Z prüfen unabhängig voneinander ihre jeweilige TransitionRequestTable:
     • Stimmt der aktuelle Zustand der State Machine mit dem Quellzustand der Regel überein und ist die Bedingung Partial Network Y == TargetState erfüllt, wird der Transitionsantrag genehmigt.
3. Zustandstransition & Aktionsausführung:
   • Jeder betroffene Automat bricht ggf. laufende unterbrechbare Aktionen ab und wechselt in seinen definierten Folgezustand.
   • Ausführung der dem neuen Zustand zugeordneten ActionList (z. B. Anfordern von Funktionsgruppen-Zuständen via Execution Management ara::exec, Setzen interner Variablen oder Starten von Timern).
4. Fehler- und Abbruchverhalten:
   • Scheitert die Transition in einer State Machine (z. B. weil eine abhängige ActionList fehlschlägt oder eine Guards-Bedingung in der TRT nicht erfüllt ist), bleibt der Fehler lokal auf diese State Machine beschränkt. Die Evaluierung in den parallelen State Machines läuft davon unbeeinflusst weiter.

4. Normative Relevanz & Entwickler-Hinweise

• Single-Controller- vs. Multi-Consumer-Prinzip:
  • Erlaubt (Multi-Consumer, im Bild dargestellt): Ein NmNetworkHandle triggert mehrere StateMachines. Dies ist die Standardarchitektur für Broadcast- und Feature-übergreifende Synchronisation.
  • Verboten / Restriktiv (Multi-Controller): Mehrere StateMachines dürfen nicht schreibend/steuernd (ActionListItem SetNetworkHandle via SmInteractsWithNmMapping) auf dasselbe NmNetworkHandle zugreifen, ohne dass eine übergeordnete Schlichtung/Priorisierung definiert ist, um Oszillationen und Race Conditions zu verhindern.
• ARXML-Konfiguration & Validierung:
  • Integratoren müssen für jedes Ziel die Metamodell-Referenzen via NmInteractsWithSmMapping exakt konfigurieren.
  • In der TransitionRequestTable jeder State Machine muss der Wertebereich des NmNetworkHandle (z. B. FULL_COMMUNICATION vs. NO_COMMUNICATION) eindeutig auf Zustandswechsel abgebildet sein.
• Laufzeit-Determinismus (Concurrency):
  • Da die Benachrichtigung der State Machines implementationsabhängig nebenläufig (z. B. über Thread-Pools) erfolgen kann, dürfen zwischen State Machine X, Y und Z keine impliziten Annahmen über die Ausführungsreihenfolge ihrer ActionLists bestehen.
  • Soll eine strikte Ausführungsreihenfolge erzwungen werden, muss dies über explizite Synchronisationspunkte (SYNC-ActionListItems gemäß SWS StateManagement) oder über eine kaskadierte Zustandsautomaten-Hierarchie modelliert werden.