Figure 7.5: Example of diagnostic event usage

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles architektonisches Software-Architekturdiagramm (Komponenten- und Interaktionsmodell) der AUTOSAR Adaptive Platform.
• Technischer Zweck: Visualisierung der funktionalen Entkopplung und Interaktion zwischen Diagnose-Monitoren fehlermeldender Applikationsinstanzen (Adaptive Applications) und der zentralen Diagnoseverwaltung (Diagnostic Management, DM) über den Functional Cluster ara::diag.
• Architektonische Einordnung: Umsetzung der Diagnose-Architektur gemäß AUTOSAR_SWS_Diagnostics zur Erfüllung von SRS_Diag_04167 (Reporting of diagnostic events by applications). Es demonstriert, wie Diagnose-Ereignisse über diskrete Monitore erfasst und im zentralen DM-Cluster über eine zweistufige Verarbeitungsfolge (Event processing und DTC processing) verarbeitet werden.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Komponenten:
  • Application A, Application B (Adaptive Applications): Eigenständige POSIX-User-Space-Prozesse, welche funktionale Algorithmen ausführen und spezifische Diagnose-Monitore kapseln.
  • Monitor1 (in Application A), Monitor2, Monitor3 (in Application B): Explizite Software-Monitore innerhalb der Applikationen, welche spezifische Prüfungen durchführen und den Status an die Diagnoseverwaltung melden.
  • ara::diag: Der Functional Cluster für Diagnose (vormals generisch Middleware) zur standardisierten prozessübergreifenden Kommunikation zwischen Applikationsmonitoren und DM.
  • DM (Diagnostic Management Daemon): Zentraler Plattform-Daemon mit strukturierter zweistufiger interner Verarbeitung:
    • Event processing: Erste Stufe zur Entprellung (Debouncing) und Aggregation der gemeldeten Diagnose-Ereignisse.
    • DTC processing: Nachgelagerte Stufe zur Qualifikation, DTC-Statusbyte-Berechnung (ISO 14229-1), Umgebungsdatenspeicherung und Fehlerbehandlung.
• Entitäten & Kommunikationskanäle:
  • DiagEvent1, DiagEvent2, DiagEvent3: Konfigurierte Diagnose-Ereignisse (ohne Unterstrich benannt).
• Beziehungen & Kardinalitäten:
  • Application zu Monitor (1 : n): Application A enthält einen Monitor (Monitor1), Application B enthält mehrere Monitore (Monitor2, Monitor3).
  • Monitor zu DiagEvent (1 : 1): Jeder Monitor ist genau einem Diagnose-Event zugeordnet (Monitor1 <-> DiagEvent1, Monitor2 <-> DiagEvent2, Monitor3 <-> DiagEvent3).
  • Bidirektionale Interaktion (Monitor <-> DM): Die gestrichelten Doppelpfeile symbolisieren bidirektionalen Informationsaustausch (Status-Reporting von Monitor an DM sowie Rückmeldungen, Statusabfragen oder Freigabebedingungen von DM an den Monitor).
  • Interner Ablauf im DM (Event processing -> DTC processing): Gerichteter Übergang von der Event-Verarbeitung zur DTC-Verarbeitung.

3. Dynamisches Verhalten & Sequenzablauf

1. Monitor-Plausibilisierung: Ein lokaler Monitor (Monitor1, Monitor2 oder Monitor3) führt zyklische oder ereignisbasierte Prüfungen durch.
2. Bidirektionale Interaktion über ara::diag:
   • Der Monitor meldet das Prüfungsergebnis über die Schnittstelle ara::diag an den DM (z. B. via ReportMonitorStatus()).
   • Über die bidirektionale Verbindung empfängt der Monitor Zustandsinformationen oder Freigabebedingungen (z. B. Enable Conditions, Operation Cycles).
3. Event processing (DM):
   • Das gemeldete DiagEvent wird im ersten Schritt im DM entprellt (Debouncing) und vorverarbeitet.
4. Übergang zu DTC processing (DM):
   • Nach erfolgreicher Qualifizierung des Events wird der interne Trigger an das DTC processing übergeben.
5. DTC processing & Persistierung:
   • Das DTC-Statusbyte wird gemäß ISO 14229-1 aktualisiert (z. B. Bits testFailed, confirmedDTC).
   • Bei qualifiziertem Fehler werden Freeze Frames und Extended Data Records über den Persistency-Cluster (ara::per) im NVM gesichert.

4. Normative Relevanz & Entwickler-Hinweise

• Monitor-Modell & API-Vertrag (ara::diag): Applikationsentwickler implementieren Monitore als Instanzen von ara::diag::Monitor. Die Trennung verdeutlicht, dass Diagnoseüberwachungen an konkrete Monitore gebunden sind, welche über ara::diag typsicher an den DM angebunden werden.
• Bidirektionalität: Die Doppelpfeile betonen, dass Diagnose in Adaptive AUTOSAR keine reine Einwegmeldung ist: Monitore müssen auf Status- und Kontrollsignale des DM (z. B. DTC-Unterdrückung, Deaktivierung durch Enable Conditions) reagieren können.
• Zweistufige Architektur (Event -> DTC): Entwickler müssen die Kaskadierung von Event zu DTC berücksichtigen. Debouncing und Fehlerqualifikation finden auf Event-Ebene statt, bevor DTC-Status und Fehlerspeicher aktualisiert werden. Mehrere Events können demselben DTC zugeordnet sein.
• Manifest-Konfiguration: Sowohl Monitore als auch DiagEvent-Instanzen sowie die Verknüpfung von Event zu DTC müssen im Diagnostic Manifest formal modelliert werden (DiagnosticEvent, DiagnosticTroubleCode).