Figure 5.1: Interfaces required by Diagnostic Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Komponentendiagramm mit detaillierter Klassenansicht (AP-Schnittstellenmethoden) gemäß AUTOSAR Adaptive Platform (AP) Standard.
• Funktionale Einordnung: Definiert die externen funktionalen Abhängigkeiten des Functional Clusters (FC) Diagnostic Management (ara::diag) im Kontext einer Daemon-basierten Architektur (daemon-based) gegenüber den Platform-Foundation-Clustern Persistency (ara::per) und Log and Trace (ara::log).
• Technischer Zweck: Spezifikation der standardisierten C++-Service- und Native-Schnittstellen, die der Diagnose-Daemon zur persistenten Speicherung diagnostischer Zustände (DTC-Status, Freeze Frames, Extended Data, Konfiguration) und zum systemweiten Logging/Tracing benötigt.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Functional Cluster

• «aapFunctionalCluster» Diagnostic Management (daemon-based): Zentraler Dienst zur Bearbeitung von UDS/DoIP-Diagnoseprotokollen, Verwaltung des Fehlerspeichers und Koordination von Diagnosesitzungen. Agiert als Service-Consumer.
• «aapFunctionalCluster» Persistency: Bereitsteller nichtflüchtiger Speicherzugriffe (ara::per).
• «aapFunctionalCluster» Log and Trace: Bereitsteller strukturierter Logging-Mechanismen (ara::log).

Schnittstellen & Realisierungen

• «aapAPI,aapPortInterface» FileStorage (Realisierung durch Persistency):
  • Typ: Port-basierte C++ API (ara::per::FileStorage).
  • Methoden: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo(), OpenFileReadOnly(): ReadAccessor, OpenFileReadWrite(): ReadWriteAccessor, OpenFileWriteOnly(): ReadWriteAccessor, RecoverFile(), ResetFile().
  • Verwendung: Blockweiser Dateizugriff für große Diagnosedaten (z. B. Routine-Control-Dumps, Zertifikate für SecurityAccess, Software-Update-Buffer).
• «aapAPI,aapPortInterface» KeyValueStorage (Realisierung durch Persistency):
  • Typ: Port-basierte C++ API (ara::per::KeyValueStorage).
  • Methoden: DiscardPendingChanges(), GetAllKeys(), GetValue(), KeyExists(), RecoverKey(), RemoveAllKeys(), RemoveKey(), ResetKey(), SetValue(), SyncToStorage().
  • Verwendung: Granulare, strukturierte Persistierung elementarer Diagnosedaten (DTC-Statusbits gemäß ISO 14229-1, Fault-Detection-Counter, Aging- und Cycle-Counter).
• «aapAPI,aapNativeInterface» Logger (Realisierung durch Log and Trace):
  • Typ: Direkte native C++ API (ara::log::Logger), bindungsfrei ohne Manifest-Port-Routing.
  • Methoden: IsEnabled(), Log(MsgId, Params), LogDebug(): LogStream, LogError(): LogStream, LogFatal(): LogStream, LogInfo(): LogStream, LogVerbose(): LogStream, LogWarn(): LogStream, WithLevel(): LogStream.
  • Verwendung: Tracing von Sitzungszuständen, Security-Ereignissen, fehlerhaften Anfragen und negativen Response Codes (NRCs).

Beziehungen & Stereotypen

• «use» «aapRequiredPort»: Port-basierte Abhängigkeit (R-Port) des Diagnostic Management zu FileStorage und KeyValueStorage. Erfordert ARXML-Port-Modellierung.
• «use» (zu Logger): Bibliotheksabhängigkeit / nativer Methodenaufruf auf Prozess-Ebene ohne Port-Abstraktion.
• Interface-Realization (gestrichelte Linie mit geschlossener Dreiecksspitze): Persistency implementiert FileStorage und KeyValueStorage; Log and Trace implementiert Logger.

3. Dynamisches Verhalten & Sequenzablauf

Startup- und Initialisierungsphase

1. Instanziierung & Binding: Der Diagnostic Daemon initialisiert die Logging-Kontexte via ara::log::CreateLogger() und bindet seine Port-Instanzen für Persistenz (OpenFileStorage(), OpenKeyValueStorage()).
2. Status-Restaurierung: Auslesen der bestehenden DTC-Zustände und Fehlerspeicher-Snapshots mittels KeyValueStorage::GetValue() bzw. Verifikation von Dateien via FileExists(). Bei Datenkorruption Triggerung von RecoverKey() bzw. RecoverFile().

Laufzeit-Operationen

• DTC-Statuswechsel & Speicherung:
  1. Diagnoseereignis führt zu Statusbit-Änderung (z. B. TestFailed).
  2. Synchrone oder asynchrone In-Memory-Aktualisierung über SetValue().
  3. Bei Transaktionsabschluss, Zündungswechsel oder Shutdown: Explizites Schreiben auf das physikalische Speichermedium via SyncToStorage(). Bei Abbrüchen: DiscardPendingChanges().
• Diagnose-Logging:
  • Jede UDS-Transaktion (Request/Response) und interne Zustandsänderung erzeugt Log-Streams (z. B. LogInfo() << ... oder LogWarn() << ...), welche intern asynchron in Ringpuffer geschrieben und an den DLT-Daemon weitergeleitet werden.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • Für KeyValueStorage und FileStorage müssen im Service-Instance- und Execution-Manifest entsprechende RPortPrototype-Elemente modelliert und den konkreten Persistenz-Instanzen zugewiesen werden.
  • Redundanz- und CRC-Konfigurationen in ara::per müssen den ASIL-Anforderungen der Diagnosefunktionen entsprechen.
• Echtzeit- und I/O-Einschränkungen:
  • SetValue() modifiziert primär den flüchtigen Cache. Aufrufe von SyncToStorage() sind blockierend/I/O-intensiv und dürfen nicht unkontrolliert in zeitkritischen Diagnose-Routinen aufgerufen werden (Flash-Wearout- und Latenz-Gefahr).
  • Streaming-Logging (LogStream) muss nicht-blockierend ausgelegt sein; Log-Level-Prüfung (IsEnabled()) ist vor ressourcenintensiven String-Formatierungen zwingend auszuwerten.
• Daemon-Isolation:
  • Da der Diagnostic Manager als eigenständiger Daemon modelliert ist, greifen Applikationen (Adaptive Applications) nicht direkt auf diese Persistenz-/Log-Instanzen des Daemons zu, sondern interagieren über die IPC-Schnittstelle von ara::diag. Die Persistenz-Integrität des Fehlerspeichers verbleibt vollständig in der Hoheit des Daemons.