Figure 3.71: Specification of the NetworkManagementPortInterface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ausschnitt (M2-Ebene) aus der AUTOSAR Adaptive Platform Template-Spezifikation (AUTOSAR_AP_TPS_ManifestSpecification).
• Funktionale Einordnung: Verankerung der Schnittstellendefinition für das Netzwerkmanagement im Manifest-Metamodell. Es ordnet das spezifische Interface für den Functional Cluster Network Management (ara::nm) in die allgemeine Port- und Komponentenarchitektur der Adaptive Platform ein.

2. Komponenten, Entitäten & Schnittstellen

• PortInterface (abstrakte Metaklasse):
  • Allgemeine Basisklasse aller Port-Schnittstellen in AUTOSAR.
  • Realisiert/spezialisiert folgende AUTOSAR-Metamodell-Konzepte:
    • ARElement: Paketierbares First-Class-Element innerhalb eines ARPackage (besitzt einen eindeutigen shortName und Pfad).
    • AtpType: Fungiert als formaler Typ im AUTOSAR-Typensystem zur Typisierung von PortPrototype-Instanzen (RPortPrototype, PPortPrototype).
    • AtpBlueprint: Dient als definierbare Vorlage/Muster im Rahmen des AUTOSAR Blueprint-Workflows.
    • AtpBlueprintable: Kann direkt aus einem Blueprint abgeleitet oder verfeinert werden.
• NetworkManagementPortInterface (konkrete Metaklasse):
  • Spezialisierte Schnittstellendefinition für Interaktionen mit dem Netzwerkmanagement.
  • Beziehung / Vererbung: Generalisierungsbeziehung (UML-Vererbungspfeil mit geschlossener, hohler Spitze) auf PortInterface. Sie erbt somit alle Eigenschaften von ARElement, AtpType, AtpBlueprint und AtpBlueprintable.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Metamodell-Natur: Nicht direkt zutreffend, da es sich um ein rein statisches Struktur- und Typmodell handelt.
• Laufzeitsemantik (ara::nm):
  • Ports, die durch NetworkManagementPortInterface typisiert sind, dienen der Adaptive Application zur Anforderung und Überwachung von Netzwerkzuständen (z. B. Beantragung des aktiven Bus-Zustands via ara::nm::NetworkHandle, Halten von Teilnetzwerken/VLANs, Freigabe in den Zustand „Ready-to-Sleep“).
  • Der Zugriff erfolgt synchron oder asynchron über die C++-API von ara::nm, wobei Zustandsänderungen des Busses über Callbacks oder Ereignisse an die Applikation propagiert werden.

4. Normative Relevanz & Entwickler-Hinweise

• Konformität & ARXML-Modellierung ([TPS_MANI_01034]):
  • Ports einer Adaptive Application (AdaptiveApplicationSwComponentType), die auf NM-Funktionen zugreifen oder solche bereitstellen, müssen zwingend auf ein NetworkManagementPortInterface referenzieren (portInterface-Assoziation). Eine Typisierung über generische ServiceInterface-Elemente ist für diesen standardisierten Zweck unzulässig.
• Code-Generatoren & Tooling:
  • Der Manifest-Compiler / ARXML-Parser prüft anhand dieser Typisierung, ob für die verknüpften Ports die standardisierten Bindings und Header des ara::nm-Stacks (z. B. NetworkHandle-Abstraktionen) anstelle von generischen ara::com-Service-Proxies/Skeletons generiert bzw. instanziiert werden müssen.
• Applikations- und Stack-Entwickler:
  • Gewährleistet die Trennung zwischen anwendungsbezogener Service-Kommunikation (ServiceInterface) und Plattform-Management-Diensten. Entwickler erhalten über standardisierte Port-Verträge deterministischen Zugriff auf das Schlafenlegen und Wecken von Ethernet-Netzwerk-Clustern bzw. CAN/LIN-Verbindungen (via Bridges).