Modul ara::nm — Network Management

Das funktionale Cluster Network Management stellt für das State Management Schnittstellen zur Verfügung, um logische Netzwerk-Handles, Teilnetze und physische Kommunikationskanäle koordiniert anzufordern und deren Status abzufragen ([SWS_ANM_01000], EXP_SWArchitecture S. 77). Über die Klasse NetworkHandle werden Soll- und Ist-Zustände zwischen kNoCom und kFullCom gesteuert sowie asynchrone Notifier registriert ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). Die Nutzung der Schnittstelle ist ausschließlich dem State Management vorbehalten, während Fehler einheitlich über NmErrorDomain gemeldet werden ([SWS_ANM_01101], [SWS_ANM_01111]).

mehr ›

Das funktionale Cluster Network Management (NM) stellt der AUTOSAR Adaptive Platform Mechanismen zur Anforderung und Statusüberwachung von Kommunikationsnetzen und Teilnetzen bereit. Die Programmierschnittstelle richtet sich exklusiv an das funktionale Cluster State Management, das über logische Instanzen der Klasse NetworkHandle Netzressourcen steuert und von physischen Busstrukturen wie Ethernet oder CAN entkoppelt wird ([SWS_ANM_01000], EXP_SWArchitecture S. 77, EXP_PlatformDesign S. 60).

Kontextdiagramm: Systemische Einbindung des Functional Clusters Network Management zwischen State Management und physischer Netzwerkebene. Quellen: SWS_NetworkManagement S. 13, EXP_PlatformDesign S. 60, [SWS_ANM_01000]

Ein NetworkHandle wird über einen ara::core::InstanceSpecifier initialisiert und unterstützt Verschiebeoperationen, während Kopierkonstruktor und Kopierzuweisung gelöscht sind ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). Das Modul unterscheidet zwischen dem gesetzten Anforderungszustand (SetNetworkRequestedState, GetNetworkRequestedState) und dem tatsächlich aktiven Netzwerkzustand (GetNetworkState), jeweils repräsentiert durch NetworkStateType mit den Zuständen kNoCom und kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Sequenzdiagramm: Interaktionsfluss bei Notifier-Registrierung, Zustandsanforderung und Zustandsabfrage. Quellen: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement S. 38

Zur asynchronen Signalisierung von Statuswechseln können Callbacks über RegisterNetworkStateChangeNotifier oder RegisterNetworkRequestedStateChangeNotifier – optional mit eigenem Executor – registriert werden ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Fehler werden über NmErrorDomain und NmErrc ausgewiesen; standardisierte Codes wie kServiceNotAvailable und kInvalidHandler sichern den deterministischen Umgang mit Ausfällen und fehlerhaften Konfigurationen ab ([SWS_ANM_01101], [SWS_ANM_01111]).

mehr ›

Systemische Rolle und funktionale Architekturabgrenzung

Das funktionale Cluster Network Management (NM) stellt innerhalb der AUTOSAR Adaptive Platform die koordinierte Verwaltung von Kommunikationsnetzwerken und Teilnetzen (Partial Networks, PN) bereit. Die Programmierschnittstelle des Moduls ist nicht für beliebige Adaptive Applications vorgesehen, sondern dient spezifisch dem funktionalen Cluster State Management (SM), um Kommunikationsfähigkeiten bedarfsgerecht anzufordern oder freizugeben ([SWS_ANM_01000], EXP_SWArchitecture S. 77). Das State Management fungiert als zentraler System-Orchestrator der Maschine und steuert Funktionsgruppen sowie Plattformzustände, während das Network Management die tatsächliche Busüberwachung, Teilnetzlogik und Bus-Keep-Alive-Zustände kapselt (SWS_NetworkManagement S. 13, EXP_PlatformDesign S. 60).

Architektonisch entkoppelt das Network Management über logische Netzwerk-Handles (NetworkHandle) übergeordnete Zustandssteuerungen von der physischen Netzwerktopologie wie Ethernet- oder CAN-Netzwerken (EXP_PlatformDesign S. 60). Eine Netzanforderung durch das State Management wird intern auf kanalspezifische Zustandsmaschinen und Partial Network State Machines (PNSM) abgebildet, wodurch die Kommunikation auf den physischen Kanälen synchronisiert und bedarfsgesteuert aktiviert oder heruntergefahren wird (SWS_NetworkManagement S. 18, SWS_StateManagement S. 17).

Kontextdiagramm: Systemische Einbindung des Functional Clusters Network Management zwischen State Management und physischer Netzwerkebene. Quellen: SWS_NetworkManagement S. 13, EXP_PlatformDesign S. 60, [SWS_ANM_01000]

