Figure 9.22: Functional Clusters in category Communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Architektur-Kategoriendiagramm der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Deklarative Zuordnung und Gruppierung von funktionalen Clustern (Functional Clusters) zur Architektur-Kategorie Communication gemäß AUTOSAR_EXP_SWArchitecture.
• Architektonische Einordnung: Definiert die Basisinfrastruktur für dienstorientierte Kommunikation (Service-Oriented Communication), ungepufferte Hochdurchsatz-Rohdatenströme (Raw Data Stream), Netzwerkzustandsverwaltung (Partial Networking, Bus-Sleep/Wake-up) und netzwerkweite Taktsynchronisation auf POSIX-basierten Adaptive-Steuergeräten.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm spezifiziert vier funktionale Einheiten mit dem AUTOSAR-Stereotyp «aapFunctionalCluster»:

1. Communication Management (ara::com):
   • Stereotyp/Annotation: Explizit als daemon-based klassifiziert. Beinhaltet Hintergrund-Dienste (z. B. SOME/IP-Daemon, Service Discovery, IPC-Routing).
   • Stellt die dienstorientierte Middleware-Abstraktion bereit (Events, Methods, Fields) für Inter-Process Communication (IPC) sowie netzwerkweite Kommunikation.
2. Raw Data Stream:
   • Bibliotheksbasiert (keine Annotation; neu hinzugefügter Cluster).
   • Bietet Schnittstellen für hochperformante, unstrukturierte Rohdatenströme (z. B. Sensor-, Kamera- oder Audio-/Videodaten) mit minimalem Overhead außerhalb der serviceorientierten Middleware.
3. Network Management (ara::nm):
   • Bibliotheksbasiert (keine Annotation).
   • Koordiniert Netzwerkzustände (z. B. Repeat Message, Normal Operation, Ready Sleep) und Partielle Netzwerke (PN).
   • Stellt Schnittstellen zur Anforderung und Freigabe von Kommunikationskanälen bereit.
4. Time Synchronization (ara::tsync):
   • Stereotyp/Annotation: Explizit als daemon-based klassifiziert.
   • Läuft als eigenständiger Systemprozess (POSIX-Daemon) im Hintergrund, um Takt-Frames kontinuierlich auf OS-/Netzwerktreiberebene zu terminieren und Zeitbasen über Zeitdomänen hinweg (z. B. gPTP nach IEEE 802.1AS) zu synchronisieren.

Beziehungen & Konnektoren: Keine expliziten Ports, Abhängigkeiten oder Schnittstellenrelationen im Diagramm dargestellt; es handelt sich um eine reine Kategorienschnitt-Taxonomie.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammart: Rein statisches Deklarationsdiagramm; enthält keine Sequenz-, Timing- oder Kontrollfluss-Pfade.
• Laufzeit-Dynamik im Gesamtsystem:
  • Communication Management nutzt Hintergrund-Daemons für Service Discovery (FindService/OfferService) sowie das Routing und Serialisieren von Botschaften über Bus- und IPC-Grenzen hinweg.
  • Raw Data Stream stellt kontinuierliche Datenkanäle bereit, über die Streaming-Endpunkte große Nutzdatenblöcke effizient zwischen Applikationen oder Netzwerktreibern transferieren.
  • ara::tsync agiert als autonomer Daemon, empfängt periodische Zeit-Pakete, nutzt Hardware-/Kernel-Timestamping und aktualisiert Zeitbasen im Shared Memory.
  • ara::nm synchronisiert zyklische NM-Botschaften über den Bus und steuert Kanalzustände, bevor Nutzdatenflüsse freigegeben werden.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- & Deployment-Modell:
  • Sowohl Communication Management als auch Time Synchronization sind als daemon-based annotiert; für beide müssen eigenständige Executables im Execution Manifest deklariert und durch das Execution Management (ara::exec) instanziiert werden.
  • Raw Data Stream und Network Management sind bibliotheksbasiert und werden direkt in den Prozesskontext der nutzenden Adaptive Applications gelinkt.
• Konfigurations-Vertrag (ARXML):
  • Dienst- und Netzwerkschnittstellen müssen im Service Instance Manifest (ServiceInstanceToMachineMapping) und Network Manifest exakt aufeinander abgestimmt sein.
  • Für Raw Data Stream sind Streaming-Ports, Transportprotokolle und Pufferstrukturen in den Manifesten zu spezifizieren.
  • NM-Cluster-Zustände müssen an die entsprechenden Network-Handles gekoppelt werden; fehlerhafte Synchronisation zwischen ara::com-Dienstaufrufen, Streaming-Kanälen und ara::nm-Freigaben führt zu stillem Paketverlust auf Bus-Ebene.