FR 3153169 A1 20250321 FR 2309803 A 20230918 L’invention concerne un procédé d’obtention d’une variable cible, comprenant une donnée, codée dans un format cible, destinée à être utilisée par au moins une unité d’exécution logicielle, dite unité consommatrice, ladite unité consommatrice appartenant à au moins un composant logiciel d’un système informatique comprenant au moins un processeur apte à exécuter au moins ladite unité consommatrice, ledit procédé comprenant : - la lecture dans une mémoire du système informatique d’un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une unité consommatrice et ladite unité productrice, - lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, l’adaptation de la variable source en la variable cible, et - la lecture de la variable cible dans la mémoire du système informatique, sinon. Figure pour l’abrégé : FIG. 7. Procédé d’obtention d’une variable cible, procédé de détermination d’une variable source, dispositifs, unités d’exécution, système et programmes d’ordinateur correspondants L’invention se rapporte au domaine technique des systèmes informatiques comprenant plusieurs composants logiciels qui échangent des données entre eux. L’invention concerne en particulier la compatibilité entre une variable produite par une unité logicielle d’un premier composant logiciel et une variable d’entrée utilisée par une unité logicielle d’un autre composant logiciel. Etat de la technique antérieure De façon connue en soi, deux composants logiciels d’un même système informatique sont amenés à échanger des données par l’intermédiaires d’une interface de communication. Cette communication peut se faire sous forme logicielle par l’intermédiaire d’une variable qui est écrite par un ou plusieurs composants logiciels, dits producteurs de la variable, et lue par un ou plusieurs autres composants logiciels, dits consommateurs de cette variable. On désigne par variable en informatique, un conteneur qui stocke une valeur ou une donnée qui peut être modifiée tout au long de l’exécution d’un programme informatique. Elle est utilisée pour stocker des données temporaires ou permanentes qui seront utilisées dans des calculs ou des opérations. En programmation, une variable est définie par trois composants : son nom, son type et sa valeur. Le nom est un identifiant unique qui permet de référencer la variable, le type définit la nature et le format (par exemple 8, 16, 32, 64 bits avec un nombre fixe de bits après la virgule ou en virgule flottante) de la donnée stockée dans la variable (par exemple un nombre entier, une chaîne de caractères, un booléen, etc.) et la valeur est la donnée effectivement stockée dans la variable. Un inconvénient est que les variables produites par les composants producteurs et celles consommées par les composants consommateurs ne sont pas toutes définies de la même façon. Autrement dit, même si elles représentent une même information par exemple, elles peuvent avoir : - des noms différents, par exemple VB et Vbat pour désigner la tension d’une batterie, - des unités de mesure différentes, par exemple en V et mV, - des types et des choix d’implémentations différents. Par exemple, une tension peut être définie comme un caractère (de l’anglais, « character ») non signé codé sur 8 bits (sa valeur logicielle varie entre 0 et 255) ou encore comme un entier non signé codé sur 16 bits (sa valeur logicielle varie entre 0 et 32767). Dans la suite, on parlera de format de variable. Il faut donc prévoir, lors d’une intégration dans un même programme informatique de deux composants logiciels utilisant des variables de formats différents pour coder une même donnée, une adaptation permettant de passer de l’une à l’autre. Généralement, cette adaptation est mise en œuvre entre le composant producteur et le composant consommateur. Plus précisément, une unité d’exécution logicielle mettant en œuvre l’adaptation en question est généralement développée à part des composants producteur et consommateur, puis intégrée statiquement dans une séquence ordonnancée d’exécution des différents composants. Pour garantir un flux de données cohérent, l’ordonnancement de l’unité d’exécution ADP réalisant la fonction d’adaptation doit remplir les conditions suivantes : - être appelée après une première unité d’exécution logicielle qui produit la donnée (par exemple la valeur de tension d’une batterie) et l’écrit dans une première variable, dite source, DA1 =VB selon un premier format de variable ; et - être appelée avant une deuxième unité d’exécution logicielle qui lit la donnée dans une deuxième variable Vbat, dite cible, selon un deuxième format de variable. En relation avec la FIG. 1 , on présente à titre d’exemple un premier composant logiciel CM1 comprenant une unité d’exécution implémentant une fonction F1 configurée pour produire la variable VB, un deuxième composant logiciel CM2 comprenant une unité d’exécution implémentant une fonction F2 configurée pour utiliser la variable Vbat et un troisième composant logiciel, dit d’adaptation, CMP ADP, comprenant une unité d’exécution implémentant une fonction ADP d’adaptation de la variable VB en la variable Vbat. Ces conditions sont faciles à satisfaire lorsque les première et deuxième unités d’exécutions F1 et F2 sont programmées dans une même et unique séquence temporelle, par exemple une seule et unique tâche logicielle exécutée par un processeur à une fréquence d’exécution donnée. En effet, comme illustré par la FIG. 2 , la séquence d’exécution comprend d’abord l’unité d’exécution F1 qui produit la variable VB et la stocke en mémoire, puis la fonction d’adaptation ADP est appelée pour réaliser l’adaptation de la variable VB et produire la variable Vbat, puis finalement c’est la fonction F2 qui s’exécute et utilise la variable Vbat qui est disponible. Du fait que toutes les fonctions s’exécutent à la même fréquence, l’ordonnancement F1 – ADP – F2 est respecté si bien que la séquence peut être répétée autant que nécessaire. En revanche, lorsque les unités d’exécution F1 et F2 ne sont pas ordonnancées dans une même séquence temporelle, par exemple, elles appartiennent à deux tâches logicielles distinctes s’exécutant à des fréquences d’exécution différentes, l’ordonnancement optimal de l’unité d’exécution de la fonction d’adaptation par rapport à F1 et F2 peut devenir complexe à établir : - l’appel de la fonction d’adaptation ADP après F1 n’est pas nécessaire si F1 s’exécute une nouvelle fois avant que F2 ne soit lancée (la variable VB est réécrite), - l’appel de la fonction d’adaptation ADP avant l’exécution de F2 n’est pas nécessaire si la variable VB a déjà été adaptée en Vbat (par exemple parce que F2 a déjà été appelée depuis la dernière exécution de F1). Dans l’exemple de la FIG. 3 , on considère deux séquences temporelles distinctes SQ1 et SQ2 qui s’exécutent en parallèle (PRL). La première séquence SQ1 présente un ordonnancement selon lequel une exécution de l’unité F1 est suivie d’une exécution de la fonction d’adaptation ADP. On note que la fréquence d’exécution de F1 n’est pas constante. En effet, il s’écoule une période temporelle plus longue entre le deuxième et le troisième appel de F1 qu’entre le premier et le deuxième. La deuxième séquence SQ2 présente un ordonnancement selon lequel une exécution de la fonction F2 alterne avec un appel de la fonction ADP. Plus précisément, c’est la séquence SQ1 qui commence avec l’exécution de l’unité F1, suivie d’une exécution de la fonction ADP, elle-même suivie d’une nouvelle exécution de la fonction F1 et de la fonction ADP. On note que le premier appel de la fonction ADP était inutile, puisque la valeur codée dans la variable VB a été modifiée par la deuxième exécution de F1 avant même qu’une exécution de F2 ne soit déclenchée. Après la deuxième exécution de ADP, c’est la deuxième séquence qui s’exécute avec le lancement de F2, puis de la fonction ADP, puis de nouveau de F2. On note que la deuxième exécution de ADP par la séquence SQ1 était utile, mais que ce n’est pas le cas de celle déclenchée dans la séquence SQ2. En effet, la fonction ADP y est lancée alors qu’il n’y a pas eu de production de nouvelle valeur de la variable VB par F1. Cet ordonnancement n’est donc pas optimal. Pour faciliter le processus de programmation et d’ordonnancement des exécutions des différentes fonctions de production, d’adaptation et d’utilisation d’une variable, qui est manuel, on peut décider de mettre en œuvre l’une ou l’autre des stratégies suivantes : - l’exécution de la fonction d’adaptation est programmée avant celle de la fonction de consommation de la variable Vbat, ou - l’exécution de la fonction d’adaptation est programmée après celle de la fonction de production de la variable VB. Même si elle n’est pas optimale, cette approche garantit que la variable adaptée Vbat soit toujours à jour. On considère maintenant en relation avec la FIG. 4 un cas d’usage plus complexe selon lequel trois variables DA1, DA2 et DA3 sont produites par un composant logiciel interne INT_CMP comprenant trois tâches logicielles distinctes TSK1, TSK2, TSK3 s’exécutant à trois fréquences d’exécution distinctes, par exemple égales respectivement à 1000ms, 1ms et 100ms, sur trois processeurs distincts. Ces variables doivent être adaptées par une unité d’exécution ADP_IN avant d’être consommées par un composant logiciel externe ou tiers EXT_CMP, intégré dans la tâche logicielle TSK2 à la fréquence 1ms. Dans l’exemple de la FIG. 4 , les trois variables data1, data2, data3 sont adaptées par la fonction ADP_IN toutes les 1ms alors que certaines d’entre elles (data1 toutes les 1000ms et data 3 toutes les 100ms) sont produites et donc mises à jour à un rythme plus lent. La variable DA4 est produite par le composant logiciel tiers EXT_CMP. Elle doit être adaptée par une fonction d’adaptation ADP_OUT, afin de pouvoir être consommée par des unités d’exécution du composant logiciel interne INT_CMP (dans les tâches logicielles TSK1 et TSK4). L'adaptation est réalisée toutes les 1ms alors qu'il n'y a pas d’unité d’exécution consommatrice qui fonctionne à ce rythme (TSK1 fonctionne à 1000ms et TSK3 à 100ms). Cet exemple illustre bien le fait que : - certaines variables sont adaptées du côté de l’unité d’exécution consommatrice. C’est le cas des variables DA1-DA3 d’entrée d’unités d’exécution tiers du composant logiciel tiers EXT_CMP, - certaines autres variables sont adaptées du côté de l’unité d’exécution productrice. C’est le cas des variables DA4 de sortie du composant logiciel tiers EXT_CMP, car les unités d’exécution consommatrices sont programmées juste après l’adaptation. Cette stratégie est la plus utilisée car elle présente l’avantage de ne nécessiter que le développement de deux unités d’exécution d’adaptation, une unité d’adaptation des variables produites par le composant INT_CMP et consommées par le composant logiciel tiers et les variables DA4 produites par le composant tiers EXT_CMP et consommées par le composant interne INT_CMP. L’adaptation est ainsi réalisée autour du composant logiciel tiers pour l’isoler du composant interne. Cette solution présente toutefois les inconvénients suivants : - Premièrement, alors que le code d'adaptation peut être généré automatiquement, il est toujours nécessaire de vérifier manuellement le flux de données, de programmer l’exécution de toute nouvelle fonction d’adaptation et de mettre à jour l’ordonnancement des unités d’exécution d’adaptation déjà existantes si besoin, - deuxièmement, elle ne garantit pas que l’adaptation soit toujours effectuée à la fréquence optimale. En effet, en relation avec la FIG. 5 , on considère un exemple d’adaptation mis en œuvre du côté du composant logiciel producteur d’une variable. Selon cet exemple, une unité d’exécution logicielle R1 produit une variable DA1 toutes les 1ms sur un premier processeur A1 à la fréquence d’exécution de 1ms. Une unité d’exécution logicielle R2 s’exécute sur un processeur A2 à la fréquence de 100ms et consomme une variable DA2 toutes les 100ms. Une unité d’exécution logicielle ADP est programmée pour s’exécuter après chaque exécution de R1 sur le processeur A1. Elle prend en entrée la variable DA1 et produit la variable adaptée DA2 en sortie. On comprend que si une fréquence de production de DA1 est supérieure à une fréquence de consommation de DA2, alors des adaptations de DA1 par ADP sont inutilement mises en œuvre. A titre d’exemple, si la production de DA1 s’effectue toutes les 10 ms et la consommation de DA2 toutes les 100ms, alors 9 adaptations sur 10 sont inutiles, car elles s’effectuent sur une valeur inchangée de la variable DA1 depuis l’exécution précédente de ADP. En relation avec la FIG. 5 , on considère maintenant un exemple d’adaptation mis en œuvre du côté du composant logiciel consommateur d’une variable DA2. L’unité d’exécution R1 s’exécute sur un processeur A1 et produit la variable DA1 toutes les 100 ms. L’unité d’exécution R2 s’exécute sur le processeur A2 et consomme la variable DA2 toutes les 1ms. Une unité d’exécution R3 s’exécute sur un processeur A3 et consomme la variable DA2 toutes les 10ms. Une unité d’exécution ADP est programmée pour s’exécuter avant R2 et R3 respectivement sur les processeurs A2 et A3 et produire la variable DA2 adaptée à partir de la variable DA1. On comprend que si une fréquence de consommation de DA2 est supérieure à une fréquence de production de la variable DA1, alors des adaptations de la variable DA1 sont inutilement effectuées. A titre d’exemple, si la production de DA1 par R1 s’effectue toutes les 100 ms et la consommation de DA2 respectivement toutes les 1ms et 10 ms par R2 et R3, alors 109 adaptations sur 110 sont inutiles, car elles s’effectuent sur une valeur inchangée de la variable DA1 depuis l’exécution précédente de ADP. Au vu de ce qui précède, les solutions actuelles ne sont pas optimales. Notamment, elles entraînent : - une charge de travail accrue du système informatique due aux exécutions inutiles de l’unité d’adaptation, - un effort d’ingénierie élevé, et - une flexibilité réduite pour programmer les adaptations de façon optimale. L’effort d’ingénierie élevé s’explique par : - la nécessité de développer, intégrer et maintenir les unités logicielles d’adaptation et programmer manuellement l’ordonnancement de l’exécution de ces unités logicielles d’adaptation dans les séquences de production et de consommation des variables par les différents composants logiciels, - le regroupement des variables à adapter et des unités d’adaptation correspondantes par tâches logicielles, en fonction des fréquences de production et de consommations de ces variables par d’autres unités/composants, - ce travail d’intégration manuel est sujet aux erreurs, ce qui induit des problèmes de flux de données entre le composant logiciel producteur et le composant logiciel consommateur. La flexibilité réduite est due notamment : - au recours à des unités logicielles d’exécution indépendantes pour réaliser les fonctions d’adaptation, – à des composants logiciels producteurs et/ou consommateurs monolithiques, notamment quand il s’agit de logiciels tiers, qui ne permettent pas d’insérer l’exécution d’une unité d’adaptation entre deux exécutions d’unités logicielles de ces composants. Il existe donc un besoin d’une solution ne présentant pas de tels inconvénients. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé d’obtention d’une variable cible, comprenant une donnée, codée dans un format cible, destinée à être utilisée par au moins une unité d’exécution logicielle, dite unité consommatrice, ladite unité consommatrice appartenant à au moins un composant logiciel d’un système informatique comprenant au moins un processeur apte à exécuter au moins ladite unité consommatrice. Ledit procédé comprend: - la lecture dans une mémoire du système informatique d’un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une unité consommatrice et ladite unité productrice, - lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, l’adaptation de la variable source en la variable cible, et - la lecture de la variable cible dans la mémoire du système informatique, sinon. Avec l’invention, l’adaptation de la variable source est mise en œuvre par l’unité d’exécution logicielle consommatrice d’une variable cible qui code la même donnée, par exemple la même mesure physique, que la variable source, mais selon un autre format. En outre, cette adaptation n’est déclenchée par l’unité d’exécution logicielle consommatrice que lorsque nécessaire, selon la valeur d’un indicateur d’adaptation de la variable source. Cet indicateur est configuré pour prendre une première valeur indiquant qu’une adaptation de la variable source en la variable cible est requise et une deuxième valeur indiquant le contraire. Au contraire, lorsque l’indicateur d’adaptation indique qu’il n’est pas nécessaire d’adapter la variable source (parce qu’elle a déjà été adaptée depuis la dernière mise à jour), la valeur de la variable cible stockée en mémoire est simplement lue afin d’être mise à disposition de l’unité consommatrice. Ainsi, l’invention propose une solution simple et efficace qui permet de déclencher automatiquement l’adaptation d’une variable quand c’est nécessaire et uniquement dans ce cas, sans avoir à programmer manuellement un ordonnancement des différentes exécutions des unités de production et de consommation, ni à prendre en compte les fréquences d’exécution de chacune d’entre elles. Cette solution s’appuie sur l’intégration au sein des unités consommatrices d’une nouvelle fonction d’adaptation de la variable source et sur l’utilisation d’une mémoire partagée entre les unités productrices et consommatrices. Cette mémoire partagée stocke au moins l’indicateur d’adaptation et la variable cible. L’invention contribue ainsi à réduire la charge CPU liée à la mise en œuvre de l’adaptation des variables produites par des unités productrices et destinées à être consommées par des entités consommatrices. Elle permet aussi de réduire l’effort de développement lié à la définition et à l’implémentation des unités d’exécution logicielles des fonctions d’adaptations selon l’art antérieur. Elle permet également d’optimiser le comportement dynamique de la fonction d’adaptation, notamment en accélérant la propagation des flux de données (la variable cible n’est adaptée que lorsque c’est nécessaire). Selon un autre aspect, l’adaptation de la variable source en la variable cible comprend : - la lecture dans ladite mémoire, de la variable source, comprenant un code de ladite donnée, dans un format source, - la détermination d’un code de la donnée dans le format cible à partir du code de la donnée dans le format source extrait de la variable source, et - le positionnement de l’indicateur d’adaptation à une deuxième valeur, distincte de la première valeur, indiquant qu’une adaptation de la variable source à la variable cible n’est pas requise et - la mise à disposition de la variable cible adaptée et de l’indicateur d’adaptation mis à jour dans la mémoire. Afin d’éviter que l’adaptation de la variable source soit déclenchée par une autre unité consommatrice après elle, la valeur de l’indicateur d’adaptation est mise à jour et stockée en mémoire. La variable cible adaptée est elle stockée en mémoire et donc mise à disposition d’autres unités consommatrices. Selon encore un autre aspect, le procédé est mis en œuvre, suite à la lecture par l’unité consommatrice, d’une étiquette insérée dans des instructions de code informatique de ladite unité consommatrice, ladite étiquette associant des instructions de code informatique pour l’exécution dudit procédé. Selon un exemple de réalisation non limitatif, le procédé d’obtention selon l’invention est mis en œuvre sous forme de macro. Cette macro réalise donc les étapes du procédé selon l’invention. Elle peut être comprise dans un autre composant logiciel du système informatique que celui de l’unité d’exécution logicielle consommatrice. Par exemple, il s’agit d’un composant logiciel dit d’adaptation qui regroupe toutes les fonctions d’adaptation nécessaires pour l’exécution des composants logiciels d’un programme informatique donné du système informatique. Selon un exemple de réalisation non limitatif, on associe la fonction macro qui implémente le procédé d’obtention de la variable cible selon l’invention à une étiquette déjà utilisée par le code source de l’unité consommatrice pour réaliser l’accès à la donnée de la variable cible dont il a besoin. La lecture de la variable source et l’écriture de la variable cible sont ainsi réalisées dans cette fonction macro associée, qui peut elle-même être définie en dehors du code informatique source. De la sorte, la mise en œuvre de l’invention n’implique pas de modification du code source. Ceci est particulièrement avantageux lorsque l’unité consommatrice fait partie d’un composant logiciel tiers, dont seul le code objet est disponible. L’invention concerne également un dispositif d’obtention d’une variable cible, comprenant une donnée, codée dans un format cible, destinée à être utilisée par au moins une unité d’exécution logicielle, dite unité consommatrice, ladite unité consommatrice appartenant à au moins un composant logiciel d’un système informatique comprenant au moins un processeur apte à exécuter ladite unité consommatrice. Ledit dispositif est configuré pour mettre en œuvre : - la lecture dans une mémoire du système informatique d’un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une entité consommatrice et ladite unité productrice, - lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, l’adaptation de la variable source en la variable cible, et - la lecture de la variable cible dans la mémoire du système informatique, sinon. Avantageusement, un tel dispositif met en œuvre le procédé précité, dans ses différents modes de réalisation. Selon un exemple de réalisation non limitatif, le dispositif précité est intégré dans une unité d’exécution logicielle, dite unité consommatrice d’une variable cible, comprise dans un composant logiciel d’un système informatique. Selon un autre exemple de réalisation non limitatif, le dispositif précité est mis en œuvre dans une unité d’exécution logicielle comprise dans un composant logiciel du système informatique dédié à l’adaptation de variables. Il est distinct du composant logiciel de l’unité productrice. Selon un exemple de réalisation non limitatif, la mise en œuvre du dispositif précité est déclenchée par la lecture d’une étiquette dans des instructions de code informatique de ladite unité d’exécution logicielle, ladite étiquette étant associée à des instructions de code informatique pour l’exécution dudit dispositif. Corrélativement, l’invention concerne aussi un procédé de détermination d’une variable source, comprenant une donnée, codée dans un format source, ledit procédé étant destiné à être mis en œuvre par une unité d’exécution logicielle, dite unité productrice, configurée pour produire la variable source, ladite unité productrice étant comprise dans un composant logiciel d’un système d’information comprenant au moins un processeur apte à exécuter ladite unité productrice. Ledit procédé comprend : - l’obtention de ladite donnée, auprès d’une mémoire de l’unité productrice, - le codage de ladite donnée, un code de ladite donnée dans un format source étant obtenu et l’insertion dudit code dans ladite variable source, - le positionnement d’un indicateur d’adaptation de la variable source à une première valeur indiquant qu’une mise à jour est requise, et - le stockage de ladite variable source et de l’indicateur d’adaptation dans une mémoire dudit système informatique, ladite mémoire étant partagée avec au moins une autre unité logicielle d’exécution, dite unité consommatrice, comprise dans un autre composant logiciel du système d’information, et configurée pour utiliser une variable cible comprenant un code de ladite donnée dans un format cible, distinct dudit format source. Avec l’invention, une unité d’exécution logicielle qui produit une variable cible destinée à être utilisée (ou consommée) par une ou plusieurs autres unités d’exécution d’un autre composant logiciel du système informatique, la met à leur disposition dans un espace mémoire partagé et lui associe un indicateur de mise à jour, qui renseigne sur la nécessité pour une unité d’exécution de l’autre composant logiciel de la mettre à jour ou non. Avantageusement, un tel dispositif met en œuvre le procédé de détermination précité, dans ses différents modes de réalisation. Selon un exemple de réalisation non limitatif, le dispositif précité est intégré dans une unité d’exécution logicielle, dite unité productrice d’une variable source, comprise dans un composant logiciel d’un système informatique. Selon un autre exemple de réalisation non limitatif, le dispositif précité est mis en œuvre dans une unité d’exécution logicielle comprise dans un composant logiciel du système informatique, dédié à l’adaptation de variables et distinct de celui de l’unité d’exécution logicielle productrice. Selon un exemple de réalisation non limitatif, la mise en œuvre du dispositif précité est déclenchée par la lecture d’une étiquette dans des instructions de code informatique de ladite unité d’exécution logicielle, ladite étiquette étant associée à des instructions de code informatique pour l’exécution dudit dispositif. Selon un exemple de réalisation non limitatif, les dispositifs de détermination d’une variable source et d’obtention d’une variable cible précités sont intégrés dans un système informatique comprenant au moins un processeur et une mémoire, ladite mémoire étant configurée pour stocker au moins un premier et un deuxième composants logiciels destinés à être exécutés par ledit au moins un processeur, le premier composant logiciel comprenant une unité d’exécution logicielle, dite productrice, configurée pour produire la variable source, le deuxième composant logiciel comprenant une unité d’exécution logicielle, dite consommatrice, configurée pour utiliser la variable cible. Le système, l’unité productrice, l’unité consommatrice et les dispositifs précités présentent les mêmes avantages que les procédés d’obtention et de détermination précités. L’invention concerne aussi des produits programmes d’ordinateur comportant des instructions pour l’exécution des procédés d’obtention et de détermination précités. L’invention concerne enfin un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateurs précités. Bien sûr les modes de réalisations qui viennent d’être présentés peuvent être combinés entre eux. D'autres caractéristiques et avantages apparaitront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés parmi lesquels : FIG. 1 déjà décrite, illustre de façon schématique, un exemple de mise en œuvre d’une adaptation d’une variable source en une variable cible par un composant logiciel dédié selon l’art antérieur ; FIG. 2 déjà décrite, illustre de façon schématique, un exemple de tâche logicielle exécutant une séquence temporelle de production d’une variable source, adaptation de la variable source en une variable cible et consommation de la variable cible selon l’art antérieur ; FIG. 3 déjà décrite, illustre de façon schématique, un exemple de deux tâches logicielles s’exécutant en parallèle, l’une comprenant la production de la variable source, l’autre comprenant la consommation de la variable cible et l’adaptation de la variable source en la variable cible étant mise en œuvre dans les deux tâches logicielles, selon l’art antérieur ; FIG. 4 déjà décrite, illustre de façon schématique, un premier exemple d’ordonnancement de la production de plusieurs variables sources par des unités d’exécution logicielles distinctes d’un composant logiciel, réparties sur plusieurs tâches logicielles s’exécutant à des fréquences temporelles distinctes, de leur adaptation en des variables cibles, et de la consommation des variable cibles par un composant tiers, selon l’art antérieur ; FIG. 5 déjà décrite, illustre de façon schématique, un deuxième exemple d’ordonnancement d’unités logicielles de production d’une variable source, adaptation de la variable source en une variable cible et consommation de la variable cible, lorsqu’elles s’exécutent dans des tâches logicielles distinctes à des fréquences temporelles distinctes selon l’art antérieur ; FIG. 5 déjà décrite, illustre de façon schématique, un troisième exemple, plus complexe, d’ordonnancement d’unités logicielles de production d’une variable source, adaptation de la variable source en une variable cible et consommation de la variable cible, lorsqu’elles s’exécutent sur des tâches logicielles distinctes à des fréquences temporelles distinctes selon l’art antérieur ; FIG. 6 illustre de façon schématique un exemple de système informatique comprenant un dispositif d’obtention d’une variable cible et un dispositif de détermination d’une variable source selon un exemple de réalisation particulier non limitatif de l’invention ; FIG. 7 présente sous forme de logigramme les étapes d’un procédé d’obtention d’une variable cible selon un exemple de réalisation particulier non limitatif de l’invention ; FIG. 8 détaille l’adaptation d’une variable source en une variable cible selon un exemple de réalisation particulier non limitatif de l’invention ; FIG. 9 présente sous forme de logigramme les étapes d’un procédé de détermination d’une variable source selon un exemple de réalisation particulier non limitatif de l’invention ; et FIG. 10 présente un exemple de structure matérielle d’un dispositif d’obtention d’une variable cible et d’un dispositif de détermination d’une variable source selon un exemple de réalisation particulier non limitatif de l’invention. Dans la description qui va suivre, des éléments identiques, similaires ou analogues seront désignés par les mêmes chiffres de référence. Sauf indication contraire, les diagrammes ne sont pas nécessairement à l’échelle. Les diagrammes blocs, algorigrammes et diagrammes de séquence de messages dans les figures illustrent l’architecture, les fonctionnalités et le fonctionnement de systèmes, dispositifs, procédés et produits programmes d’ordinateur selon un ou plusieurs exemples de réalisation. Chaque bloc d’un diagramme bloc ou chaque phase d’un algorigramme peut représenter un module ou encore une portion de code logiciel comprenant des instructions pour l’implémentation d’une ou plusieurs fonctions. Selon certaines implémentations, l’ordre des blocs ou des phases peut être changé, ou encore les fonctions correspondantes peuvent être mises en œuvre en parallèle. Les blocs ou phases de procédé peuvent être implémentés à l’aide de circuits, de logiciels ou d’une combinaison de circuits et de logiciels, et ce de façon centralisée, ou de façon distribuée, pour tout ou partie des blocs ou phases. Les systèmes, dispositifs, procédés et méthodes décrits peuvent être modifiés, faire l’objet d’ajouts et/ou de suppressions tout en restant dans le cadre de la présente description. Par exemple, les composants d’un dispositif ou d’un système peuvent être intégrés ou séparés. Également, les fonctions décrites peuvent être mises en œuvre à l’aide de plus ou de moins de composants ou de phases, ou encore avec d’autres composants ou à travers d’autres phases. Tout système de traitement de données adapté peut être utilisé pour l’implémentation. Un système ou dispositif de traitement de données adapté comprend par exemple une combinaison de code logiciel et de circuits, tels un processeur, contrôleur ou autre circuit adapté pour exécuter le code logiciel. Lorsque le code logiciel est exécuté, le processeur ou contrôleur conduit le système ou dispositif à mettre en œuvre tout ou partie des fonctionnalités des blocs et/ou des phases des procédés ou méthodes selon les exemples de réalisation. Le code logiciel peut être stocké dans une mémoire ou un support lisible accessible directement ou à travers un autre module par le processeur ou contrôleur. En relation avec la FIG. 6 , on présente, à titre d’exemple illustratif, un système informatique S, aussi appelé calculateur, dans lequel se situe l’invention. Le système S peut être embarqué ou non, par exemple dans un véhicule. Il présente la structure matérielle d’un ordinateur. Il comprend notamment des composants matériels parmi lesquels un ou plusieurs processeurs PROC1, PROC2, une mémoire non volatile MNV dans laquelle sont stockés un ou plusieurs programmes logiciels applicatifs, tels que le programme Pg, une mémoire vive MEM et une ou plusieurs interfaces de communication IC. Il comprend aussi un système d’exploitation (non représenté) apte à gérer l’utilisation des ressources matérielles et logicielles du calculateur S par le ou les programmes logiciels applicatifs Pg. Un tel programme logiciel Pg comprend un ou plusieurs composants logiciels CMP1, CMP2 et CMP3 qui échangent des données stockées dans une mémoire partagée, par exemple la mémoire vive MEM précitée. Un composant logiciel CMP1, CMP2, CMP3 comprend une ou plusieurs unités d’exécution logicielle UP1, UC2, UC3. Une unité d’exécution est configurée pour traiter des données d’entrée et produire des données de sortie, à une fréquence donnée, définie par un événement système cadencé cycliquement sur une base temporelle (par exemple1 ms, 5 ms, 10 ms, 100 ms, …) ou pour répondre à un événement extérieur, par exemple la réception d’un signal en provenance d’un actionneur (non représenté). Par exemple, le programme logiciel applicatif Pg est un programme de contrôle moteur d’un véhicule. Les données partagées sont des variables qui codent des mesures de grandeurs physiques collectées par des capteurs placés à différents points du véhicule. Par exemple, la grandeur physique mesurée est la tension d’une batterie. Les composants logiciels n’étant pas tous nécessairement conçus par la même société, les variables qu’ils utilisent en entrée et produisent en sortie ne sont pas toutes compatibles entre elles, au sens où leurs données ne sont pas toutes codées dans le même format. Par exemple, le composant CMP1 produit une variable DA1 =VB qui représente une mesure de tension d’une batterie, par exemple obtenue d’un ou plusieurs capteurs placés dans le moteur du véhicule et le composant logiciel CMP2 consomme une variable DA2 = Vbat qui représente cette mesure de tension dans un autre format. On suppose que le composant logiciel CMP3 consomme lui aussi la variable cible DA2. Le programme logiciel applicatif Pg utilise aussi un ordonnanceur (en anglais, « scheduler »), non représenté, configuré pour ordonnancer l’exécution des unités d’exécution logicielle de ses composants logiciels CMP1, CMP2, CMP3 par les ressources matérielles et logicielles mises à sa disposition par le calculateur S, en prenant en compte les fréquences d’exécution de leurs unités d’exécution. Pour ce faire, il définit une ou plusieurs tâches logicielles, chacune étant associées à une fréquence d’exécution donnée et constituant un conteneur d’intégration de la ou les unités d’exécution de ses composants devant s’exécuter à la fréquence donnée. De façon connue en soi, une tâche logicielle est généralement associée à une priorité donnée par rapport à d’autres tâches logicielles, ce qui permet si besoin de la préempter en faveur d’une autre tâche logicielle plus prioritaire. L’invention s’inscrit dans le contexte d’un tel système informatique et propose un mécanisme d’adaptation d’une variable source produite par une unité logicielle d’exécution d’un des composants logiciels du programme logiciel applicatif Pg, par exemple la variable source DA1 produite par l’unité productrice UP1 du composant logiciel CMP1, en une variable cible DA2 destinée à être consommée par une unité logicielle d’exécution, par exemple l’unité consommatrice UC2, UC3 du composant logiciel CMP2, CMP3, qui est intégré dans les fonctions d’accès à cette variable cible. Dans l’exemple de la FIG. 1 , l’unité consommatrice UC2 comprend un dispositif 200 d’obtention d’une variable cible selon un ou plusieurs modes de réalisation de l’invention. Un tel dispositif est configuré pour lire dans une mémoire du système informatique, par exemple la mémoire MEM, un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, par exemple l’unité productrice UP1 du composant CMP1, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une unité consommatrice et ladite unité productrice, lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, adapter la variable source en la variable cible, et lire la variable cible dans la mémoire MEM, sinon. Le dispositif 200 met donc en œuvre le procédé d’obtention d’une variable cible qui sera décrit plus avant en relation avec la FIG. 7 . De même, l’unité consommatrice UC3 comprend le dispositif 200 d’obtention de la variable cible DA2, mettant lui aussi en œuvre le procédé d’obtention d’une variable cible selon l’invention. Dans l’exemple de la FIG. 6 l’unité productrice UP1 du composant logiciel CMP1 comprend un dispositif 100 de détermination d’une variable source configuré pour obtenir une donnée auprès d’une mémoire de l’unité productrice, coder ladite donnée dans un format source et insérer le code obtenu dans une variable source, positionner un indicateur d’adaptation de la variable source à une première valeur indiquant qu’une mise à jour est requise, et stocker ladite variable source et l’indicateur d’adaptation dans une mémoire dudit système informatique, par exemple la mémoire MEM, ladite mémoire étant partagée avec au moins une autre unité logicielle d’exécution, dite unité consommatrice, comprise dans un autre composant logiciel du système d’information, par exemple UC2 du composant logiciel CMP2 et UC3 du composant logiciel CMP3, et configurée pour utiliser une variable cible comprenant un code de ladite donnée dans un format cible, distinct dudit format source. Le dispositif 100 met en œuvre un procédé de détermination d’une variable source qui sera décrit plus avant en relation avec la FIG. 8 . On décrit désormais, en relation avec la FIG. 7 , un procédé d’obtention d’une variable cible DA2 selon un exemple de réalisation de l’invention. Il est par exemple mis en œuvre par le dispositif 200 précité. Ce dispositif 200 peut être intégré ou non dans l’unité consommatrice UC2 de la variable cible DA2 en question. S’il est extérieur à l’unité consommatrice UC2, alors il est appelé par cette unité consommatrice UCE lorsqu’elle s’exécute. En 70, un indicateur FLG d’adaptation de la variable source est obtenu. Par exemple, il est lu dans un emplacement mémoire de la mémoire MEM du système informatique S, qui est partagée entre les différents composants logiciels CMP1, CMP2, CMP3 de ce système. Selon un ou plusieurs exemples de réalisation, l’indicateur FLG est configuré pour prendre une valeur parmi une première et une deuxième valeurs VL1, VL2 : - la première valeur VL1, par exemple égale à 1, indique qu’une adaptation de la variable source DA1 est requise, - la deuxième valeur VL2 par exemple égale à 0, indique qu’une adaptation de la variable source DA1 n’est pas requise. En 71, la valeur de l’indicateur est testée. Si elle correspond à la première valeur VL1, l’adaptation de la variable source est déclenchée en 72. Elle produit une variable cible DA2 adaptée. Sinon, la variable cible DA2 est obtenue en 73. Par exemple, elle est lue dans un emplacement mémoire de la mémoire MEM. La variable cible DA2 adaptée, respectivement lue, constitue la valeur de sortie ou résultat produit par le procédé de détermination. On détaille maintenant en relation avec la FIG. 8 , un exemple de mise en œuvre de l’adaptation de la variable source DA1 en la variable cible DA2 selon un mode de réalisation. En 721, la variable source DA1 est obtenue. Par exemple, elle est lue dans un emplacement mémoire de la mémoire partagée MEM. Elle comprend une donnée CD1, par exemple une mesure de tension, codée selon un premier format. Si on reprend l’exemple décrit plus haut, l’unité utilisée est le V et la donnée est codée sur 8 bits comme un entier non signé de type caractère. La variable cible DA2, utilise le mV comme unité et code la mesure de tension, selon un deuxième format (CD2) sous la forme d’un entier non signé sur 16 bits. En 722, une valeur correspondante de donnée codée CD2 dans le deuxième format est déterminée à partir du code CD1 extrait de la variable source. Par exemple, la conversion de format est réalisée comme suit : CD2 = (uint16)(CD1*RES +K); où RES est un facteur de changement de résolution et K une constante prédéfinis, pour passer du premier format au deuxième format. Par exemple, RES vaut 229 et K vaut zéro. En 723, l’indicateur d’adaptation FLG est positionné à la deuxième valeur VL2, à la place de la première valeur VL1, pour indiquer qu’une adaptation n’est plus requise. En 724, la variable DA2 adaptée et l’indicateur d’adaptation FLG mis à jour sont stockés dans leurs emplacements mémoire respectifs dans la mémoire partagée MEM. De la sorte, l’adaptation de la variable source DA2 est mise en œuvre au sein de l’unité consommatrice UC2, lorsqu’elle a besoin d’y accéder. En outre, l’adaptation proprement dite est conditionnée à la valeur de l’indicateur d’adaptation FLG. Ainsi, si une autre unité consommatrice de la même variable cible DA2, par exemple UC3, a besoin d’accéder à la variable cible DA2 avant l’unité consommatrice UC2, c’est elle qui va réaliser l’adaptation de la variable source, en fonction de la valeur de l’indicateur FLG stockée en mémoire MEM. Enfin, aucun ordonnancement de l’exécution de la fonction d’adaptation n’est nécessaire, puisqu’elle est intégrée dans ou appelée depuis la fonction d’accès à la variable cible de l’unité consommatrice UC2. Selon un ou plusieurs modes de réalisation de l’invention, le procédé qui vient d’être décrit est mis en œuvre, suite à la lecture par l’unité consommatrice, d’une étiquette insérée dans des instructions de code informatique de ladite unité consommatrice, ladite étiquette associant des instructions de code informatique pour l’exécution dudit procédé. Par exemple, le procédé d’obtention d’une variable cible est implémenté sous la forme d’une fonction macro. Un exemple de fonction macro « GET »s’écrit comme suit : Macro GET_ : – vérifie si l’indicateur FLG est à la première valeur VL1 - – si l’indicateur est à la première valeur VL1, appelle la fonction d’adaptation « func_adapt_Vbat » - Par exemple, pour la variable cible DA2 = Vbat : #define GET_Vbat() (if (FLG == 1) ? func_adapt_Vbat() : Vbat) La function d’adaptation est définie comme suit : - calcule la donnée codée dans le deuxième format à partir de la donnée codée dans le premier format - – positionne l’indicateur FLG à la deuxième valeur VL2 - – retourne la Valeur de la variable DA2 adaptée. Par exemple, la fonction d’adaptation s’écrit comme suit : (uint32) func_adapt_Vbat() { Vbat = (uint16)VB*229; FLG = 0; return (Vbat);} } On comprend que dans ce cas, le dispositif 200 n’est pas forcément intégré dans l’unité consommatrice UC2. Le procédé d’obtention d’une variable cible qui vient d’être présenté peut être utilisé pour adapter la même variable source DA1 ou une autre variable source en une autre variable cible que la variable DA2. Dans ce cas, la fonction d’adaptation sera différente et un autre indicateur d’adaptation sera utilisé. On comprend que la mémoire MEM comprendra autant d’indicateurs distincts que de paires (variable source, variable cible) distinctes, utilisées au sein du programme informatique Pg. On décrit maintenant en relation avec la FIG. 9 un exemple de mise en œuvre d’un procédé de détermination d’une variable source selon un ou plusieurs modes de réalisation de l’invention. Par exemple, il est implémenté par le dispositif 100 de l’unité productrice UP1. En 90, une donnée D, par exemple une mesure de tension d’une batterie, produite par l’unité productrice UP1 est obtenue. Par exemple, elle est stockée dans une mémoire de l’unité productrice UP1. En 91, elle est codée dans le premier format et insérée dans la variable source DA1. En 92, l’indicateur d’adaptation de la variable source en la variable cible DA2 est positionné à la première valeur VL1 pour indiquer qu’une adaptation est requise, puisqu’une nouvelle valeur de la donnée est disponible. En 93, les valeurs mises à jour de la variable source DA1 et de l’indicateur FLG sont stockées dans la mémoire MEM. Selon un mode de réalisation, le procédé de détermination d’une variable source qui vient d’être décrit est implémenté par le dispositif 100 qui est intégré dans l’unité productrice UP1. Selon un autre mode de réalisation, le procédé de détermination est mis en œuvre par l’unité productrice UP1 de la variable source, à la lecture d’une étiquette insérée dans des instructions de code informatique, ladite étiquette associant des instructions de code informatique pour l’exécution dudit procédé. Par exemple, cette étiquette correspond à une fonction macro qui peut être intégrée ou non dans l’unité productrice UP1. A titre d’exemple, une fonction macro associée à une étiquette « SET_DA1 » s’écrit comme suit : #define SET_DA1(value) { DA1=(value); FLG=1; } La présente description concerne ainsi un logiciel ou programme d'ordinateur, susceptible d’être exécuté par un dispositif hôte (par exemple, le dispositif 100, 200) au moyen d’un ou plusieurs processeurs de données, ce logiciel / programme comportant des instructions pour causer l'exécution par ce dispositif hôte de tout ou partie des étapes de l’un ou des procédés décrits dans ce document. Ces instructions sont destinées à être stockées dans une mémoire du dispositif hôte, chargées puis exécutées par un ou plusieurs processeurs de ce dispositif hôte de sorte à causer l’exécution par ce dispositif hôte du procédé. Ce logiciel / programme peut être codé au moyen de n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Le dispositif hôte peut être mis en œuvre par une ou plusieurs machines physiquement distinctes. Le dispositif hôte peut présenter globalement l’architecture d’un ordinateur, incluant des constituants d’une telle architecture : mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s) pour la connexion de ce dispositif hôte à un réseau ou un autre équipement, interface(s) utilisateur, etc. Dans un mode de réalisation, tout ou partie des étapes du procédé de programmation ou d’un autre procédé décrit dans ce document sont mises en œuvre par un dispositif de programmation doté de moyens de mise en œuvre de ces étapes de ce procédé. Ces moyens peuvent comprendre des moyens logiciels (software) (par exemple, des instructions d'un ou plusieurs composants d’un programme) et/ou moyens matériels (hardware) (par exemple, mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s), etc.). Ces moyens peuvent comprendre par exemple un ou plusieurs circuits configurés pour exécuter une ou plusieurs ou toutes les étapes d’un des procédés décrits ici. Ces moyens peuvent comprendre par exemple au moins un processeur et au moins une mémoire comprenant des instructions de programme configurées pour, lorsqu’elles sont exécutées par le processeur, causer l’exécution par le dispositif d’une ou plusieurs ou toutes les étapes d’un des procédés décrits ici. La FIG. 10 illustre un exemple de structure matérielle d'un dispositif 100 d’obtention d’une variable cible, respectivement d’un dispositif 200 de détermination d’une variable source selon l’invention. Dans cet exemple, le dispositif 100, 200 est configuré pour mettre en œuvre toutes les étapes du procédé d’obtention, respectivement de détermination, décrit dans le présent document. En variante, il pourrait aussi mettre en œuvre une partie seulement de ces étapes. En relation avec la FIG. 10 , le dispositif 100, 200 comprend au moins un processeur 110, 210 et au moins une mémoire 120, 220. Le dispositif 100, 200 peut aussi comprendre une ou plusieurs interfaces de communication. Dans cet exemple, le dispositif 100, 200 comprend des interfaces réseau 130 (par exemple, des interfaces réseau pour l'accès à un réseau câblé / sans fil, y compris une interface Ethernet, une interface WIFI, etc.) connectées au processeur 110, 210 et configurées pour communiquer via un ou plusieurs liens de communication câblés / non câblés et des interfaces utilisateur 140, 240 (par exemple, un clavier, une souris, un écran d'affichage, etc.) connectées au processeur. Le dispositif 100, 200 peut également comprendre un ou plusieurs lecteurs de support 150 pour lire un support de stockage lisible par ordinateur (par exemple, un disque de stockage numérique (CD-ROM, DVD, Blue Ray, etc.), une clé USB, etc.). Le processeur 110, 210 est connecté à chacun des autres composants précités afin d'en commander le fonctionnement. La mémoire 120, 220 peut comprendre une mémoire vive (RAM), une mémoire cache, une mémoire non volatile, une mémoire de sauvegarde (par exemple, des mémoires programmables ou flash), une mémoire morte (ROM), un disque dur (HDD), un lecteur à état solide (SSD) ou toute combinaison de ceux-ci. La ROM de la mémoire 120, 220 peut être configurée pour stocker, entre autres, un système d'exploitation du dispositif 100, 200 et/ou un ou plusieurs codes de programmes informatiques d'une ou plusieurs applications logicielles. La RAM de la mémoire 120, 220 peut être utilisée par le processeur 110 pour le stockage temporaire de données. Le processeur 110, 220 peut être configuré pour stocker, lire, charger, exécuter et/ou traiter autrement des instructions stockées dans un support de stockage lisible par ordinateur et/ou dans la mémoire 120, 220 de sorte que, lorsque les instructions sont exécutées par le processeur, le dispositif 100, 200 exécute une ou plusieurs ou toutes les étapes du procédé d’obtention, respectivement de détermination, décrit dans le présent document. Des moyens mettant en œuvre une fonction ou un ensemble de fonctions peuvent correspondre dans ce document à un composant logiciel, à un composant matériel ou bien à une combinaison de composants matériels et/ou logiciels, apte à mettre en œuvre la fonction ou l’ensemble de fonctions, selon ce qui est décrit ci-dessous pour les moyens concernés. La présente description concerne aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quel moyen matériel, entité ou appareil, capable de stocker les instructions d'un programme tel que mentionné ci-dessus. Les supports de stockage de programme utilisables incluent les mémoires ROM ou RAM, les supports de stockage magnétiques tels que des disques magnétiques et des bandes magnétiques, les disques durs ou des supports de stockage de données numériques à lecture optique, ou toute combinaison de ces supports. Dans certains cas, le support de stockage lisible par ordinateur n'est pas transitoire. Dans d’autres cas, le support d'informations peut être un support transitoire (par exemple, une onde porteuse) pour la transmission d’un signal (signal électromagnétique, électrique, radio ou optique) porteur des instructions de programme. Ce signal peut être acheminé via un moyen de transmission approprié, filaire ou non filaire : câble électrique ou optique, liaison radio ou infrarouge, ou par d'autres moyens. Un mode de réalisation concerne également un produit programme d'ordinateur comprenant un support de stockage lisible par ordinateur sur lequel sont stockées des instructions de programme, les instructions de programme étant configurées pour causer la mise en œuvre par le dispositif hôte (par exemple un ordinateur) de tout ou partie des étapes d’un ou des procédés décrits ici lorsque les instructions de programme sont exécutées par un ou plusieurs processeurs et/ou un ou plusieurs composants matériels programmables du dispositif hôte. L’invention qui vient d’être présentée n’est pas limitée à l’exemple particulier d’un système informatique embarqué dans un véhicule qui vient d’être présenté et elle s’applique dans d’autres systèmes embarqués, par exemple dans le domaine de l’aéronautique, du ferroviaire, ou du transport en général. L’invention qui vient d’être présentée présente de nombreux avantages. Elle permet de garantir que l’adaptation d’une variable source en une variable cible est réalisée lorsque c’est nécessaire et uniquement dans ce cas, sans avoir à mettre en œuvre d’ordonnancement manuel de cette adaptation par rapport à l’exécution des différentes unités productrice et consommatrice de ces variables. Procédé d’obtention d’une variable cible, comprenant une donnée, codée dans un format cible, destinée à être utilisée par au moins une unité d’exécution logicielle , dite unité consommatrice, ladite unité consommatrice appartenant à au moins un composant logiciel d’un système informatique comprenant au moins un processeur apte à exécuter au moins ladite unité consommatrice, ledit procédé comprenant : - la lecture dans une mémoire du système informatique d’un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une unité consommatrice et ladite unité productrice, - lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, l’adaptation de la variable source en la variable cible, et - la lecture de la variable cible dans la mémoire du système informatique, sinon. Procédé d’obtention d’une variable cible selon la revendication 1, caractérisé en ce que l’adaptation de la variable source en la variable cible comprend : - la lecture dans ladite mémoire, de la variable source, comprenant un code de ladite donnée, dans un format source, - la détermination d’un code de la donnée dans le format cible à partir du code de la donnée dans le format source extrait de la variable source, et - le positionnement de l’indicateur d’adaptation à une deuxième valeur, distincte de la première valeur, indiquant qu’une adaptation de la variable source à la variable cible n’est pas requise et - la mise à disposition de la variable cible adaptée et de l’indicateur d’adaptation mis à jour dans la mémoire. Procédé d’obtention d’une variable cible selon la revendication 1, caractérisé en ce qu’il est mis en œuvre, suite à la lecture par l’unité consommatrice, d’une étiquette insérée dans des instructions de code informatique de ladite unité consommatrice, ladite étiquette associant des instructions de code informatique pour l’exécution dudit procédé. Procédé de détermination d’une variable source, comprenant une donnée, codée dans un format source, ledit procédé étant destiné à être mis en œuvre par une unité d’exécution logicielle, dite unité productrice, configurée pour produire la variable source, ladite unité productrice étant comprise dans un composant logiciel d’un système d’information comprenant au moins un processeur apte à exécuter ladite unité productrice, ledit procédé comprenant : - l’obtention de ladite donnée, auprès d’une mémoire de l’unité productrice, - le codage de ladite donnée, un code de ladite donnée dans un format source étant obtenu et l’insertion dudit code dans ladite variable source, - le positionnement d’un indicateur d’adaptation de la variable source à une première valeur indiquant qu’une mise à jour est requise, et - le stockage de ladite variable source et de l’indicateur d’adaptation dans une mémoire dudit système informatique, ladite mémoire étant partagée avec au moins une autre unité logicielle d’exécution, dite unité consommatrice, comprise dans un autre composant logiciel du système d’information, et configurée pour utiliser une variable cible comprenant un code de ladite donnée dans un format cible, distinct dudit format source. Procédé de détermination d’une variable source selon la revendication 4, caractérisé en ce qu’il est mis en œuvre par l’unité d’exécution logicielle productrice de la variable source, à la lecture d’une étiquette insérée dans des instructions de code informatique de ladite unité d’exécution logicielle productrice, ladite étiquette associant des instructions de code informatique pour l’exécution dudit procédé. Dispositif (100) d’obtention d’une variable cible, comprenant une donnée, codée dans un format cible, destinée à être utilisée par au moins une unité d’exécution logicielle , dite unité consommatrice, ladite unité consommatrice appartenant à au moins un composant logiciel d’un système informatique comprenant au moins un processeur apte à exécuter ladite unité consommatrice, ledit dispositif étant configuré pour mettre en œuvre : - la lecture dans une mémoire du système informatique d’un indicateur d’adaptation d’une variable source, produite par une unité d’exécution logicielle, dite unité productrice, ladite unité consommatrice appartenant à au moins un autre composant logiciel dudit système informatique, ladite variable source comprenant ladite donnée, codée dans un format source, distinct du format cible, ladite mémoire étant partagée entre ladite au moins une entité consommatrice et ladite unité productrice, - lorsque l’indicateur d’adaptation est positionné à une première valeur, indiquant qu’une adaptation de la variable source en la variable cible est requise, l’adaptation de la variable source en la variable cible, et - la lecture de la variable cible dans la mémoire du système informatique, sinon. Dispositif d’obtention d’une variable cible selon la revendication précédente, caractérisé en ce qu’il est mis en œuvre dans une unité d’exécution logicielle comprise dans un composant logiciel du système informatique. Dispositif (200) de détermination d’une variable source, comprenant une donnée, codée dans un format source, ledit procédé étant destiné à être mis en œuvre par une unité d’exécution logicielle, dite unité productrice, configurée pour produire la variable source, ladite unité productrice étant comprise dans un composant logiciel d’un système d’information comprenant au moins un processeur apte à exécuter ladite unité productrice, ledit dispositif étant configuré pour mettre en œuvre : - l’obtention de ladite donnée, auprès d’une mémoire de l’unité productrice, - le codage de ladite donnée, un code de ladite donnée dans un format source étant obtenu et l’insertion dudit code dans ladite variable source, - le positionnement d’un indicateur d’adaptation de la variable source à une première valeur indiquant qu’une mise à jour est requise, et - le stockage de ladite variable source et de l’indicateur d’adaptation dans une mémoire dudit système informatique, ladite mémoire étant partagée avec au moins une autre unité logicielle d’exécution, dite unité consommatrice, comprise dans un autre composant logiciel du système d’information, et configurée pour utiliser une variable cible comprenant un code de ladite donnée dans un format cible, distinct dudit format source. Dispositif de détermination d’une variable source selon la revendication précédente, caractérisé en ce qu’il est mis en œuvre dans une unité d’exécution logicielle comprise dans un composant logiciel du système informatique. Unité d’exécution logicielle, dite unité consommatrice d’une variable cible, comprise dans un composant logiciel d’un système informatique, caractérisée en ce qu’elle est configurée pour mettre en œuvre un dispositif d’obtention d’une variable cible selon les revendications 6 et 7. Unité d’exécution logicielle, dite unité de production d’une variable source, comprise dans un composant logiciel d’un système informatique, caractérisée en ce qu’elle est configurée pour mettre en œuvre un dispositif de détermination d’une variable source selon l’une quelconque des revendications 8 et 9. Unité d’exécution logicielle selon l’une quelconque des revendications 10 et 11, caractérisée en ce que la mise en œuvre du dispositif est déclenchée par la lecture d’une étiquette dans des instructions de code informatique de ladite unité d’exécution logicielle, ladite étiquette étant associée à des instructions de code informatique pour l’exécution dudit dispositif. Programme d’ordinateur comprenant des instructions pour l’exécution d’un procédé selon l’une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par un ordinateur.