structure ara::diag::GenericUDSService::OperationOutput

La structure ara::diag::GenericUDSService::OperationOutput sert, dans le module diag, de structure de sortie pour les données utiles des messages de réponse positive UDS [SWS_DM_00632]. Après l'exécution réussie d'un service UDS générique, une application renseigne la variable d'octets responseData et transmet l'instance au Diagnostic Management. L'identifiant de service UDS (SID) ne doit pas être contenu dans responseData, car celui-ci est ajouté automatiquement par la plate-forme [SWS_DM_00632]. La structure n'est pas prévue pour les scénarios d'erreur et les réponses négatives.

plus ›

Contexte

La structure de données ara::diag::GenericUDSService::OperationOutput sert, au sein de l'AUTOSAR Adaptive Platform dans le module diag, de canal de sortie standardisé pour les services UDS génériques [SWS_DM_00632]. Elle est définie dans le fichier d'en-tête #include "ara/diag/generic_uds_service.h" et fait office d'encapsulation pour les données utiles d'une exécution réussie de service UDS [SWS_DM_00632]. Les principaux partenaires d'interaction sont l'implémentation spécifique à l'application du gestionnaire de service UDS générique ainsi que le Diagnostic Management de niveau supérieur de la plate-forme AUTOSAR_AP_SWS_Diagnostics p. 80. Tandis que le Diagnostic Management prend en charge la coordination avec le testeur de diagnostic externe, la validation du protocole et le cadre général, OperationOutput met à disposition la charge utile isolée pour le message de réponse positive UDS [SWS_DM_00632].

Cycle de vie

Les instances de ara::diag::GenericUDSService::OperationOutput présentent un cycle de vie très ciblé et éphémère. La structure est instanciée par l'application de service dans le contexte local d'une requête UDS entrante. Via l'unique variable membre publique responseData de type ara::core::Vector<std::uint8_t>, la structure prend l'entière propriété des octets de données utiles [SWS_DM_00632].

Interprétation : La durée de vie de OperationOutput est volatile et liée à la durée du traitement de la requête concernée ; après avoir été renseignée, l'instance devrait être transmise au Diagnostic Management par valeur de retour ou par sémantique de déplacement, puis détruite après la sérialisation dans la trame de réponse UDS. Question Q-c736182a9518978a (ouverte) Comme il s'agit d'un pur objet de transfert de données (DTO) sans logique d'état interne, il n'existe aucune transition d'état. En ce qui concerne la concurrence, OperationOutput n'offre aucune sécurité de thread (thread safety) inhérente ; toutefois, étant donné que l'instanciation et le remplissage ont lieu de manière isolée pour chaque requête au sein du contexte de traitement, aucune synchronisation externe n'est requise lors d'une utilisation normale du service.

Parcours d'utilisation

Le déroulement standard lors du traitement d'une requête de diagnostic se divise selon les étapes suivantes :

• Réception : le Diagnostic Management reçoit une requête UDS provenant d'un testeur de diagnostic externe et la transmet à l'instance correspondante de GenericUDSService AUTOSAR_AP_SWS_Diagnostics p. 81.
• Exécution du service : l'application interprète les paramètres reçus et exécute la fonction de diagnostic interne.
• Mise à disposition du résultat : en cas de traitement réussi, l'application instancie un objet de type OperationOutput et affecte les données utiles de la réponse au champ responseData [SWS_DM_00632]. À cet égard, la spécification prescrit obligatoirement que responseData contienne exclusivement les octets de données sans le Service Identifier (SID) [SWS_DM_00632].
• Transmission : l'application transmet OperationOutput au Diagnostic Management. Interprétation : La transmission s'effectue typiquement sous la forme d'une valeur de retour synchrone ou intégrée dans une valeur future asynchrone telle que ara::core::Future. Question Q-2dcf40060cca29a1 (ouverte)
• Envoi du message : le Diagnostic Management préfixe automatiquement le SID positif, complète le télégramme UDS et transmet la réponse au testeur de diagnostic.

Diagramme de séquence : déroulement de la génération de réponse UDS et transmission via OperationOutput. Sources : [SWS_DM_00632], AUTOSAR_AP_SWS_Diagnostics p. 81

Scénarios d'erreur

Lors de l'utilisation de la structure, des conditions aux limites et des modèles de comportement essentiels en cas d'erreur doivent être pris en compte :

• Exclusion des réponses négatives : conformément à la spécification, OperationOutput représente explicitement et exclusivement le contenu des messages de réponse positive [SWS_DM_00632]. Interprétation : si une requête de service ne peut pas être traitée avec succès (par ex. en raison de paramètres non autorisés ou de préconditions non valides), aucun OperationOutput ne devrait être généré ; à la place, l'application signale un Negative Response Code (NRC) au Diagnostic Management. Question Q-09abb9092c1dc167 (ouverte)
• Inclusion erronée du SID : si le Service Identifier est inséré par erreur dans responseData, cela génère un télégramme UDS mal formaté, car le Diagnostic Management préfixe de manière autonome le SID lors des réponses positives [SWS_DM_00632].
• Allocation mémoire : étant donné que responseData est déclaré comme un vecteur dynamique (ara::core::Vector), d'éventuels goulets d'étranglement de mémoire doivent être pris en compte lors de l'attribution de très grands volumes de données utiles [SWS_DM_00632].