Figure 7.3: 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 zwischen fehlermeldenden Applikationsinstanzen (Adaptive Applications) und der zentralen Diagnoseinstanz (Diagnostic Management, ara::diag) über eine IPC- bzw. Kommunikations-Middleware.
• 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, dass Diagnose-Ereignisse prozess- und applikationsübergreifend aggregiert und im zentralen DM-Dienst verwaltet werden.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Komponenten:
  • Application (Adaptive Application, AA): Eigenständige POSIX-User-Space-Prozesse, welche funktionale Algorithmen ausführen und als Diagnose-Monitore agieren.
  • Middleware: Inter-Process Communication (IPC) bzw. Service-Oriented Architecture (SOA) Transportschicht (z. B. via ara::com oder plattformspezifische IPC-Sockets). Kapselt die Prozessgrenzen und entkoppelt Adressräume.
  • DM (Diagnostic Management Daemon / Functional Cluster ara::diag): Zentraler Plattform-Daemon auf dem Adaptive Core, verantwortlich für Debouncing, DTC-Statusbyte-Handling (ISO 14229-1), Fehlerspeicherung (Snapshot Data / Extended Data) sowie UDS-Gateway-Funktionen (äquivalent zu Dem/Dcm in Classic AUTOSAR).
• Entitäten & Kommunikationskanäle:
  • Diag_Event1, Diag_Event2, Diag_Event3: Konfigurierte Diagnose-Ereignisse (Instanzen von ara::diag::Event bzw. ara::diag::Monitor).
• Beziehungen & Kardinalitäten:
  • Application zu Diag_Event (1 : n): Eine Applikation kann genau ein (Diag_Event1) oder mehrere disjunkte Diagnose-Ereignisse (Diag_Event2, Diag_Event3) bedienen.
  • Diag_Event zu DM (n : 1): Sämtliche Diagnose-Events laufen unabhängig von ihrer Ursprungsapplikation zentral im DM-Cluster zusammen.
  • Eindeutigkeit: Jedes Diag_Event besitzt eine eindeutige Zuordnung zu einer Applikationsinstanz via InstanceSpecifier.

3. Dynamisches Verhalten & Sequenzablauf

1. Event-Trigger: Ein lokaler Monitor innerhalb der Applikation detektiert während zyklischer oder ereignisbasierter Plausibilitätsprüfungen einen Fehler (z. B. Grenzwertüberschreitung, Bus-Timeout).
2. Event-Reporting (Applikationsebene): Aufruf des typsicheren C++-API-Endpoints der Instanz (z. B. ara::diag::Monitor::ReportMonitorStatus() oder Setzen des EventStatus).
3. Transport (Middleware): Die Meldung wird marshallt und asynchron via Middleware über die Prozessgrenze zum DM-Daemon transportiert.
4. Zentrale Verarbeitung (DM):
   • Auswertung und Filterung über Entprellalgorithmen (Debouncing, sofern im DM konfiguriert).
   • Berechnung und Aktualisierung des DTC-Statusbytes (z. B. Bits testFailed, confirmedDTC).
   • Triggerung der Persistierung von Umgebungsdaten (Freeze Frames, Extended Data Records) über den Persistency-Cluster (ara::per) ins NVM.
5. Entkopplung: Der Meldevorgang blockiert den Ausführungskontext der meldenden Applikation nicht mit Schreiblatenzen der persistenten Speicherung.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::diag): Applikationsentwickler binden Diagnose-Ereignisse über das C++-Interface ein (Instanziierung via ara::core::InstanceSpecifier aus dem Adaptive Manifest). Es existiert kein direkter Speicherzugriff auf DTCs oder Statusbytes – die gesamte Statusverwaltung obliegt dem DM.
• Prozess-Isolation & Fehlertoleranz: Durch die Entkopplung über die Middleware führt ein Absturz einer fehlerhaften Applikation nicht zum Ausfall des DM oder zur Verfälschung von Diagnoseevents paralleler Applikationen.
• IPC-Overhead & Pre-Debouncing: Das Melden über Middleware verursacht Inter-Prozess-Context-Switches. Bei hochfrequenten Prüfungen muss das Entprellen (Pre-Debouncing) applikationsseitig im Monitor erfolgen, um ein IPC-Flooding des DM-Daemons zu verhindern.
• Manifest-Konfiguration: Jedes Diag_Event muss im Diagnostic Execution/Extract Manifest konsistent definiert, dem entsprechenden DiagnosticTroubleCode (DTC) zugewiesen und mit den relevanten Freigabebedingungen (Enable Conditions) verknüpft sein. Fehlt die Manifest-Bindung, schlägt die Initialisierung des Event-Objekts zur Laufzeit fehl.