Figure 9.109: Generated interfaces for request handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Spezifikationsdiagramm (tabellarische Schnittstellendefinition und UML-Komponenten-/Schnittstellendiagramm der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifikation des Interaktionsmodells für Request Handling zwischen dem Functional Cluster Diagnostic Management (DM) (daemon-based) und einer Adaptive Application (AA) unter Verwendung von Callback-Methoden.
• Architektonische Einordnung: Neuausrichtung des Schnittstellenmodells ab R25-11: Der DM-Daemon tritt nun als Realisierer/Server der Diagnose-Port-Interfaces auf, während die Adaptive Application die Schnittstellen als Client über Required Ports («use», «aapRequiredPort») einbindet und anwendungsspezifische Handler als Callbacks («aapCallbackMethod») registriert.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application: SWC/Prozess auf Betriebssystemebene; fungiert über Required Ports als Konsument der Schnittstellen und stellt Implementierungen für Callback-Methoden bereit.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Zentraler Plattform-Daemon der Adaptive Platform; realisiert die Port-Interfaces und führt registrierte Anwendungs-Callbacks bei eintreffenden Diagnoseanfragen aus.
• Tabellarische Port-Interfaces (nicht generiert, Generated: No, Public API):
  • GenericUDSService: Am oberen Rand als Tabellenfragment mit den Operationen Offer und StopOffer dargestellt (Forwarding-Steuerung von UDS-Requests).
  • GenericRoutine: Generische Schnittstelle zur Behandlung von RoutineControl-Requests (Service 0x31) mit den Operationen Offer, StopOffer, Start, Stop, RequestResults.
• UML-modellierte Port-Interfaces («aapPortInterface, aapAPI»):
  • Routine: Port-Methoden + Offer(), + StopOffer(); Diagnose-Callbacks («aapCallbackMethod»): + RequestResults(), + Start(), + Stop().
  • DataIdentifier: Port-Methoden + Offer(), + StopOffer(); Diagnose-Callbacks («aapCallbackMethod»): + Read(), + Write().
  • DataElement: Port-Methoden + Offer(), + StopOffer(); Diagnose-Callback («aapCallbackMethod»): + Read().
• Beziehungen & Stereotypen:
  • Diagnostic Management (daemon-based) ➔ Schnittstellen: Interface Realization (gestrichelte Linie mit geschlossener/hohler Dreiecksspitze). Das DM realisiert die Port-Interfaces.
  • Adaptive Application ➔ Schnittstellen: Dependency / Port Usage («use», «aapRequiredPort»). Die AA bindet die Schnittstellen über Required Ports ein.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Bereitstellung & Callback-Registrierung (Lifecycle Start):
   • Das Diagnostic Management stellt die Port-Interfaces bereit.
   • Die Adaptive Application bindet die Required Ports ein und initialisiert die Callback-Handler.
   • Durch Aufruf von Offer() registriert die AA ihre Callback-Implementierungen beim DM-Daemon und aktiviert die Weiterleitung von Anfragen.
2. Request Dispatching via Callbacks (Normalbetrieb, asynchron):
   • Eingehende UDS-Requests (z. B. 0x22 Read, 0x2E Write, 0x31 RoutineControl) werden vom DM-Daemon validiert (Session, Security).
   • Bei erfolgreicher Validierung ruft der DM-Daemon die von der AA bereitgestellten Methoden via Callback («aapCallbackMethod»: Read(), Write(), Start(), Stop(), RequestResults()) über IPC auf.
   • Die AA verarbeitet die Daten/Routinen und gibt das Ergebnis asynchron zurück.
3. Service-Deregistrierung (Lifecycle End):
   • Die AA ruft StopOffer() am Required Port auf, um das Forwarding zu deaktivieren und die Callbacks abzumelden.
   • Eingehende Testeranfragen werden vom DM-Daemon abgewiesen.

4. Normative Relevanz & Entwickler-Hinweise

• Paradigmenwechsel zu Callback-Methoden («aapCallbackMethod»): Ab Release R25-11 wird die Trennung zwischen Port-Lebenszyklus (Offer, StopOffer) und Daten-/Ablaufverarbeitung durch das Stereotyp «aapCallbackMethod» formal im Metamodell verankert. Die AA implementiert Callbacks, während die Port-Schnittstelle vom DM-Daemon realisiert wird.
• Port-Richtung: Entwickler müssen beachten, dass die AA die Diagnose-Interfaces nun über Required Ports konsumiert («aapRequiredPort»), anstatt wie in früheren Releases als Skeleton-Provider aufzutreten.
• Asynchronität & Non-Blocking: Callback-Methoden in der AA werden im Kontext von IPC-Dispatchern ausgeführt und müssen strikt nicht-blockierend gehalten werden (ara::core::Future).
• Lifecycle-Disziplin: Vor Aufruf von Offer() müssen alle für die Callbacks erforderlichen Ressourcen und Datenstrukturen in der AA einsatzbereit sein.