FR 2631763 A1 19891124 FR 8806966 A 19880518 PROCEDE POUR LA TRANSMISSION D'INFORMATIONS ENTRE DES ENTITES APTES A EMETTRE ET/OU A RECEVOIR DES INFORMATIONS. La présente invention concerne un procédé de transmission de type série multiplexée utilisable dans le cadre d'échanges d'informations entre les capteurs, les actionneurs et les automates programmables d'un processus. D'une manière générale, on sait que la communication entre les capteurs, actionneurs et automates programmables est généralement réalisée en fil à fil, ce qui représente des coûts de câblage importants sans réelle qualité de service. L'invention concerne plus particulièrement un système de communication mieux adapté qui réduit les coûts de câblage et qui permet la connexion de tout équipement industriel intervenant dans un système de contrôle et de commande et respectant un standard approprié. Son objectif est de concevoir des systèmes à structures modulaires évolutives à partir d'une gamme limitée de modules matériels qui permet d'envisager une production de masse afin de réduire les coûts. Cette structure modulaire évolutive doit permettre, par personnalisation logicielle, de répondre à un large éventail d'applications. - 2 - Dans un tel système, l'invention propose un protocole d'échanges d'informations entre des équipements de traite- ment d'informations de type automate programmable ou calcu- lateur industriel, des équipements d'instrumentation de type capteurs ou actionneurs plus ou moins intelligents et des interfaces opérateurs de type signalisations et comman- des individuelles d'actionneurs. Ce protocole doit être suffisamment général pour permettre d'interconnecter facilement des équipements qui peuvent être d'origines diverses afin de constituer un système de contrôle et de commande industriel sans problème de convi- vialité entre ces différents équipements. Les échanges d'informations s'effectuent au moyen d'une ligne apte à effectuer une transmission sans acquittement de type série multiplexée (par exemple un câble coaxial, fibres optiques), entre des composants du système (entités) permet- tant de recevoir ou d'émettre des informations en provenance ou à destination du support de communication et d'assurer des interfaces physiques et logiques entre les outils de ligne et les interfaces d'application, des outils de ligne permettant d'assurer l'adaptation des signaux entre les composants du système et la ligne, et d'un Arbitre de Bus. Les interfaces d'application peuvent être de type différent et peuvent, par exemple, consister en: - des équipements de réception (sorties logiques, analogi- ques, visualisations interfaces d'acquisitions d'informa- tions, équipements spécialisés...); - des équipements d'émission qui émettent des informations sur la ligne lorsqu'ils sont sollicités, ces informations pouvant consister en des acquisitions logiques ou analogi- ques de capteurs, des commandes issues d'automates pro- grammables, des échanges d'informations interautomates, des informations spécialisées nécessitées par l'applica- tion; -3- - des équipements de réception et d'émission pouvant être le résultat d'une combinaison d'équipements précédemment définis mais également, par exemple, des instrumentations intelligentes, des automates réflexes, des automates séquentiels, des calculateurs de conduite, d'aide à la maintenance, des équipements spécialisés nécessités par l'application. Chaque échange sur la ligne de transmission s'effectue par une succession: - d'une première trame pouvant par exemple comprendre un préambule, un mot de 16 bits,..., un bloc de contrôle, par exemple de type "CRC" (code cyclique de détection des erreurs de concordance des informa- tions),..., cette trame correspondant à la nomen- clature de l'information qui va être mise à disposi- tion sur la ligne, et - d'une seconde trame pouvant par exemple comprendre un préambule, une valeur, un bloc de contrôle, par exemple de type "CRC",..., cette trame contenant la valeur de l'information correspondant à cette nomenclature, ce mot représentant, en fait, le contenu de la donnée identifiée par sa nomenclature. Il convient de noter que l'usage d'un code cyclique, parti- culièrement fiable pour la détection des erreurs de concor- dance des informations échangées (par exemple de type "CRC"), permet de suppléer à l'absence de procédure d'ac- quittement dans les échanges d'informations. Ainsi, le couple nomenclature/information peut être: - le résultat d'une conversion analogique/numérique issue d'un capteur; - 4 - - une commande à destination d'un actionneur analogi- que; - une combinaison d'états logiques issus de cap- teurs; - une combinaison d'états logiques à destination d'actionneurs; une variable interne à un automate; - la valeur d'un paramètre; - toute combinaison logique de 16 bits. Les échanges d'informations sont rythmés par l'Arbitre de Bus qui diffuse cycliquement sur la ligne les nomenclatures, et s'effectuent selon le processus suivant: - l'Arbitre de Bus diffuse une nomenclature; - la station qui dispose de cette nomenclature se recon- naît; - la station qui s'est reconnue met l'information associée à la nomenclature qui vient d'être émise à disposition sur la ligne; - les stations qui veulent consommer cette information précédemment identifiée par sa nomenclature, lisent alors l'information émise par la station productrice; - l'Arbitre de Bus consomme également l'information afin de s'assurer que la transaction s'est effectuée correctement et le cycle continue par l'envoi d'une nouvelle nomencla- ture. Dans le cas d'un trafic cyclique, les fonctions de l'Arbitre de Bus peuvent donc se résumer comme suit: - la gestion de la nomenclature à émettre en fonction de la fréquence d'émission de cette nomenclature; - la vérification de l'émission de la donnée associée à cette nomenclature; le cadencement des trames; - l'émission de la nouvelle nomenclature; - le test de fonctionnement du système de transmission (détection d'erreurs, de collisions, du bon fonc- tionnement des équipements connectés). Les fonctions d'un récepteur d'informations peuvent se résu- mer comme suit: - la détection de présence d'une nomenclature sur la ligne; - la réception de cette nomenclature; - la reconnaissance d'utilité de réception d'une information associée à cette nomenclature ou l'attente d'une nouvelle nomenclature; - la réception de la donnée associée à la nomenclatu- re; - le rangement de la donnée associée à la nomenclature qui vient d'être lue. Les fonctions d'un émetteur d'informations se résument également comme suit: - la détection de la présence d'une nomenclature sur la ligne; - la réception de cette nomenclature; - la reconnaissance d'utilité d'émission de la donnée associée à cette nomenclature ou l'attente d'une nouvelle nomenclature; - la sélection de la donnée à émettre, associée à la nomenclature qui vient d'être lue; - 6 - - l'émission de la donnée associée à la nomenclature. Les émetteurs-récepteurs d'informations regroupent l'ensem- ble des fonctions des émetteurs et des récepteurs d'informa- tions, précédemment énumérées. De la description qui précède, il ressort que selon ce système de transmission: 10. Chaque équipement connecté à la ligne de transmission peut accéder à l'intégralité des informations qui circulent sur cette ligne. Par construction, l'effet- multiplicateur de signaux permet de mettre l'information émise par un abonné à disposition de tous les autres abonnés. Cette particula- rité donne virtuellement à chaque abonné l'impression d'être "connecté" à l'intégralité des informations qui circulent. Une information issue d'un capteur peut donc être acquise par tous les autres équipements connectés à la ligne, dès que cette information est émise sur la ligne, le câblage se limitant au raccordement du capteur sur une carte d'acquisition d'un abonné de la ligne. 25. Le pontage d'informations entre plusieurs équipements de traitement peut s'effectuer par la ligne car les débits et les temps de rafraîchissement sont, dans la majorité des cas, compatibles avec l'aspect temps réel des automates réflexes. L'ensemble des données échangées sur un tel système (essen- tiellement des échanges cycliques de variables d'état) peut être modélisé par une base d? données distribuées, dont chaque entité connectée sur la ligne de transmission conser- ve une copie des données l'intéressant, soit comme produc- teur, soit comme consommateur. -7- En fait, cette base de données distribuées, qui regroupe une collection de données regroupées par objet, est une repré- sentation abstraite des informations qui sont distribuées sur la ligne de transmission, pour faire en sorte qu'à chaque instant, tous les utilisateurs d'un objet doivent avoir la même perception de cet objet. Cette perception est modélisée par une trame qui s'applique à chaque type d'information qui doit être distribuée sur la ligne de transmission. Ce modèle permet d'assurer une correspondance biunivoque entre un objet de la base de données et une entité adressable d'un interface de liaison d'un appareil. Une telle correspondance est illustrée sur les tableaux I et II ci-après. 263 1 763 - 8 - TABLEAU I BASE DE DONNEES DISTRIBUEES OBJET - L Identification - nom: "A name" Description - Classe:"Class" - Period = (apériodique) - Type de données: (description du type) - Validation: "Valid" Etat t- Valeur codée TABLEAU II ENTITE LOCALE Données Objet Données Image L Identification nom: "A name" f Description Image Classe - Description I Period Utilisation Type de données CONFIGURATION LOCALE DE L'OBJET Configuration-identification Attribut Clef Description des données L Identification Nom Classe Période Type de données Description des données Utilisation CONFIGURATION DE L'ENTITE Classe (démarrage automatique commandé). "List Of" (références relatives à la configura- tion des données d'un objet pour chaque objet produit par l'entité). "List Of*" (références relatives à la configura- tion d'un objet pour chaque objet connu et non produit par l'entité). -9- Comme on peut le voir sur le tableau I, la trame des objets de la base de données comprend une liste d'attributs permet- tant d'identifier les objets et supportant des variables spécifiques de cet objet. Cette liste pourra plus particu- lièrement comprendre: Un attribut LI d'identification constitué par un entier de 16 bits, qui sert à identifier l'objet dans la ligne de transmission. Il représente l'identification utilisée de façon interne dans la ligne et dans la base de données. Un attribut de nom "Aname": cet attribut, de type chaine de caractères, sert à identifier les objets entre entités coopérantes. Cette identification peut également être utilisée. Un attribut de classe "class": cet attribut indique la classe de l'objet incluant une variable et une description. 20. Un attribut de période: cet attribut contient une valeur apériodique si l'objet ne doit pas être remis à jour pério- diquement, ou la valeur de la période de rafraîchissement requise. 25. Un attribut de type de données "Data type": cet attribut doit contenir le nom du type de données. Il définit à la fois la sémantique et les règles de codage de l'attribut de valeur codée. 30. Un attribut de validation "Valid", qui contiendra une valeur signalant une faute si l'objet n'est pas, sur le moment, disponible à un consommateur pour une raison quel- conque, par exemple pour une absence de fournisseur, ou une modification au cours de sa définition. Il convient cepen- dant de noter qu'un objet peut être valide dans la base de données alors qu'il est invalide pour un consommateur, par exemple en raison d'un défaut du consommateur. - 10 - Un attribut de Valeur Codée: cet attribut doit contenir, soit la valeur courante de l'objet, codée selon les règles définies par l'attribut "type de données" ou la valeur "indéfinie". La valeur courante est remise à jour périodi- quement ou au hasard, selon ce qui est défini dans l'attri- but de période. Cet attribut contient la dernière valeur envoyée sur la ligne à la suite d'un message IDDAT LPDU. Les informations qui doivent être mémorisées dans chaque entité locale utilisable par la base de données distribuées sont modélisées localement, au niveau de la couche de liaison, selon une configuration objet déterminée "configu- ration locale de l'objet" incluant les attributs suivants (tableau II): - un attribut de configuration et d'identification qui iden- tifie la configuration locale des données de l'entité, - un attribut de description de données qui contient les attributs statiques de la trame des objets de la base de données, à savoir: - l'attribut d'identification, - l'attribut de nom "A name", l'attribut de classe "class", * - l'attribut de période "period", l'attribut de type de données "Datatype", - un attribut de "description image" qui contient les attri- buts statiques des données image, - un attribut d'utilisation (fournisseur et/ou consomma- teur, ou aucun de ces deux modes). Les paramètres caractéristiques de chaque entité sont modélisés selon une configuration objet "configuration de l'entité" lui permettant de communiquer avec une autre - il - entité, cette modélisation faisant intervenir les attributs suivants: - un attribut de classe = démarrage automatique, démarrage commandé, - un attribut "List of" qui doit contenir la liste des références relatives à la configuration des données d'un objet, pour chaque objet produit par l'entité, - un attribut "List of* qui doit contenir la liste des références relatives à la configuration d'un objet pour chaque objet connu et non produit par l'entité. A chaque valeur "démarrage commandé" incluse dans la confi- guration d'une entité correspond un registre de commande organisé selon un objet de commande "commande" consommé par l'entité, cet objet comprenant les attributs suivants: - Attribut clef (field data reference) qui contient une référence locale à un objet consommé par l'entité, et Attribut démarrage "start" qui sert à valider le protocole d'introduction qui sera défini dans la suite de la des- cription; cet attribut est envoyé dans le réseau d'une façon analogue à celle de l'attribut valeur codée précé- demment mentionné. Il apparaît donc que chaque objet présente une classe spéci- fique. Les seules classes différenciées dans le mécanisme proposé sont: la VARIABLE et la DESCRIPTION. La mise à jour et le maintien de la base de données sont assurés par un protocole sans connexion. Chaque entité locale maintient une copie locale d'une partie utile corres- pondante de la base de données et met à jour, lorsque requi- se, la partie de la base de données qu'elle renferme. - 12 - Les principaux services rendus par la ligne de transmission aux différentes entités utilisatrices sont la commande de la mise à jour de la base de données, l'accès à l'image locale de cette base de données et la mise à jour des objets. La base de données est indépendante de l'emplacement physi- que des fournisseurs et des consommateurs de données. La relation entre un appareil et ses données produites et consommées peut être modifiée sans engendrer de transforma- tion de la base de données. En plus d'une copie partielle de la base de données, chaque entité maintient une image de données pour chaque objet produit qu'il consomme. Cette image, qui contient les infor- mations pour le transfert d'un objet à un dispositif, est modélisée selon une configuration comprenant les attributs suivants: - un attribut "Clef" qui doit contenir une référence à un objet utilisé par le dispositif, - un attribut "Use" qui doit contenir, soit la valeur "consommateur" si la valeur codée de l'objet doit être reçue par l'entité ou "Provider" si il doit être transmis, une valeur Both indiquant que la valeur codée doit être reçue et transmise, et une valeur indiquant que la valeur codée n'est pas à transmettre ni à recevoir, - un attribut "Valid" qui doit contenir la valeur "Faux" si l'objet n'est pas localement disponible, et "Vrai" dans le cas contraire; les raisons de l'invalidation comprennent notamment l'invalidation globale de l'objet (attribut de validité = Faux), une non conformité entre la description de l'objet donnée par l'entité émettrice et la description de l'objet souhaitée par l'entité locale, et des défail- lances locales, - 13 - - un attribut "Prochaine valeur fournie": si l'attribut "Use" de l'image est "Provider" ou "Both", cet attribut contiendra, soit la prochaine valeur à envoyer ou la valeur "indéfinie"; cette valeur est remise à jour par l'utilisateur local et peut être différente de la valeur codée de l'objet; la valeur de cet attribut doit être transmise à la ligne à la suite d'une instruction IDDAT LPDU en effectuant, de ce fait, la mise à jour de l'attribut valeur codée de l'objet. L'accès à la base de données est assuré par l'Arbitre de Bus qui constitue.une entité unique garantissant que la mise à jour de la base de données s'effectue selon les exigences de période et de précision spécifiées par les entités utilisa- trices. La difficulté, dans un tel système, est de garantir que producteur et consommateur de la même donnée sont d'accord sur les règles d'utilisation de la variable, sur sa syntaxe et sa sémantique, et ceci, quels que soient les évènements perturbant le réseau (coupure secteur d'une station, modifi- cation de configuration d'une station, insertion d'une nouvelle station): en aucun cas, une variable émise comme une chaîne de bits ne doit être interprétée par le receveur comme un nombre flottant ou toute autre chose différent d'une chaîne de-bits. Les solutions habituellement utilisées pour garantir la cohérence entre émetteur et receveur consistent: - à envoyer sur le réseau, pour chaque échange, en même temps la valeur de la variable et sa description syntaxique ou sémantique * ceci. présente l'inconvé- nient de charger le.réseau et de perdre de la bande passante, ce qui est bien souvent inacceptable; - à négocier, avant tout échange de variables, le contexte de communication entre les entités communi- - 14 - cantes, en établissant une connexion logique entre émetteur et receveur; ceci présente l'inconvénient de nécessiter un mécanisme de connexion complexe, et qui doit être établi pour toute association émetteur- récepteur(s) (plusieurs connexions possibles par produit); il s'avère que le coQt des protocoles de connexion et de l'entretien simultané de plusieurs connexions est prohibitif pour des produits simples raccordés à la ligne de transmission, ce qui est contraire au but recherché. L'invention a plus particulièrement pour but de résoudre ce problème de garantie de cohérence, grâce à un protocole sans contact préalable, ni acquittement, conçu de manière à économiser la bande passante de la ligne de transmission. A cet effet, on a tout d'abord pensé à utiliser une entité centrale connaissant la configuration du réseau (produits connectés et variables échangées) et capable de vérifier les configurations des produits connectés avant de les mettre en service sur le réseau et, éventuellement, de télécharger cette configuration. Cette entité peut être le contrôleur maitre si il existe, ou une entité indépendante dédiée, qui doit rester en permanence sur le réseau. Toutefois, cette solution présente de multiples inconvé- nients: Elle exige une entité gérant l'ensemble des configurations du réseau. Or, même si il faut, à un certain moment de la conception, une vue globale du réseau, les informations de configuration peuvent ensuite être éclatées entre diffé- rentes entit4s (plusieurs contrôleurs sur le réseau, plusieurs constructeurs), et il peut être pénalisant de regrouper ensuite ces informations dans une entité unique. Même si l'entité centrale existe dans la phase de concep- tion, il est pénalisant d'exiger une connexion permanente - 15 - de cette entité, pour gérer les évènements perturbant le réseau (coupure de secteur, remplacement de produit défaillant...). C'est la raison pour laquelle l'invention propose d'effec- tuer ce contrôle de cohérence avant toute mise en service, même dans le cas o il y a eu au préalable un contrôle en bureau d'étude à la génération, ce contrôle devant notamment permettre la communication entre les entités globalement configurées et, éventuellement, d'autres entités localement configurées (ajout de nouvelles entités sur un réseau globa- lement configuré). Bien entendu, ce contrôle de cohérence devra être effectué en utilisant les services non optionnels de la couche de liaison des entités, c'est-àdire en utilisant le mécanisme d'échange d'informations en diffusion sans acquittement. A la mise en service d'une entité, ce contrôle sera effectué entre une entité productrice et des entités consommatrices, par l'intermédiaire de la ligne. Il convient de noter toutefois que ce contrôle ne garantit pas que toutes les entités concernées par un objet aient le même descriptif de cet objet: il a uniquement pour but de garantir que seules les entités ayant le même descriptif de cet objet participeront à l'échange de l'objet. Compte tenu de ce qui précède, l'invention propose d'une façon générale un procédé pour la transmission d'informa- tions au moyen d'une ligne apte à effectuer une transmission de type série-multiplexée entre des entités aptes à émettre et/ou à recevoir des informations, en provenance et à desti- nation de la ligne, et d'assurer des interfaces physiques entre des interfaces d'application et la ligne, de telle sorte que chaque entité connectée à la ligne puisse accéder à la totalité des informations circulant sur cette ligne, l'ensemble des données échangées étant modélisé par une base - 16 - de données distribuées dont la mise à jour et le maintien sont assurés grâce au fait que chaque entité conserve et assure la mise à jour d'une copie locale de la partie utile correspondante de la base de données qu'elle renferme. Selon l'invention, ce procédé est plus particulièrement caractérisé en ce qu'il comprend, à chacune des mises en service d'une entité, un contrôle de cohérence dans le but de garantir que les entités productrices et consommatrices interprètent une information de la même façon, ce contrôle de cohérence faisant intervenir la génération par chacune des entités d'une information de validation, cette informa- tion signifiant un état invalide au moment de la mise en oeuvre du procédé et ne signifiant un état valide que si cette entité reconnaît un descriptif d'un objet de la base de données émis sur la ligne, et en ce que, seules les entités engendrant une information de validation signifiant un état valide, peuvent participer à l'échange de la valeur de l'objet. Compte tenu du fait que les phases de validation et d'inva- lidation font appel à un service d'échange non acquitté, on évite ainsi d'avoir à utiliser un système d'acquittement habituellement coQteux. Avantageusement, les entités engendrant une information de validation à l'état valide pour un même objet présenteront le même descriptif, ce descriptif commun étant figé et pouvant être échangé à tout moment pour permettre à de nouvelles entités de participer à l'échange. Par ailleurs, le descriptif émis sur la ligne de transmis- sion dans le cadre de ce contrôle de cohérence sera fourni par l'entité comprenant le descriptif global de l'objet, ce descriptif étant alors fourni sous la forme de données apériodiques, ou éventuellement périodiques. - 17 - Il apparaît clairement que dès que la description locale d'une entité est modifiée ou susceptible d'être modifiée, remise à zéro, reprise secteur, modification locale..., cette entité se retire de l'échange. Dans le cas o cette entité est consommatrice, elle peut se retirer sans perturber les autres entités participantes * (seuie son information de validation est à l'état invalide). Une entité productrice qui émet un signal de validation à l'état invalide doit suspendre la mise à jour, non seulement de sa mémoire-tampon servant à l'émission (buffer d'émis- sion), mais aussi des mémoires-tampon servant à la réception (buffer de réception) des entités réceptrices. Pour cela, elle invalide son buffer d'émission au niveau de la couche de liaison, ce qui invalide la mise à jour sur le réseau de la valeur. Cette invalidation est détectée par les entités réceptrices. Suite à cette détection (qui est garantie pour tout récepteur) toute entité réceptrice invalide localement l'objet. Pour invalider un objet, une entité consommatrice dispose de deux informations: - La détection d'un message d'invalidation du réseau (RPDAT d'invalidation) incorrect ou absent après réception d'un message IDDAT identifiant la trame de l'objet, le message (RP_DAT) du réseau devant, quant à lui, contenir les paramètres de l'objet, étant entendu qu'une invalidation d'une entité productrice non suivie d'erreur de transmission engendre un message RPDAT d'invalidation (entité productrice en service, donnée invalide) ou un RPDAT absent (pas de trame) (entité productrice hors service). - Optionnellement, un signal (time out) de surveil- lance du rafraîchissement du réseau (promptitude) 263 1763 - 18 - qui prend aussi en compte les absences de rafraî- chissement dues aux erreurs de transmission. Ces erreurs de transmission provoquent alors, soit un RP DAT absent, soit un RP DAT incorrect, soit l'absence de séquence ID_DAT/RP-DAT. L'entité consommatrice invalide obligatoirement un objet à la suite de la réception d'un RPDAT d'invalidation. L'entité productrice impose, quant à elle, l'invalidation globale en engendrant plusieurs messages RPDAT d'invalida- tion (au moins 3), de manière à être sûr que chaque entité consommatrice détectera au moins un RP DAT d'invalidation. La modification du descriptif d'un objet tout en garantis- sant la cohérence s'effectue en deux étapes: - une première étape consistant à invalider l'objet chez l'ensemble des entités concernées, à commencer par le producteur; - une deuxième étape qui intervient lorsqu'on s'est assuré que les entités concernées ont invalidé l'objet, cette étape consistant à introduire l'objet avec un nouveau descriptif. La diffusion d'un descriptif sur le réseau doit être effec- tuée par une entité et une seule. Le plus simple est alors que ce descriptif soit diffusé par l'entité productrice de l'objet. Il peut cependant exister des produits simples (modules d'entrée TOR) pour qui le stockage et la gestion 3e cette information sont d'une complexité prohibitive. Il est possi- ble de stocker le descriptif ailleurs (par exemple dans l'automate), à condition de respecter strictement les règles d'invalidation. Le descriptif stocké disponible doit être à tout moment conforme à la valeur émise par le producteur, et - 19 - une modification éventuelle du descriptif doit suivre une invalidation par le producteur. Lors d'un démarrage automatique ou contrôlé, l'algorithme d'introduction peut être déclenché par chaque entité à la suite d'un évènement local tel que, par exemple, une reprise secteur, après coupure ou une remise à zéro. Cette introduc- tion peut s'effectuer, soit automatiquement "mode démarrage automatique", soit après autorisation d'un tiers "mode démarrage commandé". Le mode de fonctionnement est défini par l'attribut de classe "démarrage" de l'objet et l'autorisation est donnée par l'écriture d'un mot de commande représenté par l'attri- but commande du dispositif et transmis par l'identifieur "command". Le mode "démarrage commandé" permet à un programme d'appli- cation spécialisé dans le contrôle de configuration, de lire ou de télécharger la configuration des données, les données et l'image des données pour chaque entité, de faire une vérification globale, et après, seulement, de provoquer le démarrage de l'entité. Il apporte une sécurité supplémentai- re en contrôlant les duplications d'identifieur des données avant collision sur le réseau. Le descriptif diffusé sur le réseau contient (entre autres) la période réseau des données, qui doit être cohérente avec la période réseau garantie par l'Arbitre de Bus dans sa table de scrutation. Il est possible d'utiliser un programme d'application optionnel, lié à l'Arbitre de Bus, de vérifier cette cohé- rence et de prendre une décision dans le cas d'une anoma- lie: soit de retirer les données de la table de scrutation, soit de modifier la table de scrutation en conséquence. - 20 - Comme précédemment mentionné, l'invention propose un proto- cole à exécuter par toute entité productrice ou consommatri- ce de données en vue de sa mise en service sur le réseau, en garantissant la cohérence de la description entre entités émettrices et entités consommatrices. Des modes d'exécution de ce protocole seront décrits ci- après, à titre d'exemples non limitatifs, avec référence aux dessins annexés dans lesquels: La figure 1 est un organigramme d'un protocole d'introduction devant être exécuté pour chaque donnée produite quand la description est mémorisée dans l'entité productrice; La figure 2 est un organigramme d'un protocole d'introduction qui doit être exécuté pour chaque donnée produite quand la description n'est pas en mémoire dans l'entité productrice (dans le cas o l'entité productrice n'est pas assez riche pour contenir son descriptif); La figure 3 est un organigramme d'un protocole d'introduction à exécuter pour chaque donnée consommée. Il convient de noter tout d'abord que chaque donnée produite par l'entité productrice implique l'exécution d'un algori- thme. Par ailleurs, l'entité doit gérer un identifieur produit pour la valeur de chaque donnée et un autre identi- fieur pour le descriptif de cette donnée. L'entité productrice doit être en outre capable d'engendrer des demandes de mises à jour apériodiques (instruction LUPDATE = instruction de demande à la couche de liaison d'effectuer une mise à jour apériodique). - 21 - Dans le cas o l'entité productrice possède le descriptif de la variable, la phase de démarrage de l'algorithme s'effec- tue lors d'une situation locale (démarrage, remise à zéro, reprise secteur, configuration) telle que l'entité ne peut pas garantir la cohérence de son état avec celui de ses correspondants, dans ce cas: l'attribut "Valid" de la donnée Image porte la marque "Faux"; - le buffer d'émission dans la couche de liaison de l'entité contenant la valeur de la donnée est invalide (instruction d'écriture en buffer L PUT, vide); - ce qui provoque l'émission sur le réseau d'un messa- ge RPDAT d'invalidation en réponse à un message IDDAT (trame transmise par l'Arbitre de Bus qui fournit le moyen d'accès à l'entité possédant la donnée associée). En même temps, le buffer d'émission de la couche de liaison affectée à l'entité, qui contient le descriptif de la donnée, est, lui aussi, invalide, de manière à éviter le déroulement simultané du protocole d'introduction par un consommateur. Si la classe de l'entité (attribut de classe "démarrage" de l'entité) est "démarrage automatique", ou si cette classe est "démarrage commandé" et que le mot de commande (attribut "commande entité" de l'entité) autorise le démarrage, l'algorithme exécute une phase suivante de l'algorithme consistant à garantir l'invalidation (émission d'un signal d'invalidation "flag") chez toutes les entités réceptrices, une des méthodes possibles est de transmettre plusieurs (valeur conseillée: 3) messages RPDAT présentant un contenu vide. Plusieurs algorithmes sont utilisables par l'entité productrice: la seule exigence est que ces algo- rithmes engendrent au minimum plusieurs messages RPDAT d'invalidation dans un temps déterminé. - 22 - La figure 1 montre un exemple d'un tel algorithme à exécuter pour chaque donnée produite quand la description est conte- nue dans l'entité productrice. Dans cet exemple, au bloc "état initial", l'image de la donnée est invalide. L'étape suivante est alors la lecture de l'attribut de classe "Class". Dans le cas o cet attribut contient l'information démarrage automatique "Auto-Start", le systè- me passe automatiquement à l'étape suivante. Par contre, si cette information est "démarrage commandé", le système ne passera à l'étape suivante qu'à la suite de l'émission d'une instruction de commande ("commande de démarrage = Vrai"). L'étape suivante doit comprendre l'émission d'un nombre prédéterminé (valeur conseillée: 3) de messages consécu- tifs RP_DAT d'invalidation. Ces messages peuvent être envoyés par le système en réponse aux scrutations cycliques de la variable par l'Arbitre de Bus, ou peuvent être provo- qués par une demande explicite du système (au cas o la variable n'est pas scrutée périodiquement, ou périodique- ment avec une période longue), par l'instruction "LUPDATE". L'émission du message d'invalidation est signalée par l'indication LSENT. Le système compte les indications LSENT et reste en phase d'invalidation tant que leur nombre est inférieur à la valeur prédéterminée. L'étape suivante consiste en une mise à jour du buffer de la couche de liaison en introduisant une description de la nouvelle variable. Ceci est alors exécuté à la suite de l'émission des instructions LPUT (saisie de la description de la variable) et LUPDATE (mise à jour de la description de la variable). Suite à la transmission de la nouvelle description signalée par l'indication LSENT, le système procède à la mise à jour - 23 - et valide (passage de l'attribut "Valid" de l'image de données à la valeur "Vrai") l'image de la nouvelle donnée. Dans le cas o, pour une raison locale, la variable se trouve invalidée (invalidation locale), le système réen- clenche l'algorithme depuis le départ (c'est-à-dire depuis l'état inital = image de la donnée invalide). Ce processus est engagé pour chaque évènement local mettant en doute la cohérence du descriptif local par rapport au réseau. Dans le cas o l'entité productrice ne possède pas le des- criptif de la variable, un algorithme doit être exécuté pour chaque donnée produite par cette entité, laquelle doit alors gérer un identifieur objet pour cette valeur et un identi- fieur consommé pour le descriptif de cette valeur. Dans ce cas, l'entité productrice n'a pas à gérer des deman- des de mises à jour apériodiques (instruction L UPDATE) pour cette fonction. Une entité du réseau gère le descriptif de la donnée et doit donc fournir un identifieur objet pour le descriptif. D'une façon analogue à la précédente, le démarrage de cet algorithme s'effectue à la suite de situations locales (démarrage, remise à zéro, reprise secteur, configura- tion...) telles que l'entité ne peut pas garantir la cohé- rence de son état avec celui de ses correspondants dans le réseau, l'attribut "Valid" de l'image de données indique l'information "Faux". Le buffer d'émission dans la couche de liaison de l'entité contenant la valeur de la donnée est invalidé (instruction d'écriture en buffer LPUT, vide), ce qui provoque l'émis- sion sur le réseau d'un message RPDAT d'invalidation en réponse à un message IDDAT transmis par l'Arbitre de Bus. 263 1763 - 24 - Cette invalidation est surveillée par l'entité qui gère le descriptif de la donnée, laquelle invalide, en conséquence, le buffer d'émission contenant le descriptif de la donnée (ceci, pour éviter le déroulement simultané du protocole d'introduction de la nouvelle donnée par un consommateur). La façon dont l'entité gérant le descriptif est informée de l'invalidation du producteur est fonction d'un programme d'application local qui assure la détection d'un signal RPDAT d'invalidation, qui surveille l'état de la station, etc... Si la classe de la station (attribut de classe "démarrage") de l'entité est "démarrage automatique", ou si cette classe est "démarrage commandé" et que le mot de commande (attribut "commande-entité") autorise le démarrage, l'entité exécute la phase suivante de l'algorithme. Cette phase consiste alors à garantir l'invalidation par le signal d'invalidation chez tous les récepteurs, en émettant au minimum le nombre prédéfini de signaux RP_DAT d'invalida- tion, après invalidation de la valeur et du descriptif. Plusieurs algorithmes sont possibles entre le producteur et l'entité gérant le descriptif: la seule exigence est que ces algorithmes génèrent au moins le nombre prédéfini de signaux RPDAT d'invalidation dans un temps déterminé. Un mode d'exécution d'un tel algorithme est illustré sur la figure 2. Comme dans l'exemple précédent, cet algorithme part d'un bloc "état initial" dans lequel l'image de la donnée est invalide, puis d'une seconde étape incluant la lecture de l'attribut de.classe. Dans le cas o cet attribut est "démarrage automatique", le système passera à la phase suivante. Par contre, si cet - 25 - attribut est "démarrage contrôlé", le système ne passera à l'étape suivante qu'à la suite de l'émission d'une instruc- tion de commande ("commande de démarrage = Vrai"). Cette étape comprend alors l'invalidation par l'entité productrice de son buffer d'émission. L'entité gérant le descriptif, après invalidation de ce descriptif, génère au moins le nombre prédéfini de demandes apériodiques de la valeur, qui engendreront un RP DAT d'invalidation (instruc- tion LSENT signal de données d'invalidation). La phase qui suit cette étape d'invalidation est une phase de mise à jour du buffer d'émission contenant le descriptif de la donnée avec la nouvelle description par une instruc- tion LPUT, description dans l'entité gérant le descriptif. Une demande de mise à jour apériodique de cet identifieur est générée par l'instruction L_UPDATE, description dans cette entité qui provoque la diffusion du descriptif sur le réseau. L'algorithme s'assure que ce descriptif a bien été reçu par l'entité productrice, sinon il repasse à la phase d'invali- dation. Sur réception du descriptif diffusé dans le réseau, le producteur traite le descriptif selon un algorithme local comparable à celui utilisé par une entité réceptrice. Selon le résultat du traitement, il valide (ou non) l'iden- tifieur de valeur de la donnée en mettant à jour le buffer d'émission par une instruction "LPUT, value" et marque l'attribut de validation de la donnée image à la valeur "Vrai". Comme précédemment mentionné, pour chaque donnée consommée, l'entité consommatrice doit implémenter un algorithme d'introduction. - 26 - A cet effet, l'entité doit gérer un identifieur produit pour la valeur et un identifieur consommé pour le descriptif de chaque donnée. L'entité consommatrice peut ou non être capable de générer des demandes de mises à jour apériodiques (suite à l'émis- sion d'une instruction L UPDATE). Tel que représenté sur la figure 3, l'algorithme d'introduc- tion part d'un état initial dans lequel l'attribut de validation de l'image de la donnée est à l'état invalide ou faux. Ceci se produit dans le cas de situations locales telles que démarrage, remise à zéro, reprise secteur, configuration... telle que l'entité ne peut pas garantir la cohérence de son état avec celui de ses correspondants. La mise à jour dans le buffer de réception est invalidée. Si la classe "Class" de l'entité (attribut de classe de départ de l'entité) est "démarrage automatique" "Auto- Start" et si le mot de commande (attribut "Command Start" de l'entité) autorise le démarrage, le système exécute la phase suivante de l'algorithme. Cette phase consiste à attendre la diffusion du descriptif (instruction de requête pour la diffusion du descriptif = LUPDATE) et lors de la réception "'Receive" de ce descrip- tif, à traiter ce descriptif selon un algorithme propre et à le comparer à ses propres informations de configuration. Si elle accepte le descriptif reçu du réseau, elle valide la réception de la valeur de la donnée et marque l'attribut de l'image de la donnée à la valeur "Vrai", sinon elle reste dans le même état. L'algorithme de traitement du descriptif dépend de l'implé- mentation et peut par exemple résulter des trois cas d'espè- ce suivants: - 27 - - L'entité possède un descriptif local complet. Elle compare le descriptif fourni par le réseau à son descriptif local et valide la donnée si ces deux descriptifs sont identi- ques et la laisse invalide si ces descriptifs sont diffé- rents. - L'entité possède un descriptif partiel. Dans ce cas, elle compare ce descriptif aux parties correspondantes du descriptif reçu du réseau, et complète les parties man- quantes à partir du descriptif fourni par le réseau. Dans ce cas, un traitement de configuration de l'entité peut être rendu nécessaire. - L'entité ne possède pas de descriptif. Dans ce cas, elle accepte le descriptif émis par le réseau et se configure en conséquence. Il convient de noter à ce sujet qu'il n'est pas nécessaire que l'entité mémorise le descriptif transmis par le réseau. Il suffit seulement qu'elle garantisse un traitement confor- me à ce descriptif. Par ailleurs, la demande de descriptif à l'initiative d'une entité consommatrice est notamment utile dans le cas de la mise en service de cette entité consommatrice, dans un réseau en fonctionnement. Si cette entité n'est pas capable de générer des demandes apériodiques, il conviendra alors d'utiliser un programme d'application surveillant les mises en service de la station pour engendrer la demande de diffu- sion du descriptif. Une réponse anormale (silence ou donnée d'invalidation) à une demande de descriptif signifie que l'entité productrice est invalide. L'entité consommatrice se met alors en attente de la mise en service du producteur. - 28 - Une entité consommatrice invalidera une donnée en provoquant le passage de l'attribut de la valeur "Valid" à la valeur "Faux" sur réception d'un message RP _DAT d'invalidation ou. éventuellement à la suite de la détection de plusieurs erreurs consécutives à la réception. - 29 - Revendications 1. Procédé pour la transmission d'informations au moyen d'une ligne apte à effectuer une transmission de type série-multiplexée entre des entités aptes à émettre et/ou à recevoir des informations, en provenance et à destination de la ligne, et d'assurer des interfaces physiques entre des interfaces d'application et la ligne, de telle sorte que chaque entité connectée à la ligne puisse accéder à la totalité des informations circulant sur cette ligne, l'ensemble des données échangées étant modélisé par une base de données distribuées dont la mise à jour et le maintien sont assurés grâce au fait que chaque entité conserve et assure la mise à jour d'une copie locale de la partie utile correspondante de la base de données qu'elle renferme, caractérisé en ce qu'il comprend, à chacune des mises en service d'une entité, un contrôle de cohérence dans le but de garantir que les entités productrices et consommatrices interprètent une information de la même façon, ce contrôle de cohérence faisant intervenir la génération par chacune des entités d'une information de validation, cette informa- tion signifiant un état invalide au moment de la mise en oeuvre du procédé et ne signifiant un état valide que si cette entité reconnaît un descriptif d'un objet de la base de données émis sur la ligne, et en ce que seules les enti- tés engendrant une information de validation signifiant un état valide peuvent participer à l'échange de la valeur de l'objet. 2. Procédé selon la revendication 1, caractérisé en ce que les phases de validation et d'invali- dation font appel à un service d'échange non acquitté. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que les entités engendrant une information de validation à l'état valide pour un même objet présentent - 30 - le même descriptif, ce descriptif commun étant figé et pouvant être échangé à tout moment pour permettre à de nouvelles entités de participer à l'échange. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que le descriptif émis sur la ligne de transmission dans le cadre du susdit contrôle de cohérence est fourni par une entité comprenant le descriptif global de l'objet, ce descriptif étant fourni sous la forme de données apériodiques ou périodiques. 5. Procédé selon l'une des revendications précéden- tes,- caractérisé en ce qu'une entité productrice qui émet un signal de validation à l'état invalide suspend la mise à jour, non seulement de sa mémoire-tampon servant à l'émis- sion, mais aussi des mémoires-tampon servant à la réception des entités réceptrices. 6. Procédé selon l'une des revendications précéden- tes, caractérisé en ce que l'invalidation d'un objet, par une entité consommatrice, s'effectue par la réception d'un message particulier du réseau. 7. Procédé selon la revendication 6, caractérisé en ce que ledit message présente un contenu vide ou une trame incorrecte ou absente. 8. Procédé selon l'une des revendications précéden- tes, caractérisé. en ce que l'invalidation d'un objet, par une entité consommatrice, s'effectue grâce à un signal de surveillance du rafraîchissement du réseau. - 31 - 9. Procédé selon l'une des revendications précéden- tes, caractérisé en ce qu'une entité productrice impose une invalidation globale en engendrant plusieurs messages d'invalidation. 10. Procédé selon l'une des revendications précéden- tes, caractérisé en ce que la modification d'un objet, tout en garantissant la cohérence, s'effectue en deux étapes: - une première étape consistant à invalider l'objet chez -l'ensemble des entités concernées, à commencer par le producteur - une deuxième étape qui intervient lorsque les entités concernées ont invalidé l'objet, cette étape consistant à introduire l'objet avec un nouveau descriptif. 11. Procédé selon la revendication 10, caractérisé en ce que la diffusion sur la ligne de transmis- sion du nouveau descriptif est effectuée par une entité et une seule.