classe ara::diag::SovdServiceValidation

La classe ara::diag::SovdServiceValidation sert à la vérification spécifique à l'application des droits d'accès et des préconditions lors de requêtes de service SOVD entrantes ([SWS_DM_01822]). Après l'instanciation du port et son activation explicite via Offer(), le Diagnostic Management appelle pour chaque ressource demandée la méthode de validation asynchrone Validate() ([SWS_DM_01827]). Si la validation renvoie une valeur d'erreur pour ne serait-ce qu'une seule sous-ressource, le système interrompt immédiatement l'ensemble du traitement et rejette la requête du client. Alors que l'instanciation est sûre au niveau des threads (thread-safe), les méthodes telles que Offer() et StopOffer() doivent être synchronisées par l'appelant.

plus ›

Contexte

La classe ara::diag::SovdServiceValidation sert, dans l'Adaptive Platform, à fournir des vérifications spécifiques au constructeur et au fournisseur pour Service-Oriented Vehicle Diagnostics (SOVD) au sein d'une application de diagnostic ([SWS_DM_01822]). Alors que les préconditions et conditions environnementales standardisées sont évaluées dans le cadre du protocole SOVD par le Diagnostic Management (DM) avant l'exécution de la méthode ([SWS_DM_01468]), cette interface déplace les logiques de validation personnalisées directement dans l'application adaptative.

Trois partenaires centraux participent à la validation du service :

• Client SOVD : initie des requêtes de diagnostic via des méthodes HTTP à destination du système du véhicule.
• Diagnostic Management (DM) : reçoit les requêtes SOVD, vérifie les conditions d'ordre supérieur et délègue la validation aux mappages de ports configurés ([SWS_DM_01467], SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »).
• Gestionnaire de validation : réalise la spécialisation spécifique à l'application de SovdServiceValidation et décide de la recevabilité de l'opération demandée ([SWS_DM_01822], [SWS_DM_01827]).

Diagramme de contexte : composants et relations d'interfaces lors de la validation de service SOVD. Sources : [SWS_DM_01822], [SWS_DM_01823], SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »

Cycle de vie

L'instanciation d'un gestionnaire de validation s'effectue via le constructeur de SovdServiceValidation, qui est lié via un ara::core::InstanceSpecifier à un PortPrototype modélisé dans le manifeste ([SWS_DM_01823]). Le port doit ici être typé par un DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). Via le paramètre ConcurrencyType, l'application définit de manière contraignante si son implémentation est conçue pour des appels concurrents (kConcurrent) ou si elle ne doit pas être traitée de manière concurrente (kNotConcurrent) ([SWS_DM_01823]).

Après une construction réussie, l'instance se trouve dans l'état initialisé. Le relayage des requêtes par le DM doit être explicitement activé par l'appel de Offer() ([SWS_DM_01825]). Si le relayage doit être interrompu ou terminé, l'application le désactive via StopOffer() ([SWS_DM_01826]). Le destructeur virtuel ~SovdServiceValidation() termine proprement le cycle de vie du gestionnaire ([SWS_DM_01824]). Alors que le constructeur lui-même est spécifié comme thread-safe, Offer(), StopOffer() et le destructeur ne sont pas thread-safe et ne doivent pas être appelés de manière concurrente ([SWS_DM_01823], [SWS_DM_01824], [SWS_DM_01825], [SWS_DM_01826]).

Parcours d'utilisation

Le déroulement typique de la validation se divise en les phases suivantes :

1. Initialisation et enregistrement : l'application instancie la classe spécialisée et active le service au moyen de Offer() pour le DM ([SWS_DM_01823], [SWS_DM_01825]). Interprétation : cela s'effectue typiquement lors du démarrage de la fonctionnalité de diagnostic de l'application. Question (ouverte)
2. Traitement de la requête : lorsqu'un message SOVD arrive au niveau du serveur de diagnostic, ce dernier appelle, pour chaque mappage de port configuré dans DiagnosticServiceValidationConfiguration, la méthode Validate dans l'ordre défini (SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »).
3. Vérification des ressources : si l'appel concerne une collection de ressources (Resource Collection), le DM appelle Validate à plusieurs reprises : exactement une fois pour la collection elle-même, puis une fois pour chaque ressource contenue dans la collection ([SWS_DM_01827]). Le chemin de la ressource actuellement vérifiée est à chaque fois transmis dans ara::diag::MetaInfo (SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »).
4. Résultat asynchrone : la méthode renvoie un ara::core::Future<void> ([SWS_DM_01827]). Si la vérification est réussie, le future est résolu sans valeur d'erreur et le DM poursuit le traitement de la requête (SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »).
5. Désactivation du service : avant l'arrêt ou lors de modifications de configuration, l'application appelle StopOffer() ([SWS_DM_01826]).

Diagramme de séquence : déroulement d'une vérification de requête SOVD via Validate avec itération sur les ressources et traitement des erreurs. Sources : [SWS_DM_01827], SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »

Scénarios d'erreur

Des erreurs peuvent survenir dans différentes phases de l'initialisation et de l'exécution :

• Violations de construction : si le InstanceSpecifier ne peut pas être résolu dans le modèle ou ne renvoie pas à un PortPrototype, une InstanceSpecifierMappingIntegrityViolation est signalée ([SWS_DM_01823]). Une PortInterfaceMappingViolation survient si le port ne correspond pas à l'interface DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). En cas de mappage de processus manquant, ProcessMappingViolation survient, et si le même identifiant est utilisé plusieurs fois, une InstanceSpecifierAlreadyInUseViolation s'ensuit ([SWS_DM_01823]).
• Erreurs d'enregistrement lors de l'Offer : si le service a déjà été activement proposé, Offer() renvoie l'erreur DiagOfferErrc::kAlreadyOffered ([SWS_DM_01825]). Si la configuration s'écarte de la modélisation DEXT, l'erreur DiagOfferErrc::kConfigurationMismatch en résulte ([SWS_DM_01825]).
• Erreurs fonctionnelles de validation : la méthode Validate signale des irrégularités via des codes d'erreur issus de DiagSovdErrc ([SWS_DM_01827]). En font partie DiagSovdErrc::kInsufficientAccessRights en cas de droits insuffisants du client, DiagSovdErrc::kPreconditionNotFulfilled en cas de préconditions non remplies, DiagSovdErrc::kTemporarilyNotAvailable en cas d'indisponibilité temporaire (par ex. validation de jeton en ligne manquante) ou DiagSovdErrc::kSovdServerMisconfigured en cas de configuration erronée ([SWS_DM_01827]).
• Interruption immédiate en cas d'erreurs sur les sous-ressources : si la validation échoue ne serait-ce que pour une seule ressource contenue dans une collection de ressources, le DM interrompt immédiatement le traitement de la requête globale et renvoie directement un message d'erreur au client (SWS Diagnostics §7.3.3.2.3 « SOVD – Validation of Environmental Conditions »).