Figure 6.11: Communication Group Service Interfaces Relationship

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Strukturdiagramm für das Schnittstellendesign in der AUTOSAR Adaptive Platform.
• Funktionale Einordnung: Verortet im Communication Management (ara::com) gemäß AUTOSAR_EXP_ARAComAPI. Das Diagramm beschreibt das Entwurfsmuster für die Gruppenkommunikation (Communication Groups). Es illustriert die modellbasierte Transformation einer logischen, symmetrischen Gruppen-Schnittstellendefinition in zwei asymmetrische, rollenspezifische Service-Interfaces für Server- und Client-Instanzen.

2. Komponenten, Entitäten & Schnittstellen

• ServiceInterface (category: COMMUNICATION_GROUP):
  • Ausgangsdefinition (abstraktes logisches Template der Gruppeninteraktion).
  • Operationen & Events:
    • - method message(msg): Generische Operation zur Übermittlung einer Nutzlast (msg).
    • - event response(responseMsg): Generisches Event zur Bereitstellung von Antwortdaten (responseMsg).
• ServiceInterface (category: COMMUNICATION_GROUP_SERVER):
  • Abgeleitete Schnittstelle für den Gruppen-Koordinator (Server/Skeleton-Rolle).
  • Operationen & Events:
    • - method broadcast(msg): Verteilung einer Nachricht an alle assoziierten Gruppenmitglieder (1:n).
    • - method message(clientId, msg): Gezielte Unicast-Kommunikation an einen spezifischen Client innerhalb der Gruppe via clientId.
    • - event response(clientID, responseMsg): Client-spezifisch qualifizierter Event-Rückkanal.
    • - method listClients(): Administrationsmethode zur Abfrage aller aktuell beigetretenen/aktiven Gruppen-Clients.
• ServiceInterface (category: COMMUNICATION_GROUP_CLIENT):
  • Abgeleitete Schnittstelle für Gruppen-Teilnehmer (Client/Proxy-Rolle).
  • Operationen & Events:
    • - method message(msg): Client-seitiges Absenden von Nachrichten an die Gruppe bzw. den Server.
    • - event response(responseMsg): Asynchroner Empfang von Antworten bzw. Gruppen-Events.
• Beziehungen & Abhängigkeiten:
  • Stereotyp <<derive>> (gerichtete gestrichelte Pfeile): Repräsentiert eine automatische Modelltransformation bzw. Generator-Ableitung von COMMUNICATION_GROUP hin zu COMMUNICATION_GROUP_SERVER und COMMUNICATION_GROUP_CLIENT.

3. Dynamisches Verhalten & Sequenzablauf

• Gruppen-Registrierung & Administration: Der Server ermittelt autorisierte oder beigetretene Teilnehmer über listClients(), wodurch dynamische oder statische clientId-Handles zur Verfügung stehen.
• Client-zu-Server-Pfad:
  • Ein Client sendet Nutzdaten über den Proxy-Aufruf message(msg).
  • Der Gruppen-Server empfängt den Aufruf kontextualisiert mit der jeweiligen clientId (message(clientId, msg)).
• Server-zu-Gruppe (Broadcast):
  • Aufruf von broadcast(msg) auf Server-Ebene führt transportseitig (z. B. SOME/IP Multicast) zur Zustellung an alle Clients der Gruppe.
• Gezielte Antwort (Directed Response / Event):
  • Der Server triggert das Event response(clientID, responseMsg).
  • Das Kommunikations-Binding filtert/routete die Nachricht, sodass sie beim adressierten Client als standardmäßiges response(responseMsg) via ara::com::Event / SetReceiveHandler() signalisiert wird.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung: Entwickler spezifizieren auf System-Design-Ebene primär das Interface COMMUNICATION_GROUP. Die Rollenschnittstellen (COMMUNICATION_GROUP_SERVER, COMMUNICATION_GROUP_CLIENT) werden üblicherweise tooling-gestützt abgeleitet, um Redundanzen und Schnittstellendivergenzen zu vermeiden.
• C++ API-Vertrag (ara::com):
  • Server-Entwickler: Implementieren das Skeleton für COMMUNICATION_GROUP_SERVER. Müssen Session-Handling und Client-Identifikatoren (clientId) im Applikationscode verwalten (listClients(), targeted message()).
  • Client-Entwickler: Binden den Proxy für COMMUNICATION_GROUP_CLIENT. Die API bleibt frei von Gruppenverwaltungslogik (clientId wird nicht explizit exponiert, sondern durch das Binding/Transport-Layer gekapselt).
• Deployment & Bindings: Bei SOME/IP-Serialisierung erfordert dieses Muster die explizite Zuordnung von SOME/IP-Eventgruppen (für broadcast und response) sowie die Konfiguration von Transportprotokollen (UDP/TCP Multicast bzw. Unicast) in den entsprechenden SomeipProvidedServiceInstance- und SomeipConsumedServiceInstance-Manifesten.