FR 2815433 A1 20020419 FR 0013160 A 20001013 La présente invention se rapporte à un procédé de codage de langage graphique d'automatisme pour son exécution en temps réel sur une plate-forme numérique. Pour la conception et la programmation de logiciels d'exploitation d'automatismes et de simulation, on fait de plus en plus appel à des graphes reliant des fonctions. Par exemple, le"SAO"est un langage utilisé par la plupart des constructeurs aéronautiques européens. Il permet de représenter, sous forme d'un réseau orienté de schémas-blocs tout algorithme de contrôle-commande. La norme IEC 1131-3 définit trois langages graphiques de même nature (du point de vue de leur utilisation globale), qui sont le LD , le SFC et le FBD , et qui permettent de représenter tout programme d'automatisme. La modélisation de tout système fait appel à une représentation unifiée des composants hydrauliques, pneumatiques, électriques, électroniques, mécaniques..., cette représentation étant dénommée"Bond Graph". Toutes ces représentations graphiques doivent être saisies informatiquement, analysées syntaxiquement et sémantiquement, et traduites dans un langage informatique plus ou moins évolué (C, ADA, assembleur, Basic, Fortran, binaire, langage interprété...) qui, lui-même est compilé et édité pour fournir un langage binaire exécutable sur un processeur cible, qui est directement chargé pour exécution ou interprétation sur un processeur cible, et, par ailleurs, exécuté sur un calculateur hôte pour des besoins de simulation. L'exécution de ces langages binaires ou interprétés permet de mettre en oeuvre les algorithmes décrits dans la représentation graphique initiale, algorithmes correspondant à des programmes d'automatisme. Les outils qui assurent la saisie, l'analyse, la traduction, la simulation, la mise au point, le monitoring (supervision) des représentations graphiques seront dénommés, par la suite, dans leur ensemble,"atelier logiciel d'automatisme" Les ateliers logiciels connus présentent les inconvénients suivants : A)-L'obligation d'intégrer dans l'atelier logiciel des outils achetés à l'extérieur, dont les spécifications, la conception, les performances, les évolutions, la portabilité, la qualité, la maintenabilité et la pérennité échappent complètement au réalisateur de l'atelier et parfois entraînent les désoptimisations en vitesse d'exécution sur cible. C'est le cas de tout atelier générant un langage informatique évolué (C, Ada, Basic, Fortran, même assembleur) qui requiert l'intégration dans l'atelier : des éléments suivants : compilateurs correspondants associés à la cible et à l'hôte, des éditeurs de liens, d'un"library manager"et des chargeurs associés (par exemple : ISAgraphe , SAO+ de la Société Verilog) B)-L'obligation pour l'utilisateur d'intégrer dans l'atelier logiciel ses propres outils (compilation, édition, chargement de génération binaire pour une cible donnée, outils relativement complexes, car fournissant du binaire exécutable optimisé (donc générateur de coûts de développement et de maintenance et d'erreurs potentielles) mais totalement dédié à une cible ou à un hôte donné. Donc tout changement rapide de cible (optimisation des coûts de l'automate cible, évolution du producteur de micro-informatique) impose des délais et des coûts importants de redéveloppement des outils concernés (comme par exemple le Labview ). De plus, chaque instruction de ce langage n'est pas"context free"ce qui signifie que l'effet de son exécution dépend fortement du contexte dans lequel elle est exécutée (par exemple : langage du RPX , ou binaire RISC classique). Ainsi, la complétude du test de bon fonctionnement est difficile, donc coûteuse à établir puisque très dépendante du contexte d'exécution. C)-L'incapacité de reconstruire le graphe initial avec tous ses paramètres constants et d'initialisation, car l'interprétation du binaire généré ou du langage évolué fait disparaître l'architecture initiale du graphe, ce qui obligerait d'embarquer dans la cible des informations volumineuses en mémoire, inutiles à l'exécution sur cible, mais seulement utiles pour la reconstitution du graphe initial par décompilation du binaire. D)-L'incapacité d'enrichir les jeux de blocs de fonctions utilisés dans le graphe initial sans rien modifier dans la programmation de la totalité de l'atelier logiciel, par une procédure d'installation simple et tout en gardant l'efficacité optimale de l'exécution (vitesse et espace mémoire sur toute cible passée présente ou à venir). Bien sûr, le mécanisme de macro-instructions n'est pas une réponse appropriée, car il se contente d'éclater les nouvelles fonctions créées en un réseau de blocs de fonctions existants ce qui, d'une part, interdit l'introduction de nouveaux types de données ou de paramètres traités, et d'autre part n'optimise en rien l'exécution sur cible et accroît les problèmes évoqués ci-dessus. E)-L'incapacité de mixer simplement dans la même sémantique les fonctions suivantes : - des fonctions d'automatismes dont le cycle d'exécution soit n'est pas contraint au strict déterminisme temporel, comme c'est le cas du SFC ou du GRAFCET , - des fonctions contraintes par les règles du contrôle-commande, donc par des échantillonnages de signaux qui doivent respecter le théorème de Shannon, - des fonctions contraites par une exécution temps réel rapide strictement déterministe ("time triggered") comme le SAO de EADS, le tout s'éxécutant sur une plateforme logicielle dont le mode d'exécution est soit "event driven", soit ni"time triggered", ni"event driven". La présente invention a pour objet un procédé de codage de langage graphique d'automatisme pour son exécution en temps réel sur une plate-forme numérique, procédé qui permette d'intégrer facilement dans l'atelier logiciel des outils extérieurs, ainsi que ses propres outils, même complexes, qui permette de reconstruire le graphe initial, d'enrichir simplement les blocs de fonctions du graphe initial, et de mixer diverses fonctions d'automatisme à cycle d'exécution de différents types. Le procédé conforme à l'invention est caractérisé en ce que le codage comprend au moins deux séquences d'instructions"context free"ordonnées suivant l'ordre de précédence dégagé par l'analyse du graphe, la première séquence étant une séquence d'initialisation, la deuxième comportant une suite d'instructions ordonnées temporellement, qui sont exécutées à période constante, chaque instruction de cette suite étant caractérisée par un code opératoire qui ne représente qu'une seule fonction, par un numéro unique dans le graphe distinguant chaque bloc fonctionnel du graphe, et par un ensemble'opérandes appartenant à l'une au moins des catégories suivantes : variables d'entrée, variables de sortie, paramètres de sortie, variables internes et paramètres internes. La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel la figure unique est un graphe simplifié de quelques fonctions élémentaires d'automatisme, établi selon le procédé de l'invention. Le procédé de codage de l'invention permet de réaliser un graphe mélangeant indifféremment des fonctions d'automatisme (pouvant utiliser un langage approprié tel que FBD , SFC ou Grafcet par exemple), des fonctions de contrôle-commande strictement déterministes ou non (conçues à l'aide d'un langage tel que SAO ou un autre langage utilisant des schémas-blocs ou bien des fonctions de transfert diverses) et des fonctions de simulation (traduites en un langage tel que Bondgraph ...) Pour pouvoir regrouper sous une même syntaxe de graphe l'ensemble des langages décrits ci-dessus, en respectant leur sémantique propre, il convient d'autoriser dans le graphe FBD (norme EN1131-3) les deux modes de connexion suivants : 1 )-Une sortie d'une fonction peut être re-bouclée sur une entrée d'une autre fonction ou de la même fonction (On notera qu'en SAO , ceci se traduit par l'introduction d'un retard d'un cycle entre la sortie et l'entrée). - 20) -Une entrée peut ne pas être connectée : dans ce cas on initialise cette entrée à une valeur constante neutre pour l'algorithme de ladite fonction. En outre, il n'existe en aucun cas de données variables ou de constantes présentées en tant que telles dans le graphe. Toute donnée variable ou constante appartient à une fonction, que ce soit une fonction d'entrée, de sortie ou intermédiaire. Il résulte de ces conditions que toute fonction d'automatisme, de contrôle-commande"context free"doit se traduire par un sous-programme en langage quelconque utilisant des variables d'entrée, des variables de sortie, des paramètres de sortie, des variables de travail (internes) volatiles et des variables de travail rémanentes. Les variables de travail sont utilisées lors de chaque exécution de la fonction. Elles n'ont donc pas à être vues de l'interface d'appel et sont seulement connues et déclarées dans le code de la fonction. Elles sont considérées comme des données locales au sous-progamme. Il suffit d'appliquer dans le codage de la fonction les règles de portabilité vers toute cible et de déterminisme appliquées au langage haut niveau utilisé (C, Ada,...) pour obtenir un code source portable et déterministe en temps d'exécution et en encombrement mémoire. Dans la mesure où l'outil de mise au point et de monitoring a la capacité de lire ou de modifier simplement chacun des autres opérandes de la fonction (entrées, sorties, paramètres et données de travail rémanentes), ces données sont implantées dans le langage qui sert à programmer les fonctions comme des variables globales rémanentes. Pour adresser un tel opérande, le mode d'adressage en langage binaire est très variable suivant le code exécutable cible et les traductions effectuées par le compilateur/éditeur de liens associés à la cible. Aussi, pour assurer la portabilité totale, il faut définir l'adresse de ces paramètres comme des déplacements en octets ou en bits vis-à-vis du début d'une ou de plusieurs zones de mémoire. Les déplacements en octets ou en bits sont des notions universelles à tous les circuits intégrés numériques existants. Pour pouvoir définir combien de zones mémoire sont alors nécessaires et quelles sont leurs caractéristiques, seule la catégorie des variables est utile. Une variable de la catégorie : variable d'entrée, de sortie ou variable de travail rémanente : a)-Est lue et modifiée à chaque pas de calcul de la boucle d'exécution de l'automatisme ou du contrôle-commande, donc elle ne peut être placée ni en mémoire PROM, EPROM, ou EEPROM (écriture impossible ou très contraignante) ni en mémoire flash (le nombre de cycles d'écriture d'une mémoire flash est limité dans le temps !) b)-N'a besoin d'être initialisée qu'à chaque début d'exécution du programme représentant le graphe, donc lors d'une séquence d'initialisation. En cas d'anomalie grave ou de coupure d'alimentation, ces valeurs peuvent être perdues. Pour remédier à cet inconvénient, on peut mettre en place deux processus d'initialisation : - l'un correspondant à une réinitialisation complète du programme avant son exécution, - l'autre correspondant à une reprise de l'état antérieur, reprise toujours délicate en contrôle-commande), donc ces données font partie d'une zone mémoire RAM et doivent être associées à une séquence d'initialisation spécifique. Une variable de la catégorie paramètre caractérise fortement la fonction qui lui est associée. Elle est lue souvent mais jamais ou peu écrite. Lors d'une initalisation ou de toute reprise sur erreur grave ou coupure d'alimentation, la valeur "courante"du paramètre doit être accessible, donc une telle variable peut faire partie d'un type de zone PROM, EPROM, EEPROM ou flash et peut être associée à une séquence d'initialisation spécifique distincte de celle des autres données. Compte tenu des considérations ci dessus, on définit le déplacement de la variable dans une zone mémoire de la façon suivante : a)-Une variable de sortie ou une variable interne rémanente correspond à l'aboutissement des opérations effectuées par l'exécution en cours d'une fonction. On doit donc réserver en mémoire globale un espace mémoire propre à la fonction considérée. b)-Une variable d'entrée reçoit une valeur stockée dans une variable de sortie élaborée lors de l'exécution de la fonction courante. Il n'est pas nécessaire de réserver d'espace mémoire pour une variable d'entrée. TRI suffit de lire la variable de sortie associée. Par exception, une variable non connectée, devant être initialisée à une valeur neutre pour l'algorithme de la fonction, doit avoir un espace mémoire initialisé à ladite valeur, en mémoire globale dans un espace mémoire propre à la fonction considérée. c)-Un paramètre est une valeur de référence, donc un espace mémoire initialisé doit lui être réservé. Plusieurs fonctions de même type (par exemple deux ET ou deux bascules SR) appartenant au même graphe doivent pouvoir être distinguées (surtout si on autorise la modification de paramètre sur le calculateur cible et si on recherche à partir du langage exécutable la structure du graphe générateur). On alloue donc à chaque fonction du graphe un numéro unique dans ce graphe. Pour décrire l'instruction qui, sur cible ou simulateur, exécutera la fonction, la notion de type de variables passées en opérande est inutile. Les seuls outils qui doivent connaître la notion de type de variable sont : a)-le compilateur qui calcule le déplacement de chaque donnée dans sa zone et génère les séquences d'initialisation ; b)-le décompilateur qui retrouve les valeurs initiales des paramètres à partir du langage binaire seul. c)-le metteur au point symbolique et de monitoring qui traduit la donnée dans sa forme binaire cible vers une forme lisible par l'IHM de l'atelier logiciel (IHM = Interface homme-Machine), d) -1'mM de l'atelier logiciel qui garantit la cohérence des connexions sur le graphe. e)-le sous-programme appelé (qui exécute l'instruction) lit et écrit ces variables. Certains outils n'ont aucune connaissance des types de variables sur cible : ce sont l'ensemble des logiciels de service de la cible, du simulateur et des outils de communication hôte-cible. Enfin, l'IHM n'a besoin d'aucune connaissance sur l'architecture cible. Parmi les paramètres d'une fonction, certains paramètres peuvent être injectés vers des entrées d'une ou plusieurs autres fonctions pour participer aux algorithmes exprimés par le graphe. Ces paramètres sont dits sorties , et la sortie de fonction associée à ce type de paramètre peu être est lue par certaines entrées des autrees fonctions du graphe. Pour permettre de conserver à ces paramètres les caractéristiques de leur catégorie, ils doivent avoir chacun sa place dans la zone des paramètres, mais pour leur permettre d'être reliés chacun à une sortie (et donc de maintenir la lisibilité du décompilateur), ces catégories de paramètres seront définies comme des"paramètres sorties". Pour pouvoir enrichir de n'importe quelle fonction d'automatisme l'atelier et la cible sans modifier l'existant, il suffit de choisir un numéro unique caractérisant le type de fonction et de transmettre à l'atelier et à la cible la description de son instruction d'appel selon les principes précédents, puis de charger sur la cible ou le simulateur le langage binaire de ladite fonction qui est context free . Tous les graphes réalisés dans les conditions exposées ci-dessus sont décomposés en fonctions et connexions orientées (parfois mono-directionnelles comme pour : SAO , FBD , SFC ... et parfois bi-directionnelles, comme c'est le cas pour Bond Gragh ), et ils définissent un ordre de précédence pour le calcul de chaque fonction. Toute fonction doit être exécutée seulement et seulement si toutes ses entrées sont déjà validées ou initialisées dans le cycle d'exécution en cours. Les types de fonctions sont caractéristiques de chaque langage de CAO (Conception Assistée par Ordinateur) et sont repérés comme tels dans le descripteur de chaque type de fonction vu de l'atelier logiciel. Les boucles internes au graphe sont"coupées"selon la sémantique du langage de CAO considéré, dans le cadre du compilateur de graphe. Ainsi le compilateur peut très simplement définir l'ordre de précédence de calcul de chaque fonction dans la boucle de programme exécutable. Comme chaque fonction est context free , le programme exécutable correspond simplement à la liste des instructions d'appel de fonction ordonnées selon l'ordre de précédence défini ci-dessus. En gardant la même procédure que pour les instructions d'appel de chaque fonction définie dans la boucle du programme exécutable, on définit une instruction d'initialisation pour chaque couple (type-catégorie) de variable. Cette instruction d'initialisation comprend, par exemple, son numéro caractéristique, le numéro du bloc-fonction dans le graphe qui l'a engendrée, le déplacement en octets ou en bits dans la zone associée de la variable à initialiser et, uniquement pour ces fonctions d'initialisation, la constante d'initialisation sous sa forme"interne cible" (qui, grâce au respect des règles de codage portable, a la même structure sous toute cible et simulateur). Evidemment, le caractère context free de l'instruction d'initialisation et son unicité pour un doublet (type, catégorie) d'une variable fait que sur toute cible ou simulateur le sous-programme associé à cette fonction est à même de comprendre le type de ses paramètres d'appel et de comprendre le format de la constante à placer. Pour réaliser l'initialisation des paramètres de différentes catégories (sortie et interne), on peut choisir de construire la zone binaire cible représentant les constantes et les valeurs des paramètres, dans leur ordre d'implantation sur la cible, avec recopie de cette zone à chaque initialisation de programme exécutable et sauvegarde sous réserve d'énergie à chaque détection d'une chute de tension d'alimentation de cible. Ainsi, la récupération de modifications dynamiques des paramètres en EEPROM ou en mémoire Flash durant des phases de monitoring, de mise au point ou de paramétrage devient possible. On peut aussi utiliser une méthode mixte alliant les deux principes : une initialisation par séquence d'instructions exécutable sur la première initialisation suivant le chargement programme exécutable sur la cible, puis réaliser des recopies de zone lors des arrêts alimentation/mise sous tension. On peut aussi, quand la cible ne contient que des mémoires RAM et EPROM ou PROM ou ROM, appliquer une technique d'initialisation unique par séquence regroupant les instructions d'initialisation exécutables systématiquement en prélude à l'exécution en boucle des instructions du programme exécutable représentant le graphe. Dans ce cas, on ne peut pas modifier dynamiquement la valeur des paramètres sur la cible en dehors des phases de chargement du programme exécutable et du programme d'initialisation associé. Si les types des données se limitent à des caractères HASCH 7,8, ou Unicode, ou à des nombres entiers en puissance de 2 (booléen, entier signé, entier non signé, fixe accompagné de sa précision absolue), la portabilité de ces données et de ces constantes entre deux cibles est vérifiée (sous réserve de prise en compte des mécanismes de représentation des nombres sur 2 octets ou plus : Big Endian, Little Endian). Si on introduit le type flottant, le format du type flottant, , le choix du mode d'arrondi et de comparaison (par exemple en format flottant IEEE) cassent la portabilité. La notion de précision relative introduite dans les calculs est la seule qui permette d'assurer la portabilité. L'alignement et le volume de réservation des données peuvent être choisis pour assurer la portabilité. On a représenté en figure unique un graphe simplifié de quelques fonctions élémentaires d'automatisme pouvant être saisies en langage FBD (donc compatibles avec ce langage). Ce graphe comporte, d'une part, quatre blocs d'entrée à fonctionnement en tout-ou-rien, référencés 1 01, 1 03, 1 04, et 1 05, et un bloc d'entrée fournissant des entiers signés sur 16 bits, référencé 106. Il comporte d'autre part un compteur (référencé COUNTER) enregistrant les modifications de l'entrée 101, un circuit de retard (référencé DELAY) déclenché par l'entrée 103, une bascule monostable (référencée ONE SHOT) déclenchée par l'entrée 1 04, un circuit à fonction de gain (du type y=A/B. X + C, ce circuit étant référencé GAIN) relié à l'entrée 1 05 et validé par l'entrée tout-ou-rien 1 06, un comparateur (référencé COMPARE) qui compare la valeur de comptage venant de COUNTER à la durée du créneau produit par DELAY, et qui fournit le résultat de la comparaison (sous forme d'un signal en tout-ou-rien) à une sortie référencée 0 01, et il comporte enfin un autre comparateur (référencé COMPARE) comparant le signal apparaissant sur l'entrée 1 05 et mis à l'échelle par le circuit GAIN avec la durée du créneau fourni par la fonction ONE SHOT, le résultat de la comparaison apparaissant sur la sortie 005. Ce graphe est traduit selon le procédé de l'invention dans la suite de fonctions présentées dans l'annexe à la présente description. Dans cette annexe, la première table (intitulée Architecture programme utilisateur et équivalence en code généré ), issue du compilateur, décrit la topologie du graphe en clair, les deuxième et troisième tables, également issues du compilateur et intitulées Marquage des terminaux de sortie et Rangs de génération , déterminent respectivement des fonctions de sortie et le rang de génération ( précédence ) des diverses fonctions du graphe, la quatrième table (intitulée Table binaire exécution ) décrit en clair les opérateurs et opérandes générés par le compilateur, et les trois dernières tables (respectivement intitulées Table binaire exec finale , Table binaire init param et Table bin exec init ) présentent les codes binaires chargeables dans le microcalculateur cible ou dans un simulateur. Ces binaires, conformément à la description ci-dessus des différents opérandes, correspondent respectivement à la liste des instructions du programme, à la table des initialisations de paramètres et à la liste des instructions d'initialisation des variables de sortie et internes rémanentes. ANNEXE ARCHITECTURE PROGRAMME UTILISATEUR ET EQUIVALENCE EN CODE GENERE Fonction OUTTOR (IdIHM 001) de numgeneration 51 l'entrée I1L est connectée à la sortie OIR de COMPARE (Id IHM 2) aucune sortie existante Fonction OUTTOR (IdJHM 005) de numgeneration 51 l'entrée I1L est connectée à la sortie 01R de COMPARE (Id IHM 4) aucune sortie existante Fonction DELAY (Id~IHM 1) de numgeneration 113 l'entrée I1L n'est pas connectée l'entrée I2L est connectée à la sortie 01R de IN~TOR (Id IHM 68) le paramsorti PS 1 est connectée à l'entrée I3L de COMPARE (Id IHM 2) Delai front montant : 1/10 secondes Delai front descendant : 1/10 secondes Fonction COMPARE (IdJHM 2) de numgeneration 120 l'entrée I1L est connectée à la sortie 01R de INTOR (Id IHM 66) l'entrée 12L est connectée à la sortie PS 1 de COUNTER (Id IHM 7) l'entrée I3L est connectée à la sortie PS 1 de DELAY (Id IHM 1) la sortie aiR est connectée à l'entrée I1L de OUT~TOR (Id IHM 101) Comparaison : Superieur ou Egale Fonction COMPARE (IdIHM 4) de numgeneration 120 l'entrée I1L n'est pas connectée l'entrée 12L est connectée à la sortie 02R de ONE SHOT (Id IHM 5) l'entrée I3L est connectée à la sortie 01R de GAIN (Id IHM 6) la sortie 01R est connectée à l'entrée I1L de OUTTOR (Id IHM 105) Comparaison : Egale Fonction ONE SHOT (IdJHM 5) de num~generation 115 l'entrée I1L est connectée à la sortie 01R de IN-TOR (Id IHM 69) l'entrée I2L n'est pas connectée la sortie 02R est connectée à l'entrée 12L de COMPARE (Id IHM 4) Durée du pulse : 1/10 secondes Option sur la fin du pulse : 0 Fonction GAIN (IdJHM 6) de numgeneration 123 l'entrée I1L est connectée à la sortie 01R de INTOR (Id IHM 70) l'entrée I2L est connectée à la sortie 01R de IN~ANA (Id IHM 86) la sortie 01R est connectée à l'entrée I3L de COMPARE (Id IHM 4) Valeur de A : 1 Valeur de B : 1 Valeur de C : 0 Borne Superieur : 32767 Borne Inferieur :-32768 Fonction COUNTER (Id~IHM 7) de numgeneration 112 l'entrée I1L est connectée à la sortie 01R de INTOR (Id IHM 66) l'entrée 12L n'est pas connectée le paramsorti PSI est connectée à l'entrée I2L de COMPARE (Id IHM 2) Valeur maximum du compteur : 42 Fonction IN~TOR (IdIHM 66) de num~generation 50 aucune entree existante la sortie OIR est connectée à l'entrée IlL de COMPARE (Id IHM 2) la sortie 01R est connectée à l'entrée I1L de COUNTER (Id IHM 7) Fonction IN~TOR (Id~IHM 68) de num~generation 50 aucune entree existante la sortie 01R est connectée à l'entrée I2L de DELAY (Id IHM 1) Fonction IN~TOR (IdIHM 69) de numgeneration 50 aucune entree existante la sortie OIR est connectée à l'entrée IlL de ONE SHOT (Id IHM 5) Fonction IN~TOR (Id~IHM 70) de num~generation 50 aucune entree existante la sortie 01R est connectée à l'entrée I1L de GAIN (Id IHM 6) Fonction INANA (IdIHM 86) de num~generation 52 aucune entree existante la sortie 01R est connectée à l'entrée 12L de GAIN (Id IHM 6) MARQUAGE DES TERMINAUX DE SORTIE la fonction 101 de type 51 est une sortie la fonction 105 de type 51 est une sortie RANGS DE GENERATION fonc : 10 1 rang-generation= 1 fonc : 105 rang~generation=1 fonc : 1 rang~generation=3 fonc : 2 rang~generation=2 fonc : 4 rang~generation=2 fonc : 5 rang~generation=3 fonc : 6 rang~generation=3 fonc : 7 rang~generation=3 fonc : 66 rang~generation=4 fonc : 68 rang~generation=4 fonc : 69 rang~generation=4 fonc : 70 rang~generation=4 fonc : 86 rang~generation=4 TABLE BINAIRE EXECUTION fonc : IN~TOR num : 50 Oe Is Ops Ip 1vi sortie : Odeplt : O param : Odeplt : O vi : 0 deplt : O fonc : IN-TOR num : 50 Oe Is Ops Ip lvi sortie : 0 deplt : 1 param : 0 deplt : 1 vi : 0 deplt : 1 fonc : INTOR num : 50 Oe Is Ops Ip Ivi sortie : 0 deplt : 2 param : 0 deplt : 2 vi : 0 deplt : 2 fonc : INTOR num : 50 Oe 1s Ops Ip Ivi sortie : 0 deplt : 3 param : 0 deplt : 3 vi : 0 deplt : 3 fonc : IN~ANAnum : 52 Oe Is Ops 4p Ivi sortie : 0 deplt : 4 param : 0 deplt : 4 param : 1 dépit : 5 param : 2 deplt : 6 param : 3 deplt : 7 vi : 0 deplt : 5 fonc : DELAY num : 113 2e 3s 2ps Op 4vi entree : 0 deplt : 14 entree : 1 deplt : 1 sortie : 0 deplt : 4 sortie : 1 deplt : 6 sortie : 2 deplt : 7 parsor : O deplt : 8 parsor : 1 deplt : 9 vi : 0 deplt : 5 vi : 1 deplt : 6 vi : 2 deplt : 7 vi : 3 deplt : 8 fonc : ONESHOT num : 115 2e 2s Ips Ip 2vi entree : 0 deplt : 2 entree : 1 deplt : 14 sortie : 0 deplt : 8 sortie : 1 deplt : 9 parsor : O deplt : 10 param : 0 deplt : 11 vi : 0 deplt : 9 vi : 1 deplt : 10 fonc : GAIN num : 123 2e Is Ops 5p Ovi entree : 0 deplt : 3 entree : 1 deplt : 4 sortie : 0 deplt : 11 param 0: deplt : 12 param : 1 deplt : 13 param : 2 deplt : 14 param : 3 deplt : 15 param : 4 deplt : 16 fonc : COUNTER num : 112 2e 2s Ips Op Ivi entree : 0 deplt : O entree : 1 deplt : 14 sortie : 0 deplt : 10 sortie : 1 deplt : 12 parsor : O deplt : 17 vi : 0 deplt : 11 fonc : COMPARE num : 120 3e Is Ops Ip Ovi entree : 0 deplt : O entree : 1 deplt : O entree : 2 deplt : O sortie : 0 deplt : 12 param : 0 deplt : 18 fonc : COMPARE num : 120 3e Is Ops Ip Ovi entree : 0 deplt : 14 entree : 1 deplt : 9 entree : 2 deplt : 11 sortie : 0 deplt : 13 param : 0 deplt : 19 fonc : OUTTOR num : 51 le Os Ops Ip Ovi entree : 0 deplt : 12 param : 0 deplt : 20 fonc : OUTTOR num : 51 le Os Ops Ip Ovi entree : 0 deplt : 13 param : 0 deplt : 21 TABLE BINAIRE EXEC FINALE 0050 0066 0000 0000 0000 0050 0068 0001 0001 0001 0050 0069 0002 0002 0002 0050 0070 0003 0003 0003 0052 0086 0004 0004 0005 0113 0001 0014 0001 0004 0006 0007 0008 0005 0006 0007 0008 0115 0005 0002 0014 0008 0009 0010 0009 0010 0123 0006 0003 0004 0011 0012 0112 0007 0000 0014 0010 0012 0017 0011 0120 0002 0000 0000 0000 0012 0018 0120 0004 0014 0009 0011 0013 0019 0051 0101 0012 0020 0051 0105 0013 0021 0000 TABLE BINAIRE INIT PARAM 0001 0003 0004 0005 0006 0000 0000 0000 0001 0001 0001 0000 0001 0001 0000 0255 0000 0042 0006 0001 0001 0005 0000 TABLE BIN EXEC INIT 0006 0066 0000 0000 0006 0068 0001 0000 0006 0069 0002 0000 0006 0070 0003 0000 0006 0086 0005 0000 0001 0001 0004 0000 0002 0001 0006 0000 0002 0001 0007 0000 0005 0001 0005 0000 0005 0001 0006 0000 0005 0001 0007 0000 0001 0005 0008 0000 0002 0005 0009 0000 0005 0005 0009 0000 0002 0006 0011 0000 0001 0007 0010 0000 0002 0007 0012 0000 0001 0002 0012 0000 0001 0004 0013 0000 0005 0001 0014 0000 REVENDICATIONS 1.-Procédé de codage de langage graphique d'automatisme pour son exécution en temps réel sur une plate-forme numérique caractérisé en ce que le codage comprend au moins deux séquences d'instructions "context free" ordonnées suivant l'ordre de précédence dégagé par l'analyse du graphe, la première séquence étant une séquence d'initialisation, la deuxième comportant une suite d'instructions ordonnées temporellement, qui sont exécutées à période constante, chaque instruction de cette suite étant caractérisée par un code opératoire qui ne représente qu'une seule fonction, par un numéro unique dans le graphe distinguant chaque bloc fonctionnel du graphe, et par un ensemble'opérandes appartenant à l'une au moins des catégories suivantes : variables d'entrée, variables de sortie, paramètres de sortie, variables internes et paramètres internes. 2.-Procédé selon la revendication 1, caractérisé en ce qu'une variable d'entrée, de sortie ou interne rémanente est lue et modifiée à chaque pas de calcul de la boucle d'exécution de l'automatisme. 3.-Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une variable d'entrée, de sortie ou interne rémanente n'a besoin d'être initialisée qu'à chaque début d'exécution du programme représentant le graphe, donc lors d'une séquence d'initialisation. 4.-Procédé selon la revendication 3, caractérisé en ce qu'il comporte deux modes d'initialisation : un correspondant à une réinitialisation complète du programme avant son exécution, l'autre correspondant à une reprise de l'état antérieur, ces données faisant partie d'un type de zone RAM et étant associées à une séquence d'initialisation spécifique. 5.-Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un opérande de type paramètre est lu souvent mais jamais ou peu écrit, et que lors d'une initalisation ou de toute reprise sur erreur grave ou coupure d'alimentation, la valeur "courante" du paramètre est accessible, un tel opérande faisant partie d'un type de zone PROM, EPROM, EEPROM ou flash et étant associé à une séquence d'initialisation spécifique distincte de celle des autres données. 6.-Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on réserve à une variable de sortie ou à une variable interne rémanente un espace mémoire propre à la fonction relative à cette variable. 7.-Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une variable d'entrée reçoit une valeur stockée dans une variable de sortie élaborée lors de l'exécution de la fonction courante. 8.-Procédé selon la revendication 7, caractérisé en ce que par exception, une variable non connectée, est initialisée à une valeur neutre pour l'algorithme de la fonction et a un espace mémoire initialisé à ladite valeur. 9.-Procédé selon l'une des revendications précédentes, caractérisé en ce que les seuls outils qui doivent connaître la notion de type de variable sont : -le compilateur qui calcule le déplacement de chaque donnée dans sa zone et génère les séquences d'initialisation ; -le décompilateur qui retrouve les valeurs initiales des paramètres à partir du langage binaire seul. -le metteur au point symbolique et de monitoring qui traduit la donnée dans sa forme binaire cible vers une forme lisible par l'IHM de l'atelier logiciel (IHM = Interface homme-Machine), -l' IHM de l'atelier logiciel qui garantit la cohérence des connexions sur le graphe. -le sous-programme appelé, qui exécute l'instruction et qui lit et écrit ces variables. 10.-Procédé selon l'une des revendications précédentes, caractérisé en ce que parmi les paramètres d'une fonction, des paramètres, dits sorties sont injectés vers des entrées d'une ou plusieurs autres fonctions et sont lus par certaines entrées du graphe. 11.-Procédé selon la revendication 10, caractérisé en ce que pour permettre de conserver à ces paramètres dits sorties les caractéristiques de leur catégorie, chacun a sa place dans la zone des paramètres, mais pour leur permettre d'être reliés chacun à une sortie, ces catégories de paramètres seront définies comme des paramètres sorties . 12.-Procédé selon l'une des revendications précédentes, caractérisé en ce que pour pouvoir enrichir de n'importe quelle fonction d'automatisme la cible et les outils informatiques mis en oeuvre par le procédé de l'invention, sans modifier l'existant, on choisit un numéro unique caractérisant le type de fonction et qu'on transmet à ces outils et à la cible la description de son instruction d'appel, puis que l'on charge sur la cible ou le simulateur le langage binaire de ladite fonction qui est context free . 13.-Procédé selon l'une des revendications précédentes, caractérisé en ce que l'on définit une instruction d'initialisation pour chaque couple (type-catégorie) de variable, et que cette instruction d'initialisation comprend son numéro caractéristique, le numéro du bloc-fonction dans le graphe qui l'a engendrée, le déplacement en octets ou en bits dans la zone associée de la varaible à initialiser et, uniquement pour ces fonctions d'initialisation, la constante d'initialisation sous sa forme"interne cible"