Figure 9.25: 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) für IPC und fahrzeugweite Kommunikation.
2. Raw Data Stream:
   • Bibliotheksbasiert (keine Annotation).
   • Stellt Schnittstellen für kontinuierliche, latenzarme Rohdatenströme (z. B. Sensor-, Video- oder Streamingdaten) bereit.
3. Network Management (ara::nm):
   • Bibliotheksbasiert (keine Annotation).
   • Koordiniert Netzwerkzustände (Repeat Message, Normal Operation, Ready Sleep) und Partielle Netzwerke (PN).
4. Time Synchronization (ara::tsync):
   • Stereotyp/Annotation: daemon-based.
   • Bereitstellung synchronisierter Zeitbasen über Zeitdomänen hinweg (gPTP / IEEE 802.1AS, CAN-TSyn).
5. Automotive API Gateway:
   • Stereotyp/Annotation: daemon-based (neu hinzugefügt in einer zweiten Zeile unterhalb von Communication Management).
   • Agiert als Gateway und Protokollumsetzer zwischen externen/standardisierten Fahrzeug-APIs (z. B. REST, WebSocket, COVESA Vehicle Signal Specification) und den internen Adaptive-Plattformdiensten.

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:
  • Communication Management, Time Synchronization und Automotive API Gateway sind als daemon-based annotiert und erfordern eigenständige POSIX-Executables im Execution Manifest, die von ara::exec überwacht und gestartet werden.
  • Für das Automotive API Gateway sind IP-Endpunkte, Portbindungen und Zugriffskontrollen (z. B. TLS, Authentifizierung und Berechtigungen via Identity and Access Management) zu konfigurieren.
  • Raw Data Stream und Network Management verbleiben bibliotheksbasiert.
• Konfigurations-Vertrag (ARXML):
  • Mappings von externen Fahrzeug-API-Modellen auf interne Service-Interfaces (ServiceInterface) müssen im Konfigurationsmanifest des Gateways hinterlegt werden.
  • Dienst- und Netzwerkschnittstellen müssen im Service Instance Manifest und Network Manifest aufeinander abgestimmt sein.