Figure 9.90: Generated interfaces for request handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Spezifikationsdiagramm (Kombination aus tabellarischer Schnittstellendefinition und UML-Komponenten-/Schnittstellendiagramm der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifikation des Interaktionsmodells für die Diagnoseanfragebehandlung (Request Handling) zwischen dem Functional Cluster Diagnostic Management (DM) in daemon-basierter Ausprägung und einer Adaptive Application (AA), unterteilt in generische und modellgenerierte Schnittstellen.
• Architektonische Einordnung: Ergänzung der generierten, typspezifischen Schnittstellen (ara::diag) um standardisierte generische Schnittstellen (GenericUDSService, GenericRoutine) für Anwendungsfälle, in denen Diagnoseanfragen ohne vordefiniertes Datenmodell dynamisch oder payload-transparent von der Applikation verarbeitet werden.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application: SWC/Prozess auf Betriebssystemebene; implementiert sowohl generierte Schnittstellen als auch generische Nachrichten-Handler.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Zentraler Plattform-Daemon der Adaptive Platform; vermittelt UDS-Requests an registrierte generierte oder generische Schnittstellen.
• Tabellarische Port-Interfaces (nicht generiert, Generated: No, Public API):
  • GenericUDSService (Metamodell-Typ: DiagnosticGenericUdsInterface): Generische UDS-Nachrichtenweiterleitung.
    • HandleMessage: Nimmt vollständige UDS-Request-Nachrichten zur applikationsspezifischen Verarbeitung entgegen.
    • Offer() / StopOffer(): Aktiviert bzw. deaktiviert das Weiterleiten von Diagnoseanfragen durch das Diagnostic Management.
  • GenericRoutine (Metamodell-Typ: DiagnosticRoutineGenericInterface): Generische Abwicklung von RoutineControl-Requests (Service 0x31).
    • Offer() / StopOffer(): Aktiviert bzw. deaktiviert das Weiterleiten von Routine-Anfragen.
    • Start: Bearbeitung von RoutineControl-Requests mit SubFunction Start.
    • Stop: Bearbeitung von RoutineControl-Requests mit SubFunction Stop.
    • RequestResults: Bearbeitung von RoutineControl-Requests mit SubFunction RequestResults.
• Generierte Port-Interfaces («aapPortInterface, aapAPI»):
  • Routine: Generierte Schnittstelle für UDS-Service 0x31 (+ Offer(), + StopOffer(), + Start(), + Stop(), + RequestResults()).
  • DataIdentifier: Generierte Schnittstelle für DIDs (+ Offer(), + StopOffer(), + Read(), + Write()).
  • DataElement: Generierte Schnittstelle für atomare Datenelemente (+ Offer(), + StopOffer(), + Read()).
• Beziehungen & Stereotypen:
  • Adaptive Application ➔ Schnittstellen: Interface Realization (gestrichelte Linie mit geschlossener Dreiecksspitze).
  • Diagnostic Management ➔ Schnittstellen: Dependency / Interface Usage («use», «aapRequiredPort»).

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung (Lifecycle Start):
   • Die AA instanziiert die generierten Handler- bzw. generischen Service-Klassen.
   • AA ruft synchron Offer() auf (für GenericUDSService, GenericRoutine, Routine, DataIdentifier, DataElement). Das DM schaltet das Weiterleiten (Forwarding) eingehender Testeranfragen für die jeweiligen Identifier frei.
2. Request Dispatching (Normalbetrieb, asynchron):
   • Generischer UDS-Dienst: Eingehende UDS-Requests werden über GenericUDSService::HandleMessage direkt an die AA übergeben.
   • Generische Routine-Steuerung: Routine-Requests (0x31) für nicht dediziert modellierte Routine-IDs werden an GenericRoutine weitergeleitet (Start, Stop, RequestResults).
   • Typisierte/generierte DIDs & Routinen: Eingehende Standard-DIDs (0x22/0x2E) werden über DataIdentifier::Read()/Write() bzw. DataElement::Read() bedient; modellierte Routinen über Routine::Start(), Stop(), RequestResults().
3. Service-Deregistrierung (Lifecycle End):
   • Bei Shutdown oder temporärer Inaktivität ruft die AA StopOffer() auf.
   • Eingehende Testeranfragen für abgemeldete Services beantwortet das Diagnostic Management direkt mit entsprechenden NRCs, ohne Forwarding zur AA.

4. Normative Relevanz & Entwickler-Hinweise

• Generierte vs. statische Port-Interfaces: Die Spezifikation unterscheidet strikt zwischen nicht generierten Public APIs (GenericUDSService, GenericRoutine, Generated: No) für raw/generisches Message-Handling und generierten APIs (Routine, DataIdentifier, DataElement), die aus dem Diagnostic Extract (DEXT) kompiliert werden.
• Forwarding-Semantik (Offer/StopOffer): Der Aufruf von Offer() schaltet im DM-Daemon das Routing und Forwarding der entsprechenden UDS-Nachrichten frei. Erst nach erfolgreichem Offer() werden Requests an die Applikation durchgestellt.
• Asynchrone Ausführung & Non-Blocking-Vertrag: Alle Methodenaufrufe erfolgen nicht-blockierend über asynchrone Plattform-Primitive (ara::core::Future). Langlaufende Operationen dürfen den IPC-Thread des DM-Daemons nicht blockieren.
• Daemon-basierte IPC-Overheads: Sämtliche Aufrufe zwischen AA und DM unterliegen prozessübergreifender Interprozesskommunikation (IPC).