Figure 9.85: Generated interfaces for request handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Struktur- und Interaktionsarchitektur nach AUTOSAR Adaptive Plattform-Modellierung).
• Technischer Zweck: Spezifikation des standardisierten Interaktionsmodells zwischen dem Functional Cluster Diagnostic Management (DM) in daemon-basierter Ausprägung und einer Adaptive Application (AA).
• Architektonische Einordnung: Kapselung der externen Fahrzeugdiagnose (UDS via DoIP nach ISO 13400 / ISO 14229-1/-5) im DM-Daemon. Die Anwendungslogik für Messwerte, Konfigurationsdaten und Diagnoseroutinen verbleibt in der AA und wird über generierte Schnittstellen (ara::diag) per prozessübergreifender Kommunikation (IPC) an den Daemon angebunden.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application: SWC/Prozess auf Betriebssystemebene; dient als Server/Provider für diagnosebezogene Nutzdaten und Routinenausführungen.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Zentraler Plattform-Daemon der Adaptive Platform; agiert als Protokollendpunkt gegenüber dem externen Diagnose-Tester und als Client/Konsument der anwendungsspezifischen Services.
• Port-Interfaces («aapPortInterface, aapAPI»):
  • Routine: Abbildung von UDS-Service 0x31 (RoutineControl).
    • + Offer(): Registriert den Routine-Handler beim DM-Daemon.
    • + StopOffer(): Meldet den Routine-Handler beim DM-Daemon ab.
    • + Start(): Trigger für Unterfunktion 0x01 (startRoutine).
    • + Stop(): Trigger für Unterfunktion 0x02 (stopRoutine).
    • + RequestResults(): Trigger für Unterfunktion 0x03 (requestRoutineResults).
  • DataIdentifier: Abbildung kompletter Diagnosedaten-Identifier (DIDs; UDS-Services 0x22 ReadDataByIdentifier und 0x2E WriteDataByIdentifier).
    • + Offer(), + StopOffer(): Steuerung der Service-Verfügbarkeit.
    • + Read(): Liest den vollständigen DID-Datenstrom aus der Applikation.
    • + Write(): Übergibt zu schreibende Datenbytes an die Applikation.
  • DataElement: Granulare Abbildung einzelner Datenelemente (z. B. innerhalb zusammengesetzter DIDs oder Freeze-Frame-/Snapshot-Records).
    • + Offer(), + StopOffer(): Steuerung der Service-Verfügbarkeit.
    • + Read(): Liest ein atomares Datenelement aus.
• Beziehungen & Stereotypen:
  • Adaptive Application ➔ Schnittstellen: Interface Realization (gestrichelte Linie mit geschlossener Pfeilspitze). Die AA implementiert die Schnittstellen und stellt die Callbacks/Methodenrümpfe bereit.
  • Diagnostic Management ➔ Schnittstellen: Dependency / Interface Usage («use», «aapRequiredPort»). Der DM-Daemon bindet die Schnittstellen über typisierte Required Ports (RPorts) ein, um Tester-Requests an die Provider weiterzuleiten.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung (Lifecycle Start):
   • Die AA instanziiert die generierten Skeleton-/Handler-Klassen.
   • AA ruft synchron Offer() auf (Routine::Offer(), DataIdentifier::Offer(), DataElement::Offer()). Der DM-Daemon bindet die Provider in seine interne Routing-Tabelle für aktive DIDs/RIDs ein.
2. Request Dispatching (Normalbetrieb, asynchron):
   • DID-Lese-/Schreibzugriff: Externer Tester sendet UDS-Request (0x22 / 0x2E). Der DM validiert Session- und Security-Levels. Bei Autorisierung ruft der DM Read() bzw. Write() über IPC auf. Die AA führt die Operation aus und meldet das Ergebnis (bzw. UDS Negative Response Codes / NRCs) via ara::core::Future/ara::core::Result zurück.
   • Routine-Steuerung: Externer Tester sendet 0x31 mit Subfunktion. Der DM ruft zielgerichtet Start(), Stop() oder RequestResults() auf.
3. Service-Deregistrierung (Lifecycle End):
   • Bei State-Transitionen (z. B. Execution Management Stop-Trigger) oder temporärer Nichtverfügbarkeit ruft die AA StopOffer() auf.
   • Eingehende Testeranfragen beantwortet der DM-Daemon daraufhin direkt mit negativem Response-Code (z. B. NRC 0x31 RequestOutOfRange oder NRC 0x22 ConditionsNotCorrect), ohne einen IPC-Call zur AA abzusetzen.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Generierung (ara::diag): Diese Interfaces werden nicht manuell deklariert, sondern vom AUTOSAR-Adaptive-Toolchain-Generator aus dem Diagnostic Extract (DEXT / Service Interface Deployment) abgeleitet. Entwickler müssen die generierten Pure-Virtual-Methoden (Read, Write, Start, etc.) in eigenen Servant-Klassen überschreiben.
• Asynchrone Ausführung & Non-Blocking-Vertrag: Die Methodenrückgaben erfolgen in ara::diag über ara::core::Future<...>. Implementierungen in der AA dürfen den aufrufenden Dispatcher-Thread niemals blockieren (z. B. kein langes Warten auf Hardware-Busse), da dies die IPC-Warteschlange des DM-Daemons ausbremst.
• Lebenszyklus-Disziplin: Vor dem Aufruf von Offer() empfangene Testeranfragen werden vom Daemon standardmäßig abgewiesen. Entwickler müssen sicherstellen, dass Offer() erst dann aufgerufen wird, wenn die internen Abhängigkeiten der AA vollständig initialisiert sind.
• Daemon-basierte IPC-Overheads: Da der DM als separater Prozess läuft, unterliegen alle Schnittstellenaufrufe Datenserialisierung und Kontextwechseln. Für hochfrequente oder zeitkritische DIDs sind Puffergrößen und Latenzen im OS-Scheduling zu berücksichtigen.