Figure 6.10: CG Template Service Interface Descritpion, example PowerMode

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Formales ARXML-Instanzauszug / Metamodell-Serialisierung eines AUTOSAR Adaptive ServiceInterface-Deskriptors (XML-Fragment gemäß AUTOSAR Adaptive Schema).
• Architektur-Kontext:
  • Subsystem: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com) in Interaktion mit State Management (ara::sm).
  • Funktionaler Zweck: Standardisiertes Template-Design (Communication Group Template, kurz CG Template) zur Abbildung von Kontroll- und Statuskommunikation. Am Beispiel des PowerMode-Dienstes wird demonstriert, wie interprozessuale bzw. maschinenweite Zustandsübergänge (hier State Management / Power Mode) über ein entkoppeltes Request-Response-Muster per ara::com typisiert und modelliert werden.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Metamodell-Struktur:
  • <SERVICE-INTERFACE>:
    • SHORT-NAME: PowerMode (eindeutiger Bezeichner des Service-Interfaces und Namensgeber der Kommunikationsgruppe, vgl. Annotation (1)).
    • CATEGORY: COMMUNICATION_GROUP (semantische Metadaten-Klassifizierung für den Code-Generator und Stack zur Identifikation des Kommunikationsgruppen-Musters).
  • <NAMESPACES>:
    • Aggregiert hierarchische <SYMBOL-PROPS> (ara → sm).
    • Definiert bindend das C++ Namespace-Target ::ara::sm für die Codegenerierung (proxy/skeleton).
  • <METHODS> → <CLIENT-SERVER-OPERATION>:
    • SHORT-NAME: message (RPC-Einstiegspunkt für Kommandos/Requests).
    • <ARGUMENTS> → <ARGUMENT-DATA-PROTOTYPE>:
      • SHORT-NAME: msg
      • DIRECTION: IN (unidirektionaler Eingabeparameter).
      • TYPE-TREF: Referenziert DEST="STD-CPP-IMPLEMENTATION-DATA-TYPE" auf /AUTOSAR/StateM/Imp/PowerModeMsg.
  • <EVENTS> → <VARIABLE-DATA-PROTOTYPE>:
    • SHORT-NAME: response (asynchroner Rückmelde-/Broadcast-Kanal).
    • TYPE-TREF: Referenziert DEST="STD-CPP-IMPLEMENTATION-DATA-TYPE" auf /AUTOSAR/StateM/Imp/PowerModeRespMsg.
• Beziehungen & Kardinalitäten:
  • ServiceInterface aggregiert exakt eine Operation (message, Kardinalität 1) und exakt ein Event (response, Kardinalität 1).
  • Keine OUT- oder INOUT-Parameter in der Operation: Entkopplung von Anfrage (Method) und Status-/Rückmeldung (Event).
  • Typ-Assoziationen verweisen über modellweite Pfade strikt auf standardisierte C++-Implementierungsdatentypen (STD-CPP-IMPLEMENTATION-DATA-TYPE) des Functional Clusters State Management (/AUTOSAR/StateM/Imp/...).

3. Dynamisches Verhalten & Sequenzablauf

Das Template erzwingt ein asynchron entkoppeltes Messaging-Pattern anstelle eines blockierenden RPCs:

1. Service Registration & Subscription:
   • Der Service-Provider (State Management Daemon / Skeleton) bietet die Instanz von ara::sm::PowerModeSkeleton an (OfferService()).
   • Der Service-Consumer (Client-Applikation / Proxy) abonniert das Event response (proxy->response.Subscribe(1)), um Statusrückmeldungen empfangen zu können.
2. Kommando-Trigger (Request-Pfad):
   • Consumer ruft proxy->message(msg) auf.
   • Da msg rein vom Typ DIRECTION: IN ist und keine OUT-Parameter existieren, liefert die Methode ein ara::core::Future<void> (nicht-blockierend bzw. Fire-and-Forget-Semantik auf Applikationsebene).
3. Zustandsverarbeitung & Notifikation (Response-Pfad):
   • Das State Management führt die interne Zustandsüberführung (Power Mode State Transition) asynchron aus.
   • Nach Abschluss oder Statusänderung publiziert das Skeleton das Event response.Send(respMsg).
   • Der Consumer empfängt das Event via Event-Receive-Handler (SetReceiveHandler) oder zyklisches Abfragen (GetNewSamples).

4. Normative Relevanz & Entwickler-Hinweise

• Generierte C++-Artefakte & Signatur:
  • Der AP-Codegenerator erzeugt unter dem Namespace ara::sm die Header powermode_proxy.h und powermode_skeleton.h.
  • Signatur auf Proxy-Ebene:

    namespace ara::sm::proxy::methods {
        using message = ...; // Aufruf: ara::core::Future<void> message(const PowerModeMsg& msg);
    }
    namespace ara::sm::proxy::events {
        using response = ...; // Event-Wrapper für PowerModeRespMsg
    }

• Korrelation & Parallelität:
  • Da die Zuordnung von Anfrage zu Rückmeldung nicht über die RPC-Infrastruktur (SessionId / Request-ID des Transport-Stacks) korreliert wird, muss eine logische Correlation-ID/Transaktions-ID innerhalb der Payloads PowerModeMsg und PowerModeRespMsg transportiert werden, falls mehrere Anfragen überlappend aktiv sind.
• Race-Condition-Vermeidung:
  • Applikations-Entwickler müssen proxy->response.Subscribe() zwingend vor dem Absenden des Methodenaufrufs proxy->message(...) ausführen und den Subscription-State verifizieren (GetSubscriptionState() == kSubscribed), da sonst schnelle Antworten verloren gehen.
• Deployment & Binding:
  • Das Template erfordert im weiteren AP-Workflow ein passendes Service-Interface-Deployment (z. B. SOME/IP- oder Shared-Memory/IPC-Deployment), in dem Method-ID, Event-ID und Event-Group konfiguriert werden.