Figure 9.23: 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 (Release R22-11).
• Architektonische Einordnung: Definiert die Basisinfrastruktur für dienstorientierte Kommunikation (Service-Oriented Communication), Netzwerkzustandsverwaltung (Partial Networking, Bus-Sleep/Wake-up) und netzwerkweite Taktsynchronisation auf POSIX-basierten Adaptive-Steuergeräten.

2. Komponenten, Entitäten & Schnittstellen

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

1. Communication Management (ara::com):
   • Stellt die dienstorientierte Middleware-Abstraktion bereit (Events, Methods, Fields).
   • Realisiert Inter-Process Communication (IPC) sowie fahrzeugweite Netzwerkanbindungen (z. B. SOME/IP, DDS, Signal-to-Service).
   • Architekturtypisch primär als Link-Bibliothek (library-based) direkt im Adressraum der Adaptive Applications implementiert.
2. Network Management (ara::nm):
   • 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.
3. Time Synchronization (ara::tsync):
   • Bereitstellung synchronisierter Zeitbasen über Zeitdomänen hinweg (z. B. synchronisierte Fahrzeugzeit nach IEEE 802.1AS / gPTP, IEEE 1588 oder CAN-TSyn).
   • Stereotyp/Annotation: Explizit als daemon-based klassifiziert. Läuft zwingend als eigenständiger Systemprozess (POSIX-Daemon) im Hintergrund, um Takt-Frames kontinuierlich auf OS-/Netzwerktreiberebene zu terminieren und Uhren-Disziplinierung vorzunehmen.

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:
  • ara::tsync agiert als autonomer Daemon, empfängt periodische Zeit-Pakete, nutzt Hardware-/Kernel-Timestamping und aktualisiert Zeitbasen, die Applikationen über IPC/Shared Memory synchron abrufen.
  • ara::nm synchronisiert zyklische NM-Botschaften über den Bus und triggert Zustandswechsel.
  • ara::com überträgt Nutzdaten asynchron oder synchron erst, wenn ara::nm den betreffenden Netzwerkkanal freigegeben hat.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- & Deployment-Modell:
  • Für Time Synchronization muss ein separates POSIX-Executable im Execution Manifest konfiguriert werden, das mit entsprechenden OS-Privilegien (z. B. CAP_SYS_TIME, Zugriff auf PTP Hardware Clock /dev/ptp*) durch das Execution Management (ara::exec) gestartet wird.
  • Communication Management erfordert typischerweise kein eigenständiges Daemon-Deployment für die Kern-API, sondern bindet sich als Laufzeitbibliothek in die Applikationsprozesse ein (abgesehen von optionalen, herstellerspezifischen IPC-Routern oder Binding-Daemons).
• Konfigurations-Vertrag (ARXML):
  • Dienst- und Netzwerkschnittstellen müssen im Service Instance Manifest (ServiceInstanceToMachineMapping) und Network Manifest exakt aufeinander abgestimmt sein.
  • NM-Cluster-Zustände müssen an die entsprechenden Network-Handles gekoppelt werden; fehlerhafte Synchronisation zwischen ara::com-Dienstaufrufen und ara::nm-Freigaben führt zu stillem Paketverlust auf Bus-Ebene.