FR 2758634 A1 19980724 FR 9700542 A 19970120 La présente invention concerne un décodeur de téléaffichage traitant des informations diffusées par un serveur central via un réseau de communication. Le décodeur est destiné à être intégré ou associé à un terminal, lui-même associé à un ordinateur, ou à un micro-ordinateur. Les informations décodées sont ensuite transmises à une ou des unités d'affichage. La présente invention concerne également un terminal équipé d'un tel décodeur, et un système de téléaffichage comportant une pluralité de terminaux selon l'invention, organisés en réseaux et commandés localement ou à distance à partir d'un seul serveur central. Les données sont transmises en temps réel entre le serveur et les différents terminaux du réseau. Les informations transmises par le serveur central sont de type varié telles que par exemple des caractères alpha-mosaïques selon le codage vidéotex, des trames d'images ou encore des informations mixtes composées d'informations codées selon la norme vidéotex et des images. Les domaines d'applications vont notamment au téléaffichage d'informations destinées au grand public telles que les ventes aux enchères, la promotion de nouveaux produits, les animations en lieux publics, les informations relatives au trafic ferroviaire destinées aux usagers et aux régulateurs de trafic,... Il existe, à l'heure actuelle, différents procédés de visualisation d'une image sur un écran d'un terminal ou d'un micro-ordinateur. Parmi ces procédés, trois familles de procédés se distinguent. Les caractéristiques de visualisation et de codages de ces familles sont définies par la Commission Européenne des Postes et Télécommunications (CEPT) dans sa recommandation T/CD06-01 correspondant à la norme vidéotex). Ces familles de procédés sont - l'approche alpha-mosaïque (Chapitre 1 de ladite recommandation) - l'approche géométrique (Chapitre 2 de ladite recommandation) - l'approche photographique (Chapitre 3 de ladite recommandation). Dans les techniques alpha-mosaïques, le terminal gère fondamentalement un espace composé de caractères, qui peuvent être pris dans différentes polices, et dotés d'attributs (soulignement, inversion, clignotement, tailles, couleurs,...). Le standard français "TELETEL" définit notamment des terminaux conformes au chapitre 1 de la recommandation sus-visée. Dans les techniques géométriques, le terminal est un outil de type graphique, gérant un espace de points, dotés de couleurs ; il dispose de toute l'intelligence nécessaire pour lui permettre de décoder et d'exécuter les commandes de dessin élaborées qui lui sont transmises (lignes, surfaces, cercles, textes,...). Les techniques photographiques permettent le codage d'une image ou d'un document quelconque et sa transmission point à point vers un terminal de restitution (qui peut être une console ou un dispositif d'impression) ; la télécopie relève de cette catégorie. Ces diverses techniques de visualisation peuvent être mises en oeuvre aussi bien dans un terminal dénué d'intelligence locale ou, au contraire, dans un microordinateur. C'est ainsi que le terminal peut être dédié à une communication de masse, dont les spécifications sont arrêtées une fois pour toutes (c'est le cas du terminal Minitel, aux normes françaises Télétel, conçu au départ pour remplacer l'annuaire téléphonique) ; il sera dans ce cas le plus souvent dénué d'intelligence locale, malgré quelques variantes haut de gamme comportant des fonctions d'agenda, appel automatique, etc... Il se peut au contraire qu'en tout ou partie l'animation du dialogue avec l'usager soit décentralisée dans des stations locales. On aura dans ce cas des stations construites autour d'un véritable micro-ordinateur, susceptibles de se voir télécharger tant les messages à diffuser que l'ensemble des données qui définissent la logique de leur diffusion. Les terminaux se présentent sous la forme d'afficheurs "passifs" qui n'ont pour seule fonction que celle de générer des caractères. La logique d'affichage et la base de données d'évènements à afficher sont gérées au niveau de la pluralité de stations locales quasi autonomes, organisées autour d'un système centralisé. Les évènements logiques et les évènements graphiques relèvent de la responsabilité de la station locale. Cette structure n'autorise pas des téléchargements en temps réel, entre le système central et les différentes stations locales, d'images nécessitant des capacités de débit très importantes vers un nombre important de points d'affichage (plusieurs centaines). Le besoin se fait notamment ressentir dans l'application de téléaffichage d'informations sur le trafic ferroviaire destiné aux usagers où un grand nombre de points d'affichages est exploité. Les données relatives à la position de chacun des trains d'une région doivent être transmises au serveur régional en temps réel et permettre la mise à jour, également en temps réel, des horaires affichés sur les quais ou dans les bureaux des contrôleurs. La présente invention a pour but de pallier notamment cet inconvénient. A cet effet, l'invention a pour objet un décodeur de téléaffichage traitant des informations télédiffusées en temps réel par un serveur central via un réseau de communication, et comportant - un port de communication recevant les informations transmises par le réseau, - un module de communication stockant sur une unité de mémorisation les informations reçues par le port de communication et gérant le protocole de communication entre le décodeur et le serveur, - un module maître ayant pour fonction d'activer les modules à mettre en communication au sein du décodeur, et d'assurer la communication entre ces modules, - un module élaborant des scénarios d'affichage correspondant à des séquences d'images déterminées, à partir des informations reçues et de commandes émises par le module maître, pour restituer les images sous la forme de pages cycliquement remises à jour, - un module de gestion des scénarios analysant et interprétant les trames des images reçues du serveur via le module de communication d'une part, et assurant d'autre part le maintien de la communication entre le module de communication et le serveur, et - un module d'affichage permettant d'afficher les images sur un périphérique de visualisation à une cadence imposée par le module maître (10). Le décodeur peut comporter en outre un module d'horloge permettant d'envoyer l'heure courante à un module destinataire déterminé à intervalle de temps déterminé. I1 peut comporter en outre également une carte graphique disposée en sortie du module d'affichage permettant d'adapter l'affichage à un périphérique de visualisation déterminé. Cette carte graphique est par exemple une carte permettant l'affichage de texte et d'images de qualité photographique compatible des standards informatiques en matière de visualisation d'images. L'invention a en outre pour objet un terminal de téléaffichage comportant un décodeur couplé à un périphérique de visualisation. Le périphérique de visualisation est par exemple un téléviseur standard et la carte graphique est une carte permettant l'affichage de texte et d'images de qualité photographique compatible des standards informatiques en matière de visualisation d'images. Enfin, l'invention a également pour objet un système de téléaffichage d'informations télédiffusées en temps réel par un serveur central via un réseau de communication, caractérisé en ce qu'il comporte une pluralité de terminaux selon l'une quelconque des revendications, organisés en réseau autour du serveur central (2), gérant localement les évènements graphiques les évènements logiques étant relégués au niveau du serveur central. Un avantage de la présente invention est d'autoriser tout à la fois des commandes à distance et des possibilités locales d'affichage selon un dialogue intelligent entre un serveur et une pluralité de points d'affichage selon des scénarios prédéterminés. Ces scénarios correspondent par exemple à des séquences d'images déterminées se présentant sous la forme de page d'informations affichées sur un moniteur ou écran TV standard. Les images s'affichent d'un coup, cycliquement, page d'écran par page d'écran. Elles sont diffusées en temps réel du serveur vers les différents points d'affichage qui gèrent eux-mêmes l'enchaînement des pages. L'architecture modulaire du décodeur selon l'invention permet de scinder le fonctionnement du décodeur en deux ensembles fonctionnels distincts , un premier pour la définition des scénarios et un deuxième pour l'affichage des pages. Une telle solution permet de s'affranchir des protocoles de liaison avec le serveur. Le décodeur selon l'invention se comporte comme un tampon physique disposé entre le serveur et l'afficheur dans lequel une logique autonome traite l'image reçue pour la présentation et le rafraîchissement permanent de l'image à afficher. Le niveau local est très puissamment structuré pour gérer de multiples évènements graphiques (plusieurs scénarios qui coexistent et prennent le contrôle sur simple commande). Les évènements "logiques" sont relégués au niveau central, c'est-à-dire au niveau du serveur. Selon l'invention, un grand nombre de terminaux peuvent être ainsi gérés en temps réel par un seul serveur. Enfin la présente invention permet la compatibilité de la vidéo avec les standards informatiques en matière de visualisation d'images (VGA, EGA,...). D'autres avantages et caractéristiques de la présente invention apparaîtront plus clairement à la lecture de la description qui suit, faite en référence aux figures annexées qui représentent - la figure 1, un schéma synoptique de l'architecture d'un décodeur de téléaffichage selon l'invention, - la figure 2, un schéma synoptique illustrant le fonctionnement du module maître du décodeur selon l'invention, - la figure 3, un schéma synoptique d'illustrant le fonctionnement du module de gestion de scénarios d'un décodeur selon l'invention, - la figure 4, un schéma synoptique illustrant le fonctionnement du module "scénario" du décodeur selon l'invention, - la figure 5, un schéma synoptique illustrant le fonctionnement du module d'affichage du décodeur selon l'invention, et - la figure 6, un schéma synoptique illustrant le fonctionnement du module d'horloge du décodeur selon l'invention. Sur ces figures, les éléments homologues sont désignés par le même repère. Le décodeur selon l'invention reçoit du serveur les informations nécessaires à la composition de l'image à afficher et valide par l'interprétation d'une liste d'un nombre déterminé de paramètres, l'intégrité de ces dernières. Il peut recevoir ainsi une ou plusieurs images, les stocker en mémoire, et enfin les afficher selon le mode d'utilisation et le scénario d'affichage prédéfini. La capacité de stockage du décodeur n'est pas limitée et permet le cas échéant la mémorisation d'images déjà composées. Les principales fonctionnalités du décodeur selon l'invention peuvent se résumer en trois phases principales - la première phase consiste à la connexion au réseau via une interface de communication gérant les protocoles, les commandes et les donnée, et l'interprétation ; - la deuxième phase consiste à la réception et l'interprétation des données reçues du réseau permettant la préparation des pages selon un scénario programmé ; et - la troisième phase consiste à l'affichage des pages par l'afficheur via une carte de visualisation ou carte graphique (driver) à polices de caractères résidentes et/ou programmables. L'architecture d'un décodeur 1 selon l'invention est illustrée à la figure 1. Le décodeur 1 est délimité par une ligne fermée discontinue. Le décodeur 1 reçoit les informations transmises par un serveur 2 via un réseau de communication 3, par exemple le réseau X25, par l'intermédiaire du port de communication 4 du décodeur 1. Les données reçues via ce port de communication 4 sont transmises à un module de communication 5 qui assure l'interface avec le serveur 2. Ce module 5 stocke sur une unité de mémorisation, non représentée, telle qu'un disque, les informations reçues et gère le protocole de communication entre le serveur 2 et le décodeur 1. Les informations sont ensuite transmises du module de communication 5 à un module de gestion de scénarios 6 assurant l'interface entre le module de communication 5 et un module d'affichage 7. Les signaux de sortie du module d'affichage 7 sont ensuite transmis vers un afficheur 8 tel que par exemple un moniteur qui peut recevoir par exemple soit directement des informations au format VGA ou par l'intermédiaire d'une carte de visualisation 9 DRIVER, adaptée au type d'information à afficher et au type d'afficheur utilisé. Le fonctionnement détaillé du décodeur 1 selon l'invention est décrit ci-après en regard des figures 2 à 6. Le fonctionnement du module maître 10 est décrit ci-après en référence à la figure 2. Il a pour fonction d'activer tous les modules listés dans son fichier de paramètres, puis d'assurer la communication entre les différents modules lli. Le module maître 10 émet des commandes CMDE sous la forme de fichiers à destination des modules Ili et reçoit au retour l'état STATUS de ces derniers sous forme de fichiers. D'autre part, ce module 10 peut exécuter des fichiers de commande. Au démarrage, le module maître 10 trouve dans le fichier des paramètres le nombre de modules à gérer ainsi que les données concernant ces modules. Tous les modules lli se trouvent dans un sous répertoire. Pour chaque module lli, le fichier des paramètres spécifie le nom du répertoire et le nom du fichier à exécuter pour lancer le module lli. En fin de chargement des modules lli ou en actionnant une commande extérieure de démarrage sur le module 10, ce dernier envoie une commande de démarrage à chacun d'eux. Les modules lli peuvent suspendre leur exécution sur réception d'une commande d'arrêt. Le module maître 10 envoie cette commande à tous les modules lli quand une commande d'arrêt extérieure est actionnée. Enfin, les modules lli sont désactivés sur réception d'une commande de fin d'exécution. Avant désactivation, tous les fichiers de données du répertoire du module maître 10 sont effacés. Le module maître 10 envoie cette commande à tous les modules lli quand une commande extérieure de fin d'exécution est actionnée. Le fonctionnement du module scénario 12 d'un décodeur selon l'invention est décrit ci-après en référence à la figure 3. Le module scénario 12 détermine la séquence d'exécution de l'affichage des pages selon un cycle donné et le mode d'affichage. Ces derniers correspondent chacun à l'exécution d'un scénario prédéfini 13 se présentant sous la forme d'un fichier. La structure très modulaire du décodeur 1 selon l'invention permet de scinder son fonctionnement en deux parties distinctes. La première partie concerne la définition des scénarios. Un scénario prédéfini 13 comporte par exemple des instructions du type "afficher la page P1 pendant x secondes, puis afficher la page P3 pendant y secondes, etc..." Les numéros de page Pn et les temporisations x, y sont des paramètres du programme exécuté par le module scénario 12. Le module scénario 12 permet d'exécuter un scénario prédéfini de façon cyclique. Ce cycle permet d'envoyer des ordres à des modules. Ces ordres seront interprétés par le module destinataire 14. De la sorte, un nouveau module 14 avec une syntaxe spécifique pourra être géré par le module scénario 12 sans modification de celui-ci. Le module scénario 12 est actif sur réception d'une commande de démarrage émise par le module maître 10. Le fichier des paramètres de fonctionnement est chargé dans le module 12 par cette commande. Le fichier relatif à un scénario prédéfini 13 est rechargé à chaque cycle. Ce fichier peut ainsi être changé à n'importe quel moment. Dès que le scénario 13 courant est fini, un nouveau scénario est pris en compte. Sur réception d'une commande d'arrêt émise par le module maître 10, l'exécution du module 12 est suspendue. Sur réception d'une commande de fin d'exécution émise par le module maître 10, le module scénario 12 termine son exécution. Au-dessus du scénario dit "applicatif", figure un scénario dit scénario "système" dont les fonctions sont les suivantes - surveillance de la connexion au point d'entrée du réseau local (X25), - relance et reconnexion automatiques continuelles - mise au noir des écrans en cas de prolongation de la déconnexion (la temporisation étant paramétrable), et - régénération de son propre système après un nombre déterminé de tentatives et de temporisations. Le scénario "système" est ouvert à d'autres fonctionnalités d'alarme locale ou non locale, de déroutement sur des lignes de secours. En ce qui concerne l'affichage des pages, le fonctionnement est issu d'évolutions successives d'une version de base qui était initialement prévue pour gérer des graphismes DRCS (abréviation anglo-saxonne signifiant "jeu de caractères dynamiquement redéfinissables"), sur des bornes publiques et qui composait des pages entières en puisant dans des mémoires vives RAM, les unités graphiques à assembler. Une innovation importante apportée à cette version consiste à charger dans la mémoire vive des polices de caractères DRCS en guise d'unité de graphisme, ces polices étant optimisées en taille d'occupation mémoire. C'est donc la fonction "générateur de caractères" qui est ainsi intégrée à une architecture de réseaux de type notamment X25. Dès ce premier niveau, le décodeur 1 selon l'invention bénéficie d'une souplesse de programmation complète : une maquette d'affichage nouvelle peut être créée à l'aide d'outils de composition du marché en quelques heures, une police de caractères complète en moins de huit jours sans aucune programmation spécifique autre que celle du scénario d'une part et des commandes correspondantes du serveur d'autre part. A partir de là et une fois l'affichage définitivement en service, il ne reste plus qu a substituer progressivement dans la plus absolue compatibilité des versions successives, à la page créée et au scénario 13 qui lui correspond, les particularités et surtout les optimisations spécifiques à l'applicatif. En effet, l'image codifiée graphiquement zone par zone au niveau du serveur 2 serait trop lourde en cas de transfert permanent en temps réel. Dans les applicatifs où cela se justifie, quelques optimisations simples à intégrer dans l'architecture et extrêmement efficaces permettent de réaliser le compactage nécessaire à la version de "télécommunication" de l'image. Ce compactage peut être réalisé à l'aide d'un module non représenté dédié au compactage dont un premier niveau consisterait à ne transférer au décodeur 1 que la partie variable de l'image, le fond d'écran étant associé par l'interpréteur à la page du scénario concerné. Ce compactage est compatible aux différents applicatifs. Dans un second niveau, le compactage consiste à pousser le premier niveau encore plus loin en tenant compte du comportement de la page en fonction de l'applicatif. Le fonctionnement du module de gestion de scénarios 6 d'un décodeur selon l'invention est décrit ci-après en référence à la figure 4. Ce module analyse et interprète les trames des images reçues du serveur 2 via le module de communication 5 du décodeur 1. Les trames sont reçues et acquittées par le module de communication 5 et transmises aux module de gestion de scénarios 6 dans un fichier 15 (TRA-xxx). La communication entre le module de communication 5 et le module de gestion de scénarios 6 se fait à travers un jeu de fichiers de commandes (CMDE) et d'états (STATUS). D'autre part, le module de gestion de scénarios 6 assure le maintien de la communication entre le module de communication 5 et le serveur 2. Les états de connexion (STATUS) reçus du module de communication 5 sont analysés et une action appropriée est exécutée pour rétablir la connexion en cas de rupture de celle-ci. La communication entre le module de gestion de scénarios 6 et le module maître 10 est basée sur le même principe que la communication entre le module de gestion de scénarios 6 et le module de communication 5. Au lancement du module 6, celui-ci lance le module de communication 5. Ce dernier doit se trouver dans un sous-répertoire du module de gestion de scénarios 6. La connexion au serveur 2 est demandée sur réception d'une commande de démarrage émise par le module de communication 5. La procédure de connexion est gérée à l'aide d'un automate d'état fini. Sur réception d'une commande d'arrêt émise par le module maître 10, une commande de déconnexion est transmise au module de communication 5. Sur réception d'une commande de désactivation émise par le module maître 10, la commande de désactivation est transmise au module de communication 5 et le module de gestion de scénarios 6 termine son exécution. Pendant la phase de communication établie, le module de gestion de scénarios 6 analyse les trames (TRA-xxx) reçues du serveur 2 via le module de communication 5 et distribue les pages (PAGE 1) mises en oeuvre par les différents scénarios. Le fonctionnement du module d'affichage 7 d'un décodeur 1 selon l'invention est décrit ci-après en référence à la figure 5. Ce module 7 permet d'afficher des codes vidéotex et des images sur un périphérique d'affichage 8. Les périphériques d'affichage peuvent être un téléviseur 50 Hertz, 100 Hertz, un écran VGA,... Plusieurs cartes graphiques (DRIVER) 9 peuvent être utilisées notamment une carte d'affichage commercialisée par la demanderesse sous la dénomination AMPH. Cette carte permet un affichage d'images de qualité photographique sur un téléviseur standard tout en restant compatible des standards informatiques en matière de visualisation d'images (VGA, EGA,...). La définition des images affichées sur le téléviseur est de 768 x 288 pour seize couleurs et de 384 x 288 pour 256 couleurs. Cette dernière est utilisée par le module d'affichage 7. Le module 7 est actif sur réception d'une commande de démarrage émise par le module maître 10. Au démarrage du module 7, le fichier de paramètres de fonctionnement est chargé. Sur réception d'une commande d'arrêt émise par le module maître, l'exécution du module 7 est suspendue. Sur réception d'une commande de fin d'exécution émise par le module maître 10, le module 7 termine son exécution. Un module horloge 16 peut être intégré au décodeur 1 selon l'invention. Le fonctionnement du module horloge est décrit ciaprès en référence à la figure 6. Le module horloge 16 permet d'envoyer l'heure courante à un module destinataire 14 via un fichier (HORLOGE) également représenté à la figure 5. Le module 16 accepte deux commandes, une pour valider l'envoi de l'heure, une autre pour l'inhiber. Le module d'horloge 16 est actif sur réception d'une commande de démarrage émise par le module maître 10. Au démarrage du module 16, le fichier des paramètres d'horloge 17 est chargé. Sur réception d'une commande d'arrêt émise par le module maître 10, l'exécution du module 16 est suspendue. Sur réception d'une commande de fin d'exécution émise par le module maître 10, le module d'horloge 16 termine son exécution. Un module lli peut demander au module d'horloge 16 de valider l'envoi des informations d'heure au module destinataire 14 spécifié dans le fichier des paramètres par un paramètre correspondant au module destinataire 14. La commande de validation est active. Les commandes de prise en compte de l'heure sont par exemple envoyées au module destinataire 14 selon des intervalles de temps déterminés réguliers. Un module lli peut demander au module d'horloge 16 d'inhiber l'envoi des informations d'heure au module destinataire 14 spécifié dans le fichier des paramètres par le paramètre relatif au module destinataire 14. La commande de validation est alors désactivée. REVENDICATIONS 1. Décodeur (1) de téléaffichage traitant des informations télédiffusées en temps réel par un serveur central (2) via un réseau de communication (3), caractérisé en ce qu'il comporte: - un port de communication (4) recevant les informations transmises par le réseau (3), - un module de communication (5) stockant sur une unité de mémorisation les informations reçues par le port de communication (4) et gérant le protocole de communication entre le décodeur (1) et le serveur (2), - un module maître (10) ayant pour fonction d'activer les modules (lli) à mettre en communication au sein du décodeur (1), et d'assurer la communication entre ces modules (lui), - un module (12) élaborant des scénarios d'affichage correspondant à des séquences d'images déterminées, à partir des informations reçues et de commandes émises par le module maître (10), pour restituer les images sous la forme de pages cycliquement remises à jour, - un module de gestion des scénarios (6) analysant et interprétant les trames des images reçues du serveur (2) via le module de communication (5) d'une part, et assurant d'autre part le maintien de la communication entre le module de communication (5) et le serveur (2), et - un module d'affichage (7) permettant d'afficher les images sur un périphérique de visualisation (8) à une cadence imposée par le module maître (10). 2. Décodeur (1) selon la revendication 1, caractérisé en ce qu'il comporte en outre un module d'horloge (16) permettant d'envoyer l'heure courante à un module destinataire (14) déterminé à intervalle de temps déterminé. 3. Décodeur (1) selon l'une quelconque des revendication 1 et 2, caractérisé en ce qu'il comporte en outre une carte graphique (9) disposée en sortie du module d'affichage (7) permettant d'adapter l'affichage à un périphérique de visualisation (8) déterminé. 4. Décodeur (1) selon la revendication 3, caractérisé en ce que la carte graphique (9) est une carte permettant l'affichage de texte et d'images de qualité photographique compatible des standards informatiques en matière de visualisation d'images. 6. Terminal de téléaffichage , caractérisé en ce qu'il comporte un décodeur (1) selon l'une quelconque des revendications 1 à 5 couplé à un périphérique de visualisation (8). 7. Terminal selon la revendication 6, caractérisé en ce que le périphérique de visualisation (8) est un téléviseur standard et en ce que la carte graphique (9) est une carte permettant l'affichage de texte et d'images de qualité photographique compatible des standards informatiques en matière de visualisation d'images. 8. Système de téléaffichage d'informations télédiffusées en temps réel par un serveur central (2) via un réseau de communication (3), caractérisé en ce qu'il comporte une pluralité de terminaux selon l'une quelconque des revendications 6 et 7, organisés en réseau autour du serveur central (2), gérant localement les évènements graphiques ; les évènements logiques étant relégués au niveau du serveur central.