Instanziierung und Ressourcenverwaltung über NetworkHandle

Der funktionale Zugriff auf ein konkretes Teilnetz oder einen physischen Kommunikationskanal erfolgt über Instanzen der Klasse NetworkHandle ([SWS_ANM_01000]). Ein NetworkHandle wird explizit durch Übergabe eines ara::core::InstanceSpecifier konstruiert, welcher den zugeordneten Port-Prototyp eines NetworkManagementPortInterface eindeutig referenziert ([SWS_ANM_01001]). Die Initialisierung über diesen Konstruktor ist als threadsicher spezifiziert ([SWS_ANM_01001]).

Das Schnittstellendesign von NetworkHandle folgt strengen Lebenszyklus- und Eigentumsregeln: Kopierkonstruktor und Kopierzuweisungsoperator sind explizit gelöscht (= delete), womit ein unkoordiniertes Duplizieren von Handle-Instanzen unterbunden wird ([SWS_ANM_01005], [SWS_ANM_01006]). Dagegen werden Verschiebekonstruktor und Verschiebezuweisung bereitgestellt, um Ressourcen kontrolliert transferieren zu können ([SWS_ANM_01003], [SWS_ANM_01004]). Interpretation: Da das Kopieren verboten und lediglich Verschiebeoperationen erlaubt sind, dürfte die Architektur eine exklusive Besitzsemantik je Handle-Instanz erzwingen, um konkurrierende Notifier-Registrierungen auf demselben Objekt auszuschließen. Frage Q-912cb5d1ddff2896 (offen) Destruktor und Verschiebezuweisung sind explizit als nicht threadsicher definiert, weshalb die Lebenszyklusverwaltung eines Handles im State Management synchronisiert erfolgen muss ([SWS_ANM_01002], [SWS_ANM_01004]).

Steuerung und Abfrage von Kommunikationszuständen

Das Modul unterscheidet strikt zwischen dem angeforderten Soll-Zustand (Requested State) und dem tatsächlich aktiven Ist-Zustand (Network State) eines Netzwerk-Handles ([SWS_ANM_01007], [SWS_ANM_01008]). Beide Zustände werden über die Enumeration NetworkStateType mit den Ausprägungen kNoCom (Wert 0) und kFullCom (Wert 1) repräsentiert ([SWS_ANM_01358]). Der Gesamtzustand ist definitionsgemäß nur dann kFullCom, wenn ausnahmslos alle dem Handle zugeordneten Teil- oder Vollnetze im Kommunikationszustand FULL_COM sind; andernfalls lautet der Status kNoCom ([SWS_ANM_01358]).

Über die Methode SetNetworkRequestedState fordert das State Management die Aktivierung (kFullCom) oder Freigabe (kNoCom) des zugehörigen PNC-, VLAN- oder physikalischen Netzes an ([SWS_ANM_01009], EXP_SWArchitecture S. 77). Mit GetNetworkRequestedState kann der zuletzt gesetzte Anforderungswert synchron abgefragt werden ([SWS_ANM_01008]). Der tatsächliche, busrelevante Betriebszustand wird hingegen mit GetNetworkState ausgelesen, wobei beide Abfragemethoden als threadsicher deklariert sind und ihr Ergebnis in einem ara::core::Result kapseln ([SWS_ANM_01007], [SWS_ANM_01008]).

Zustandsdiagramm: Zustandsübergänge des elementaren Netzwerkstatus NetworkStateType. Quellen: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Ereignisbasierte Zustandsüberwachung und Benachrichtigungsmechanismen

Da Zustandswechsel auf Netzwerkebene durch externe Busteilnehmer, Botschafts-Timeouts oder asynchrone Hochlaufzeiten verzögert eintreffen, stellt NetworkHandle asynchrone Benachrichtigungsmechanismen über Callback-Funktionen vom Typ NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) bereit ([SWS_ANM_01020]). Für Änderungen des effektiven Netzwerkzustands dient RegisterNetworkStateChangeNotifier ([SWS_ANM_01010]), während Änderungen des angeforderten Zustands über RegisterNetworkRequestedStateChangeNotifier überwacht werden ([SWS_ANM_01012]).

Pro Handle und Überwachungsart kann maximal ein Notifier registriert werden; jeder nachfolgende Registrierungsaufruf überschreibt den zuvor registrierten Callback (EXP_SWArchitecture S. 77). Mit UnregisterNetworkStateChangeNotifier sowie UnregisterNetworkRequestedStateChangeNotifier können bestehende Registrierungen explizit wieder aufgehoben werden ([SWS_ANM_01011], [SWS_ANM_01013]). Für eine erweiterte Ablaufsteuerung stehen template-basierte Registrierungsmethoden zur Verfügung, die einen benutzerdefinierten Executor (ExecutorT&& executor) entgegennehmen, um die Benachrichtigung in einem spezifischen Ausführungskontext oder Thread abzuarbeiten ([SWS_ANM_01014], [SWS_ANM_01015]).

