Figure 6.13: CG Server Service Interface Description, example PowerMode

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Strukturelles XML-Metamodell-Listing (ARXML-Serialisierungsauszug eines Software-Component-Service-Interfaces).
• Kontext & Zweck: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_EXP_ARAComAPI (Service-Oriented Architecture via ara::com).
• Funktionale Einordnung: Definition des Musters Communication Group (CG), realisiert als Server-seitiges Service-Interface (COMMUNICATION_GROUP_SERVER) für das State Management (ara::sm). Es dient der koordinativen Steuerung und Verteilung von Power-Mode-Zuständen zwischen einem zentralen Server (z. B. State Manager) und mehreren Gruppen-Clients (z. B. Funktionsgruppen oder Subsystemen) über Inter-Process-Communication (IPC) oder SOME/IP.

2. Komponenten, Entitäten & Schnittstellen

• Wurzelelement:
  • <SERVICE-INTERFACE>: Repräsentiert das abstrakte Dienst-Interface PowerModeServer.
  • <CATEGORY>: Definiert als COMMUNICATION_GROUP_SERVER. Weist dem Codegenerator und der Runtime die Gruppensemantik zu.
• Namespaces:
  • <NAMESPACES> / <SYMBOL-PROPS>: Hierarchische Strukturierung nach ara::sm, welche den Ziel-C++-Namespace ::ara::sm determiniert.
• Methoden (<METHODS> / <CLIENT-SERVER-OPERATION>):
  1. broadcast:
     • Argument: msg (DIRECTION: IN, Typ: STD-CPP-IMPLEMENTATION-DATA-TYPE /AUTOSAR/StateM/Imp/PowerModeMsg).
     • Semantik: Verteilung einer Nachricht an alle Gruppenmitglieder.
  2. message (im Diagramm mit Annotationsmarker (2) indiziert):
     • Argument 1: clientID (DIRECTION: IN, Typ: STD-CPP-IMPLEMENTATION-DATA-TYPE /AUTOSAR/StdTypes/uint32_t).
     • Argument 2: msg (DIRECTION: IN, Typ: STD-CPP-IMPLEMENTATION-DATA-TYPE /AUTOSAR/StateM/Imp/PowerModeMsg).
     • Semantik: Selektive, gezielte Zustellung einer Nachricht an ein spezifisches Gruppenmitglied via clientID.
  3. listClients:
     • Argument: clients (DIRECTION: IN, Typ: STD-CPP-IMPLEMENTATION-DATA-TYPE /AUTOSAR/StateM/Imp/Clients).
     • Semantik: Verwaltung bzw. Aktualisierung der aktiven Client-Registrierungen.
• Events (<EVENTS> / <VARIABLE-DATA-PROTOTYPE>):
  • response:
    • Typ: STD-CPP-IMPLEMENTATION-DATA-TYPE /AUTOSAR/StateM/Imp/PowerModeResponse.
    • Semantik: Asynchroner Rückkanal (Publish/Subscribe) zur Übertragung von Zustandsantworten oder Quittierungen an die Gruppe.
• Kardinalitäten & Typbeziehungen:
  • Alle Methoden enthalten ausschließlich Eingabeparameter (DIRECTION = IN). Es sind weder OUT-Parameter noch <POSSIBLE-ERROR-REFS> deklariert.
  • Strikte Referenzierung vorkonfigurierter C++-Implementierungsdatentypen (STD-CPP-IMPLEMENTATION-DATA-TYPE).

3. Dynamisches Verhalten & Sequenzablauf

• Kommunikationsmuster (Asymmetrische Gruppe):
  1. Registrierung / Verwaltung: Der Server führt über listClients die Liste der adressierbaren clientID-Endpunkte nach.
  2. 1:N-Steuerung (Broadcast): Der Aufruf von broadcast(msg) stößt das synchrone/asynchrone Verteilen eines neuen Power-States an sämtliche Gruppen-Clients an.
  3. 1:1-Steuerung (Unicast innerhalb CG): Über message(clientID, msg) wird ein dezidierter Client isoliert angesprochen (z. B. gestaffeltes Herunterfahren, selektives Wake-up).
  4. N:1 bzw. 1:N Rückmeldung (Eventing): Da die Operationen keine RPC-Rückgabewerte liefern (Fire-and-Forget-Charakteristik), erfolgt die Rückmeldung über das Event response. Clients abonnieren dieses Event, bzw. der Server nutzt dieses zur Statusquittierung nach Zustandsübergängen.
• Fehler- und Abbruchverhalten:
  • Es existiert kein synchroner Fehlerrückkanal (keine ara::core::ErrorCode / ApplicationErrors in den Methoden-Signaturen). Verbindungs- und Protokollabbrüche müssen transportseitig durch den ara::com-Binding-Stack abgefangen werden.

4. Normative Relevanz & Entwickler-Hinweise

• C++ API-Generierung (ara::com):
  • Skeleton-Generierung: Der Interface-Generator erzeugt ara::sm::skeleton::PowerModeServerSkeleton. Methoden mit reinen IN-Parametern ohne Return-Wert werden in Adaptive Platform typischerweise als One-Way-Methoden oder mit ara::core::Future<void> abgebildet.
  • Namespace: Die generierten Proxy- und Skeleton-Header liegen bindend im Namespace ara::sm.
• Binding & Deployment:
  • Das Service-Interface muss in nachgelagerten Manifesten (SomeipServiceInterfaceDeployment oder IpcServiceInterfaceDeployment) an Transport-IDs gebunden werden:
    • broadcast, message, listClients benötigen eindeutige methodIds.
    • response benötigt eine zugewiesene eventId.
• Einschränkungen & Fallstricke für Anwendungsentwickler:
  • Kein synchrones Feedback: Da DIRECTION: IN ohne OUT vorliegt, blockiert der Aufrufer nicht auf die Antwort des Clients. Entwickler müssen Timeout-Überwachungen für Reaktionen auf response im State Manager selbst implementieren.
  • Datentyp-Allokation: Typen wie /AUTOSAR/StateM/Imp/Clients und PowerModeMsg müssen deterministisch dimensioniert sein (z. B. ara::core::Vector mit maximaler Kapazität), um Heap-Fragmentierung zur Laufzeit gemäß den AUTOSAR Adaptive Echtzeitanforderungen zu verhindern.