Figure 6.27: UpdateRate Class

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: C++-Klassenschnittstellen-Listing / API-Signaturdeklaration (generierter Skeleton-Code).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R17-03 / AP R1.1.0), Kommunikations-Management (ara::com).
• Funktionale Einordnung: Dargestellt ist die Skeleton-/Server-seitige C++-Klassenrepräsentation eines AUTOSAR-Service-Interface-Fields namens UpdateRate. Ein Field in ara::com kombiniert bis zu drei Kommunikationsmuster auf demselben Datum: Getter (Request/Response), Setter (Request/Response) und Notifier (Publish/Subscribe-Event).

2. Komponenten, Entitäten & Schnittstellen

• Klasse UpdateRate: Generierte C++-Field-Klasse auf Server- bzw. Skeleton-Ebene.
• Typ-Alias:
  • using FieldType = uint32_t;: Stark typisierter Payload-Datentyp des Fields.
• Elementfunktionen (Schnittstellenverträge):
  • void Update(const FieldType& data):
    • Entspricht semantisch der Send()-Methode eines ara::com-Events.
    • Löst das Versenden einer Benachrichtigung an alle subscribierten Clients aus (sofern Notifier modelliert ist).
    • Initialisiert den stack-internen Cache des Felds für autonome Getter-Antworten.
  • void RegisterGetHandler(std::function<ara::com::Future<FieldType>()> getHandler):
    • Registriert eine Callback-Funktion zur Bearbeitung eingehender Get-Anfragen.
    • Rückgabetyp des Handlers ist ein asynchrones ara::com::Future<FieldType>.
  • void RegisterSetHandler(std::function<ara::com::Future<FieldType>(const FieldType& data)> setHandler):
    • Registriert den Setter-Callback zur Validierung und Übernahme neuer Werte bei Client-Set-Anfragen.
    • Rückgabetyp ist ara::com::Future<FieldType>; der darin gesetzte finale Wert wird dem anfragenden Client quittiert und zeitgleich per Notifier gebroadcastet.

3. Dynamisches Verhalten & Sequenzablauf

A. Initialisierungs- & Startphase

1. Instanziierung: Das Service-Skeleton wird durch die Applikation erzeugt.
2. Handler-Registrierung:
   • Falls das Field Setter-Zugriff erlaubt, muss RegisterSetHandler() aufgerufen werden.
   • RegisterGetHandler() ist optional.
3. Initiale Wertbelegung:
   • Bedingung ohne Getter-Handler: Falls kein getHandler registriert wird, muss die Applikation mindestens einmal vor OfferService() die Methode Update() aufrufen, um den Initialwert in ara::com abzulegen.

B. Laufzeit-Trigger & Signalpfade

• Eingehender Get-Request:
  • Mit registriertem GetHandler: ara::com ruft den Callback asynchron auf; der gelieferte ara::com::Future-Wert wird serialisiert und an den Client übermittelt.
  • Ohne GetHandler: ara::com bedient den Request autonom ohne Applikations-Interaktion direkt aus dem durch Update() gecachten Datenbestand.
• Eingehender Set-Request:
  1. Client sendet neuen Wert.
  2. ara::com ruft den registrierten setHandler(data) auf.
  3. Applikation validiert die Daten, aktualisiert interne Zustände und füllt das ara::com::Promise/ara::com::Future.
  4. Nach Auflösung des Futures sendet ara::com die Antwort an den Requester und verteilt den neuen Wert automatisch als Notifier-Event an alle Abonnenten.
• Autonomes Update (Event-Pfad):
  • Die Server-Applikation ruft aktiv Update(data) auf, wenn sich interne Sensordaten oder Zustände ändern; ara::com versendet die Notification-PDU/SOME/IP-Event-Message an alle aktiven Subscriber.

4. Normative Relevanz & Entwickler-Hinweise

• Zwingende Reihenfolge / Deadlock- & Fehlervermeidung:
  • Unterbleibt sowohl die Registrierung eines GetHandler als auch der Initialaufruf von Update() vor dem Aufruf von OfferService(), schlagen Client-Get-Requests fehl oder verhalten sich undefiniert.
• Vermeidung redundanter Notifications:
  • Innerhalb des setHandler darf kein separater Aufruf von Update() erfolgen, da ara::com den Rückgabewert des Setters bereits normativ an das Notifier-Event weiterleitet. Ein zusätzlicher Update()-Aufruf führt zu doppelten Netzwerk-Bursts.
• Asynchronitäts- und Threading-Modell:
  • Die Callbacks laufen typischerweise auf Worker- oder Dispatch-Threads der Middleware-Laufzeitumgebung. Alle Datenzugriffe im getHandler bzw. setHandler müssen threadsicher gekapselt sein.
  • Länger dauernde Berechnungen dürfen nicht synchron im Handler blockieren, sondern müssen über ara::com::Promise / ara::com::Future entkoppelt werden, um den Kommunikations-Threadpool nicht zu erschöpfen.