Figure 9.85: Common interfaces of Diagnostic Management (1 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen-/Komponentendiagramm (AUTOSAR Adaptive Platform Metamodell-Sicht).
• Architektonische Einordnung: AUTOSAR Adaptive Platform (Release R22-11), Functional Cluster Diagnostic Management (ara::diag).
• Technischer Zweck: Spezifikation der Interaktionsmuster zwischen einer Adaptive Application (AA) und dem diagnostischen Subsystem (Diagnostic Management, daemon-basiertes Deployment). Es unterscheidet explizit zwischen nativen C++-Laufzeitschnittstellen (Conversation) und modellierten, service-/portbasierten Kommunikationsschnittstellen (DTCInformation).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application (UML-Komponente):
  • Konsument der Diagnosedienste im User-Space.
• Diagnostic Management (UML-Komponente):
  • Stereotyp: «aapFunctionalCluster».
  • Deployment-Attribut: daemon-based (Ausführung als separater OS-Prozess / Daemon, der UDS/DoIP-Verbindungen und Event-Memory managt und per IPC angebunden ist).

Schnittstellen & Realisierungen

• Conversation:
  • Stereotypen: «aapNativeInterface, aapAPI» (direkte C++-Sprachbindung/Klassen-API unter ara::diag::Conversation).
  • Bindung zur AA: «use» (direkte Instanziierung/Nutzung über C++-Header und Client-Bibliothek).
  • Realisierung: Realisiert durch Diagnostic Management (Dashed Line mit geschlossenem Pfeilkopf).
  • Operationen:
    • Statische Factory-/Lookup-Methoden (unterstrichen): GetAllConversations(), GetConversation(): Conversation, GetCurrentActiveConversations().
    • Zustandsabfragen & Aktionen: GetActivityStatus(), GetConversationIdentifier(), GetDiagnosticSecurityLevel(), GetDiagnosticSecurityLevelShortName(), GetDiagnosticSession(), GetDiagnosticSessionShortName(), ResetToDefaultSession().
    • Callback-/Notifier-Registrierungen: SetActivityNotifier(), SetDiagnosticSessionNotifier(), SetSecurityLevelNotifier().
• DTCInformation:
  • Stereotypen: «aapAPI, aapPortInterface» (als Port-Interface im Manifest modellierte Dienstschnittstelle).
  • Bindung zur AA: «use» über «aapRequiredPort» (RPort der AA konsumiert den PPort des Diagnostic Daemon via ARA::COM / IPC).
  • Realisierung: Realisiert durch Diagnostic Management.
  • Operationen:
    • Steuer-/Löschmethoden: Clear(), EnableControlDtc().
    • Status-/Speicherabfragen: GetControlDTCStatus(), GetCurrentStatus(), GetEventMemoryOverflow(), GetNumberOfStoredEntries().
    • Asynchrone Notifier: SetControlDtcStatusNotifier(), SetDTCStatusChangedNotifier(), SetEventMemoryOverflowNotifier(), SetNumberOfStoredEntriesNotifier(), SetSnapshotRecordUpdatedNotifier().

3. Dynamisches Verhalten & Sequenzablauf

1. Verbindungs- und Sitzungsverfolgung (Conversation):
   • Die AA ruft die statische Methode GetConversation() auf, um das spezifische Kontext-Handle für eine Diagnosesitzung (z. B. Tester-Verbindung via DoIP) zu erhalten.
   • Über SetDiagnosticSessionNotifier() und SetSecurityLevelNotifier() hinterlegt die AA Callbacks.
   • Trigger: Schaltet der externe Diagnosetester eine Session (UDS $10) oder schlägt die Security-Access-Routine (UDS $27) fehl bzw. gelingt, benachrichtigt der Daemon die AA asynchron über die Notifier.
   • Fallback: Über ResetToDefaultSession() kann die AA aktiv das Zurücksetzen auf Session 0x01 auslösen (z. B. bei sicherheitskritischen Fehlern im System).
2. DTC- und Fehlerspeicher-Interaktion (DTCInformation):
   • Polling vs. Event-driven: Neben synchronen bzw. blockierenden Get-Aufrufen (GetCurrentStatus(), GetNumberOfStoredEntries()) registriert die AA Notifier für Zustandswechsel.
   • Status-Änderungen: Tritt ein Fehlerspeicherüberlauf auf oder aktualisieren sich Snapshots/Freeze-Frames (UDS $19 04), triggert der Daemon via IPC den entsprechenden Handler (SetEventMemoryOverflowNotifier, SetSnapshotRecordUpdatedNotifier).
   • Löschzyklus: Clear() stößt das Löschen der Diagnosedaten an (UDS $14); die Rückmeldung erfolgt gemäß ARA-Fehlerbehandlungsmodell asynchron via ara::core::Future/Result.

4. Normative Relevanz & Entwickler-Hinweise

• Dualität des Interfacedesigns:
  • Conversation ist als native C++-API realisiert: Zugriff erfordert keine ARXML-Port-Modellierung, sondern das direkte Linken der ara::diag-Bibliothek und Inkludieren des entsprechenden C++-Headers.
  • DTCInformation ist ein Port-Interface: Erfordert zwingend die Modellierung im Software-Component-Description-Manifest (ARXML) mit definiertem RPortPrototype an der AA sowie entsprechendem Service-Mapping zur Instanz des Diagnostic Management.
• Daemon-basiertes IPC-Overhead:
  • Da Diagnostic Management daemon-basiert agiert, sind Aufrufe an DTCInformation Inter-Process-Calls (IPC). Zeitkritische Threads dürfen diese Methoden nicht blockierend aufrufen; Notifier laufen im Kontext der internen Dispatcher-Threads von ara::diag.
• Thread-Sicherheit & Callback-Semantik:
  • Registrierte Notifier (Set*Notifier) müssen wiedereintrittsfähig und thread-sicher ausgelegt sein. Callbacks dürfen keine langlaufenden Operationen ausführen, um den Empfangs- und Dispatch-Thread des Diagnosestacks nicht zu blockieren.
• Security & Session Management:
  • Applikationen, die zugriffsgeschützte Aktionen ausführen (z. B. Aktorkontrolle, Routine Control $31), müssen vor Ausführung über GetDiagnosticSecurityLevel() den aktuellen Sicherheitsstatus validieren oder den Status aktiv über SetSecurityLevelNotifier() nachführen.