Figure 9.100: Interfaces required by Diagnostic Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Architecture Modeling Profile «aap*»).
• Technischer Zweck: Spezifikation der strukturellen Abhängigkeiten und erforderlichen Serviceschnittstellen des Functional Clusters Diagnostic Management (DM) zu benachbarten Plattform-Clustern. Das Diagramm modelliert das DM als Daemon-basierte Architekturkomponente (daemon-based), die für Fehlerspeicherverwaltung, UDS-Protokollabwicklung (ISO 14229-1 via DoIP/ISO 13400-2) und Session-Handling auf standardisierte Basisdienste der Adaptive Platform zurückgreift.

2. Komponenten, Entitäten & Schnittstellen

Akteure / Functional Cluster:

• Diagnostic Management («aapFunctionalCluster», Tag: daemon-based): Konsument aller modellierten Schnittstellen; agiert als zentraler Plattform-Daemon.
• Persistency («aapFunctionalCluster»): Realisiert Persistierungsdienste für Diagnosedaten (DTC-Status, Freeze Frames, Extended Data Records, NvData).
• Log and Trace («aapFunctionalCluster»): Realisiert standardisierte Logging- und Tracing-Dienste (ara::log).

Schnittstellen, Typen & Methoden:

• FileStorage («aapAPI, aapPortInterface»):
  • Rolle: Dateibasierter Speicherzugriff für größere Datenblöcke (z. B. Crash-Logs, Trace-Puffer, binäre Speicherabbilder).
  • Methoden: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo(), OpenFileReadOnly(): ReadAccessor, OpenFileReadWrite(): ReadWriteAccessor, OpenFileWriteOnly(): ReadWriteAccessor, RecoverFile(), ResetFile().
• KeyValueStorage («aapAPI, aapPortInterface»):
  • Rolle: Granulare Key-Value-Persistierung für DTC-Ereignisse, Debounce-Counter, DID-Werte und Zustandskonfigurationen.
  • Methoden: DiscardPendingChanges(), GetAllKeys(), GetValue(), KeyExists(), RecoverKey(), RemoveAllKeys(), RemoveKey(), ResetKey(), SetValue(), SyncToStorage().
• Logger («aapAPI, aapNativeInterface»):
  • Rolle: Direkte native Schnittstelle (ara::log::Logger) zur Übermittlung strukturierter Log- und Diagnose-Trace-Events an DLT.
  • Methoden: IsEnabled(), Log(MsgId, Params), LogDebug(): LogStream, LogError(): LogStream, LogFatal(): LogStream, LogInfo(): LogStream, LogVerbose(): LogStream, LogWarn(): LogStream, WithLevel(): LogStream.

Beziehungen & Stereotypen:

• Port-basierte Kopplung («use», «aapRequiredPort»): DM greift über formale Required Ports auf FileStorage und KeyValueStorage zu (AUTOSAR-Port-Modellierung, typisiert über PortInterface).
• Native API-Nutzung («use»): Direkter C++-Aufruf von Logger ohne Port-Overhead (modelliert als NativeInterface).
• Interface-Realisierung (gestrichelte Linie mit geschlossener, nicht gefüllter Dreieckspitze): Persistency realisiert FileStorage und KeyValueStorage; Log and Trace realisiert Logger.

3. Dynamisches Verhalten & Sequenzablauf

• Diagnosedaten-Persistierung (Persistency):
  1. Beim Hochlauf initialisiert der DM-Daemon über seine Required Ports den Zugriff auf KeyValueStorage und FileStorage.
  2. Granulare Statusdaten (z. B. DTC-Statusmasken, UDS-Snapshots, Extended Data Records, Debounce-Zähler) werden über GetValue() abgefragt und bei Statusänderungen via SetValue() aktualisiert.
  3. Zur transaktionalen Sicherung im nichtflüchtigen Speicher ruft DM SyncToStorage() auf; fehlerhafte Transaktionen werden über DiscardPendingChanges() verworfen.
  4. Größere Diagnosedaten (z. B. Speicherabbilder, Log-Dateien) werden dateibasiert über OpenFileReadOnly(), OpenFileReadWrite() oder OpenFileWriteOnly() unter Verwendung der entsprechenden Accessor-Objekte gelesen oder geschrieben.
  5. Im Fehlerfall ermöglichen RecoverKey() bzw. RecoverFile() oder ResetKey()/ResetFile() die Wiederherstellung redundanter oder persistenter Datensätze.
• Diagnose-Logging und Tracing (Log and Trace):
  1. Während der Protokollverarbeitung und bei Zustandsübergängen prüft DM über Logger::IsEnabled(), ob Logging auf dem gewünschten Level aktiv ist.
  2. Bei aktivem Logging werden Diagnoseereignisse, UDS-Meldungen und Fehlerspeicheroperationen über Loglevel-spezifische Methoden (LogInfo(), LogWarn(), LogError(), LogDebug(), etc.) oder parametrisiert via Log(MsgId, Params) in den LogStream geschrieben.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturrolle des DM-Daemons: Diagnostic Management ist als zentraler Plattformdienst (daemon-based) ausgelegt und kapselt die UDS-Protokollverarbeitung sowie den Fehlerspeicher der Adaptive Platform.
• Port-basierte vs. native Kopplung:
  • Die Anbindung an Persistency erfolgt strikt über Ports («aapRequiredPort») mit typisierten Port-Interfaces («aapPortInterface»). Dies erfordert entsprechende Port-Konfigurationen im AUTOSAR-Manifest (ARXML) und erlaubt die Entkopplung von Persistenz-Backends.
  • Die Bindung an Logger ist als «aapNativeInterface» spezifiziert. Sie erfolgt ohne Port-Abstraktion direkt über C++-APIs (ara::log), was den Aufruf-Overhead bei hochfrequentem Logging minimiert.
• Transaktions- und Persistenzrichtlinien: Änderungen an Schlüsselwerten verbleiben im flüchtigen Speicherpuffer, bis SyncToStorage() explizit aufgerufen wird. Entwickler von Diagnosefunktionen müssen sicherstellen, dass kritische DTC-Zustandswechsel vor dem Shutdown oder bei Crash-Ereignissen synchronisiert werden.
• Wegfall der direkten IAM-Abhängigkeit: Das Functional Cluster DM modelliert keine direkte strukturelle Schnittstellenabhängigkeit mehr zu Identity and Access Management (PolicyDecisionPoint). Autorisierungs- und Zugriffskontrollmechanismen für Diagnosedienste werden architektonisch außerhalb dieser direkten Schnittstellenbeziehung behandelt.