Figure 15.14: Mapping of the interaction between network management and state management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ausschnitt (M2) der AUTOSAR Adaptive Platform (TPS Manifest Specification, R23-11).
• Technischer Zweck: Formale Definition des ARXML-Konfigurationsmodells zur deklarativen Kopplung zweier standardisierter Functional Clusters (FC): Network Management (NM) und State Management (SM).
• Architektur-Einordnung: Ermöglicht die systemweite Bindung von physikalischen/logischen Netzwerk-Zuständen bzw. Kanälen (NmNetworkHandle) an übergeordnete Zustandssteuerungen (StateManagementStateRequest), um koordinierte Übergänge von Machine States oder Function Groups in Abhängigkeit von Busaktivitäten (z. B. Partial Networking, Network Wakeup/Sleep) im Deployment-Manifest zu etablieren.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Stereotypen

• FunctionalClusterInteractsWithFunctionalClusterMapping (spezialisiert UploadableDeploymentElement):
  • Abstrakte Basis-Metaklasse für alle Manifest-Elemente, die Interaktionspfade zwischen AUTOSAR-Adaptive-Funktionsclustern definieren.
  • Als UploadableDeploymentElement ist das resultierende Mapping Bestandteil eines Deployment-Pakets und auf die Adaptive Machine deploybar.
• NmInteractsWithSmMapping (normiert durch [TPS_MANI_01447]):
  • Konkretes Mapping-Element, das die Brücke zwischen der NM-Domäne und der SM-Domäne schlägt.
• NmNetworkHandle (spezialisiert Referrable):
  • Repräsentiert das logische Netzwerk-Handle bzw. den Kommunikationskanal im Adaptive Platform Network Management.
• StateManagementStateRequest (spezialisiert Identifiable):
  • Abstrakte Basisklasse für Zustandsanforderungen innerhalb des State Managements (z. B. Anforderung zum Wechsel einer Function Group oder eines Machine State).

Beziehungen & Kardinalitäten

• Generalisierung: NmInteractsWithSmMapping ⟶ FunctionalClusterInteractsWithFunctionalClusterMapping (Vererbung der Deployment-Eigenschaften).
• Assoziation +nmNetworkHandle (0..1): Unidirektionale Referenz von NmInteractsWithSmMapping auf die Zielinstanz NmNetworkHandle.
• Assoziation +stateRequest (0..1): Unidirektionale Referenz von NmInteractsWithSmMapping auf die Zielinstanz StateManagementStateRequest.
• Hinweis zur Kardinalität: Beide Enden sind optional (0..1). Ein vollständig konfiguriertes Mapping zur Laufzeitkopplung erfordert semantisch die Belegung beider Referenzen.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert die statische Manifest-Struktur; zur Laufzeit steuert das Mapping folgende funktionale Kette:

1. Netzwerk-Trigger (NM → SM):
   • NM empfängt NM-PDUs über den Bus oder registriert einen externen Wake-up auf dem durch NmNetworkHandle identifizierten Kanal.
   • Das NM-Modul signalisiert die Netzwerkverfügbarkeit über die interne FC-Interaktionsschnittstelle (IPC / ara::com) an das State Management.
2. Zustandsauswertung (SM):
   • SM löst anhand des Mappings die referenzierte StateManagementStateRequest aus.
   • Die SM-interne Rule-Engine evaluiert die Request und initiiert Transitions (z. B. Starten relevanter Function Groups via Execution Management ara::exec).
3. Kommunikationsanforderung (SM → NM):
   • Im umgekehrten Pfad fordert SM über den verknüpften StateManagementStateRequest-Pfad die Freigabe oder das Offenhalten des NmNetworkHandle an (Full Communication Request), um den Bus aktiv zu halten, solange abhängige Applikationen aktiv sind.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Konfiguration & Validierung (TPS_MANI_01447):
  • System-Integratoren müssen sicherstellen, dass in den Deployment-Manifesten (ExecutionManifest / MachineManifest) Instanzen von NmInteractsWithSmMapping existieren, wenn Function Groups an den Kommunikationsstatus von Bussystemen gekoppelt werden sollen.
  • Fehlt das Mapping, verbleiben NM und SM isoliert; es erfolgt kein automatischer Zustandswechsel bei externem Bus-Wakeup.
• Code-Generierung & Stack-Implementierung:
  • Der Manifest-Compiler des Plattform-Herstellers generiert aus NmInteractsWithSmMapping die internen Dispatch-Tabellen oder Routing-Handler zwischen dem NM-Daemon und dem SM-Daemon.
• Applikations-Architektur:
  • Adaptive Applications müssen den Busstatus nicht manuell per Polling über NM-Schnittstellen überwachen. Die Synchronisation erfolgt deklarativ über das State Management, welches die Applikations-Lebenszyklen steuert.