Figure 7.13: Communication Group

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Service-Interaktions- und Topologiediagramm (Architekturmodell auf Komponentenebene) der AUTOSAR Adaptive Platform (ara::com).
• Funktionale Einordnung: Visualisierung des Broker- und Vermittlungsmusters einer Communication Group gemäß [RS_CM_00600]. Die Communication Group dient als logische Entkopplungs- und Verteilungsschicht für 1:N-Broadcast- und N:1-Aggregationskommunikation innerhalb des Adaptive State Managements (z. B. Synchronisation von Power-States, Function Groups oder globalen Zustandsübergängen über mehrere Prozesse hinweg).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Rollen:
  • Client Applications (oben, violett): Mehrere Prozessinstanzen (dargestellt: 1 benannter Client, 2 weitere Instanzen). Jeder Client hostet ein Skeleton (S) des CG Client Service.
  • Communication Group (Zentralblock, rot): Vermittlungsinstanz / Broker-Komponente des Communication Managements.
    • Client-seitig: Beherbergt je angebundenem Client einen Proxy (P).
    • Server-seitig: Stellt ein Skeleton (S) des CG Server Service bereit.
  • Server Applications (unten, grün): Koordinierende Prozessinstanz (z. B. State Management; dargestellt: 1 aktiver Server, 1 redundanter/alternativer Server-Kandidat). Der Server bindet über einen Proxy (P) an.
• Schnittstellen (Service Interfaces):
  • CG Client Service (CommunicationGroupClient): Vom Client bereitgestellte Skeleton-Schnittstelle, von der Communication Group via Proxy konsumiert. Dient dem Empfang von Steuerungs- und Broadcast-Nachrichten sowie der Rückmeldung lokaler Prozesszustände.
  • CG Server Service (CommunicationGroupServer, [SWS_CM_99000]): Von der Communication Group bereitgestellte Skeleton-Schnittstelle, vom Server via Proxy konsumiert. Kapselt Management- und Broadcast-Funktionen (z. B. broadcast(), [SWS_CM_99001]).
• Architektonische Inversion & Kardinalitäten:
  • Invertiertes Service-Muster: Der logische Koordinator ("Server") ist nach außen hin Service-Konsument (Proxy), während die Arbeitslast-Prozesse ("Clients") Service-Provider (Skeleton) für die Gruppe sind. Dies realisiert ein typisiertes Callback-/Observer-Muster über Standard-ara::com-Primitive.
  • Kardinalität: 1 : 1 : N (Genau 1 Server steuert über 1 Communication Group N Clients; im Diagramm N=3).

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierung & Service Discovery:
  1. Clients instanziieren das Skeleton für CG Client Service und rufen OfferService() auf.
  2. Die Communication Group sucht via FindService() die konfigurierten Clients und bindet jeweils eine Proxy-Instanz.
  3. Die Communication Group bietet den CG Server Service via Skeleton an (OfferService()).
  4. Die Server-Applikation bindet via Proxy (FindService()) an die Gruppe.
• Broadcast-Ablauf ([SWS_CM_99001], [RS_CM_00601]):
  1. Trigger: Der Server ruft am Proxy des CG Server Service synchron oder asynchron die Methode broadcast(message) auf.
  2. Broker-Dispatch: Das Skeleton in der Communication Group nimmt die Nachricht entgegen, prüft Herkunft/Kontext und propagiert den Aufruf parallel über alle registrierten CG Client Service-Proxies.
  3. Empfang am Client: Das Skeleton der Clients führt die registrierten Methoden-Handler/Event-Callbacks aus.
  4. Fehlerbehandlung: Schlägt die Zustellung an einen oder mehrere Teilnehmer fehl, meldet der CG Server Service einen normierten Fehlercode an den Server zurück (SWS_CM_99024).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurations- und Manifestvertrag (ARXML):
  • Modellierung separater Port-Prototypes: PPortPrototype am Client (CommunicationGroupClient), RPortPrototype am Server (CommunicationGroupServer).
  • Zuweisung über Deployment- und Instance-Manifeste an die bindungsabhängige Middleware (z. B. IPC / SOME/IP).
• API-Vertrag (ara::com):
  • Server-Entwickler: Verwendet ausschließlich die generierte Proxy-Klasse von CommunicationGroupServer. Darf keine Annahmen über direkte Peer-to-Peer-Verbindungen zu den Clients treffen.
  • Client-Entwickler: Muss die Service-Methoden des CommunicationGroupClient Skeleton implementieren und deterministische Antwortzeiten gewährleisten, um Gruppen-Timeouts zu verhindern.
• Lifecycle & Deprecation-Warnung (Release R20-11 vs. neuere Stände):
  • In R20-11 ist das Feature normativ spezifiziert.
  • Hinweis für Systemarchitekten: In späteren AUTOSAR-Releases (ab R23-11) wurden CommunicationGroup, RS_CM_00600, RS_CM_00601 und SWS_CM_99001 als OBSOLETE deklariert und gestrichen. Für zukunftssichere Designs sind stattdessen native Pub/Sub-Events (ara::com::Event) oder standardisierte RPC-Schnittstellen mit direktem Service Discovery zu verwenden.