structure ara::diag::UploadService::OperationOutput

La structure ara::diag::UploadService::OperationOutput sert de paramètre de sortie pour renvoyer les données utiles d'une réponse de diagnostic positive lors de services de téléversement [SWS_DM_00796]. Le logiciel d'application instancie l'objet après la réussite d'une opération d'upload et renseigne le membre responseData avec les octets de données à envoyer [SWS_DM_00796]. Le contenu de responseData ne doit contenir aucun Service Identifier (SID) et doit correspondre aux exigences spécifiques à l'opération de services tels que UploadData ou RequestUploadExit. Interprétation : En cas d'erreur, la structure n'est pas utilisée et un état de réponse négatif est signalé. Question Q-52a8538825bc0a30 (ouverte)

plus ›

Contexte

La structure ara::diag::UploadService::OperationOutput fait office de conteneur de données pour les données utiles d'une opération de diagnostic réussie dans le cadre du service de téléversement côté véhicule [SWS_DM_00796]. Sa responsabilité principale consiste à encapsuler les données d'un message de réponse positive (« positive response message ») et à les relayer vers la plate-forme [SWS_DM_00796].

Dans le système global, trois composants interagissent ici : le client de diagnostic externe (testeur), l'environnement d'exécution de diagnostic du système Adaptive (ara::diag) ainsi que l'implémentation spécifique à l'application de UploadService [SWS_DM_00796]. Dès que le testeur demande une opération de service UDS, ara::diag délègue le traitement au fournisseur de service compétent de l'application, lequel renvoie le résultat à la couche de plate-forme via OperationOutput [SWS_DM_00796].

Diagramme de contexte : interaction entre le client de diagnostic, l'environnement d'exécution ara::diag et UploadService lors de la mise à disposition des données de réponse. Sources : [SWS_DM_00796], AUTOSAR_AP_SWS_Diagnostics, p. 74.

Cycle de vie

La structure OperationOutput est conçue comme un pur objet de transfert de données sans logique d'état propre et est fournie via le fichier d'en-tête #include "ara/diag/upload.h" [SWS_DM_00796]. Son cycle de vie se divise selon les phases suivantes :

• Création : l'instanciation s'effectue côté application au sein de l'opération de diagnostic en cours d'exécution, dès que les données d'upload demandées ont été composées avec succès. Interprétation : L'objet est vraisemblablement alloué localement sur la pile de l'application de service. Question (ouverte)
• Remplissage : la logique applicative affecte les données utiles à fournir au membre public responseData de type ara::core::Vector<std::uint8_t> [SWS_DM_00796].
• Transfert de propriété : l'objet est transmis en tant que résultat d'opération à ara::diag. Interprétation : Cette transmission devrait s'effectuer par valeur ou par sémantique de déplacement, ce par quoi la responsabilité des données passe à la plate-forme. Question (ouverte)
• Destruction : après la sérialisation des données utiles dans le message de réponse UDS, la structure est libérée par l'environnement d'exécution.

En ce qui concerne la concurrence, OperationOutput n'offre aucune synchronisation interne. Toutefois, comme les instances sont créées de manière dédiée pour chaque appel d'opération et sont traitées de manière locale au thread, aucune gestion d'état partagé n'est nécessaire.

Parcours d'utilisation

Le déroulement standard pour la mise à disposition des données de réponse via OperationOutput comprend une séquence déterminée d'étapes d'interaction :

1. Un testeur externe envoie une requête d'upload (telle que UploadData ou RequestUploadExit) au calculateur [SWS_DM_00796].
2. La gestion du diagnostic ara::diag traite l'en-tête de protocole et appelle l'opération correspondante de l'instance applicative de UploadService [SWS_DM_00796].
3. L'application traite la requête, crée une instance de OperationOutput et renseigne responseData avec les données utiles [SWS_DM_00796]. À cet égard, responseData doit contenir exclusivement les données utiles sans le Service Identifier (SID) [SWS_DM_00796]. Selon l'opération, le contenu requis ainsi que la position initiale des données dans le message de réponse positive varient [SWS_DM_00796].
4. La structure est renvoyée à ara::diag.
5. La couche de plate-forme génère le message de réponse UDS complet et le transmet au testeur [SWS_DM_00796].

Diagramme de séquence : séquence d'appels pour le renvoi de données de diagnostic au moyen d'OperationOutput. Sources : [SWS_DM_00796], AUTOSAR_AP_SWS_Diagnostics, p. 74.

Scénarios d'erreur

La structure OperationOutput est spécifiée exclusivement pour les exécutions réussies et les messages de réponse positive [SWS_DM_00796]. Si une opération échoue (par exemple en raison de plages d'adresses non valides ou d'erreurs de séquence lors de UploadData), OperationOutput n'est pas utilisée. Interprétation : Les déroulements erronés sont vraisemblablement signalés à ara::diag via des codes d'erreur de diagnostic distincts (NRC), de sorte que la création ou le remplissage de la structure de sortie ne sont pas nécessaires. Question Q-fa3daf3152f7131c (ouverte)

Comme précondition pour le renvoi, responseData doit comporter exactement les octets requis par l'opération de service concernée et ne doit contenir aucun identifiant de protocole en préfixe [SWS_DM_00796]. Comme postcondition, la gestion du diagnostic prend en charge les données pour la finalisation de la communication sur le bus [SWS_DM_00796].