class ara::diag::MultipleMonitor

Verwendung

Die Methode ara::diag::MultipleMonitor::ConfigureMonitor initialisiert einen Diagnosemonitor für die monitor-interne Entprellung [SWS_DM_01696]. Über den Parameter monitorHandle wird der zu konfigurierende Monitor adressiert, während mit initMonitor ein Notifier-Callback für Reinitialisierungen und mit getFaultDetectionCounter eine Funktion zur Abfrage des aktuellen Fehlerzählwerts (FDC) registriert werden [SWS_DM_01696]. Die Ausführung erfolgt synchron und gibt ein ara::core::Result<void> zurück AUTOSAR_AP_SWS_Diagnostics §8.44.2.1.3.4 „ConfigureMonitor“.

Fehlerbehandlung und Nebenläufigkeit

Im Fehlerfall wird das Fehlerergebnis DiagErrc::kInvalidArgument zurückgeliefert [SWS_DM_01696]. Dies dürfte insbesondere dann auftreten, wenn ungültige Funktionszeiger übergeben werden oder inkompatible Zustände bei interner Entprellung vorliegen (Interpretation). Frage Q-3de0f2b0cc427ef3 (offen) Die Operation ist als noexcept sowie ausnahmesicher (exception safe) spezifiziert, jedoch ausdrücklich als nicht threadsicher (not thread-safe) gekennzeichnet [SWS_DM_01696]. Aufrufe auf derselben Monitor-Instanz müssen daher anwendungsseitig synchronisiert werden.

Reihenfolge und Zusammenspiel

Jede Überladung von ConfigureMonitor darf für einen Monitor nur genau einmal aufgerufen werden; der Monitor ist erst nach diesem Initialisierungsschritt einsatzbereit [SWS_DM_01696]. Bei monitor-interner Entprellung verarbeitet die Diagnostic-Monitor-Anwendung die Entprelllogik eigenständig und übermittelt lediglich finale Ergebnisse an das Diagnostic Management AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.5.3 „Monitor-internal debouncing“. Für andere Entprellmechanismen stehen alternative Überladungen für zeitbasierte [SWS_DM_01697], zählerbasierte [SWS_DM_01702] oder unentprellte Überwachungen [SWS_DM_01973] bereit.

Verwendung

Die synchrone Memberfunktion ara::diag::MultipleMonitor::ConfigureMonitor aus der Header-Datei ara/diag/multiple_monitor.h konfiguriert einen diagnostischen Monitor mit zeitbasierter Entprellung ([SWS_DM_01697], SWS Diagnostics §8.44.2.1.3.2 „ConfigureMonitor(MonitorHandleType, InitMonitorNotifier, TimeBased)“). Beim Aufruf werden das Handle monitorHandle zur Identifikation des Monitors, die Callback-Funktion initMonitor vom Typ InitMonitorNotifier sowie die Entprellparameter defaultValues vom Typ TimeBased übergeben ([SWS_DM_01697]). Als Rückgabewert dient ara::core::Result<void>, und die Funktionssignatur ist als noexcept deklariert ([SWS_DM_01697]).

Aufrufbedingungen und Nebenläufigkeit

Ein Monitor kann erst nach Abschluss dieses Initialisierungsschritts verwendet werden ([SWS_DM_01697]). Jede überladene Variante von ConfigureMonitor darf pro Monitorinstanz nur genau einmal aufgerufen werden ([SWS_DM_01697]). Die Schnittstelle ist zwar ausnahmesicher (exception safe), aber nicht threadsicher (not thread-safe), sodass parallele Aufrufe auf derselben Instanz anwenderseitig synchronisiert werden müssen ([SWS_DM_01697]).

Fehlerbehandlung

Schlägt die Konfiguration fehl, liefert der Aufruf ein Fehlerobjekt innerhalb von ara::core::Result zurück, insbesondere den Fehlercode DiagErrc::kInvalidArgument ([SWS_DM_01697]).

Zusammenspiel

Die Methode ergänzt die alternativen Initialisierungsfunktionen für zählerbasierte Entprellung ([SWS_DM_01702]), monitorinterne Entprellung ([SWS_DM_01696]) sowie Monitore ohne Entprellung ([SWS_DM_01973]). Für zeitbasiert entprellte Ereignisse unterstützt der Diagnostic Manager zudem das gezielte Einfrieren des Entprell-Timers ([SWS_DM_00880]) und dessen spätere Fortführung ab dem eingefrorenen Stand ([SWS_DM_00038]).

Die synchrone Methode ConfigureMonitor der Klasse ara::diag::MultipleMonitor dient der Initialisierung eines Diagnose-Monitors mit zählerbasierter Entprellung ([SWS_DM_01702], AUTOSAR_AP_SWS_Diagnostics §8.44.2.1.3.1 „ConfigureMonitor“). Die Deklaration wird über die Header-Datei ara/diag/multiple_monitor.h bereitgestellt ([SWS_DM_01702]).

