Figure 6.14: CG Client Service Interface Description, example PowerMode

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-XML (ARXML) Modellausschnitt / M1-Metamodell-Instanziierung zur deklarativen Dienstbeschreibung (SERVICE-INTERFACE).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Kommunikations-Middleware ara::com im Zusammenspiel mit dem Functional Cluster State Management (ara::sm).
• Technischer Zweck: Formale Spezifikation der Client-seitigen Dienstschnittstelle einer Kommunikationsgruppe (Communication Group, CG) am Beispiel des Power-Mode-Managements. Das Modell trennt Steuerbefehle (Methodenaufruf) von Statusrückmeldungen (Event-Publikation) zur entkoppelten Gruppen- und Zustandsinteraktion.

2. Komponenten, Entitäten & Schnittstellen

• SERVICE-INTERFACE (PowerModeClient):
  • CATEGORY: COMMUNICATION_GROUP_CLIENT – weist das Interface semantisch als Client-Endpunkt einer Kommunikationsgruppe aus.
  • NAMESPACES: Hierarchische C++-Namespace-Abbildung via SYMBOL-PROPS auf ara::sm (resultiert im generierten C++-Namespace ::ara::sm).
• METHODS (Markierung [3]):
  • Aggregiert eine CLIENT-SERVER-OPERATION namens message.
  • ARGUMENTS: Beinhaltet einen ARGUMENT-DATA-PROTOTYPE (msg) mit Richtung DIRECTION = IN.
  • TYPE-TREF: Typisiert als STD-CPP-IMPLEMENTATION-DATA-TYPE mit Referenz auf /AUTOSAR/StateM/Imp/PowerModeMsg. Es sind weder OUT-Parameter noch synchrone Rückgabewerte definiert (Einweg-/Asynchroncharakter).
• EVENTS:
  • Aggregiert einen VARIABLE-DATA-PROTOTYPE namens response.
  • TYPE-TREF: Typisiert als STD-CPP-IMPLEMENTATION-DATA-TYPE mit Referenz auf /AUTOSAR/StateM/Imp/PowerModeRespMsg.
• Beziehungen & Kardinalitäten:
  • 1 SERVICE-INTERFACE enthält 1 Operation (METHODS) und 1 EVENT.
  • Direkte Modellkopplung an die Datentyp-Definitionen des State-Management-Subpakets (StateM/Imp).

3. Dynamisches Verhalten & Sequenzablauf

• Asymmetrisches Anforderungs-/Rückmelde-Muster:
  1. Anforderung (Egress / Client → Server): Der Client initiiert eine Zustandsänderung durch Aufruf der Proxy-Methode message(const PowerModeMsg& msg). Da kein Rückgabewert deklariert ist, erfolgt der Methodenaufruf als nicht-blockierender bzw. entkoppelter Request an den State Manager / Group Coordinator.
  2. Verarbeitung & Verteilung: Der Koordinator evaluiert den angeforderten Power-Mode innerhalb des Funktionsclusters State Management.
  3. Rückmeldung (Ingress / Server → Client): Die Bestätigung oder der neue Status erfolgt asynchron über das Event response. Der Client abonniert das Event (Subscribe(cacheSize)), registriert optional einen Callback (SetReceiveHandler(...)) und liest die Nutzdaten per GetNewSamples(...) aus.

4. Normative Relevanz & Entwickler-Hinweise

• Code-Generierung (ara::com Proxy/Skeleton):
  • Aus dem Modell generiert der Codegenerator die Klassen ara::sm::proxy::PowerModeClientProxy und ara::sm::skeleton::PowerModeClientSkeleton.
  • Applikationsentwickler binden auf Client-Seite ausschließlich den generierten Proxy ein.
• Spezifische Bindings für COMMUNICATION_GROUP_CLIENT:
  • Die Kategorie COMMUNICATION_GROUP_CLIENT signalisiert dem Tooling und Generator, dass kein klassischer Punkt-zu-Punkt-RPC vorliegt. Das Deployment erfordert eine entsprechende Bindung (z. B. SOME/IP oder lokales POSIX-IPC-Transportprotokoll), die Multicast-/Broker-Strukturen der Kommunikationsgruppe unterstützt.
• Datentypspezifikation:
  • Die Typen PowerModeMsg und PowerModeRespMsg müssen im SWC-Manifest als vollständige C++-Datenstrukturen mit definierten Serialisierungsregeln (z. B. Byte-Alignment, dynamische Längenfelder nach SOME/IP- bzw. IPC-Spezifikation) hinterlegt sein.