class ara::diag::SovdServiceValidation

Die Klasse ara::diag::SovdServiceValidation dient der anwendungsspezifischen Prüfung von Zugriffsrechten und Vorbedingungen bei eingehenden SOVD-Dienstanfragen ([SWS_DM_01822]). Nach der Port-Instanziierung und expliziten Aktivierung über Offer() ruft das Diagnostic Management für jede angefragte Ressource die asynchrone Validierungsmethode Validate() auf ([SWS_DM_01827]). Liefert die Validierung auch nur für eine einzige Teilressource einen Fehlerwert, bricht das System die gesamte Verarbeitung unverzüglich ab und weist die Client-Anfrage zurück. Während die Instanziierung threadsicher ist, müssen Methoden wie Offer() und StopOffer() vom Aufrufer synchronisiert werden.

mehr ›

Kontext

Die Klasse ara::diag::SovdServiceValidation dient in der Adaptive Platform dazu, hersteller- und lieferantenspezifische Prüfungen für Service-Oriented Vehicle Diagnostics (SOVD) innerhalb einer diagnostischen Anwendung bereitzustellen ([SWS_DM_01822]). Während standardisierte Vorbedingungen und Umgebungsbedingungen im Rahmen des SOVD-Protokolls vom Diagnostic Management (DM) vor der Methodenausführung ausgewertet werden ([SWS_DM_01468]), verlagert diese Schnittstelle benutzerdefinierte Validierungslogiken direkt in die adaptive Anwendung.

An der Dienstvalidierung sind drei zentrale Partner beteiligt:

• SOVD-Client: Initiiert diagnostische Anfragen über HTTP-Methoden an das Fahrzeugsystem.
• Diagnostic Management (DM): Empfängt SOVD-Anfragen, prüft übergeordnete Bedingungen und delegiert die Validierung an die konfigurierten Port-Mappings ([SWS_DM_01467], SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“).
• Validierungs-Handler: Realisiert die anwendungsspezifische Spezialisierung von SovdServiceValidation und entscheidet über die Zulässigkeit der angeforderten Operation ([SWS_DM_01822], [SWS_DM_01827]).

Kontextdiagramm: Komponenten und Schnittstellenbeziehungen bei der SOVD-Dienstvalidierung. Quellen: [SWS_DM_01822], [SWS_DM_01823], SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“

Lebenszyklus

Die Instanziierung eines Validierungs-Handlers erfolgt über den Konstruktor von SovdServiceValidation, der über einen ara::core::InstanceSpecifier an einen im Manifest modellierten PortPrototype gebunden wird ([SWS_DM_01823]). Der Port muss hierbei durch ein DiagnosticSovdServiceValidationInterface typisiert sein ([SWS_DM_01823]). Über den Parameter ConcurrencyType definiert die Anwendung verbindlich, ob ihre Implementierung für nebenläufige Aufrufe ausgelegt ist (kConcurrent) oder nicht nebenläufig bedient werden muss (kNotConcurrent) ([SWS_DM_01823]).

Nach erfolgreicher Konstruktion befindet sich die Instanz im initialisierten Zustand. Die Weiterleitung von Anfragen durch das DM muss explizit durch den Aufruf von Offer() aktiviert werden ([SWS_DM_01825]). Soll die Weiterleitung unterbrochen oder beendet werden, deaktiviert die Anwendung diese über StopOffer() ([SWS_DM_01826]). Der virtuelle Destruktor ~SovdServiceValidation() beendet den Lebenszyklus des Handlers sauber ([SWS_DM_01824]). Während der Konstruktor selbst threadsicher spezifiziert ist, sind Offer(), StopOffer() und der Destruktor nicht threadsicher und dürfen nicht nebenläufig aufgerufen werden ([SWS_DM_01823], [SWS_DM_01824], [SWS_DM_01825], [SWS_DM_01826]).

Nutzungspfad

Der typische Ablauf der Validierung gliedert sich in folgende Phasen:

