structure <ExtendedDataRecord-Namespace>::<ExtendedDataRecordElementInterface>::<ExtendedDataRecordElement>ReadOutput

Dans le module de diagnostic d'AUTOSAR Adaptive Platform, la structure sert d'encapsulation pour les arguments de sortie lors de la lecture d'un élément d'Extended Data Record. Elle regroupe les données de diagnostic résultantes d'une opération de lecture dans un objet typé, qui est transmis par l'interface fournisseuse à l'instance de diagnostic appelante. Vraisemblablement, la structure de données est remplie avec les valeurs déterminées pendant l'appel, puis mise à disposition pour un traitement ultérieur ou une transmission par valeur ou par sémantique de déplacement. Question (ouverte) En tant que pur objet de données dépourvu de mécanismes de synchronisation propres, elle requiert une coordination externe par les composants impliqués en cas d'accès concurrent.

plus ›

Contexte

La structure de données <ExtendedDataRecordElement>ReadOutput fait partie du module diag au sein d'AUTOSAR Adaptive Platform (version R25-11). Elle est assignée à l'espace de noms <ExtendedDataRecord-Namespace>::<ExtendedDataRecordElementInterface> et déclarée syntaxiquement en tant que structure C++ (struct <ExtendedDataRecordElement>ReadOutput {...};). Selon la description de la spécification, cette structure sert d'encapsulation pour les arguments de sortie d'une opération de lecture (Structure wrapping the out arguments for a ReadOutput).

Dans le cadre de la gestion adaptative du diagnostic, les enregistrements de données étendues (EDR, Extended Data Records) ont pour rôle de fournir des informations de diagnostic supplémentaires, spécifiques au constructeur ou standardisées, telles que des conditions de fonctionnement, des valeurs mesurées ou des compteurs d'état au moment d'une entrée de défaut. La structure <ExtendedDataRecordElement>ReadOutput agit ici en tant qu'objet de transfert de données dédié pour les résultats d'une requête portant sur un tel élément d'enregistrement de données. Au lieu de transmettre des valeurs de retour via plusieurs paramètres de sortie séparés ou des pointeurs, la structure regroupe les données de sortie générées.

L'instance de diagnostic demandeuse (par exemple un service de diagnostic ou l'environnement d'exécution de ara::diag) ainsi que l'implémentation applicative de l'interface <ExtendedDataRecordElementInterface> interviennent comme partenaires d'interaction principaux. Interprétation : la structure sert vraisemblablement avant tout à regrouper de manière sûre au niveau des types les valeurs de retour d'un appel de lecture sur une interface pour enregistrements de données étendues dans ara::diag et à les mettre à disposition pour le flux de données ultérieur. Question Q-0b74f3ccd5993cf3 (ouverte) De cette manière, une séparation nette de l'interface entre la fourniture et le traitement des données est garantie.

Cycle de vie

La structure <ExtendedDataRecordElement>ReadOutput est conçue comme un pur agrégat de données C++ sans logique métier ni maintien d'état propres. Il en résulte des caractéristiques univoques pour la création, les relations de propriété et la destruction dans le système.

L'instanciation de l'objet a lieu directement dans le contexte de l'appel de lecture à exécuter. Le composant fournisseur crée l'instance sur la pile ou au sein d'un contexte de traitement asynchrone et lui assigne les données de sortie déterminées. Interprétation : la durée de vie de l'instance devrait être liée au cycle respectif d'exécution et de retour de l'opération de lecture et se terminer après l'évaluation des données contenues par l'appelant. Question Q-8df0c1a01d7b670d (ouverte) Il n'existe aucun état interne et par conséquent aucune transition d'état définie ; après son initialisation, la structure se trouve dans un état de lecture immuable ou purement passif.

Concernant les relations de propriété, la structure est habituellement transmise par valeur (by value) ou au moyen d'une sémantique de déplacement (move semantics) à l'appelant. La propriété est ainsi intégralement transférée à l'entité appelante. Lors de la sortie de la portée (scope), la mémoire est libérée de façon déterministe selon les règles usuelles de destruction en C++.

En ce qui concerne la concurrence, <ExtendedDataRecordElement>ReadOutput ne contient aucun mécanisme interne de synchronisation, mutex ou opération atomique. Si une instance devait être partagée entre plusieurs threads ou réacheminée dans des pipelines de données asynchrones, la responsabilité d'un accès thread-safe incombe entièrement aux composants logiciels environnants du système de diagnostic.

Parcours d'utilisation

Le chemin d'utilisation typique décrit la succession des étapes lors de l'interrogation de données de diagnostic via l'interface <ExtendedDataRecordElementInterface> :

Tout d'abord, un service de diagnostic ou une fonction de diagnostic interne initie une requête de lecture pour un élément d'Extended Data Record donné. Cette requête s'adresse à l'opération de lecture de l'interface. Interprétation : dans le chemin d'utilisation, la structure est vraisemblablement remplie avec les valeurs lues par l'implémentation de l'application ou du gestionnaire, puis transmise pour la suite du traitement. Question Q-14a94978fff8f96e (ouverte) L'implémentation lit les informations de diagnostic actuelles depuis les sources de données internes et initialise une instance de <ExtendedDataRecordElement>ReadOutput avec ces valeurs.

Après l'initialisation, l'instance est retournée au composant de diagnostic appelant. L'appelant accède aux champs de données contenus dans la structure afin de valider les valeurs, de les sérialiser ou de les préparer pour la réponse de diagnostic conformément au protocole de diagnostic. Dès que les données de sortie ont été traitées avec succès ou transférées vers des zones mémoire en aval, l'utilisation de la structure prend fin et l'objet est détruit.