FR 2823578 A1 20021018 FR 0105218 A 20010417 troisième zone du support informatique. La présente invention concerne un procédé pour visualiser graphiquement, sur un terminal informatique, une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme. L'invention concerne également un terminal informatique capable de visualiser graphiquement une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme. Une station de programmation désigne ci-après un équipement informatique, notamment un ordinateur personnel de type PC, connectable à un équipement d'automatisme, et disposant d'un logiciel permettant de concevoir un programme 0 d'application d'automatisme à l'aide de langages graphiques d'automatisme. Un équipement d'automatisme désigne ci-après un automate programmable, une station de contrôle/commande, une commande numérique ou tout équipement pouvant contenir et exécuter un programme d'application contrôlant une application d'automatisme. Cette application d'automatisme appartient par exemple au domaine des automatismes industriels, des automatismes du bâtiment ou du contrôle/commande des réseaux électriques de distribution. Un tel équipement d'automatisme est composé d'une unité centrale et d'un ou plusieurs coupleurs d'entrces-sorties connectés à des capteurs et à des présctionneurs du process industriel à commander. L'unité centrale d'un équipement d'automatisme comprend au moins un processeur, une mémoire non volatile, en général non modifiable (type ROM) ou mod ifiable (type EEP RO M), contenant le program me constructeur appelé encore système d'exploitation propriétaire (proprietary operating system) exprimé dans un langage spécifique au constructeur de l'équipement d'automatisme, une mémoire vive 2s et un gestionnaire des entrces/sorties, qui communiquent entre eux par un bus dit bus fond de panier. La mémoire vive ou mémoire volatile (type RAM) contient, dans une première zone, le programme utilisateur et dans une deuxième zone, les données, en particulier les images des états des coupleurs d'entrces- sorties et les constantes relatives au programme utilisateur. Le programme utilisateur, ou appelé encore programme d'application, est chargé de faire du contrôle ou de la commande d'une application d'automatisme au moyen d'entrées/sorties pilotées par ce programme d'application. Il est élaboré par un concepteur et est écrit dans un ou plusieurs langages graphiques d'automatisme incluant notamment des schémas à contacts (Ladder Diagram), appelés ci-après langage Ladder, des diagrammes fonctionnels en séquence (Sequential Function Chart ou langage Grafcet), appelés ci-après langage SFC, des blocs fonctions (Function Block Description), appelés ci-après langage FBD, ou bien dans des s langages textuels d'automatisme de type IL (Instruction List) ou ST (Structured Text). Ces langages d'automatisme sont avantageusement conformes à la norme IEC1131- 3, de façon à faciliter la programmation par un concepteur automaticien ne matrisant pas forcément les langages informatiques. Ces langages sont utilisables sur des stations de programmation qui sont reliées ou non à l'équipement d'automatisme à 0 programmer. A ce jour, les applications d'automatisme résultant de l'utilisation des langages graphiques d'automatisme de la norme IEC1131-3 (LadUer, Grafcet, FBD, IL Instruction List, ST Structured Text) ne peuvent être visualisses que sur une station de programmation disposant du logiciel de programmation d'une application. Or ce logiciel est très souvent coûteux et ne peut pas être de ce fait installé sur tous les terminaux informatiq ues. Le tech nicien d'exploitation d'une application d'automatis me, q ui souhaite pouvoir intervenir dès qu'un dysfonctionnement se produit sur un équipement d'automatisme, ne peut donc pas visualiser graphiquement son programme d'application sans recourir à une station de programmation disposant du logiciel de programmation d'une application. Le but de la présente invention est donc de pallier ces inconvénients de l'art antérieur en proposant une solution qui permette notamment à un technicien de visualiser graphiquement ou bien d'imprimer graphiquement son programme d'application à partir d'un terminal informatique quelconque équipé de logiciels qui ne sont pas spécifiques au monde des automatismes. Ce but est atteint par un procédé pour visualiser ou imprimer graphiquement sur un terminal informatique, une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme (LD, SFC, FBD) caractérisé en ce qu'il comprend: - une étape de mémorisation sur le terminal d'un programme source d'une application d'automatisme formulée à partir d'un des langages graphiques d'automatisme, le programme source étant dans un langage unique hiérarchisé et orienté objet vers au moins un de ces langages graphiques d'automatisme, - une étape de mémorisation sur le terminal d'au moins une feuille de style associée au langage graphique adopté pour le développement de l'application d'automatisme, - une étape de traitement sur le terminal du programme source par la feuille de style pour générer un fichier vectoriel graphique contenant les directives de dessin graphique vectoriel permettant l'affichage graphique de l'application d'automatisme sur le terminal ou son impression graphique. 0 Selon une autre particularité, le programme source décrit une application d'automatisme en langage Ladder en définissant les différents éléments du langage Ladder comme des objets, à savoir un contact, un lien horizontal, un lien vertical, une bobine, un court-circuit, une cellule vide, un appel de bloc fonction, une expression FFB, un bloc de comparaison, un bloc d'opérations arithmétiques, chacun de ces éléments comprend des attributs soit sous forme d'objets, de paramètres (par exemple de position), de variables ou de textes et constituent des informations mémorisées dans la mémoire de la station ou de l'équipement d'automatisme et représentables sous forme d'arborescence. Selon une autre particularité, le programme source décrit une application d'automatisme en langage SFC en définissant comme objets les différents éléments du langage SFC, à savoir une étape, une transition, un saut, un lien entre graphe, un commentaire, les coordonnées graphiques des différents objets de type saut, étape ou transition étant définies par un objet de type position définissant les coordonnées de position de l'objet respectif dans la grille de lignes et de colonnes de représentation du graphique de 1'objet type saut, étape ou transition sur les moyens de visualisation de la station. Selon une autre particularité, le programme source décrit une application d'automatisme en langage graphique FBD en définissant comme objet les différents éléments du langage FBD, à savoir des blocs fonctions (FFBBlock), des botes de texte (TextBoxFBD), des liens entre blocs, des instructions de saut, des labels et des commentaires. Selon une autre particularité, la feuille de style comprend des règles, chaque règle correspondant à un élément du langage d'application d'automatisme, I'activation de la règle étant effectuée lorsque l'élément a été trouvé dans le programme source cette activation produisant une ou plusieurs instructions graphiques dans le fichier vectoriel graphique généré. Selon une autre particularité, le procédé comprend une étape préalable de production du programme source en langage XML sur une station de programmation s de l'application d'automatisme. Selon une autre particularité, I'étape de production du programme source dans un langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD, SFC, FBD) est réalisée sur la station de programmation à partir d'une grammaire de description des applications 0 d'automatisme écrite dans ce langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD,SFC,FBD). Selon une autre particularité, la feuille de style est une feuille de style XSL définie pour chaque langage graphique utilisé pour le développement d'une application d'automatisme. Selon une autre particularité, I'adresse URL de la feuille de style est mémorisée dans le programme source en langage XML et la feuille de style est téléchargée par un réseau au moment du traitement du programme source par le terminal informatique. Un autre but de l'invention est de proposer un terminal informatique pouvant mettre en _uvre ce procédé. Cet autre but est atteint par un terminal informatique pour visualiser ou imprimer graphiquement une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme, caractérisé en ce 2s qu'il comprend des moyens de traitement par une feuille de style, d'un programme source d'une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme (LD, SFC, FBD), le programme source étant dans ce langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD,SFC,FBD), des moyens de production d'un fichier en fonction du traitement effectué par les moyens de traitement, le fichier contenant les directives de dessins et des moyens de visualisation sur le terminal du fichier comprenant les directives de dessins permettant de reproduire le programme d'application d'automatisme programmé dans un langage graphique d'automatisme. Selon une autre particularité, les moyens de visualisation sont constitués d'un logiciel éditeur supportant le format SVG (Scalable Vector Graphics) du W3C (Worid Wide Web Consortium). Selon une autre particularité, le logiciel éditeur dispose d'un interpréteur, c'est à dire d'une application exécutable, pour afficher graphiquement des documents au format SVG. Selon une autre particularité, les moyens de traitement comprennent un processeur XSLT permettant de générer le fichier par le traitement du programme source par la feuille de style. Selon une autre particularité, le terminal comprend des moyens d'impression supportant directement le standard SVG comme format d'impression. Selon une autre particularité, le terminal comprend des moyens de téléchargement d'une feuille de style adaptée au langage graphique adopté pour le développement de l'application d'automatisme. L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés dans lesquels: - la figure 1 représente une vue schématique d'une station de programmation équipée d'un gestionnaire XML pour importer ou exporter des fichiers d'application du langage unique vers un des langages graphiques; - la figure 2 représente une vue schématique de l'organisation en mémoire de la grammaire permettant de décrire une application d'automatisme dans le 2s langage unique selon 1'invention; - la figure 3 représente un composant logiciel qui constitue un générateur d'index de balises pour produire un fichier d'index; - la figure 4 représente une vue schématique des modules constitutifs d'un gestionnaire XML Hndir permettant l'importation et l'exportation de fichiers d'un langage vers un autre; la figure 5 représente une vue schématique des phases principales du procédé selon l'invention. L'invention consiste à produire un fichier contenant des directives de dessin permettant de reproduire graphiquement sur n'importe quel terminal informatique disposant d'un logiciel approprié, une application d'automatisme saisie sur une station de programmation par un développeur d'application d'automatisme dans un langage graphique d'automatisme tel que ceux conformes à la norme IEC1131-3 dénommés langage Ladder (LD), Langage FBD (Function Block Description) ou Langage SFC (Sequential Flow Chart). La production de ce fichier dans un format spécifique pour l'affichage sous forme graphique d'une application d'automatisme écrite dans un de ces langages graphiques (LD, SFC, FBD) est réalisée en partant du programme source écrit en langage unique, hiérarchisé et orienté objet de l'application formulée dans un des langages graphiques d'automatisme (LD, SFC, FBD). Dans le mode de réalisation présenté, ce langage unique, hiérarchisé et orienté objet est le langage XML (eXtended Markup Language) . Le programme source écrit dans le langage universel XML basé sur des objets ou éléments hiérarchisés est obtenu en décrivant l'application d'automatisme à partir d'une grammaire écrite dans ce langage XML. La grammaire est propre à la traduction dans le langage XML de l'application d'automatisme formulé dans un des langages graphiques d'automatisme (LD, SFC, FBD). La description est un iq uement textuelle (aucune information bina ire), el le est indépendante de l'implémentation et doit respecter les standards XML. Le programme source pourra être stocké en tout ou partie sous forme de fichiers. Ces fichiers pourront être importés ou exportés vers des logiciels tiers. Le programme source XML est constitué d'un arbre d'éléments. Chaque élément se compose d'une balise ("tag") d'ouverture avec le nom de l'élément, du contenu ou valeur de l'élément et d'une balise de clôture. Les balises d'ouverture ou de clôture sont des mots encadrés par des signes "inférieur" ( ). Dans une balise d'ouverture, le nom d'élément peut-être suivi par un ou plusieurs attributs destinés à décrire certaines propriétés de l'élément. Chaque attribut est une paire nom="valeur". L'application d 'a utomatis me est e ntiè rement d écrite à l 'aid e d 'él é ments et d 'attrib uts. Une grammaire spécifique à la traduction en langage XML d'une application écrite en langage graphique Ladder est définie en annexe 1. Un programme source d'une application formulée en langage Ladder, écrit à partir de cette grammaire spécifique, est défini en annexe 4. La description en langage Ladder est structurce en réseaux de contacts: chaque réseau est décrit ligne par ligne du haut vers le bas. Chaque ligne est décrite de la gauche vers la droite. Chaque ligne commence au rail gauche (à gauche de la représentation du réseau de contacts Ladder) et se termine sur le dernier élément s graphique décrit. Chaque ligne contient une liste d'éléments graphiques standards du langage à relais: contacts, bobines, lien horizontal, lien vertical, bloc fonction, etc.... Les coordonnées graphiques sont relatives à la position des objets dans la grille de lignes et de colonnes de représentation d'un graphique. Sur l'annexe 1, la position de l'élément ou objet par rapport au début de la 0 ligne définit par son retrait la dépendance hiérarchique de l'objet. La ligne 10 de la grammaire représentée à l'annexe 1, correspondant à une représentation graphique d'une application en langage Ladder définit qu'une application "LDSource" en Ladder est constituée d'un réseau Ladder (networkLD) et de zéro à n (indiqué par *) botes de texte (textBox). Un réseau Ladder (networkLD) est constitué d'une ou plusieurs is (indiqué par le signe +) lignes types (typeLine) et d'un lien avec zéro à n blocs fonctions (FBLink). Le lien avec au moins un bloc fonction (FBLink) est constitué com me indiqué ligne 50 de l'annexe 1 de deux objets de position (obj Position) définissant par leurs coordonnées u ne position de dépa rt correspond ant à l'attribut "depuis" (from, ligne 51) et une position d'arrivée correspondant à l'attribut "vers" (to, ligne 52). L'objet ligne type (typeLine) est constitué, comme indiqué à la ligne 13 de l'annexe 1, de zéro à n d'une combinaison des objets suivants: soit d'une ligne vide (em ptyLine), soit au choix d'un contact (contact), d'u n lien horizontal (H li nk), d'un lien vertical (Vlink), d'une bobine (coil), d'un contrôle (control), d'un court-circuit (shortCircuit), d'une cellule vide (emptyCell), d'un appel de bloc fonction (calls), d'une 2s expression FFB (FFBExpression), d'un bloc de comparaison (compareBlock) et d'un bloc d'opération arithmétique (operateBlock). L'objet ligne type (typeLine) a un attribut label qui est du texte. L'objet contact qui est défini à la ligne 18, a pour attribut le type de contact qui définit le type de contact, ouvert, fermé, montant, descendant sous forme d'énumération (openContact, closedContact, Pcontact, Ncontact) et le nom de la variable de contact (ContactVariableName) qui est du type texte. La ligne 23 définit l'objet lien horizontal (H Lin k) qui a pour attribut un nombre des cell ules (nu mberCell) traversées par le lien horizontal (HLink). Les lignes 26 et 27 de l'annexe 1 définissent I l'objet bobine (Coil) qui peut être de type bobine directe (Coil), bobine inverse (notCoil), bobine de mise à un (setCoil), bobine de mise à zéro (resetCoil), bobine de 3s franchissement de transition (hash Coi l) utilisée en association avec le la ngage S FC, bobine à front montant (Pcoil), bobine à front descendant (Ncoil) et le nom de la variable bobine (coilVariableName) qui est du type texte. L'objet contrôle (control) définit lignes 35 à 37 le type de commande à saut aumpCoil) ou à retour (retCoil). L'objet court-circuit (shortCircuit) est défini ligne 38 comme la combinaison des objets lien vertical (Vlink) et au choix un des éléments suivants: lien horizontal (Hlink), contact (contact), bobine (coil), appels (calls), bloc de comparaison (compareBlock). Un bloc appel (calis), comme défini ligne 39, contient une instance d'un objet (instanceObj), un type de paramètre (typeParam) et une description d'appel (descriptionCall). Le type de paramètre (typeParam) et la description d'un appel 0 (descriptionCall) peuvent être, comme indiqué par le point d'interrogation ("?"), de valeurs différentes. La valeur de type de paramètre est définie ligne 41 comme étant la valeur booléenne "0" ou "1" (enEnO). La ligne 43 définit la description d'un appel (descriptionCall) comme étant constituée d'une liste d'entrées (inputListFBD) de bloc fonction (FBD) qui sont des listes de paramètres formels-et de paramètres effectifs (voir ligne 45 et 46) et d'une liste de sorties (outputListFBD) de bloc fonction (FBD). Les boites de texte sont définies par la position de l'objet boite de texte et par ses dimensions en hauteur et en largeur. Chaque programme d'application pour des sections écrites en Ladder pourra être décrit en utilisant la grammaire correspondante au langage graphique Ladder. Chaque grammaire permet de définir une hiérarchie entre objets et de représenter une application sous forme d'une arborescence graphique (30) dans la mémoire vive de la station de programmation. Ainsi qu'on peut le voir sur l'annexe 1, la racine de l'arbre est constituée par l'application source (LDSource) à laquelle sont rattachés un ou plusieurs fils qui sont le 2s réseau (networkLD) et éventuellement une ou plusieurs boites de texte (textBox). Le réseau a un ou plusieurs fils constitués d'objets du type ligne (typeLine) et du type lien bloc fonction (FBLink). L'objet de type ligne (typeLine) a pour fils la ligne vide (emptyLine) ou un des éléments suivants: contact (contact), lien vertical (VLink), lien horizontal (HLink), bobine (coil), commande (control), court-circuit (shortCircuit), appels (calls), expression FFB (FFBExpression), comparaison de blocs (compareBlock), exécution de bloc (operateBlock). Une grammaire spécifique à la traduction en langage XML d'une description d'une application en langage graphique SFC est définie en annexe 2. La description en langage SFC d'une application (SFCSource) comprend un en-tête (SFCHeader) et est structurée en pages (SFCPage) qui correspondent aux pages d'écrans afffichées par l'éditeur de langage SFC. L'entête (SFCHeader) a pour attribut la tâche (task) et le nom d u g raphe (graph Name). Chaq ue page peut contenir s un ou plusieurs réseaux SFC (networkSFC). Chaque réseau contient une liste d'éléments "objet" choisis parmi les éléments graphiques standards suivants du langage SFC: étapes (step), sauts aump), transitions (transition), liens entre étape et transition (SFCLinkObject), commentaires (commentSFC), liens entre graphes (linkSFC). Les coordonnées graphiques des différents objets de type saut, étape ou transition sont définies par un objet de type position (objPosition) définissant la position de l'objet respectif (saut, étape ou transition) dans la grille en ligne/colonne. Un objet de type étape (step) est défini par une ou plusieurs actions dont les attributs sont définis lignes 23 et 24 de l'annexe 2. Les transitions sont définies également par des conditions de transition (transitionCondition). Les objets du type liens entre graphes (linkSFC) sont constitués de deux objets de position (objPosition) définissant par leur coordonnées une position de départ correspondant à l'attri but "depu is u n type d'objet" (typeObjectFrom) et une position d'arrivée correspondant à l'attribut"vers un type d'objet" (typeObjectTo). Chacun de ces deux attributs est choisi parmi un des objets suivants: étape initiale (initialStep), étape (step), macro étape (macoStep), étape interne (stepin), transition (transition), branche A (Abranch), branche P (Pbranch), jointure A (Ajoint), jointure P (Pjoint) et pour l'attribut "vers" également entre les objets précédents et l'objet saut aump). La hiérarchie du langage SFC est la suivante. L'arborescence a pour racine l'objet source (SFCSource) qui a lui-méme pour fils l'entête (SFCHeader) et la page 2s (SFCPage). La page a pour fils le réseau (networkSFC), lequel réseau a pour fils l'étape (step), le saut aump), la transition (transition), le lien objet FSC (SFCLinkObject), le commentaire SFC (CommentSFC) et le lien entre graphes SFC (linkSFC). De manière similaire, une grammaire spécifique à la traduction en langage XML d'une description d'une application en langage graphique FBD est définie en annexe 3. Chaque réseau en langage FBD contient une liste d'éléments graphiques standards du langage FBD: bloc fonction (FFBBlock), bo^'te de texte (textBoxFBD), label (labelObject), commentaire (commentObjectFBD), lien entre blocs (iinkFBD) et instruction de saut aumpObject). Chaque élément est défini conformément aux 17gnes 12 à 38 de l'annexe 3. Les coordonnées graphiques sont relatives à la position des objets dans la grille en ligne/colonne. s La hiérarchie entre objets déflnie dans cette grammaire est la suivante. La racine est constituée par la source FBD (FBDSource), laquelle est constituée d'un ou plusieurs réseaux FBD (networkFBD). chaque réseau est constitué de l'un ou plusieurs des éléments flls suivants: le bloc (FFBBlock), la bo^'te de texte (textBoxFBD), I'étiquette (labelObject), le saut aumpObject), le commentaire (commentObjectFBD), le lien (linkFBD). Les fichiers (402, fig.2) descriptifs de la grammaire sont organisés de la manière suivante. Une application d'automatisme peut se décomposer principalement en trois parties: son programme, ses données et ses entrces / sorties. La grammaire de chacune de ces parties est décrite, selon 1'invention, dans un fichier de "Définition du Type de Document" (ou Document Type Definition) de la forme ".dtd" (par exemple : program. dtd pour le fichier programme d'application, datas.dtd pour le fichier donnces, lOConf.dtd pour le fichier de configuration des entrées/sorties) ou de manière équivalente dans un fichier"Schéma" de la forme ".xsd". Par la suite, on parlera de fichiers ".dtd" mais ils pourront être remplacés de façon équivalente par des fichiers "Schéma" de la forme ".xsd". Ainsi, lorsque la notation de type "datas.*" est utilisée, cela signifie qu'il s'agit d'un fichier de données qui peut être de type "dates.dtd" ou "dates.xsd". Chacune des parties d'application peut elle-même se décomposer en sous-parties faisant elles-mêmes l'objet d'un fichier descriptif en ".dtd" (ou ".xsd"). A titre d'exemple, le fichier programme (program.dtd) pourra inclure les fichiers source (LDSource.dtd, SFCSource. dtd et FBDSource.dtd, comme cela est représenté à la figure 2) qui contiennent les grammaires des différents langages graphiques de type schémas à contacts (LD), diagrammes fonctionnels en séquence (SFC) et blocs fonctions (FBD). Les fichiers ".dtd" ou ".xsd" (402) sont les fichiers spéciflques au constructeur et contiennent la description des différentes grammaires. Ainsi le dossier "Application" (figure 2) comprend le fichier (commonElements.*) qui contient les éléments communs à l'application d'automatisme, à savoir le nom de l'application, la date de réalisation de l'application ou de la version, le numéro de version et des commentaires. Le dossier "Configuration" contient les fichiers de configuration respectivement des entréesisorties (lOConf.*) et de la configuration logique (LogicConf.*). Les dossiers "Instance", "DDT", "DFB types" contiennent la description des données instance, DDT, FB type sous forme des fichiers (datas, DDTSource.*, FBDSource.*, FBSource.*). Le dossier "Program" contient les fichiers sources (LDSource. *, SFCSource.* et FBDSource.*) qui contiennent respectivement la description de chaque grammaire respective à chaque représentation graphique usuelle en matière d'automatisme décrites respectivement aux annexes 1 à 3. Le dossier "Animation tables" contient la description des tables d'animation qui est constituée en partie des fichiers (commonElements.* et dates.*). Le dossier "Operator screens" contient les descriptions des écrans d'exploitation constituées des fichiers des éléments communs (commonElements.*) et des données du fichier (datas.*). Ces différents fichiers de grammaire (402) définissent la structure des fichiers XML. Un fichier XML d'une application représente une instance de la grammaire définie dans le fichier".dtd" (ou ".xsd") correspondant. Les fichiers XML (401, fig.3) sont eux spécifiques de l'application d'automatisme considérée. Le principe de correspondance entre ces deux types de fichiers est défini par la norme XML V1.0 conformément au modèle objet du document (DOM, Document Object Model). Le modèle objet du document DOM est un ensemble de fonctions de programmation (API: Application Programming Interface) standards pour manipuler des fichiers XML. La correspondance entre les fichiers XML et les bases de données de l'application est la suivante: Une application d'automatisme est stockée en binaire dans une mémoire d'une station de programmation. Cette application d'automatisme selon l'art antérieur était mise au point par l'utilisateur qui se servait d'un éditeur (5) pour des langages graphiques IEC1131-3, utilisant un composant logiciel dénommé par la suite gérant (Mng1,Mng2,...) pour ranger les saisies utilisateurs, dans plusieurs bases de données, par exemple: une base de données (Db1) pour le programme, une base de données (Db2) pour les données de l'application et une base de données (Db3) pour la configuration des entréesisorties de l'application, (Db1) et (Db2) étant représentées sur la figure 1. La description de l'application en langage XML selon l'invention est complètement indépendante de son implémentation dans les bases de données constructeurs Pour assurer cette indépendance, un composant logiciel particulier a été développé; il constitue un générateur automatique d'index de balises (Tag) représenté sur la figure 3 et est dénommé ci-après composant GeninTag (25). Le composant logiciel GeninTag (25) générateur d'index de balises doit être exécuté pour produire des fichiers d'index (".h") qui permettent de faire la correspondance entre 1'arborescence graphique XML (30) représentative de l'application d'automatisme dans le langage de l'invention et les structures des bases de données (Db1,Db2). Plus particulièrement, un fichier d'index permet de faire la correspondance entre les n_uds de l'arborescence produite par l'exécution des fichiers en langage unique XML et les objets associés aux langages graphiques de 0 description d'automatisme qui sont stocRés dans les bases de données. Ce composant GeninTag extrait les mots clés (éléments, objets et attributs) des différents fichiers de grammaire ".dtd" (402) qui définissent les grammaires XML pour le programme, les données, la configuration d'entréessorties en langage XML, afin de générer des index organisés selon plusieurs fichiers, par exemple quatre fichiers (11,12,13,14) dans la figure 3, contenant chacun un ou plusieurs fichiers de constantes d'index utilisés par les différents gérants (Mng1,Mng2,...) gérant une application. Le composant GeninTag lit les fichiers de définition du type de document ".dtd" -ou de schéma ".xsd"- et génère les différents fichiers d'index. Dans le mode de réalisation présenté, il existe les fichiers d'index (11) pour la définition des mots-clés de la configuration matérielle et logicielle (SrcTaglOConf.h, SrcTagLogicConf.h), les fichiers d'index (12) pour la définition des mots clés des données et des types de données regroupés dans les fichiers (SrcTagDatas.h, SrcTagDDTSource.h, SrcTagFBSource.h), les fichiers d'index (13) pour la définition des mots clés pour le programme (SrcTagProgram.h, SrcTagProgramHeader.h, SrcTagSFCSource.h, ScrTagLDSource.h, ScrTagFBDSource.h) et les fichiers d'index (14) pour la définition des mots clés communs aux autres parties de l'application (SrcTagCommonElements.h). Ces fichiers d'index réalisent la correspondance qui permet d'utiliser les bases de données (Db1, Db2,...) de description des applications selon l'art antérieur. Ils sont stockés dans une mémoire non volatile de la station de programmation. La station de programmation incorpore dans une mémoire non volatile un programme gestionnaire XML Hndlr (20) -en anglais XML Handier-. Le gestionnaire XML Hndir (20) est un composant logiciel développé en langage C++, utilisable au travers d'une interface COM. Il encapsule et utilise les services d'un analyseur Prsr DOM (215) -en anglais Parser DOM- et offre des services de haut niveau pour la gestion de l'arborescence graphique XML (30). Le gestionnaire XMLHndir (20), représenté plus en détail sur la figure 4, permet de fabriquer l'arborescence (30) s représentative de l'application à partir des fichiers de description (401) en utilisant les fichiers de grammaire (402) ou de fabriquer cette arborescence à partir des demandes des gérants (Mng1, Mng2,...) des bases de données de l'application. Il utilise les différents gérants qui appellent les services du gestionnaire XML Hndir (20) en utilisant les fichiers d'index (11 à 14) générés par le composant GeninTag (25). Comme représenté à la figure 1, chaque partie d'une application, par exemple programme d'application (Db1) données de l'application (Db2), est gérée par un gérant spécifique (par exemple Mng1 pour le programme d'application, Mng2 pour les données). Le gestionnaire XML Hndlr (20) comporte, en plus de l'analyseur Prsr DOM qui est un composant logiciel en langage C++, une routine d'exportation (EXP) et une routine d'importation (IMP). Dans le cadre de la présente invention, seule la routine d'exportation est intéressante. La routine d 'exportation écrit, dans un fichier XM L, les données de l'application d'automatisme tandis que la routine d'importation lit dans un fichier XML les données de l'application d'automatisme. Ces routines font appel à la fois au service du module (210) de service (CsrcServices) qui lui-même se décompose en plusieurs services. Un service (IscrWalkSource) permet le déplacement dans le fichier modèle (401) en langage XML chargé en mémoire. Le composant (CsrcServices) comprend également un service (IsrclmportSource) qui est un service d'initialisation de lecture 2s d'un fichier XML (401), le service (IsrcexportSource) qui est un service d'écriture de fichiers XML et le composant (IsrcPUnitService) qui permet de gérer les services spécifiques à la station de programmation. Le gestionnaire XML Hndir (20) comporte également un service (IsrcPUnitService) qui permet de gérer les services spécifiques à l'unité de programmation. Enfin, le gestionnaire (20) comporte un service (IsrcElement) qui est un service permettant l'accès au contenu d'une donnce XML (éléments et attributs). Chacun des gérants dialogue avec les différents service du gestionnaire (20). Les gérants spécifiques (Mng1, Mng2,...) utilisent les fichiers index (11 à 14) générés par le composant GeninTag (25) correspondant aux donnces de la base de données. L'application mémorisée sur la station de programmation dans un ensemble d'un ou plusieurs fichiers de description XML (401) est modélisée par le gestionnaire XML Hndir (20) sous forme d'arborescence (30) en utilisant d'une part les informations réparties dans la mémoire de la station de programmation dans des bases de données s (Db1, Db2,...) et sous forme de fichiers binaires, et d'autre part les index (11 à 14) créés par le composant GeninTag (25) pour accéder à ces informations et les représenter sous forme arborescente. Le composant gestionnaire XML Hndir (20), comme représenté à la figure 1, communique par des notifications avec les gérants (Mng1, Mng2,...) des bases de données (Db1, Db2,...) et avec le module de gestion 0 de l'arborescence de l'application. Ainsi, lors de l'export, un gérant (Mng1) peut émettre une notification (102) "CreateNode (index, value)" demandant au gestionnaire XML Hndlr (20) de créer un n_ud ayant un index déterminé et une valeur déterminée. Le gestionnaire (20), en utilisant les valeurs d'index et par lecture des fichiers sources (401) et des fichiers grammaires (402), va demander au module de gestion de l'arborescence de créer par une notification (203) "Create Node (tagname, value)", un n_ud ayant pour nom de balise le nom défini par "tagname" et pour valeur, la valeur désignée par "value". Le développement de ces grammaires en langage XML et l'écriture de fichiers permettent de développer un interpréteur sur un équipement d'automatisme, ce module interpréteur ayant pour fonction de traduire les instructions, décrivant une application, formuléss en langage XML, en instructions exécutables par le système d'exploitation (I'operating system) de l'équipement d'automatisme. De cette façon, on aboutit à un équipement d'automatisme dont le langage de programmation serait accessible à n'importe quei éditeur disponible sur une machine de type PC et permettrait ainsi au 2s concepteur d'automatisme de développer des programmes d'application dont les fichiers seraient mémorisés en ASCII. Les langages graphiques peuvent ainsi être décrits de façon normalisée en ASCII. Cette normalisation d'une grammaire permet l'échange de programmes d'applications d'automatisme entre logiciels (operating system) de constructeurs différents. La procédure selon l'invention est représentée en figure 5. Une fois qu'un programme source XML (50) d'une application d'automatisme programmée sur une station de programmation (51) a été produit selon la description faite cidessus, celui-ci peut être mémorisé dans une mémoire (M) de n'importe quel terminal informatique (54) et visualisé textuellement sur un éditeur de texte de ce terminal (54). Un programme source XML (50) d'une application d'automatisme écrite en langage Ladder est déflni en annexe 4. Ce programme source (50) renvoie en ligne 6 à une feuille de style XSL (Extensible Stylesheet Language) dont l'adresse URL est: "d:\xml\presentation\tp\LDtoSVG3.xsl". s Selon l'invention, une feuille de style XSL (52) est crsée pour être appliquée au programme source XML (50) d'une application d'automatisme formulée à partir d'un des langages graphiques d'automatisme tel que ceux de la norme IEC1131-3 (LD, SFC, FBD) , afin de produire un fichier (53) vectoriel graphique au format SVG (Scalable Vector Graphics) et de le visualiser sur un terminal (54) comportant un 0 logiciel éditeur supportant le format SVG et disposant des composants essentiels pour comprendre le langage XML. Ce logiciel éditeur sera, par exemple, un navigateur Internet tel que "Microsoft Internet Explorer". La feuille de style XSL (52) est unique pour chaque langage graphique d'automatisme Ainsi, il existe une feuille de style distincte pour le langage Ladder, pour le langage SFC et pour le langage FBD. Pour produire le fichier (53) au format SVG et ainsi pouvoir visualiser sur l'éditeur du terminal (54) I'application d'automatisme sous forme graphique, il faudra appliquer sur le programme source la feuille de style XSL (52) correspondant au langage graphique d'automatisme dans lequel a été formulée l'application d'automatisme au départ. Ainsi, selon l'invention, il sera possible de visualiser graphiquement une application d'automatisme formulée dans un langage graphique d'automatisme sans avoir recours à sa station de programmation (51). Il est seulement nécessaire de récupérer le programme source (50) en XML de cette application et de lui appliquer une feuille XSL (52) propre au langage graphique d'automatisme utilisé pour programmer l'application d'automatisme, pour obtenir un fichier (53) au format 2s SVG. Ce fichier (53) au format SVG reproduit des directives de dessin permettant de visualiser graphiquement sur n'importe quel terminal informatique (54) I'application d'automatisme comme représenté en figure 5. Une feuille de style XSL (52) est écrite en XML et structurée en un arbre d'éléments. Une feuille de style XSL (52) comprend un ensemble de règles et de structures définies par la feuille de style qui vont s'appliquer sur le programme source. Un sélecteur associé à chaque règle est chargé d'activer ia règle lorsqu'un certain type d'élément est trouvé dans le programme source. La feuille de style XSL (52) définie pour le langage Ladder est visible en annexe 5. Le fichier SVG (53) textuel, issu de l'application de cette feuille XSL (52) sur le programme source (50) visible en annexe 4, est défini en annexe 6. La feuille XSL (annexe 5) se présente de la manière suivante. L'expression "xsl" est répétée devant tous les éléments de manière à ce que, lorsque la feuille de style XSL (52) est appliquée sur le programme source (50), I'éditeur comprenne l'instruction en prenant s en compte le langage XSL et non un autre langage. La feuille de style XSL (52) est écrite suivant une structure prédéfinie dans un fichier".dtd" défini après l'instruction "DOCTYPE" et ayant pour nom "svg-20000303stylable.dtd". Les premières lignes de la feuille de style XSL (52) correspondent à la recherche de l'élément racine défini par "/" ("template match="/"") dans le programme source. Ensuite la feuille de style XSL 0 (52) comprend ligne 46 une instruction de recherche de "currentposx" dans le programme source (50). Une fois trouvée, un certain nombre de règles seront activées par le sélecteur dans le fichier SVG (53) généré. Ceci est particulièrement visible à partir de la page 25, ligne 8 de l'annexe 5, dans la feuille de style (52). L'instruction signifie que lorsque l'élément "networkLD" est s trouvé dans le programme source (50), les règles définies à partir de la ligne 9, page de l'annexe 5 et comprenant en particulier " à 13 apparaissent exactement ces règles définies dans la feuille de style (annexe 5). Ensuite cette feuille de style (52) propre au langage Ladder définit de la ligne 28, page à la ligne 32, page 26 la recherche dans le programme source (50) des différents éléments de type "contact". Ces contacts peuvent être de différentes sortes le long du graphique représentant l'application d'automatisme. Ils peuvent être ouverts ("openContact"), fermés ("closedContact"), de type "P" montant ("PContact"), de type "N" descendant ("NContact"). Lorsqu'un de ces types de contact est trouvé dans le programme source (50), certaines règles sont activées par le sélecteur. Ces règles comprennent des instructions graphiques nécessaires au dessin de ces contacts pour qu'ils soient représentés comme lorsque l'application d'automatisme est visualisée directement sur sa station de programmation (51) comme représenté en figure 5. Ces instructions sont de type " 19, 31), "closedContact" (lignes 22, 39), "PContact" (ligne 28) et"NContact" (ligne 37). Les règ l es sont don c activées en fonction d e l'em place ment d es élé ments d a ns le programme source (50) et se retrouvent dans le fichier SVG (53), par exemple, en 3s page 29, lignes 14-23 pour l'élément "openContact", en page 29, lignes 28-37 pour I'élément"closedContact", en page 29, ligne 59 à page 30, ligne 6 pour l'élément "PContact" et en page 30, lignes 44-53 pour l'élément "NContact". La feuille de style XSL (annexe 5) définit également toutes les règles nécessaires au dessin des différents types de bobines ("Coil"). En effet il existe dans le s langage Ladder différents types de bobines, "setCoil" (page 27, lignes 5-20), "resetCoil" (page 27, lignes 21-36), "PCoil" (page 27, lignes 37-52), "NCoil" (page 27, ligne 53-page 28, ligne 4). Différents types de bobines se retrouvent dans le programme source de l'annexe 4 et donc dans l'application d'automatisme. Les bobines de type "PCoil" sont repérées en lignes 32 et 53, de type "setCoil" en ligne 41, o de type "resetCoil" en ligne 47, de type "Ncoil" en ligne 60 dans le programme source (50). Les règles correspondant à ces découvertes dans le programme source sont donc reproduites de la feuille de style XSL dans le fichier SVG. Ces règles sont par exemple comme ci-après: " opacity:1..." (annexe 6, page 30, ligne 24). Notons également que pour la bobine de type "P" ("PCoil"), apparaissent dans la feuille de style et donc dans le fichier SVG (annexe 6, page 30, ligne 27) des instructions de type " d'automatisme dont le programme source (50) est issu. L'ouverture du programme source (50) XML qui comprend cette instruction par un logiciel éditeur tel qu'un navigateur Internet provoque par cette ligne de code l'appel de la feuille de style XSL (52) qui va automatiquement s'appliquer sur le programme source (50) XML, comme décrit ci-dessus. Cette application produit directement le fichier SVG (53) comportant des instructions graphiques pour l'affichage graphique de l'application d'automatisme sur l'écran du terminal informatique (54). Grâce à la feuille de style XSL (52), I'affichage en format SVG sur le terminal informatique (54) correspondra exactement à l'affichage de l'application d'automatisme sur sa station de programmation (51). Cet afffichage sur le terminal (54) comportant le logiciel éditeur est permis si celui-ci comprend un processeur XSLT (525) ("Extensible Stylesheet Language Transformation"). Le logiciel Internet Explorer et d'autres navigateurs Internet disposent de ce type de processeur (525). Le processeur XSLT (525) permet à I'éditeur de comprendre le langage XML et d'appliquer la feuille XSL sur le programme source XML lorsque celuici est ouvert sur l'éditeur. Toutefois, I'afffichage graphique à partir du logiciel éditeur et donc l'interprétation des instructions du fichier SVG seront permis si le logiciel éditeur dispose également d'un interpréteur SVG. Par exemple, s Internet Explorer nécessite actuellement l'installation additionnelle d'un "plug-in" pour afficher graphiquement les documents SVG. Si l'éditeur ne comporte pas le "plug-in", il afffichera le programme source (50) seulement textuellement. Selon l'invention, il sera donc possible de visualiser graphiquement une application d'automatisme sans pour cela devoir utiliser la station de programmation lo (51) de 1'application. L'application d'automatisme pourra donc être visualisée graphiquement sur n'importe quel terminal informatique (54) comportant un éditeur supportant le format SVG tel que, par exemple, un navigateur Internet. Ceci pourra être utile, en particulier pour des opérations de maintenance afin d'établir un diagnostic de dysfonctionnement. Dans ce cas, il ne sera plus nécessaire de disposer d'une station de programmation de 1'application d'automatisme, seul le programme source XML sufffira. L'application de la feuille de style XSL (52) sur le programme source (50) XML sera effectuée directement sur un terminal informatique (54) après avoir téléchargé, par un réseau de type Internet ou Intranet, la feuille de style XSL (52) pour l'appliquer au programme source (50) en XML visualisable sous forme textuelle, afin d'obtenir un programme source visualisable sous forme graphique. Selon l'invention, il sera également possible d'imprimer graphiquement l'application d'automatisme. Certaines imprimantes supportent directement le standard SVG comme format d'impression. Il doit être évident pour les personnes versées dans l'art que la présente 2s invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d 'illustration, mais peuvent être mod ifiés dans le domaine défin i par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci dessus. ANNEXE 1 Description DTD de la grammaire du langage Ladder: %commonElements; _ c!ATTLIST HLink numberCell CDATA #IMPLIED > c!ELEMENT coil EMPTY> ANNEXE 2 Description DTD de la grammaire du langage SFC: s %commonElements; 0 --> #REQUIRED, ANNEXE 3 Description de la grammaire du langage FBD: %commonElements; _ ) ANNEXE 4 Programme source XML d'une application formulée en langace Ladder "38"P 1 5 ANNEXE Feuille de style XSL définie pour le langage Ladder xsl:stylesheet xmins:xsl="http://www.w3.org/1999/XSLlTransform" version="1.0"> > > > 75 --> xsl:value-of select="$increment+$rest"/> c/xsl:when> 55 S o pen Contact linejoin:round; stroke-miterlimit: 10; stroke-linecap:butt; fill:#000000; fill-opacity: 1 " x1 ="{$poscontact+35}" y1 ="{$posline+5}" x2="{$poscontact+35}" y2="{$posline+45}" /> closedContact PContact P NContact linejoin:round, stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1 ="{$poscontact}" y1 ="{$posline+5}" x2="{$poscontact}" y2="{$posline+45}" /> N coil SO SS setcoil size:24; font-family:Arial; font-weight:400; fill:#O00000; fillopacity:1" transform="translate(528 {$ posline+32})">S resetcoil size:24; font-family:Arial; font-weight:400; fill:#O00000; fillopacity:1" transform="translate(528 {$posline+32})">R Pcoil size:24; font-family:Arial; font-weight:400; fill:#O00000; fillopacity:1" transform="translate(528 {$posline+32})">P Ncoil N ANNEXE 6 Fichier SVG de visualisation pour langage Ladder 550 2)'/> openContact Hlink closed Contact notcoil *1 550 2)"/> Hlink PContact cline style="strcke:#000000; stroke-width:1; stroke-opacity:1; strokelinejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1="165" y1="55" x2="165" y2="95"/> P Hlink Pcoil P 1 550 2)"/> Hlink NContact N closedContact Hlink setcoil line style="stroke:#000000; stroke-width:1; stroke-opacity:1; stroke linejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1="555" y1="125" x2="575" y2="125"P S 1 550 2)"/> op e n Co ntact Hlink resetcoil R line style="stroke:#000000; stroke-width:1; stroke-opacity:1; stroke-linejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1="505" y1="175" x2="515" y2="175"/> 1 550 2)"/> Hlink closedContact cline style="stroke:#000000; stroke-width:1; stroke-opacity:1; strokelinejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1="280" y1="225" x2="505" y2="225"/> Pcoil cline style='stroke:#000000; stroke-width:1; stroke-opacity:1; stroke linejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fiil:#O00000; fill-opacity:1" x1="555" y1="225" x2="575" y2="225"/> P 1 550 2)"/> cline style='stroke:#000000; stroke-width:1; stroke-opacity:1; strokelinejoin:round; stroke-miterlimit:10; stroke-linecap:butt; fill:#O00000; fill-opacity:1" x1="25" y1="275" x2="55" y2="275"/> 2 0 closed Co ntact openContact Ncoil N 33 2823578 REVENDICATIONS 1. Procédé pour visualiser ou imprimer graphiquement sur un terminal informatique (54), une application d'automatisme programmée sur une station de s programmation (51) à l'aide de langages graphiques d'automatisme (LD, SFC, FBD) caractérisé en ce qu'il comprend: - une étape de mémorisation sur le terminal (54) d'un programme source (50) d'une application d'automatisme formulée à partir d'un des langages graphiques d'automatisme (LD, SFC, FBD), le programme source étant dans un langage unique hiérarchisé et orienté objet vers au moins un de ces langages graphiques d'automatisme (LD, SFC, FBD), - une étape de mémorisation sur le terminal (54) d'au moins une feuille de style (52) associée au langage graphique adopté pour le développement de l'application d'automatisme, une étape de traitement sur le terminal (54) du programme source (50) par la feuille de style (52) pour générer un fichier (53) vectoriel graphique contenant les directives de dessin graphique vectoriel permetta nt l'affichage g raph ique de l 'a pp lication d 'a utomatisme su r le terminal (54) ou son impression graphique. 2. Procédé selon la revendication 1, caractérisé en ce que le programme source (50), utilisé dans l'étape de mémorisation du programme source (50) , décrit une application d'automatisme en langage LadUer en définissant les différents éléments du langage Ladder comme des objets, à savoir un contact, un lien horizontal, un lien vertical, une bobine, un courtcircuit, une cellule vide, un appel de bloc fonction, une expression FFB, un bloc de comparaison, un bloc d'opérations arithmétiques, chacun de ces éléments comprend des attributs soit sous forme d'objets, de paramètres (par exemple de position), de variables ou de textes et constituent des informations mémorisoes dans la mémoire de la station ou de l'équipement d'automatisme et représentables sous forme d'arborescence. 3. Procédé selon la revendication 1, caractérisé en ce que le programme source (50), utilisé dans l'étape de mémorisation du programme source (50) , décrit une application d'automatisme en langage SFC en définissant comme objets les différents éléments du langage SFC, à savoir une étape, une transition, un saut, un lien entre graphe, un commentaire, les coordonnées graphiques des différents objets 34 2823578 de type saut, étape ou transition étant définies par un objet de type position définissant Ies coordonnées de position de l'objet respectif dans la grille de lignes et de colonnes de représentation du graphique de l'objet type saut, étape ou transition sur les moyens de visualisation de la station. 4. Procédé selon la revendication 1, caractérisé en ce que le programme source (50), utilisé dans l'étape de mémorisation du programme source (50) , décrit une application d'automatisme en langage graphique FBD en définissant comme objet les différents éléments du langage FBD, à savoir des blocs fonctions (FFBBlock), des botes de texte (textBoxFBD), des liens entre blocs, des instructions de saut, des 0 labels et des commentaires. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que la feuille de style (52), utilisée dans l'étape de mémorisation de la feuille de style et dans l'étape de traitement du programme source (50), comprend des règles, chaque règle correspondant à un élément du langage d'application d'automatisme, 1 5 I 'activation de la règ le étant effectuée lorsq ue l'élément a été trouvé da ns le programme source (50), cette activation produisant une ou plusieurs instructions graphiques dans le fichier (53) vectoriel graphique généré. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il comprend une étape préalable de production du programme source (50) en langage XML sur une station de programmation (51) de l'application d'automatisme. 7. Procédé selon la revendication 6, caractérisé en ce que l'étape de production du programme source (50) dans un langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD, SFC, FBD) est réalisée sur la station de programmation (51) à partir d'une grammaire de description des applications d'automatisme écrite dans ce langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD, SFC, FBD). 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que la feuille de style (52), utilisée dans l'étape de mémorisation de la feuille de style et dans l'étape de traitement du programme source (50), est une feuille de style XSL définie pour chaque langage graphique utilisé pour le développement d'une application d'automatisme. 9. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que l'adresse URL de la feuille de style (52), utilisée dans l'étape de mémorisation de la 3s 2823578 feuille de style et dans l'étape de traitement du programme source (50), est mémorisée dans le programme source (50) en langage XML et la feuille de style est téléchargée par un réseau au moment du traitement du programme source (50) par le terminal informatique. s 10.Terminal informatique pour visualiser ou imprimer graphiquement une application d 'automatis me programmée sur une station de program mation à l 'aide de langages graphiques d'automatisme, caractérisé en ce qu'il comprend des moyens de traitement par une feuille de style, d'un programme source d'une application d'automatisme programmée sur une station de programmation à l'aide de langages graphiques d'automatisme (LD, SFC, FBD), le programme source étant dans ce langage unique hiérarchisé et orienté objet vers au moins un des langages graphiques d'automatisme (LD, SFC, FBD), des moyens de production d'un fichier en fonction du traitement effectué par les moyens de traitement, le fichier contenant les directives de dessins et des moyens de visualisation sur le terminal du fichier comprenant les directives de dessins permettant de reproduire le programme d'application d'automatisme programmé dans un langage graphique d'automatisme. 11. Terminal selon la revendication 10, caractérisé en ce que les moyens de visualisation sont constitués d'un logiciel éditeur supportant le format SVG. 1 2. Terminal selon la revendication 11, caractérisé en ce que le logiciel éditeur dispose d'un interpréteur, c'est à dire d'une application exécutable, pour afficher graphiquement des documents au format SVG. 13. Terminal selon l'une des revendications 10 à 12, caractérisé en ce que les moyens de traitement comprennent un processeur XSLT permettant de générer le fichier par le traitement du programme source par la feuille de style. 2s 14. Terminal selon l'une des revendications 10 à 13, caractérisé en ce qu'il comprend des moyens d'impression supportant directement le standard SVG comme format d'impression. 15. Terminal selon l'une des revendications 910 à 14, caractérisé en ce qu'il comprend des moyens de téléchargement d'une feuille de style adaptée au langage