structure ara::diag::DownloadService::OperationOutput

La structure de données ara::diag::DownloadService::OperationOutput sert de conteneur de transport pour les données utiles de réponses de diagnostic positives lors de services de téléchargement ([SWS_DM_00785]). L'application adaptative remplit ici le champ responseData avec les octets de résultat et transmet la structure à la gestion du diagnostic ([SWS_DM_00786]). Une contrainte essentielle réside dans le fait que responseData doit obligatoirement contenir les données utiles sans ID de service, des contenus différents étant attendus selon l'opération, telle que DownloadData ou RequestDownloadExit ([SWS_DM_00786]).

plus ›

Contexte

La structure ara::diag::DownloadService::OperationOutput est un type de données spécialisé du module Diagnostics au sein de l'AUTOSAR Adaptive Platform et est fournie via le fichier d'en-tête ara/diag/download.h ([SWS_DM_00785]). Son rôle principal consiste à encapsuler les données utiles d'un message de réponse de diagnostic positive pour les services de téléchargement (AUTOSAR_AP_SWS_Diagnostics §8.14.2 « Struct: OperationOutput »). Au sein de l'architecture de diagnostic, la structure agit en tant que conteneur de transport de données entre l'implémentation concrète du service dans l'application adaptative et l'environnement d'exécution de diagnostic sous-jacent (ara::diag), lequel interagit à son tour avec le client de diagnostic externe (testeur) (AUTOSAR_AP_SWS_Diagnostics §7 « API Specification »).

Le seul membre inclus est le champ public responseData de type ara::core::Vector<std::uint8_t> ([SWS_DM_00786]). Il transporte les octets purs de données utiles et de charge utile qui doivent être renvoyés au testeur de diagnostic lors d'un traitement réussi d'une opération de téléchargement.

Cycle de vie

En tant que pure structure de données (struct), OperationOutput ne possède ni machines à états internes ni méthodes propres ([SWS_DM_00785]). Son cycle de vie est éphémère et directement couplé au traitement synchrone ou asynchrone d'une requête de diagnostic unique :

• Création : La structure est instanciée par l'application dès qu'une opération de téléchargement a pu s'achever avec succès et que des données de réponse sont disponibles. La création devrait typiquement s'effectuer sur la pile ou au sein d'une chaîne de callbacks ou de futures. Question (ouverte)
• Remplissage et transmission : L'application remplit le vecteur responseData avec les octets calculés ([SWS_DM_00786]). Avec le retour à la gestion du diagnostic, la responsabilité des données est transférée à la plateforme.
• Destruction : Dès que la couche de plateforme a sérialisé les données et émis la trame UDS, l'instance est libérée.

En ce qui concerne la concurrence, il convient de noter que OperationOutput, en tant qu'objet-valeur passif, n'est pas thread-safe. Si des opérations sont traitées dans des threads de travail concurrents de l'application, il faut s'assurer qu'aucun accès concurrent à responseData n'a lieu avant que l'objet ne soit transmis à ara::diag.

Parcours d'utilisation

L'utilisation typique de OperationOutput s'effectue dans le cadre du traitement de requêtes de téléchargement de diagnostic. Un testeur de diagnostic externe envoie une requête au véhicule, qui est réceptionnée par la plateforme et relayée à la méthode appropriée de l'interface DownloadService dans l'application adaptative (AUTOSAR_AP_SWS_Diagnostics §7 « API Specification »). Après un traitement interne réussi, l'application crée une instance de OperationOutput et transmet les données de réponse.

Diagramme de séquence : interaction entre le client de diagnostic, le runtime de la plateforme et l'application lors de la mise à disposition de données de réponse positive via OperationOutput. Sources : [SWS_DM_00785], [SWS_DM_00786], AUTOSAR_AP_SWS_Diagnostics §8.14.2 « Struct: OperationOutput ».

Lors du remplissage de responseData, il faut tenir compte du fait que les données utiles doivent être fournies sans le SID (Service-ID) ([SWS_DM_00786]). La plateforme ajoute d'elle-même le SID spécifique au protocole ainsi que les éventuelles informations d'en-tête. De plus, la structure exacte du contenu dépend de l'opération appelée : avec DownloadData ou RequestDownloadExit, l'attente sémantique concernant le début et la structure des données de réponse dans le vecteur diffère ([SWS_DM_00786]).

Scénarios d'erreur

Comme OperationOutput est explicitement spécifié pour les messages de réponse positive (AUTOSAR_AP_SWS_Diagnostics §8.14.2 « Struct: OperationOutput »), aucun champ pour les codes d'erreur ou les retours négatifs n'existe au sein de la structure de données. Si une erreur survient lors de l'exécution de l'opération de téléchargement (par exemple des plages d'adresses non valides, un ordre de bloc incorrect ou des transferts interrompus), OperationOutput n'est vraisemblablement pas évalué ; l'application signale plutôt l'échec via les canaux d'erreur de la plateforme, à la suite de quoi un code de réponse négative (NRC) est généré. Question (ouverte)

Une erreur côté application lors de l'utilisation de OperationOutput survient lorsque le Service-ID est inséré par inadvertance dans responseData. Cela contredit la spécification [SWS_DM_00786] et devrait entraîner un formatage de trame erroné. Question (ouverte) De même, un ordre des octets incorrect ou une quantité de données incomplète entraîne, selon l'opération spécifique, des erreurs de protocole du côté du testeur ([SWS_DM_00786]).