Figure 7.7: Switching Network State by "Trigger"

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd Network State transition).
• Technischer Zweck: Spezifikation der zustandsgesteuerten Netzwerkzustandsumschaltung (Network State Transition / Partial Networking) in der AUTOSAR Adaptive Platform (AP). Das Diagramm visualisiert die Entkopplung und Vermittlerrolle des funktionellen Clusters State Management (SM) zwischen anfordernden Applikationen und dem Network Management (NM) unter Verwendung von ara::com-basierten Service-Schnittstellen (Fields/Events).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Komponenten (Lifelines):
  • Application1: Adaptive Applikation (Client/Requester), die einen externen oder anwendungsbezogenen Netzanforderungstrigger initiiert.
  • State Management (AP Functional Cluster, gekennzeichnet mit Stereotyp-Marker A): Zentrale State-Machine- und Orchestrierungsinstanz zur Auswertung von Transitionen, Guard-Bedingungen und Vor-/Nachbereitungsaktionen.
  • Network Management (AP Functional Cluster, gekennzeichnet mit Stereotyp-Marker A): Ausführende Instanz für Netzwerk-Handles, Bus-Keep-Alive und Partial-Network-Zustände.
• Ports & Service Interfaces:
  • TriggerIn (an State Management): Eingangs-Port/Service-Interface zur Entgegennahme von externen Umschaltanforderungen (write() → interner Trigger event()).
  • TriggerOut (an State Management): Ausgangs-Port/Service-Interface zur Signalisierung intermediärer und finaler Statusübergänge (pre_state, final_state) an überwachende Instanzen oder andere Cluster.
  • NetworkCurrentState (an Network Management): Zustandsüberwachungs-Port (Event/Field-Notifier), über den NM seinen Ist-Zustand publiziert (subscribe() / write() / event()).
  • NetworkRequestedState (an Network Management): Steuerungs-Port (Field/Method/Event), über den SM Zielzustände oder Partial-Network-Cluster anfordert.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase (Subscription):
   • State Management abonniert asynchron den Ist-Zustand des Netzwerks über den Port NetworkCurrentState mittels subscribe().
2. Trigger-Eingang & Evaluierung:
   • Application1 sendet ein write() an den Eingangs-Port TriggerIn.
   • TriggerIn generiert ein internes event() an den SM-Zustands-Kern.
   • SM führt synchron checkGuardCondition(s) aus (Validierung von Vorbedingungen, Safety-/Security-Zuständen, System-Modi).
3. Pre-State-Phase & NM-Anforderung:
   • Nach erfolgreicher Guard-Prüfung signalisiert SM über TriggerOut den Zustand write(pre_state) (z. B. Vorbereitung von Kommunikationspfaden, Buffer-Allokation).
   • SM setzt die Netzwerkanforderung durch Aufruf von write() am Port NetworkRequestedState von NM ab.
4. Zustandsumschaltung im Network Management:
   • NetworkRequestedState reicht die Anforderung per event() an den NM-Kern weiter.
   • NM führt die eigentliche Netzwerkkonfiguration bzw. Wake-up-/Sleep-Sequenz aus (set (partial) network).
   • NM meldet den vollzogenen Zustand über seinen Meldeport NetworkCurrentState per write().
5. Finalisierung:
   • Der Port NetworkCurrentState propagiert das Status-event() an SM.
   • SM beendet die Transition und publiziert über TriggerOut den endgültigen Zustand via write(final_state).

4. Normative Relevanz & Entwickler-Hinweise

• Keine direkte Kopplung Applikation ↔ Network Management: Applikationen dürfen das Netzwerk nicht direkt anfordern. Alle Netzanforderungen müssen über standardisierte Trigger-Interfaces von SM laufen, damit globale Guard Conditions und Modusbeschränkungen durchgesetzt werden.
• Service-Design (ara::com Mapping):
  • Die Interaktion über TriggerIn, TriggerOut, NetworkCurrentState und NetworkRequestedState bildet typischerweise ara::com::Field (mit Getter/Setter/Notifier) oder Skeleton/Proxy-Event-Strukturen ab.
  • Entwickler müssen bei write()-Operationen auf Non-Blocking-Semantik achten bzw. Callbacks/Events asynchron verarbeiten, um Blockaden des SM-Threads zu verhindern.
• Zweistufiger Transitionsvertrag (pre_state / final_state):
  • Systeme, die von Netzwerkressourcen abhängen, müssen den Übergangszustand (pre_state) abwarten bzw. tolerieren und dürfen produktiven Datenverkehr erst nach Eintreffen des final_state aufnehmen.
  • Scheitert checkGuardCondition(s), wird weder pre_state noch NetworkRequestedState ausgelöst; SM verbleibt im Ausgangszustand (stille Verwurf- oder projektspezifische Error-Notification).