Figure 9.105: Common interfaces of Diagnostic Management (2 of 3)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm mit Schnittstellenspezifikation (Interface Realization & Dependency).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Diagnostic Management (ara::diag), dokumentiert in AUTOSAR_AP_EXP_SWArchitecture (Figure 9.105, Teil 2 von 3).
• Funktionaler Zweck: Modellierung der generischen, querschnittlichen C++-Laufzeitschnittstellen (Common Interfaces) zwischen dem daemon-basierten Diagnose-Stack (Diagnostic Management) und benutzerdefinierten Diagnose-Service-Providern innerhalb einer Adaptive Application. Die Interfaces dienen der Bereitstellung von Protokoll-/Kontextmetadaten (MetaInfo) und der kooperativen Unterbrechungssteuerung (CancellationHandler) bei langlaufenden UDS-Diensten.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

1. Adaptive Application (UML-Komponente):
   • Konsumierende Applikationsinstanz im User Space, welche Diagnose-Handler (z. B. für Routine Control, Data Identifier Read/Write) implementiert.
2. Diagnostic Management (Stereotyp: «aapFunctionalCluster», Eigenschaft: daemon-based):
   • Bereitstellender AUTOSAR Adaptive Functional Cluster. Läuft architektonisch als eigenständiger System-Daemon und realisiert die UDS/DoIP-Session- und Protokollabwicklung.
3. CancellationHandler (Stereotyp: «aapAPI,aapNativeInterface»):
   • Natives C++-Interface (ara::diag::CancellationHandler).
   • Operationen:
     • + IsCanceled(): Polling-Methode zur Abfrage, ob die aktuelle Diagnoseanforderung abgebrochen wurde.
     • + SetNotifier(): Registrierung eines Callbacks (std::function), der bei Abbruch durch den Stack asynchron benachrichtigt wird.
4. MetaInfo (Stereotyp: «aapAPI,aapNativeInterface»):
   • Natives C++-Interface (ara::diag::MetaInfo).
   • Operationen:
     • + GetContext(): Rückgabe des operativen Ausführungskontexts des Diagnose-Requests.
     • + GetValue(): Zugriff auf schlüsselbasierte Metadaten der UDS-Transaktion (z. B. Tester-Quelladresse, Zieladresse, Protokolltyp).

Beziehungen & Abhängigkeiten

• Interface Realization (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze):
  • Diagnostic Management → CancellationHandler: Der Daemon bzw. die generierte ara::diag-Laufzeitumgebung implementiert die konkrete Instanz des Handlers.
  • Diagnostic Management → MetaInfo: Der Daemon instantiiert und befüllt das Metadaten-Objekt basierend auf dem empfangenen PDU/DoIP-Transportframe.
• Usage Dependency (gestrichelte Linie mit offener Pfeilspitze, Stereotyp «use»):
  • Adaptive Application → CancellationHandler: Applikationsmethoden erhalten eine Referenz auf den Handler zur Abbruchüberwachung.
  • Adaptive Application → MetaInfo: Applikationsmethoden fragen Transaktionsparameter über die Schnittstelle ab.

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Eingang & Kontextinitialisierung:
   • Ein UDS-Request (z. B. Service 0x31 RoutineControl oder 0x2E WriteDataByIdentifier) erreicht den Diagnostic Management Daemon.
   • Der Daemon extrahiert Transport- und Sessiondaten, erzeugt eine konkrete MetaInfo-Instanz und initialisiert einen CancellationHandler.
2. Aufruf der Applikationslogik:
   • Der Stack delegiert den Request via IPC an die zuständige Adaptive Application. MetaInfo und CancellationHandler werden als Referenzen an die Service-Methode übergeben.
3. Kontextauswertung:
   • Die Applikation ruft synchron MetaInfo::GetContext() und MetaInfo::GetValue() auf, um tester-spezifische Zugriffsprüfungen (z. B. Security-Level, Adressvalidierung) durchzuführen.
4. Asynchrone Überwachung & Abbruch (Cancellation Flow):
   • Polling-Pfad: Bei iterativer oder zeitintensiver Verarbeitung prüft die Applikation zyklisch CancellationHandler::IsCanceled().
   • Event-Pfad: Die Applikation registriert via CancellationHandler::SetNotifier() einen Notifier.
   • Trigger: Tritt ein UDS-Protokollereignis ein (z. B. P2/P2*-Timeout, Session-Reset durch Tester, S3-Timeout oder Überschreiben durch höher priorisierte Diagnoseanforderung), setzt der Daemon den Status auf canceled und feuert den gesetzten Notifier.
   • Reaktion: Die Applikation bricht die laufende Hardware-/Software-Aktion unverzüglich ab, gibt Ressourcen frei und beendet die Methode kooperativ.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::diag):
  • CancellationHandler erzwingt kooperatives Multitasking. Der Stack bricht Threads der Applikation nicht hart ab; die Applikation ist normativ verpflichtet, IsCanceled() regelmäßig abzufragen oder per SetNotifier() blockierende I/O-Vorgänge sauber abzubrechen.
  • Ignoriert eine Applikation den Abbruch, drohen UDS-Protokollverletzungen (z. B. NRC 0x78 Response Pending Deadlocks oder Überschreitung der P2/P2*-Zeiten).
• Speicher- und Threading-Restriktionen:
  • Instanzen von MetaInfo und CancellationHandler besitzen eine an die Lebensdauer des jeweiligen Service-Aufrufs gebundene Gültigkeit (Scope Lifetime). Zeiger oder Referenzen darauf dürfen nicht über die Rückkehr des asynchronen Future/Promise-Ergebnisses hinaus in der Applikation gespeichert werden.
  • Der über SetNotifier() registrierte Callback kann im Kontext eines Worker-Threads des Diagnostic Management Daemons bzw. der ARA-Laufzeitumgebung aufgerufen werden; Thread-Sicherheit und Deadlock-Freiheit (Reentrancy, Mutex-Vermeidung im Callback) liegen in der Verantwortung des Applikationsentwicklers.
• Konfigurationsaspekt:
  • Unterstützte Metadaten-Schlüssel in MetaInfo (z. B. SA Source Address, TA Target Address) hängen von der UDS/DoIP-Stack-Konfiguration im ARXML-Manifest (DiagnosticServerConfiguration) ab.