Verwendung und Parameter

Die Funktion nimmt folgende Übergabeparameter entgegen ([SWS_DM_01702]):

• monitorHandle (MonitorHandleType): Identifiziert den zu konfigurierenden Diagnose-Monitor.
• initMonitor (InitMonitorNotifier): Registriert eine Benachrichtigungs-Callback-Funktion zur Initialisierung des Monitors.
• defaultValues (CounterBased): Übergibt Standard-Konfigurationswerte für die zählerbasierte Entprellung.

Als Rückgabewert liefert die Operation ein ara::core::Result<void>, das über Erfolg oder Fehler Auskunft gibt ([SWS_DM_01702]).

Fehlerbehandlung

Schlägt die Konfiguration fehl, wird ein Fehler im Rückgabewert gemeldet. Bei ungültigen Argumenten wird der Fehlercode DiagErrc::kInvalidArgument zurückgegeben ([SWS_DM_01702]). Die Funktion ist als noexcept deklariert und gewährleistet Ausnahmesicherheit (exception safe) ([SWS_DM_01702]).

Nebenläufigkeit und Einschränkungen

Jede Überladung von ConfigureMonitor darf für einen Monitor zwingend nur genau einmal aufgerufen werden; der Monitor ist erst nach diesem Initialisierungsschritt verwendbar ([SWS_DM_01702]). Da die Operation als nicht threadsicher (not thread-safe) eingestuft ist ([SWS_DM_01702]), dürfte eine externe Synchronisation erforderlich sein, wenn Aufrufe über Thread-Grenzen hinweg stattfinden (Interpretation). Frage Q-fcb809ccb021dd6d (offen)

Zusammenspiel

Die Methode ist Teil der Konfigurationsschnittstelle in MultipleMonitor. Sie ergänzt verwandte Überladungen für zeitbasierte Entprellung mit TimeBased ([SWS_DM_01697]), für monitorinterne Entprellung mit Auslesefunktion ([SWS_DM_01696]) sowie für Monitore ganz ohne Entprellmechanismus ([SWS_DM_01973]).

Die synchrone Methode ConfigureMonitor dient der Initialisierung eines Diagnosemonitors ohne Entprellung innerhalb von ara::diag::MultipleMonitor ([SWS_DM_01973], AUTOSAR_AP_SWS_Diagnostics §8.44.2.1.3.3 „ConfigureMonitor(MonitorHandleType, InitMonitorNotifier)“). Sie nimmt als Eingabeparameter das Handle des Monitors (monitorHandle) sowie eine Callback-Funktion (initMonitor) zur Registrierung einer InitMonitorNotifier-Benachrichtigung entgegen ([SWS_DM_01973]). Erst nach diesem zwingenden Initialisierungsschritt kann der betreffende Monitor aktiv verwendet werden ([SWS_DM_01973]).

Hinsichtlich des Aufrufkontexts und der Nebenläufigkeit gelten folgende Randbedingungen:

• Jede Überladung von ConfigureMonitor darf für jeden einzelnen Monitor exakt einmal aufgerufen werden ([SWS_DM_01973]).
• Die Methode ist als exception safe spezifiziert, jedoch als not thread-safe eingestuft ([SWS_DM_01973]). Ein nebenläufiger Zugriff auf denselben Monitor dürfte daher eine externe Synchronisation durch die Anwendung erfordern. Frage Q-2272f26f380a5a11 (offen)

Die Funktion liefert als Ergebnis ein ara::core::Result<void> zurück ([SWS_DM_01973]). Schlägt die Konfiguration fehl, wird ein Fehler zurückgegeben, beispielsweise DiagErrc::kInvalidArgument ([SWS_DM_01973]). Falls für den Diagnosemonitor ein Entprellverfahren benötigt wird, stehen stattdessen die überladenen Varianten für monitor-internes Debouncing ([SWS_DM_01696]), zeitbasiertes Debouncing ([SWS_DM_01697]) oder zählerbasiertes Debouncing ([SWS_DM_01702]) bereit.

Die Funktion Offer aktiviert die Weiterleitung eingehender Diagnoseanfragen durch den Diagnostic Management Daemon (DM) an den jeweiligen Handler [SWS_DM_01699]. Der synchrone Aufruf ist parameterlos und als noexcept mit Ausnahme-Sicherheit (exception safe) spezifiziert [SWS_DM_01699].

Im Erfolgsfall liefert die Funktion ein leeres ara::core::Result<void> zurück [SWS_DM_01699]. Wurde die Registrierung für den Handler bereits zuvor erfolgreich ausgeführt, schlägt der Aufruf fehl und liefert den Fehlercode DiagOfferErrc::kAlreadyOffered mit Rollback-Semantik [SWS_DM_01699]; dieser Fehlerzustand ist in der Diagnose-Fehlerdomäne verankert [SWS_DM_00514].

