class ara::diag::Condition

Die Klasse ara::diag::Condition stellt die Schnittstelle DiagnosticConditionInterface bereit, mit der adaptive Anwendungen Umgebungs- und Freigabebedingungen an das Diagnostic Management melden ([SWS_DM_00712]). Der Diagnostic Server wertet diese Zustände aus, um die Ausführung normierter Diagnosefunktionen oder Löschvorgänge im Fahrzeug gezielt zu steuern (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 „Condition checks“). Instanzen sind fest an einen Port-Prototyp gebunden und weder kopier- noch verschiebbar. Bei nebenläufiger Nutzung erfordern die Abfrage- und Setzoperationen eine externe Synchronisation, da sie nicht threadsicher sind.

mehr ›

Kontext

Die Klasse ara::diag::Condition stellt die Programmierschnittstelle für Diagnosebedingungen (DiagnosticConditionInterface) in der AUTOSAR Adaptive Platform dar ([SWS_DM_00712]). In Fahrzeugdiagnosesystemen dürfen bestimmte Diagnosefunktionen oder UDS-Dienste nur ausgeführt werden, wenn sich das Fahrzeug in einem definierten Umgebungszustand befindet – wie beispielsweise bei stehendem Fahrzeug mit einer Geschwindigkeit von null (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 „Condition checks“). Gemäß [SWS_DM_00111] führt der Diagnostic Server entsprechende Umgebungsprüfungen durch, wenn ISO 14229-1 dienstspezifische Bedingungsprüfungen vorschreibt, und antwortet bei Nichterfüllung mit einem konfigurierten Negative Response Code (NRC).

Innerhalb der Anwendungsarchitektur fungiert ara::diag::Condition als Bindeglied zwischen der adaptiven Anwendung und dem Diagnostic Management (DM). Eine Anwendung instanziiert das Bedingungsobjekt über einen Port, der im Modell entweder über ein DiagnosticEnableConditionPortMapping oder ein DiagnosticClearConditionPortMapping verknüpft ist ([SWS_DM_00712]). Interpretation: Durch diese Port-Zuordnung wird festgelegt, ob der gemeldete Zustand als Freigabebedingung für reguläre Diagnoseabläufe oder als Kriterium zum Löschen von Diagnosedaten dient. Frage (offen) Das Objekt kapselt somit die Zustandsübermittlung an den Diagnostic Server, der die Bedingungen für ankommende Diagnoseanforderungen auswertet ([SWS_DM_00111]).

Kontextdiagramm: Einbindung von ara::diag::Condition zwischen Anwendungssoftware und Diagnostic Management. Quellen: [SWS_DM_00712], [SWS_DM_00111], AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 „Condition checks“

Lebenszyklus

Die Erzeugung eines ara::diag::Condition-Objekts erfolgt explizit durch Übergabe eines ara::core::InstanceSpecifier an den Konstruktor ([SWS_DM_00712]). Dieser Bezeichner verweist auf den modellierten Port-Prototyp der Anwendung. Der Konstruktor ist als noexcept deklariert und garantiert Ausnahme- sowie Thread-Sicherheit ([SWS_DM_00712]).

Hinsichtlich der Besitzverhältnisse ist die Klasse als strikte Einzelinstanz konzipiert: Sowohl der Kopierkonstruktor ([SWS_DM_01625]) als auch der Kopierzuweisungsoperator ([SWS_DM_01623]) sind gelöscht (=delete). Gleichermaßen sind der Move-Konstruktor ([SWS_DM_01626]) und der Move-Zuweisungsoperator ([SWS_DM_01624]) gelöscht. Ein Bedingungsobjekt kann weder kopiert noch verschoben werden, was eine feste 1:1-Zuordnung zum jeweiligen Port sicherstellt.

Im laufenden Betrieb sind die Methoden SetCondition ([SWS_DM_00715]) und GetCondition ([SWS_DM_00714]) als nicht thread-sicher spezifiziert. Bei parallelen Zugriffen aus mehreren Threads muss die aufrufende Anwendung eine externe Synchronisation gewährleisten. Der Lebenszyklus schließt mit dem Destruktor ~Condition() ([SWS_DM_00713]), der noexcept und ausnahmesicher, jedoch ebenfalls nicht thread-sicher ist.

Nutzungspfad

Der typische Nutzungspfad umfasst die Initialisierung, die wiederkehrende Aktualisierung des Zustands sowie die Abfrage der Bedingung:

1. Initialisierung: Die Anwendung instanziiert ara::diag::Condition unter Angabe des passenden ara::core::InstanceSpecifier ([SWS_DM_00712]) zur Anbindung an die Modellkonfiguration.
2. Zustand setzen: Ändert sich der maßgebliche Fahrzeug- oder Systemzustand, aktualisiert die Anwendung die Bedingung über SetCondition(condition) ([SWS_DM_00715]). Der Aufruf bestätigt die Übernahme mit einem ara::core::Result<void>.
3. Zustand abfragen: Zur Überprüfung des gegenwärtigen Zustands ruft die Anwendung GetCondition() auf ([SWS_DM_00714]). Das Ergebnis wird asynchron über ein ara::core::Future<ConditionType> bereitgestellt.
4. Server-Verarbeitung: Interpretation: Der Diagnostic Server greift intern auf den hinterlegten Zustand zu, um anstehende Diagnoseanforderungen zu prüfen ([SWS_DM_00111]). Frage Q-bbf48f735ef80e33 (offen)
5. Beendigung: Bei Terminierung der Komponente wird das Objekt über den Destruktor freigegeben ([SWS_DM_00713]).

Sequenzdiagramm: Typische Aufrufabfolge zur Initialisierung, Aktualisierung und Abfrage einer Diagnosebedingung. Quellen: [SWS_DM_00712], [SWS_DM_00715], [SWS_DM_00714], [SWS_DM_00713]

Fehlerszenarien

Fehlerzustände können bei der Objektinstanziierung sowie während der Laufzeit auftreten:

• Konstruktor-Verletzungen: Bei der Erzeugung ([SWS_DM_00712]) validiert das Framework die Konfiguration gegen das Softwaremodell. Mögliche Verletzungen umfassen:
  • InstanceSpecifierMappingIntegrityViolation: Der Bezeichner kann im Modell nicht aufgelöst werden oder referenziert kein PortPrototype ([SWS_DM_00712]).
  • PortInterfaceMappingViolation: Der PortPrototype ist zwar typisiert durch DiagnosticConditionInterface, wird jedoch weder von einem DiagnosticEnableConditionPortMapping noch von einem DiagnosticClearConditionPortMapping referenziert ([SWS_DM_00712]).
  • ProcessMappingViolation: Zur Instanzreferenz existiert kein passender modellierter Prozess zur Laufzeit ([SWS_DM_00712]).
  • InstanceSpecifierAlreadyInUseViolation: Der Bezeichner wird im selben Prozess bereits von einer anderen Instanz verwendet ([SWS_DM_00712]).
• Ausfall von Diagnose-Basisdiensten: GetCondition() ([SWS_DM_00714]) kann über das zurückgegebene ara::core::Future mit dem Fehler DiagErrc::kServiceNotAvailable fehlschlagen, wenn grundlegende Funktionalitäten des Diagnostic Management temporär nicht erreichbar sind.
• Fehlerfreie Zustandsspeicherung: Für SetCondition() ([SWS_DM_00715]) sind keine standardisierten Fehlercodes definiert; die Funktion meldet Erfolg direkt über ein leeres ara::core::Result<void>.