Sequenzdiagramm: Interaktionsfluss bei Notifier-Registrierung, Zustandsanforderung und Zustandsabfrage. Quellen: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement S. 38

Manifest-Modellierung und Zuordnungskonfiguration

Die Einbindung des Network Managements in die Adaptive Application erfolgt über standardisierte Metamodell-Elemente im Manifest. Die Schnittstelle NetworkManagementPortInterface spezialisiert die fundamentale Metaklasse PortInterface und definiert somit formale Port-Prototypen (PPortPrototype, RPortPrototype) zur Interaktion mit dem Cluster (TPS_ManifestSpecification S. 263).

Im Deployment-Manifest wird die Bindung zwischen Applikationsinstanzen und dem logischen Netzwerk-Management über das Mapping-Element NetworkHandlePortMapping deklariert (TPS_ManifestSpecification S. 620). Dieses verknüpft einen Port-Prototyp innerhalb eines Prozesses (Process) mit einem logischen NmNetworkHandle (TPS_ManifestSpecification S. 620). Zudem wird über das Metamodell-Element NmInteractsWithSmMapping die koordinative Kopplung zwischen dem Cluster State Management (über StateManagementStateRequest) und dem Netzwerk-Handle (NmNetworkHandle) verbindlich konfiguriert (TPS_ManifestSpecification S. 875).

Metamodell-Diagramm: ARXML-Konfigurations- und Mapping-Beziehungen zwischen Ports, Prozessen, Handles und State Management. Quellen: TPS_ManifestSpecification S. 263, TPS_ManifestSpecification S. 620, TPS_ManifestSpecification S. 875

Verhalten im Fehlerfall

Zur einheitlichen Fehlerbehandlung implementiert das Modul eine eigene Fehlerdomäne gemäß der AUTOSAR-Adaptive-Fehlerarchitektur. Die Klasse NmErrorDomain erbt von ara::core::ErrorDomain und identifiziert Fehler der Netzwerkverwaltung über die statische Domänenabfrage GetNmDomain sowie die Identifikationsmethoden Name und Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

Die spezifischen Fehlerursachen sind in der Enumeration NmErrc definiert ([SWS_ANM_01111]). Der Fehlercode NmErrc::kServiceNotAvailable (Code 1) signalisiert, dass der zugrunde liegende Plattformdienst oder Daemon nicht erreichbar ist; er kann bei den Methoden GetNetworkState, GetNetworkRequestedState und SetNetworkRequestedState auftreten ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). Der Fehlercode NmErrc::kInvalidHandler (Code 2) wird gemeldet, wenn ein ungültiger Notifier-Handler an eine der Registrierungsmethoden übergeben wurde ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Fehlercodes werden über MakeErrorCode in reguläre ara::core::ErrorCode-Objekte überführt ([SWS_ANM_01110]). Falls in Ausführungsumgebungen C++-Exceptions zulässig und konfiguriert sind, können diese Fehler über ThrowAsException als Ausnahme vom Typ NmException ausgelöst werden ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). Zur Vereinfachung stehen die Typaliase Errc und Exception zur Verfügung ([SWS_ANM_01103], [SWS_ANM_01104]).

Weiterführende Detailbelege

Die wesentlichen Vorgaben des Moduls stützen sich auf normative Festlegungen der Spezifikation und begleitende Architekturmodelle:

• Klassen- und Schnittstellenspezifikation: NetworkHandle als Kernklasse für Netzanforderungen und Zustandsabfragen ([SWS_ANM_01000] bis [SWS_ANM_01015]).
• Zustandsdefinition: NetworkStateType mit kNoCom und kFullCom zur Abbildung des Netzstatus ([SWS_ANM_01358]).
• Fehlerdomäne und Fehlercodes: NmErrorDomain, NmException und NmErrc ([SWS_ANM_01100] bis [SWS_ANM_01111]).
• Architektur- und Manifestbelege: Schnittstellen- und Port-Definitionen in EXP_SWArchitecture S. 77, SWS_NetworkManagement S. 13, EXP_PlatformDesign S. 60 sowie Metamodell-Mappings in TPS_ManifestSpecification S. 263, TPS_ManifestSpecification S. 620 und TPS_ManifestSpecification S. 875.