Hinsichtlich der Nebenläufigkeit ist die Methode als not thread-safe deklariert [SWS_DM_01699]. Interpretation: Aufrufe auf derselben Handler-Instanz dürfen vermutlich nicht ungeschützt aus verschiedenen Threads erfolgen, um Inkonsistenzen im Registrierungszustand zu vermeiden. Frage Q-95f2e0895004c73b (offen)

Das Muster der Offer-Methode entspricht dem einheitlichen Bereitstellungsmechanismus für Diagnose-Handler in AUTOSAR Adaptive, wie er analog etwa für generische Routinen [SWS_DM_00557] oder UDS-Dienste [SWS_DM_00619] zum Einsatz kommt. Obwohl die Benennung an die Dienstbereitstellung in ara::com angelehnt ist, handelt es sich um eine eigenständige diagnosespezifische Implementierung AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 „Monitors“.

Die Funktion [SWS_DM_01698] dient in ara::diag::MultipleMonitor dazu, Statusinformationen und Entprellkommandos für einen spezifischen Diagnose-Monitor an den Diagnostic Manager (DM) zu melden. Über den Parameter monitorHandle wird der Ziel-Monitor adressiert, während action das (un-)qualifizierte Testergebnis oder Befehle zur Entprellung und Vorspeicherung übergibt.

Hinsichtlich des Fehlerverhaltens gilt, dass Aufrufe mit ungültigem monitorHandle vom DM ignoriert werden [SWS_DM_01698]. Wird eine Aktion übergeben, die vom konfigurierten Entprellverfahren nicht unterstützt wird, löst der DM eine Verletzung (Violation) aus [SWS_DM_01988]. Zudem können nicht erfüllte Enable-Bedingungen dazu führen, dass Meldungen verworfen werden (AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.4 „EnableConditions“), was mit internen Fehlercodes korrespondiert [SWS_DM_00514].

Zur Nebenläufigkeit und Ausführung:

• Die Methode ist als noexcept deklariert und somit exception-sicher [SWS_DM_01698].
• Die Threadsicherheit ist konditional: Ob Aufrufe threadsicher sein müssen, wird über den beim Konstruktor übergebenen ConcurrencyType festgelegt [SWS_DM_01698].
• Im Zusammenspiel mit der zählerbasierten Entprellung führt etwa die Meldung kPrefailed zur Inkrementierung des internen Zählers [SWS_DM_00875]. Interpretation: Die für Einzel-Monitore definierten Entprellmechanismen und Enable-Bedingungen gelten vermutlich identisch für die über Handles gesteuerte Mehrfach-Instanz. Frage Q-ff29529143d35ca2 (offen)

Die Methode StopOffer der Klasse ara::diag::MultipleMonitor dient dazu, die Weiterleitung von Anfragenachrichten aus dem Diagnostic Management (DM) an den Handler zu deaktivieren [SWS_DM_01700]. Sie bildet das funktionale Gegenstück zum Anbieten der Schnittstelle und ermöglicht es der Applikation, die Bearbeitung eingehender Diagnoseanfragen gezielt einzustellen.

Die Verwendung unterliegt folgenden Merkmalen und Randbedingungen:

• Signatur und Aufrufkontext: Die Funktion ist über den Header ara/diag/multiple_monitor.h deklariert und besitzt die Signatur void StopOffer() noexcept; [SWS_DM_01700]. Sie nimmt keine Parameter entgegen und liefert keinen Rückgabewert. Der Aufruf wird synchron ausgeführt.
• Fehlerbehandlung: Die Methode ist als noexcept und ausnahmesicher (exception safe) spezifiziert [SWS_DM_01700]. Sie wirft keine Ausnahmen und sieht keine spezifischen Fehlercodes oder Fehlermeldungen vor.
• Nebenläufigkeit: Das Element ist explizit als nicht threadsicher (not thread-safe) eingestuft [SWS_DM_01700]. Ein nebenläufiger Aufruf an derselben Instanz dürfte von der Applikation extern synchronisiert werden müssen. Frage Q-b73ead392f8b95b2 (offen)

Die Semantik von StopOffer folgt dem einheitlichen Entwurfsmuster für Diagnose-Handler in AUTOSAR Adaptive, bei dem Dienste über Offer und StopOffer gesteuert werden AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 „Monitors“. Das gleiche Prinzip der Deaktivierung der Anfragenweiterleitung findet sich bei verwandten Ports wie ara::diag::Monitor::StopOffer [SWS_DM_01089] sowie generischen Routinen [SWS_DM_00558] und UDS-Diensten [SWS_DM_00620].