structure <RoutineInterface-Namespace>::<RoutineInterface>::<RoutineInterface6>StartOutput
struct <RoutineInterface6>StartOutput {...};
Structure wrapping the out arguments for a Start
| Header-Datei | #include "<RoutineInterfaceDirectoryPath>/<RoutineInterfaceShortname>.h" |
|---|---|
| Forwarding-Header | #include "<RoutineInterfaceDirectoryPath>/<RoutineInterfaceShortname>/<RoutineInterfaceShortname>_fwd.h" |
| Scope | class <RoutineInterface-Namespace>::<RoutineInterface> |
Guide utilisateurGÉNÉRÉ PAR IA
Encapsule les paramètres de sortie pour le démarrage d'une routine de diagnostic en vue de leur transmission à la plateforme adaptative.
Encapsule les paramètres de sortie pour le démarrage d'une routine de diagnostic en vue de leur transmission à la plateforme adaptative.
La structure <RoutineInterface6>StartOutput issue du module diag d'AUTOSAR Adaptive Platform encapsule tous les arguments de sortie pour l'opération de démarrage d'une routine de diagnostic. Lors de la réception d'une demande de démarrage, l'implémentation de la routine propre à l'application remplit les champs de données de la structure avec les valeurs résultantes et transmet l'instance à la plateforme, vraisemblablement imbriquée dans un objet de retour asynchrone. Question (ouverte) Selon l'interprétation, les états d'erreur ne sont pas signalés au sein de la structure de données elle-même, mais par des codes d'erreur distincts, raison pour laquelle tous les paramètres de sortie requis doivent toujours être initialisés de manière complète et cohérente avant le retour.
Contexte
La structure <RoutineInterface6>StartOutput fait partie du module diag d'AUTOSAR Adaptive Platform dans la version R25-11. Au sein de ce module de diagnostic, le type sert de conteneur de données regroupant les arguments sortants pour l'opération de démarrage d'une routine de diagnostic. Lors de l'exécution de fonctions de diagnostic par commande de routine, une implémentation de service spécifique à l'application et l'infrastructure de diagnostic de la plateforme interagissent généralement entre elles. La structure intervient ici à l'interface entre l'implémentation concrète de la routine et la couche de gestion des requêtes de diagnostic.
Dans cet ensemble, <RoutineInterface6>StartOutput a pour rôle de mettre à disposition sous forme groupée toutes les données de sortie générées par une application lors de l'exécution de la commande de démarrage. Interprétation : la structure sert vraisemblablement de pur objet de transfert de données (Data Transfer Object, DTO) sans logique métier propre, dont les champs membres spécifiques correspondent aux paramètres de sortie de la routine définis dans le modèle d'interface. Question Q-99209f0267b43982 (ouverte) Grâce à cette encapsulation, il est garanti que la gestion de diagnostic appelante puisse recevoir les valeurs de retour de manière groupée et les préparer pour un traitement ultérieur ou pour la restitution aux testeurs de diagnostic externes.
Cycle de vie
Le cycle de vie de <RoutineInterface6>StartOutput est étroitement couplé au contexte d'exécution de l'opération de démarrage de la routine de diagnostic. Une instance de cette structure est instanciée par l'implémentation de routine de l'application chargée de l'exécution dès qu'une demande de démarrage de la routine est traitée. Durant le traitement, l'application assigne aux différents attributs de la structure les données résultant du processus de démarrage.
En ce qui concerne les relations de propriété, la maîtrise de l'objet incombe d'abord localement à la routine exécutante. Lorsque le retour vers la gestion de diagnostic a lieu, il s'effectue typiquement par passage par valeur ou par sémantique de déplacement, par exemple dans le contexte de structures de retour asynchrones de la plateforme. Après la prise en charge par l'environnement d'exécution de la plateforme et l'acheminement des données vers la couche de protocole de diagnostic, le cycle de vie de l'objet prend fin, après quoi la structure est détruite et la mémoire occupée est libérée. La structure étant conçue comme un pur conteneur de données, elle ne dispose pas de machine à états interne propre ; ses phases de vie se résument à la création, au remplissage, au retour et à la libération. Question (ouverte)
Parcours d'utilisation
Le déroulement typique de l'utilisation de <RoutineInterface6>StartOutput se compose d'une séquence fixe d'étapes au sein du traitement de la routine :
- Initialisation : à la réception d'une demande de démarrage, l'application fournisseuse instancie une instance de
<RoutineInterface6>StartOutputsur la pile ou au sein du contexte d'exécution compétent. - Remplissage des champs de données : l'application réalise les vérifications fonctionnelles et les actions de lancement de la routine. Les données de sortie déterminées au cours de ce processus sont assignées aux champs de la structure.
- Retour : la structure entièrement remplie est retournée au système de diagnostic en tant que résultat de fonction. Vraisemblablement, le retour s'effectue imbriqué dans un conteneur typé tel que
ara::core::Resultouara::core::Futureafin de respecter la convention d'interface asynchrone de l'Adaptive Platform. Question Q-08976b247fab2180 (ouverte) - Traitement par la plateforme : la plateforme lit les valeurs contenues, les transpose dans la trame de réponse de diagnostic correspondante et conclut l'opération de traitement.
Pour les développeurs d'applications de diagnostic, la tâche principale consiste à assurer l'assignation correcte et complète de toutes les valeurs de sortie requises avant de quitter la méthode.
Scénarios d'erreur
Étant donné que <RoutineInterface6>StartOutput est définie comme une structure de données pour des paramètres de sortie réguliers, elle n'encapsule elle-même aucun code d'erreur ni traitement d'exceptions. Les scénarios d'erreur surviennent principalement lorsque la routine ne peut pas être démarrée correctement ou que des valeurs de sortie non valides sont générées.
Interprétation : si l'exécution de l'opération de démarrage échoue, les erreurs de diagnostic qui en résultent ne devraient pas être transportées par les champs de cette structure, mais par le modèle d'erreur de la plateforme, par exemple au moyen de codes d'erreur standardisés dans ara::core::ErrorCode. Question Q-fe76c79ba073f321 (ouverte) La précondition pour l'utilisation réussie de la structure est que l'action de démarrage déclenchée était autorisée et que les conditions requises pour l'exécution de la routine sont remplies. La postcondition veut que tous les paramètres de sortie de la structure déclarés dans l'interface soient laissés dans un état valide et cohérent avant que la transmission au système de diagnostic n'ait lieu.
Ce guide de classe est basé sur les données de spécification du module diag dans AUTOSAR Adaptive (Release R25-11).
gemini-3.8-flash-low· 2026-10-13 · Original allemand