structure <DataElement-Namespace>::<DataElementInterface>::<DataElement>ReadOutput

La structure <DataElement>ReadOutput sert, dans le module de diagnostic adaptatif, de conteneur de transport pour encapsuler tous les arguments de sortie d'une opération de lecture d'un élément de données. Lors d'une requête de lecture entrante, elle est instanciée par le fournisseur de service, remplie avec les valeurs déterminées et retournée à l'appelant. Les instances possèdent une sémantique de valeur pure sans gestion d'état propre et devraient être détruites immédiatement après leur évaluation. Question (ouverte) Les éventuelles erreurs survenues pendant la requête sont traitées, selon l'interprétation, par les mécanismes de retour de la fonction de plateforme de niveau supérieur et non par la structure elle-même.

plus ›

Contexte

La structure <DataElement>ReadOutput fait partie intégrante de la définition d'interface du module de diagnostic (diag) au sein d'AUTOSAR Adaptive Platform dans la version R25-11. Son rôle principal consiste à regrouper, en tant que structure enveloppe (wrapper), les arguments de sortie (out arguments) d'une opération de lecture (ReadOutput) pour un élément de données de diagnostic donné au sein du <DataElementInterface> associé. Dans l'architecture d'AUTOSAR Adaptive, les composants logiciels fonctionnels communiquent avec le gestionnaire de diagnostic de la plateforme via des interfaces de service clairement définies. <DataElement>ReadOutput agit ici comme un pur conteneur de transfert de données regroupant les données utiles d'une requête de lecture. Vraisemblablement, la structure de données sert de type de retour d'une opération de lecture asynchrone (telle que Read()) au sein de l'interface de diagnostic <DataElementInterface>, afin de fournir les paramètres de sortie de manière groupée. Cette encapsulation crée une interface uniforme et typée qui s'affranchit du passage de pointeurs ou de paramètres de sortie séparés. Question Q-e3c1110153021b2a (ouverte)

Cycle de vie

En ce qui concerne le cycle de vie, la structure <DataElement>ReadOutput présente les propriétés d'un type valeur élémentaire. Elle ne possède pas d'identité durable et ne traverse aucun état interne complexe. Sa création est effectuée de manière dynamique ou sur la pile par le composant qui implémente l'accès en lecture à l'élément de données et rassemble les données de sortie. Les instances de la structure devraient typiquement être transmises par valeur ou via une sémantique de déplacement (move semantics), puis être consommées et détruites par le composant de diagnostic appelant ou par le framework de la plateforme après l'achèvement de l'opération de lecture. Le transfert de propriété s'opère alors directement au profit du destinataire du résultat de lecture. Dès que la routine de traitement a lu les données requises, la structure est automatiquement libérée à la sortie de la portée. En matière de concurrence, <DataElement>ReadOutput n'offre aucune synchronisation interne. Comme les instances sont transmises exclusivement à l'appelant respectif dans le flux d'appel régulier, une utilisation partagée au-delà des limites de threads n'est pas prévue en fonctionnement standard. Question Q-f7af8c361e9352b0 (ouverte)

Parcours d'utilisation

Le chemin d'utilisation typique s'étend du déclenchement d'une requête de lecture jusqu'au traitement des paramètres de sortie fournis. Un déroulement typique se présente comme suit :

• Requête : un client de diagnostic ou le framework adaptatif demande la lecture d'un élément de données via la méthode de l'interface <DataElementInterface>.
• Instanciation et remplissage : le composant logiciel fournisseur détermine les données de diagnostic actuelles, instancie une instance de <DataElement>ReadOutput et renseigne ses champs de données avec les valeurs relevées.
• Retour : la structure remplie est transmise au framework demandeur en tant que résultat de l'opération.
• Consommation : le framework ou le composant appelant accède aux arguments de sortie contenus, formate la réponse de diagnostic et termine le traitement de la requête.

Après une transmission et une extraction réussies des champs de données, l'instance perd sa validité et est rejetée sans étapes d'interaction supplémentaires.

Scénarios d'erreur

Interprétation : l'échec d'une opération de lecture ne sera vraisemblablement pas représenté par la structure elle-même, mais par le mécanisme de résultat ou d'erreur englobant de la plateforme (par exemple ara::core::Result ou ara::core::Future). Question Q-7d16241843f2d5e6 (ouverte) En tant que pure structure de données, <DataElement>ReadOutput ne déclare aucune méthode propre, précondition ou code d'erreur. Si l'accès en lecture à un élément de données devait échouer – par exemple en raison d'autorisations insuffisantes, d'états système non valides ou de problèmes de communication avec les capteurs sous-jacents –, l'interface d'implémentation signale cette erreur via le canal d'erreur de niveau supérieur de la plateforme. Dans un tel cas d'erreur, aucune instance valide de <DataElement>ReadOutput n'est mise à disposition pour évaluation, ce qui évite toute mauvaise interprétation de données utiles incomplètes du côté de l'appelant.