Figure 9.102: Interfaces for Managing Multiple Conditions, Events, and Monitors

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Schnittstellenspezifikation (AUTOSAR Adaptive Platform Architecture Model).
• Funktionaler Kontext: Darstellung der Schnittstellenarchitektur des Functional Clusters Diagnostic Management (DM) (ara::diag) zur Verwaltung aggregierter Diagnose-Entitäten über die Port-Schnittstellen MultipleCondition, MultipleEvent und MultipleMonitor.
• Systemische Einordnung: Bündelung und Abstraktion von Diagnose-Funktionalitäten für Adaptive Applications. Anstelle statischer Einzelports pro Diagnose-Event/-Monitor erlaubt das Pattern die dynamische oder parameterbasierte Interaktion mit mehreren Events, Monitoren und Freigabebedingungen (Enable Conditions) über gemeinsame generische Port-Interfaces.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

• Adaptive Application: Konsumenten-Komponente im Anwendungsraum (OS-Prozesskontext der Applikation).
• «aapFunctionalCluster» Diagnostic Management: Plattform-Kernkomponente zur Diagnoseabwicklung nach UDS/ISO 14229, annotiert als daemon-based (zentraler Plattform-Hintergrundprozess mit IPC-Anbindung).

Port-Interfaces & Operationen

• «aapAPI, aapPortInterface» MultipleCondition:
  • + GetCondition(): Abfrage des aktuellen Status einer Freigabebedingung (Condition/Enable Condition).
  • + SetCondition(): Setzen/Aktualisieren des Status einer Diagnosebedingung zur Freigabe oder Sperrung der Event-/Monitor-Ausführung.
• «aapAPI, aapPortInterface» MultipleEvent:
  • + GetDebouncingStatus(): Abfrage des Entprellungsstatus (Debounce-Status) des adressierten Events.
  • + GetDTCNumber(): Abfrage der zugeordneten Diagnostic Trouble Code (DTC)-Nummer (3-Byte UDS-DTC).
  • + GetEventStatus(): Abfrage des UDS-Statusbytes (StatusOfDTC nach ISO 14229-1, z. B. testFailed, confirmedDTC).
  • + GetFaultDetectionCounter(): Abfrage des aktuellen Fehlervalidierungszählers (FDC) im Bereich [-128, +127].
  • + SetEventStatusChangedNotifier(): Registrierung eines Callback-/Notifier-Funktors zur asynchronen Benachrichtigung bei Statusbit-Änderungen.
• «aapAPI, aapPortInterface» MultipleMonitor:
  • + ConfigureMonitor(): Parametrierung und Zuordnung der Monitor-Instanz.
  • + Offer(): Aktivierung und Registrierung der Monitor-Dienstbereitschaft am DM-Daemon.
  • + ReportMonitorAction(): Übermittlung des Testergebnisses (z. B. PASSED, FAILED, PREPASSED, PREFAILED).
  • + StopOffer(): Deregistrierung und Deaktivierung des Monitors.

Beziehungen & Stereotypen

• Interface Realization (gestrichelte Linie mit geschlossenem Dreieckspfeil): Diagnostic Management realisiert und implementiert die drei Schnittstellen MultipleCondition, MultipleEvent und MultipleMonitor.
• Dependency / Required Port («use», «aapRequiredPort», offene Pfeile): Die Adaptive Application deklariert jeweils R-Ports vom Typ der drei Interfaces zur Interaktion mit dem Diagnosedämon.

3. Dynamisches Verhalten & Sequenzablauf

1. Monitor-Initialisierung & Lebenszyklus (MultipleMonitor):
   • Applikation konfiguriert Monitore über ConfigureMonitor().
   • Aufruf von Offer() publiziert die Ausführungsbereitschaft der Monitor-Logik gegenüber dem Diagnostic Management.
   • Zur Laufzeit übermittelt die zyklische oder ereignisbasierte Prüfroutine Testergebnisse mittels ReportMonitorAction() an den Daemon.
   • Bei Shutdown oder Deaktivierung beendet StopOffer() die Meldungsbereitschaft.
2. Ereignisüberwachung & Entprellung (MultipleEvent):
   • Der Daemon führt basierend auf den ReportMonitorAction()-Daten das Entprellen (Counter- oder Time-based Debouncing) durch und aktualisiert DTC-Status sowie FDC.
   • Statusänderungen werden über den via SetEventStatusChangedNotifier() registrierten Callback asynchron an die Applikation propagiert.
   • Polling von DTC, FDC, Entprellstatus und Statusbyte erfolgt synchron über GetDTCNumber(), GetFaultDetectionCounter(), GetDebouncingStatus() und GetEventStatus().
3. Bedingungssteuerung (MultipleCondition):
   • Die Applikation setzt Betriebszustände (z. B. Zündungsstatus, Unter-/Überspannung, Fahrzeuggeschwindigkeit) über SetCondition().
   • Der DM-Daemon wertet diese Bedingungen aus und sperrt/aktiviert intern das Setzen oder Speichern der betroffenen Events/DTCs.

4. Normative Relevanz & Entwickler-Hinweise

• Vermeidung von Port-Explosion: Das Multiple*-Pattern adressiert Systeme mit hoher DTC-Dichte. Statt für jedes Einzelevent separate R-Ports im ARXML-Manifest zu deklarieren, werden Events/Monitore/Conditions über Identifier (z. B. Instance-Specifier oder Event-IDs) generisch über einen einzigen R-Port verwaltet.
• Daemon-basierte IPC-Kosten: Da Diagnostic Management als separater Dämonprozess (daemon-based) spezifiziert ist, erzeugen ReportMonitorAction(), Getter und Notifier Interprozesskommunikation (IPC). Zeitkritische Monitor-Loops dürfen IPC-Aufrufe nicht im harten Echtzeitkontext ohne Entkopplung (z. B. Lock-free Queues / Worker Threads) ausführen.
• ARXML-Modellierung: In den Execution- und Service-Instance-Manifesten müssen entsprechende RPortPrototype Instanzen mit Verweis auf die PortInterfaces MultipleCondition, MultipleEvent bzw. MultipleMonitor instanziiert und dem Service-Deployment der Plattform zugeordnet werden.
• Entprellungsverantwortung (Debouncing): Entwickler müssen sicherstellen, ob das Debouncing im Applikationscode (Monitor-seitig via PASSED/FAILED) oder daemon-seitig (via PREPASSED/PREFAILED und FDC-Tracking im DM) konfiguriert ist.