DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-fc8be1fd2c3d58e9 930 × 1025 px 2 Release(s)

Figure 9.96: Common interfaces of Diagnostic Management (2 of 2)

SHA-256 Inhalts-Fingerabdruck: fc8be1fd2c3d58e9bb9669d1a2df53aa03b597d23ca06deed44c699770ce3d1a

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Hybride Spezifikationsansicht bestehend aus einer tabellarischen Port-Interface-Spezifikation (AUTOSAR Meta-Modell DiagnosticDTCInformationInterface) und einem UML-Klassen-/Komponentendiagramm mit Stereotypen der AUTOSAR Adaptive Platform.
  • Funktionale Einordnung: AUTOSAR Adaptive Platform (EXP Software Architecture, R23-11/R24-11), Functional Cluster Diagnostic Management (ara::diag).
  • Technischer Zweck: Spezifikation der standardisierten C++-Laufzeitschnittstellen für Applikationen (Adaptive Application) zur Interaktion mit dem Fehlerspeicher (DTC Information, UDS-Status, Freeze Frames) sowie allgemeiner Hilfsschnittstellen (CancellationHandler, MetaInfo) für die asynchrone Diagnoseabwicklung im daemon-basierten Architekturmodell.

2. Komponenten, Entitäten & Schnittstellen

A. Port Interface DTCInformation (Meta-Modell: DiagnosticDTCInformationInterface)
  • Charakteristik: Nicht-generiert (Generated: No), standardisiertes Public API. Bietet Operationen bezogen auf ein konfiguriertes DiagnosticMemory-Ziel.
  • Operationen (Methoden):
    • Clear: Löschen einzelner DTCs oder DTC-Gruppen (UDS Service 0x14).
    • EnableControlDtc: Forciert das Reaktivieren der DTC-Aktualisierung (ControlDTCStatus = enabled), wenn Monitor-Bedingungen dies erzwingen (UDS Service 0x85).
    • GetControlDTCStatus: Abfrage des aktuellen Kontrollstatus für die Fehleraufzeichnung.
    • GetCurrentStatus: Liest das standardisierte UDS-DTC-Statusbyte (StatusOfDTC gem. ISO 14229-1) eines angegebenen DTCs aus.
    • GetEventMemoryOverflow: Gibt den Überlaufstatus des Ereignisspeichers zurück.
    • GetNumberOfStoredEntries: Liefert die Anzahl aktuell gespeicherter Fehlerspeichereinträge.
    • Notifier-Registrierungen (Observer-Pattern):
      • SetControlDtcStatusNotifier: Callback bei Modifikation der Control-DTC-Einstellung.
      • SetDTCStatusChangedNotifier: Callback bei Flanken-/Statuswechsel des UDS-DTC-Statusbytes.
      • SetEventMemoryOverflowNotifier: Callback bei Speicherüberlauf.
      • SetNumberOfStoredEntriesNotifier: Callback bei Änderung der Belegungsanzahl.
      • SetSnapshotRecordUpdatedNotifier: Callback bei Aktualisierung von Freeze-Frame-/Snapshot-Daten.
B. UML-Klassen & Komponenten
  • Adaptive Application (UML Component): Konsument der Diagnosedienste.
  • «aapFunctionalCluster» Diagnostic Management (UML Component, Kennzeichnung: daemon-based): Realisiert den zentralen Diagnose-Daemon im AP-System.
  • «aapAPI, aapNativeInterface» CancellationHandler:
    • Methoden: + IsCanceled(): bool, + SetNotifier()
    • Ermöglicht kooperativen Abbruch langlebiger Diagnosevorgänge.
  • «aapAPI, aapNativeInterface» MetaInfo:
    • Methoden: + GetContext(), + GetValue()
    • Transportiert UDS-Kontextinformationen (z. B. SA, TA, Tester-Verbindungs-ID, Session-/Security-Level).
C. Relationen & Stereotypen
  • Realization («realize» / gestrichelte Pfeile mit geschlossener hohler Spitze): Diagnostic Management implementiert die nativen Schnittstellen CancellationHandler und MetaInfo.
  • Usage («use» / gestrichelte Pfeile mit offener Spitze): Die Adaptive Application konsumiert CancellationHandler und MetaInfo.

