Figure 9.24: 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), standardisierte fahrzeugweite API-Gateways (Automotive API Gateway), ungepufferte Rohdatenströme (Raw Data Stream), Netzwerkzustandsverwaltung (Partial Networking) und netzwerkweite Taktsynchronisation auf POSIX-basierten Adaptive-Steuergeräten.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm spezifiziert fünf funktionale Einheiten mit dem AUTOSAR-Stereotyp «aapFunctionalCluster»:

1. Communication Management (ara::com):
   • Stereotyp/Annotation: daemon-based.
   • Stellt die dienstorientierte Middleware-Abstraktion bereit (Events, Methods, Fields).
2. Raw Data Stream:
   • Bibliotheksbasiert (keine Annotation; einzig verbliebenes rein bibliotheksbasiertes Cluster der Kategorie).
   • Stellt Schnittstellen für latenzarme, ungepufferte Rohdatenübertragungen bereit.
3. Network Management (ara::nm):
   • Stereotyp/Annotation: daemon-based (Status von bibliotheksbasiert auf Daemon-basiert geändert).
   • Läuft nun als eigenständiger Systemprozess zur Verwaltung von Netzwerkzuständen (Repeat Message, Normal Operation, Ready Sleep) und Partiellen Netzwerken (PN).
4. Time Synchronization (ara::tsync):
   • Stereotyp/Annotation: daemon-based.
   • Bereitstellung synchronisierter Zeitbasen (gPTP, CAN-TSyn).
5. Automotive API Gateway:
   • Stereotyp/Annotation: daemon-based.
   • Protokoll- und API-Gateway zur Übersetzung externer/standardisierter Fahrzeug-APIs in interne Plattform-Dienste.

Beziehungen & Konnektoren: Keine expliziten Ports, Abhängigkeiten oder Schnittstellenrelationen im Diagramm dargestellt; rein deklarative Kategorienschnitt-Taxonomie.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammart: Rein statisches Deklarationsdiagramm; enthält keine Sequenz-, Timing- oder Kontrollfluss-Pfade.
• Laufzeit-Dynamik im Gesamtsystem:
  • Automotive API Gateway nimmt als Hintergrund-Daemon externe API-Anfragen entgegen, transformiert diese in standardisierte ara::com-Methodenaufrufe oder Feldbeschreibungen und leitet Antworten bzw. Ereignisse bidirektional weiter.
  • Communication Management vermittelt Service Discovery, IPC und Netzwerk-Bindings.
  • Raw Data Stream wickelt hochvolumige Datenübertragungen ohne Middleware-Serialisierung ab.
  • ara::tsync synchronisiert Takte autonom im Hintergrund via Hardware-/Kernel-Timestamping.
  • ara::nm schaltet Netzwerk- und Kanalzustände bedarfsgerecht aktiv oder versetzt sie in den Schlafzustand.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- & Deployment-Modell:
  • Vier der fünf funktionalen Cluster (Communication Management, Network Management, Time Synchronization und Automotive API Gateway) sind nun als daemon-based ausgewiesen.
  • Für Network Management muss nun zwingend ein separates POSIX-Executable im Execution Manifest definiert werden, das mit entsprechenden Rechten zur Kommunikation auf Socket-/CAN-Ebene durch ara::exec gestartet wird; Applikationen binden lediglich schlanke NM-Client-Bibliotheken ein.
  • Raw Data Stream verbleibt als einziger Cluster rein bibliotheksbasiert.
• Konfigurations-Vertrag (ARXML):
  • NM-Daemon-Instanzen müssen den konfigurierten Network-Handles und partiellen Netzwerkclustern im Network Management Manifest exakt zugeordnet sein.
  • Gateway- und Service-Manifeste bleiben konsistent zu den Service- und Netzwerkkonfigurationen.