classe ara::diag::ServiceValidation

La méthode Confirmation de l'interface ara::diag::ServiceValidation ([SWS_DM_00775], déclarée dans ara/diag/service_validation.h) sert de notification concernant l'achèvement et le résultat d'une requête de diagnostic préalablement traitée.

Utilisation et sémantique

La fonction de rappel virtuelle est appelée de manière synchrone par le Diagnostic Management dès que le traitement de la requête est terminé. Elle ne possède aucune valeur de retour (void) et reçoit deux paramètres d'entrée ([SWS_DM_00775]) :

• status (ConfirmationStatusType) : Signale l'état final ou le résultat du traitement du service ([SWS_DM_00775]).
• metaInfo (const Meta Info &) : Contient les métainformations associées de la requête de diagnostic ([SWS_DM_00775]).

Gestion des erreurs et concurrence

La fonction est spécifiée comme sans exception (exception safe) et déclarée avec l'identifiant noexcept ([SWS_DM_00775]). Les redéfinitions côté application ne doivent donc propager aucune exception vers l'extérieur. Des codes d'erreur spécifiques tels que des notifications DET ou DEM ne sont pas définis pour cette méthode. Concernant la concurrence, Confirmation est classée comme non sûre au niveau des threads (not thread-safe) ([SWS_DM_00775]) ; l'accès à des états internes à l'application au sein du callback nécessite une synchronisation appropriée lors d'exécutions parallèles.

Interaction

Le déclenchement de la notification est couplé à la fin du cycle de vie d'une requête de diagnostic ([SWS_DM_00775]). Ce cycle se termine dès qu'une réponse positive ou négative a été transmise ou supprimée (AUTOSAR_AP_SWS_Diagnostics §7.3.2.1.2 « Life-cycle of a Diagnostic Conversation »). Interprétation : Au niveau du module, le Diagnostic Management ne devrait déclencher le callback Confirmation qu'une fois que la transmission via la couche de transport a été acquittée au moyen de TransmitConfirmation et du résultat kTransmitOk ou kTransmitFailed ([SWS_DM_00307], [SWS_DM_00351]). Question Q-97c38586ef5e3704 (ouverte)

Utilisation

La fonction membre Offer de la classe ara::diag::ServiceValidation (en-tête ara/diag/service_validation.h) active la transmission des requêtes de diagnostic entrantes par le gestionnaire de diagnostic (DM) à ce gestionnaire de validation spécifique [SWS_DM_00776]. L'appel s'effectue de manière synchrone et sans paramètre de transmission via la signature ara::core::Result<void> Offer() noexcept; [SWS_DM_00776]. La valeur de retour est un ara::core::Result<void>, qui est vide en cas de succès ou qui encapsule le code d'erreur survenu en cas d'erreur [SWS_DM_00776].

Gestion des erreurs

Si l'enregistrement échoue, la méthode renvoie un Result en erreur. Si le service a déjà été proposé auparavant pour l'instance concernée, le code d'erreur DiagOfferErrc::kAlreadyOffered est renvoyé [SWS_DM_00776]. Une sémantique de rollback s'applique ici, de sorte que l'état antérieur de l'instance reste inchangé [SWS_DM_00776].

Concurrence et restrictions

La fonction est spécifiée comme sûre vis-à-vis des exceptions (exception safe), mais expressément comme non sûre pour les threads (not thread-safe) [SWS_DM_00776]. Les accès parallèles à une même instance doivent être coordonnés par l'application appelante. Concernant l'ordonnancement, Offer doit être appelée avant que le gestionnaire de diagnostic ne puisse transmettre des requêtes de service pour validation [SWS_DM_00776].

Interaction

La proposition d'interfaces via Offer constitue un patron de conception cohérent du diagnostic AUTOSAR Adaptive et s'emploie de manière analogue, entre autres, pour les routines ([SWS_DM_00557], [SWS_DM_00594]), les services UDS génériques ([SWS_DM_00619]), les fonctions DoIP ([SWS_DM_00725], [SWS_DM_00735]) ainsi que les accès sécurisés ([SWS_DM_00766]). Tant qu'une interface n'a pas été mise à disposition via Offer, le DM rejette les requêtes ou a recours à des valeurs de remplacement définies ([SWS_DM_01525], [SWS_DM_01527]). Les similitudes conceptuelles avec ara::com sont motivées par le fonctionnement, mais représentent une implémentation autonome du diagnostic (AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 « Monitors »).