3. Dynamisches Verhalten & Sequenzablauf

  • Synchrones / Polling-Muster: Getter-Operationen (GetCurrentStatus, GetControlDTCStatus, GetNumberOfStoredEntries, GetEventMemoryOverflow) erlauben der Applikation synchrone Abfragen des aktuellen Zustands im Fehlerspeicher.
  • Asynchrones Push- / Observer-Muster: Über Set*Notifier registriert die Applikation Handler. Treten Statusübergänge im Diagnostic Management Daemon auf (z. B. DTC qualifiziert/dequalifiziert, Snapshot aktualisiert), benachrichtigt der Daemon die Applikation via Callback.
  • Asynchrone Methodenabwicklung & Abbruch:
    • Zeitintensive Operationen wie Clear werden typischerweise über ara::core::Future / ara::core::Promise asynchron abgewickelt.
    • Der CancellationHandler signalisiert dem Handler via Polling (IsCanceled()) oder Event-gesteuert (SetNotifier()), ob eine laufende Routine/Operation durch den Client (UDS-Tester-Reset, Timeout oder Protokollabbruch) vorzeitig beendet werden muss.

4. Normative Relevanz & Entwickler-Hinweise

  • Keine Generierung (Generated: No): DTCInformation ist eine feste C++-API-Definition im Namespace ara::diag. Sie wird nicht vom AUTOSAR-Codegenerator erzeugt, sondern direkt gegen die Plattform-Bibliotheken gelinkt.
  • Modellierungs-Binding: Im ARXML-Manifest muss der Port der Applikation als DiagnosticDTCInformationInterface deklariert und mit dem entsprechenden DiagnosticMemory verknüpft sein.
  • Threading & Thread-Safety:
    • Die via Set*Notifier registrierten Callbacks laufen im Thread-Kontext des ara::diag-Runtimes bzw. IPC-Dispatchers der Applikation. Sie müssen reentrant, blockierungsfrei und thread-safe implementiert sein.
  • IPC-Kosten (daemon-based): Da das Diagnostic Management als Daemon realisiert ist, bedingen synchrone Aufrufe Interprozesskommunikation (IPC). Häufige Statusabfragen sollten zugunsten der Event-basierten Notifier vermieden werden.
  • Kontext-Transparenz via MetaInfo: Applikations-Handler müssen dynamische Kontextprüfungen (z. B. Zugriffsberechtigungen basierend auf aktiver Security-Level-ID) über MetaInfo::GetValue() abfragen, statt hardkodierte Zustände anzunehmen.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Name: DTCInformation | Technology: Port interface | Generated: No | Meta-model interface type: | DiagnosticDTCInformationInterface | Usage: Public API | Description: This interface provides operations on DTC information per configured DiagnosticMemory destination. | Clear Method for Clearing a DTC or a group of DTCs. | EnableControlDtc Enforce restoring ControlDTCStatus setting to enabled in case the monitor has some conditions or states demands to do so. | GetControlDTCStatus Contains the current status of the ControlDTCStatus. | GetCurrentStatus Retrieves the current UDS DTC status byte of the given DTC identifier. | GetEventMemoryOverflow Contains the current event memory overflow status. | GetNumberOfStoredEntries Contains the number of currently stored fault memory entries. | SetControlDtcStatusNotifier Registers a notifier function which is called if the control DTC setting is changed. | SetDTCStatusChangedNotifier Register a notifier function which is called if a UDS DTC status is changed. | SetEventMemoryOverflowNotifier Register a notifier function which is called if the current event memory overflow status changed. | SetNumberOfStoredEntriesNotifier Register a notifier function which is called if the number of currently stored fault memory entries changed. | Operations: | SetSnapshotRecordUpdatedNotifier Register a notifier function which is called if the SnapshotRecord is changed. | «aapFunctionalCluster» Diagnostic Management daemon-based | «aapAPI,aapNativeInterface» | CancellationHandler | + IsCanceled() + SetNotifier() | Adaptive Application | «aapAPI,aapNativeInterface» | MetaInfo | + GetContext() + GetValue() | «use» «use»

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SWArchitecture S. 128 9.88 Figure 9.88: Common interfaces of Diagnostic Management (2 of 2)
R24-11 AUTOSAR_AP_EXP_SWArchitecture S. 144 9.96 Figure 9.96: Common interfaces of Diagnostic Management (2 of 2)