1. Initialisierung und Registrierung: Die Anwendung instanziiert die spezialisierte Klasse und schaltet den Service mittels Offer() für das DM frei ([SWS_DM_01823], [SWS_DM_01825]). Interpretation: Dies erfolgt typischerweise beim Starten der diagnostischen Funktionalität der Applikation. Frage (offen)
2. Anfragebearbeitung: Trifft eine SOVD-Nachricht beim Diagnostic Server ein, ruft dieser für jedes in DiagnosticServiceValidationConfiguration konfigurierte Port-Mapping die Methode Validate in der festgelegten Reihenfolge auf (SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“).
3. Ressourcen-Prüfung: Betrifft der Aufruf eine Ressourcensammlung (Resource Collection), ruft das DM Validate mehrfach auf: genau einmal für die Sammlung selbst und anschließend jeweils einmal für jede in der Sammlung enthaltene Ressource ([SWS_DM_01827]). Der Pfad der aktuell geprüften Ressource wird jeweils in ara::diag::MetaInfo übergeben (SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“).
4. Asynchrones Ergebnis: Die Methode liefert ein ara::core::Future<void> zurück ([SWS_DM_01827]). Ist die Prüfung erfolgreich, wird der Future ohne Fehlerwert aufgelöst und das DM setzt die Bearbeitung der Anfrage fort (SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“).
5. Dienst-Deaktivierung: Vor der Terminierung oder bei Konfigurationsänderungen ruft die Anwendung StopOffer() auf ([SWS_DM_01826]).

Sequenzdiagramm: Ablauf einer SOVD-Anfrageprüfung über Validate mit Ressourcen-Iteration und Fehlerverarbeitung. Quellen: [SWS_DM_01827], SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“

Fehlerszenarien

Fehler können in unterschiedlichen Phasen der Initialisierung und Ausführung auftreten:

• Konstruktionsverletzungen: Kann der InstanceSpecifier im Modell nicht aufgelöst werden oder verweist nicht auf einen PortPrototype, wird eine InstanceSpecifierMappingIntegrityViolation gemeldet ([SWS_DM_01823]). Eine PortInterfaceMappingViolation entsteht, wenn der Port nicht dem Interface DiagnosticSovdServiceValidationInterface entspricht ([SWS_DM_01823]). Bei fehlendem Prozess-Mapping tritt ProcessMappingViolation auf, und wird derselbe Bezeichner mehrfach verwendet, folgt eine InstanceSpecifierAlreadyInUseViolation ([SWS_DM_01823]).
• Registrierungsfehler bei Offer: Ist der Service bereits aktiv angeboten worden, gibt Offer() den Fehler DiagOfferErrc::kAlreadyOffered zurück ([SWS_DM_01825]). Weicht die Konfiguration von der DEXT-Modellierung ab, resultiert der Fehler DiagOfferErrc::kConfigurationMismatch ([SWS_DM_01825]).
• Fachliche Validierungsfehler: Die Methode Validate meldet Unzulässigkeiten über Fehlercodes aus DiagSovdErrc ([SWS_DM_01827]). Dazu zählen DiagSovdErrc::kInsufficientAccessRights bei unzureichenden Rechten des Clients, DiagSovdErrc::kPreconditionNotFulfilled bei nicht erfüllten Vorbedingungen, DiagSovdErrc::kTemporarilyNotAvailable bei temporärer Nichtverfügbarkeit (z. B. fehlende Online-Token-Validierung) oder DiagSovdErrc::kSovdServerMisconfigured bei fehlerhafter Konfiguration ([SWS_DM_01827]).
• Sofortiger Abbruch bei Teilressourcen-Fehlern: Schlägt die Validierung auch nur für eine einzige enthaltene Ressource einer Ressourcensammlung fehl, bricht das DM die Bearbeitung der Gesamtanfrage unverzüglich ab und liefert direkt eine Fehlermeldung an den Client zurück (SWS Diagnostics §7.3.3.2.3 „SOVD – Validation of Environmental Conditions“).