Figure 7.7: Communication Group service interface categories

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ableitungsmodell (Service Interface Derivation Pattern).
• Technischer Zweck & Einordnung: Dargestellt ist das formale Ableitungskonzept für Communication Groups (Gruppenkommunikation) innerhalb des Functional Clusters Communication Management (ara::com) der AUTOSAR Adaptive Platform (Release R20-11, Kapitel 7).
• Architektonischer Kontext: Da Gruppenkommunikation asymmetrische Rollen zwischen dem Gruppen-Koordinator (Server) und den Gruppen-Teilnehmern (Clients) aufweist, wird ein primäres, neutrales Schnittstellenmodell (COMMUNICATION_GROUP) über automatisierte Modelltransformation (<<derive>>) in zwei rollenspezifische Service-Interfaces aufgeteilt. Dies gewährleistet typ- und rollenkonforme Proxies und Skeletons ohne manuelle Redundanz in ARXML.

2. Komponenten, Entitäten & Schnittstellen

• Basis-Entität:
  • ServiceInterface (Kategorie: COMMUNICATION_GROUP):
    • Rolle: Quell-/Templateschnittstelle zur Definition des Nutzdatenvertrags der Gruppe.
    • Methoden/Events:
      • - method message(msg): Abstrakte Nachrichtensignatur für eingehende Gruppennachrichten.
      • - event response(responseMsg): Abstrakte Eventsignatur für Antwort- bzw. Rückmeldungsdaten.
• Abgeleitete Entitäten:
  • ServiceInterface (Kategorie: COMMUNICATION_GROUP_SERVER):
    • Rolle: Schnittstelle für den Gruppen-Koordinator/Server zur Orchestrierung und gezielten Adressierung.
    • Methoden/Events:
      • - method broadcast(msg): 1:n-Nachrichtenverteilung an alle aktuell registrierten Gruppen-Clients.
      • - method message(clientId, msg): 1:1-Unicast-Nachricht an ein dezidiertes Gruppenmitglied über dessen clientId.
      • - event response(clientID, responseMsg): Asynchrones Antwort-Event inklusive Absender-Identifikation (clientID).
      • - method listClients(): Abfrageschnittstelle zur Ermittlung aller aktiven bzw. registrierten Clients der Gruppe.
  • ServiceInterface (Kategorie: COMMUNICATION_GROUP_CLIENT):
    • Rolle: Schlanke Schnittstelle für reguläre Gruppen-Teilnehmer (Clients).
    • Methoden/Events:
      • - method message(msg): Clientseitiges Senden einer Nachricht an den Server/die Gruppe (Identifikation erfolgt implizit über den Stack).
      • - event response(responseMsg): Empfang von Antworten/Statusnachrichten (Filterung auf Client-Ebene).
• Beziehungen & Stereotypen:
  • <<derive>> (UML Dependency): Formale Transformations-Abhängigkeit. Kennzeichnet die regelbasierte Ableitung der Server- und Client-Schnittstellen aus dem Basis-Interface gemäß den Anforderungen SWS_CM_99008, SWS_CM_99009 und SWS_CM_99019.
  • Kardinalität: 1 Group Server zu n Group Clients pro Gruppeninstanz.

3. Dynamisches Verhalten & Sequenzablauf

1. Client-Registrierung & Discovery:
   • Clients lokalisieren den Gruppen-Dienst über ara::com::FindService basierend auf dem COMMUNICATION_GROUP_CLIENT-Interface.
   • Der Server instanziiert das COMMUNICATION_GROUP_SERVER-Skeleton und führt die Session-/Client-Verwaltung (listClients()).
2. Uplink (Client → Server):
   • Ein Client ruft message(msg) auf seinem Proxy auf. Der Kommunikations-Stack (z. B. via SOME/IP oder Shared Memory/IPC) übermittelt den Payload an den Server; der Stack injiziert transportseitig die Zuordnung zur clientID.
3. Downlink Broadcast (Server → Alle Clients):
   • Server triggert broadcast(msg). Die Middleware verteilt die PDU an alle der Gruppe zugeordneten Endpunkte.
4. Downlink Unicast (Server → Spezifischer Client):
   • Server ruft message(clientId, msg) auf. Der Stack löst die clientId in den entsprechenden Transportkanal auf und stellt die Nachricht selektiv zu.
5. Asynchroner Antwortpfad:
   • Server-seitig feuert response(clientID, responseMsg); der jeweilige Client empfängt dies als entitiespezifisches response(responseMsg) Event ohne manuelle Filterlogik im Applikationscode.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung:
  • Entwickler/Systemarchitekten modellieren ausschließlich das Service-Interface der Kategorie COMMUNICATION_GROUP.
  • AUTOSAR-Authoring-Tools müssen die Generatoren für COMMUNICATION_GROUP_SERVER und COMMUNICATION_GROUP_CLIENT automatisiert ausführen (Konformität zu RS_CM_00600, RS_CM_00601).
• API-Vertrag (ara::com C++ Implementation):
  • Server-Entwickler: Implementieren das Skeleton für COMMUNICATION_GROUP_SERVER. Methodenrückgaben erfolgen über ara::core::Future / ara::core::Result (asynchron, nicht-blockierend). listClients() erfordert ein threadsicheres Member-Tracking im Applikations- oder Middleware-Kontext.
  • Client-Entwickler: Instanziieren den Proxy für COMMUNICATION_GROUP_CLIENT. Der Entwickler hat keinen Zugriff auf fremde clientIds und benötigt keine Broadcast-Logik, was die Client-Applikation schlank und frei von Routing-Code hält.
• Einschränkungen & Binding-Anforderungen (SWS_CM_99020):
  • Das zugrundeliegende Transport-Binding (z. B. SOME/IP Binding) muss Session-Handling und Client-Multiplexing unterstützen.
  • Fehlerbehandlung bei ungültigen clientIds in message(clientId, msg) muss über AUTOSAR-spezifische ara::core::ErrorCode bzw. ApApplicationErrors abgebildet werden.