Utilisation

La méthode StopOffer() de la classe ara::diag::ServiceValidation (fichier d'en-tête ara/diag/service_validation.h) sert à désactiver le réacheminement des messages de requête entrants du Diagnostic Management (DM) vers l'instance de validation de service [SWS_DM_00777]. L'appel s'effectue de manière synchrone, ne prend aucun paramètre d'entrée et ne fournit aucune valeur de retour [SWS_DM_00777].

Gestion des erreurs et concurrence

La fonction est déclarée comme noexcept et est considérée comme sûre face aux exceptions (exception safe), de sorte qu'aucune exception C++ ne survient lors de l'exécution [SWS_DM_00777]. Aucun code d'erreur spécifique ni retour d'information vers la gestion des erreurs n'est défini pour cet appel [SWS_DM_00777].

En ce qui concerne la concurrence, la méthode est spécifiée comme non sûre vis-à-vis des threads (not thread-safe) [SWS_DM_00777]. Interprétation : l'application appelante doit s'assurer que les appels concurrents sur la même instance de StopOffer() sont synchronisés afin d'éviter les incohérences de données. Question Q-dde3c015d30a9db1 (ouverte)

Interaction

La mise à disposition et le retrait d'interfaces via Offer() et StopOffer() s'inspirent de la sémantique connue de ara::com, mais constituent une fonctionnalité autonome dans le domaine du diagnostic AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 « Monitors ». Le modèle de désactivation du réacheminement des requêtes issues du DM est utilisé de manière cohérente dans le standard pour d'autres gestionnaires de diagnostic, tels que pour les services d'authentification [SWS_DM_01131], le contrôle de communication [SWS_DM_00810], les services de téléchargement [SWS_DM_00793] ainsi que les demandes de réinitialisation d'ECU [SWS_DM_01017].

Utilisation

La méthode virtuelle ara::diag::ServiceValidation::Validate est appelée pour chaque message de requête de diagnostic entrant [SWS_DM_00774]. Le serveur de diagnostic (DM) exécute par ce biais des vérifications de service spécifiques au constructeur [SWS_DM_01252] ainsi que des vérifications de service spécifiques au fournisseur [SWS_DM_01253] selon l'ISO 14229-1 configurées. L'affectation en tant que contrôle constructeur ou fournisseur dépend de la modélisation dans le constructeur [SWS_DM_00772].

La fonction reçoit les données de diagnostic, y compris le Service Identifier (SID), via requestData ainsi que des méta-informations via metaInfo [SWS_DM_00774]. Le tampon requestData reste valide jusqu'à ce que le ara::core::Future<void> renvoyé soit satisfait via la promesse associée ou que l'exécution soit annulée [SWS_DM_00774]. Si la validation s'achève avec succès sans erreur, le serveur de diagnostic poursuit le traitement de la requête conformément à l'ISO 14229-1 [SWS_DM_01254].

Gestion des erreurs et conditions limites

Si la vérification échoue, un NRC approprié selon l'ISO 14229-1 doit être renvoyé au moyen de DiagUdsNrcErrc [SWS_DM_00774]. Si Validate renvoie l'erreur kNoProcessingNoResponse, l'instance du Diagnostic Server rejette le message sans autre réponse [SWS_DM_00860].

En ce qui concerne la concurrence, Validate est spécifiée comme sûre face aux exceptions (exception safe), mais non sûre vis-à-vis des threads (not thread-safe) [SWS_DM_00774]. Interprétation : étant donné que la fonction n'est pas sûre vis-à-vis des threads, le Diagnostic Server devrait sérialiser les appels vers la même instance ou exclure les accès concurrents. Question Q-e150c15ad709602c (ouverte) Le contexte d'appel est défini par la séquence de NRC de l'ISO 14229-1 avant l'exécution effective du service [SWS_DM_00772].