FR2648974A1 - Dispositif de communication entre plusieurs equipements, du genre bus serie multiplexe - Google Patents

Abstract

Un réseau de communication peut être constitué d'un bus série multiplexé interconnectant plusieurs équipements, chacun par l'intermédiaire d'un coupleur. Dans un coupleur gérant, on définit une table de configuration TCNF, désignant des tables de contexte TCNX, de canal telles que TGCl, et de description telles que TDEG. Dans un coupleur abonné (ou en plus dans un coupleur gérant), la table de configuration TCNF désigne une table d'accès aux données TADA, pointant dans un bloc de tampon de données en mémoire MBDA. Les mécanismes d'exploration de ces tables sont entièrement inscrits en mémoire morte dans des unités incorporées au coupleur. Ceci permet, en liaison avec l'usage des décodeurs numériques de bus, et de coupleurs pour le reste totalement interchangeables, d'assurer la compatibilité du dispositif de communication avec plusieurs types de bus série asynchrones opérant sur des milieux de transmission semblables, à des cadences d'horloge voisines, et avec une structure semblable d'échange d'informations, d'une manière transparente pour les équipements connectés.

Description

Dispositif de communication entre plusieurs équipements, du genre bus série multiplexé
L'invention concerne les moyens électroniques de transmission d'informations, en particulier à bord des véhicules militaires.

Pareils véhicules sont destinés à comprendre une grande variété d'équipements, consacrés les uns aux fonctions essentielles de déplacement du véhicule, d'autres à des fonctions essentielles pour son application, comme par exem plue la commande des systèmes d'armes que comportent le véhicule, d'autres enfin à des fonctions de service comme celles d'un calculateur de bord, ou bien d'organes de transmission.

La tendance actuelle est à intégrer tous ces équipements dans un réseau de communications, qui peut comporter plusieurs sous-réseaux interconnectés. Réaliser de tels réseaux pose des problèmes considérables, compte tenu notamment de la grande diversité de besoins en communication des différents équipements concernés.

Par exemple, dans le cas d'un char de combat, on peut distinguer le châssis qui comporte des fonctions de déplacement du char, y compris sa suspension, et la tourelle où se trouvent le plus souvent concentrés les systèmes d'armes, associés à un calculateur de bord. En l'espèce, le problème de communication est encore compliqué par le mouvement de rotation relatif entre le châssis et la tourelle. Une solution envisageable consiste à prévoir une ligne de transmission omnibus dite "bus tourelle", une autre formant "bus châssis"r et une interconnexion entre les deux avec joint tournant au niveau d'un répéteur séparateur de bus, lequel peut aussi assurer la liaison avec certains équipements particuliers du char.

On connaît déjà des structures particulières dites "bus série multiplexé", qui conviennent pour les applications dont il s'agit. Toutefois, les contraintes techniques rencontrées à bord de véhicules militaires tels que des chars, liées à la contrainte économique d'éviter un coût prohibitif, font que l'on a jusqu'à présent recherché à réduire autant que possible le coût des éléments individuels ou "coupleurs" servant à interconnecter les équipements du véhicule avec le ou les bus.

Diverses autres contraintes pèsent sur ce genre d'application.

Par exemple, un bus série multiplexé possède en règle générale un fonctionnement asynchrone. Mais certains équipements exigent pour leur bon fonctionnement une transmission d'informations en temps réel. L'incorporation de ces "fonctions temps réel" dans un système de transmission asynchrone est d'ores et déjà une chose assez délicate.

L'ensemble des contraintes rencontrées amène naturellement l'homme de l'art à concevoir des coupleurs spécifiques, qui sont adaptés pour satisfaire les contraintes initiales rencontrées, en permettant de minimiser le coût global du dispositif de transmission.

Cependant, la Demanderesse a remarqué que ceci finit par poser des problèmes pratiques considérables, que la présente invention vient résoudre.

L'une des observations à la base de l'invention, faite parla
Demanderesse, est que les systèmes de bus actuellement envisagés au niveau international sont assez divers, tout en n'offrant a priori aucune compatibilité directe entre eux.

I1 est apparu alors que le recours à une combinaison spécifique de moyens particuliers permettait d'obtenir une bien meilleure évolutivité dans le temps des dispositifs de communication en question, et ceci non seulement en conservant le même type de bus, mais aussi en passant d'un type de bus à un autre, lorsque cela est nécessaire.

Le dispositif de communication proposé est du type comportant - un milieu de transmission, - au moins un coupleur gérant, comprenant une isolation galvanique à transformateur, montée entre ledit milieu et une unité d'émission/réception, connectée à une unité de gestion possédant un bus interne qui communique avec au moins une mémoire et un circuit de base de temps, - des coupleurs d'abonné, comprenant une isolation galvanique à transformateur, montée entre ledit milieu et une unité d'émission/réception, connectée à une unité de transfert d'abonné reliée à au moins une mémoire ainsi qu'à une interface vers un équipement associé, - tandis que l'unité de gestion du coupleur gérant est associée à un moniteur d'enchaînement des échanges, propré à définir sur ledit milieu une trame de communication asynchrone, du type bus série multiplexé, où chaque échange d'informations comporte une phase de commande, laquelle peut être suivie d' une phase de transfert de données.

Comme déjà indiqué, de tels dispositifs ont été jusqu'à présent conçus en liaison étroite avec une structure particulière de bus, voire même avec des compromis qui les rendaient insusceptibles de fonctionner dès qu'on souhaitait apporter des modifications significatives à la structure des communications.

Selon l'invention, les unités de transfert d'abonné sont en principe rendues totalement interchangeables fonctionnellement entre elles. I1 en est de même pour la ou les unités de gestion des coupleurs gérant. Lorsqu'elles existent, les parties-abonné de ces unités de gestion sont également interchangeables avec les unités de transfert d'abonné.

Le moniteur d'enchaînement des échanges est contenu dans des tables de gestion associées au coupleur gérant. L'adressage de destination des blocs de données est réalisé exclusivement à l'aide d'une table d'accès aux données associée à chaque coupleur d'abonné, le cas échéant au coupleur gérant. Le mécanisme d'analyse des tables de gestion est inscrit en mémoire fixe dans l'unité de gestion du coupleur gérant. Le mécanisme d'analyse de la table d'accès aux données est à chaque fois inscrit en mémoire fixe dans l'unité de transfert du coupleur abonné concerné.

Ceci permet la compatibilité du dispositif de communication avec plusieurs types de bus série asynchrones opérant sur des milieux de transmission semblables, à des cadences d'horloge voisines; et avec une structure semblable d'échange d'informations, d'une manière transparente pour les équipements connectés. Ceci est vrai notamment pour le bus "Digibus" utilisé en France, et auquel la Demanderesse a activement collaboré, aussi bien que le bus dit "1553" issu d'une norme militaire d'un autre pays.

Très avantageusement, il est associé à chaque coupleur une table de configuration. Le mécanisme d'analyse de cette table de configuration est également inscrit en mémoire fixe dans l'unité de gestion du coupleur gérant, ou dans l'unité de transfert du coupleur abonné concerné, et la table de configuration définit la structure des autres tables incorporées au coupleur.

D'autres caractéristiques et avantages de l'invention apparaitront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels - la figure 1 est un exemple de bus multiplexé utilisé dans une application militaire - la figure 2 est le schéma de principe d'un coupleur gé rant - la figure 3 est le schéma de principe d'un coupleur d'abonné - la figure 4 est un schéma fonctionnel illustrant le travail d'un coupleur gérant - la figure 5 est un diagramme illustrant le mécanisme préparatoire au fonctionnement d'un coupleur gérant - la figure 6 est un diagramme illustrant le mécanisme préparatoire au fonctionnement d'un coupleur abonné - la figure 7 est un diagramme illustrant le fonctionnement courant d'un coupleur gérant ; et - la figure 8 est un diagramme illustrant le fonctionnement courant d'un coupleur abonné.

Les dessins annexés comportent pour l'essentiel des éléments de caractère certain. Ils sont donc à considérer comme in corporés. à la description, et pourront non seulement servir à mieux faire comprendre celle-ci, mais aussi contribuer à la définition de l'invention le cas échéant.

L'exemple de dispositif de communication de la figure 1 est placé dans le cadre d'un char, dont on sait qu'il comporte un châssis et une tourelle.

Pour des raisons de sécurité connues de l'homme de l'art, on prévoit dans un tel char deux bus séparés l'un BT pour la tourelle, et l'autre BC pour le châssis. En mode normal, ces deux bus sont interconnectés par un répéteur séparateur de bus RSB, qui fait partie du bus tourelle, et se trouve relié par un joint tournant JT au bus châssis.

Au bus tourelle BT est connecté un coupleur gérant principal
CG0-T, ainsi qu'un coupleur gérant de secours CG1-T, susceptible de prendre le relais du premier en cas de défaillance.

S'y trouvent également connectés directement des équipements utilisateur ou abonné, pourvus de coupleurs abonné CAB1-T et CAB2-T.

Le bus tourelle reçoit encore, au niveau du répéteur séparateur de bus, des coupleurs abonné CAB3-T, destinés par exemple à un détecteur laser, et CAB4-T, destinés à l'appareil dit "Arcuremètre", et qui sert à mesurer la flexion du canon principal du char. Le répéteur séparateur de bus peut encore se voir muni d'une prise externe PE. I1 communique à travers le joint tournant JT avec le bus châssis BC, qui possède lui aussi un coupleur gérant de secours CG2-C, ainsi que des coupleurs abonné tels que CAB5-C et CAB6-C.

Cette application donne une idée de la complexité des dispositifs de communication associés à des systèmes d'armes.

Les deux bus BT et BC n'en forment normalement qu'un seul, placé par exemple sous le contrôle du coupleur gérant CG0-R.

Si celui-ci est défaillant, le coupleur CG1-T peut prendre le relais.

Mais, pour différentes raisons, les deux bus peuvent être séparés, chacun fonctionnant alors sous le contrôle de son propre coupleur gérant, par exemple CG0-T pour le bus tourelle BT et CG2-C pour le bus châssis BC.

On désignera maintenant par BSM le bus série multiplexé utilisé selon l'invention. Dans la suite, on suppose que l'application concernée ne comporte qu'un seul bus, mais en principe avec deux lignes, comme on le verra plus loin.

La figure 2 fait apparaître le schéma de principe d'un coupleur gérant. Celui-ci est relié par une isolation galvanique à deux transformateurs IGT aux deux lignes physiques du bus BSM. Après l'organe IGT, on trouve une double unité d'émission/réception UER. Celle-ci est suivie d'un modem
MDM, dont on peut considérer aussi qu'il soit incorporé à l'unité d'émission/réception.

Dans de nombreux cas, il sera intéressant que les coupleurs comportent systématiquement un décodeur numérique de bus.

De tels appareils ont été proposés pour des applications utilisant certains des bus, mais ils n'étaient jusqu'à présent utilisés là où les circonstances ne l'imposaient pas, du fait par exemple que le digibus déjà mentionné possède une structure particulière des messages ne nécessitant pas toujours un décodeur numérique de bus.

En sortie du modem, on trouve l'unité de gestion UGC, associée à une horloge à quartz HOR qui est également reliée à d'autres circuits qui la nécessitent. L'unité de gestion
UGC communique avec un bus interne de coupleur gérant BIG, qui peut être associé à un microprocesseur MPG, tel que le modèle 68000 de MOTOROLA.

Ce bus interne BIG communique avec un circuit de base de temps BTG, ainsi qu'à des mémoires vive MVG et fixe MFG.

Dans un coupleur gérant, on trouve aussi au niveau des mémoires un tampon TAG destiné à la transmission d'un signal d'interruption IRQ, par exemple pour des "requêtes internes" coupleur/hôte.

Pour le reste, le bus interne BIG communique avec un tampon de données TDG, vers un bus extérieur d'hôte BEH. En parallèle, un tampon TCG est prévu pour les signaux de contrôle normalement associés au bus, et qui sont ici séparés simplement pour faciliter la compréhension.

La figure 3 illustre le schéma de principe d'un coupleur d'abonné. On retrouve, reliées au bus BSM, les unités IGT et UER (le modem étant ici supposé incorporé à cette unité).

Le coeur du coupleur d'abonné est l'unité de transfert d'abonné UTA, associée à une horloge HOR, et communiquant avec un premier bus interne BIA1 muni d'une mémoire vive MVA et d'une mémoire fixe MFA.

I1 est prévu un second bus interne BIA2 communiquant avec des tampons TDA et TCA dont le fonctionnement est analogue à ceux des tampons TDG et TCG de la figure 2.

On relèvera toutefois que le tampon TDA comporte ici une sélection 8/16 bits, destinée à permettre l'ajustement des tailles de transfert des tampons vis-à-vis du type de microprocesseur utilisé par l'équipement hôte. Enfin, les deux bus internes BIA1 et BIA2 sont interconnectés par l'intermédiaire d'un tampon interne d'abonné TIA.

La figure 4 fait apparaître, dans le cas d'un coupleur gérant, les différentes tables associées à celui-ci selon l'invention.

En partie gauche se trouve cette fois l'équipement hôte, qui est en général un calculateur dans le cas d'un coupleur gérant.

En partie droite se trouve le bus série multiplexé.

On suppose dans cette description détaillée que le coupleur gérant est également capable d'une fonction d'abonné, ce qui est vrai dans la très grande majorité des cas.

Les blocs de données en mémoire, qu'il y a lieu d'échanger entre le bus et le calculateur hôte sont donc stockés dans une mémoire vive MBDA. Celle-ci est généralement subdivisée en "tampons", qu'il y a lieu de considérer comme des unités logiques de transfert, et non comme des mémoires tampons telles que celles décrites en référence aux figures précédentes.

L'adressage de cette mémoire MBDA s'effectue exclusivement sous le contrôle d'une table d'accès aux données émises ou reçues, TADA.

Le coupleur comporte par ailleurs une table de configuration
TCNF, dont on verra plus loin le rôle.

Un coupleur gérant comporte en outre une table des contextes
TCNX, qui peut viser parmi une ou plusieurs tables de programme-canal telles que TGCl pour un canal 1, TGC2 pour un canal 2, etc...

Les tables de programme-canal agissent sur une table de description des échanges TDEG, définissant les actions sur le bus.

Sont également prévus des organes de compte-rendu des communications.

Ceux-ci comprennent tout d'abord un organe CRAI servant au compte-rendu des actions immédiates. Dans le cas d'un coupleur abonné, il s'intéressera uniquement à ce qui se passe au niveau de la table d'accès aux données TADA. Dans le cas d'un coupleur gérant, il s'intéressera aussi à ce qui se paisseau niveau de la table de description des échanges TDEG.

Cette dernière table peut enfin, par l'intermédiaire d'un autre organe CRER, faire compte-rendu au calculateur hôte des erreurs non masquées, c'est-à-dire des erreurs qui sont à lui communiquer.

L'homme de l'art comprendra que le schéma de la figure 4 concerne l'ensemble des fonctionnalités, que l'on trouve dans un coupleur gérant.

Pour un coupleur d'abonné, les tables TCNX, TDEG, TGC1,
TGC2 disparaissent, de même que l'organe CRER.

I1 est maintenant fait référence à la figure 5. Cette figure décrit l'initialisation d'un coupleur gérant par son calculateur hôte, comme indiqué en 50.

Les étapes 51 à 55 consistent d'une façon générale à charger des tables à des emplacements choisis par le calculateur hôte.

La première étape 51 consiste en le chargement de la table de configuration, laquelle indique les adresses de toutes les autres tables que devra utiliser le coupleur gérant, et à déterminer les registres de configuration dudit coupleur.

L'étape 52 consiste à charger dans une table d'accès aux données, pour chaque échange déterminé d'informations, l'adresse d'un bloc de contrôle de ces informations.

L'étape suivante 53 consiste à charger dans les tables des contextes : contextes de fond et contextes d'insertion.

Le contexte de fond désigne, pour la trame de fond, l'adresse du programme-canal à exécuter, le numéro de bus souhaité pour la transmission globale et dans quels cas un rangement d'un compte-rendu d'erreurs doit être exécuté.

Le contexte d'insertion correspond à un autre programmecanal comprenant nécessairement un début et une fin d'exécution avant de retourner dans le contexte de fond.

L'homme de l'art comprendra que le contexte de fond définit le fonctionnement de base du ou des bus, tandis que le contexte d'insertion correspond à une tâche spécifique à effectuer.

L'étape 54 consiste alors à charger, suivant le nombre de contextes que l'on désire pouvoir traiter, la définition de l'enchaînement des échanges contenus dans les différents programmes-canal.

L'étape 55 consiste à charger la table de description des échanges', pour définir les fonctions modulaires ou instructions d'échanges individuelles que devra pouvoir effectuer le coupleur gérant (numéro d'échange, traitements de l'échange, d'erreurs détectées, types d'échanges, notamment).

Toutes les tables sont ainsi convenablement remplies sous le contrôle du calculateur hôte.

L'étape 57 consiste alors à commander le démarrage de l'unité de gestion UGC du coupleur gérant.

Après l'initialisation interne de celui-ci, avec les autres tests et autres fonctions connus de l'homme de l'art, l'étape 58 consiste à communiquer à ce coupleur gérant UGC l'adresse de départ de la table de configuration, où il pourra trouver la structure de toutes les autres tables.

Ces transferts d'informations d'adresses sont utiles car toutes les informations des différentes tables décrites ci-dessus sont contenues dans la mémoire vive MVG de la figure 2, pour un coupleur gérant normal.

Elles pourraient être, en variante, contenues dans la mémoire fixe MFG, pour des gérants simplifiés utilisés dans certaines applications où le coupleur gérant ne comporte pas de microprocesseur dédié.

Après cela, l'étape 59 consiste en des traitements répéti tifs faisant intervenir la table des descriptions des échanges et la table d'accès aux données.

I1 est maintenant fait référence à la figure 6, qui décrit l'initialisation d'un coupleur d'abonné. Celle-ci est un peu plus simple que la précédente.

En effet, après l'étape 60, on trouve en 61 le chargement de la table de configuration, puis en 62 le chargement de la table d'accès aux données. Ces opérations se passent sensiblement comme précédemment.

En 63 intervient le démarrage de l'unité de transfert d'abonné UTA, avec ses contrôles internes.

En 64, l'équipement hôte donne à cette unité de gestion un ordre de mise en service, accompagné de l'adresse de départ de la table de configuration en mémoire vive (MVA) ou en mémoire morte (MFA figure 3).

La suite est illustrée schématiquement par l'étape 65 qui consiste alors en des traitements répétitifs sur la table d'accès aux données.

Là encore, le chargement des tables peut être effectué soit en mémoire vive si l'équipement hôte comporte un microprocesseur, susceptible d'adresser celle-ci, soit en mémoire morte si l'équipement hôte ne comporte pas de microprocesseur. Dans ce dernier cas, le numéro d'abonné intervient par programmation dans la mémoire fixe MFA.

L'homme de l'art comprendra, et c'est là un avantage essentiel de l'invention, qu'après les opérations d'initialisation décrites en référence figures 5 et 6, le fonctionnement du bus passe entièrement sous le contrôle des coupleurs.

La figure 7 illustre ce qui se passe pour un coupleur gérant.

Les premières étapes sont le reflet de son dialogue précédent avec l'équipement hôte.

On retrouve en 701 l'initialisation interne du coupleur gérant, puis en 702 l'accès à la table de configuration, à une adresse indiquée par l'équipement hôte. Dans cette table, le coupleur gérant va trouver son numéro d'abonné (le cas échéant) et l'adresse de départ de toutes les autres tables qu'il devra utiliser.

L'étape 703 consiste en une analyse de la table des contextes par l'unité de gestion UCG. On admet ici que le contexte désigné porte le rang i.

A l'étape 704, l'unité UCG va alors explorer la table de gestion i ainsi définie par le contexte, et y trouver un pointeur vers une instruction de départ.

On retrouve alors le fonctionnement proprement répétitif de gestion du bus.

Celui-ci commence par l'étape 710 qui est l'exécution d'une instruction en cours. Deux cas peuvent se présenter - si cette instruction est une instruction interne ou "non bus", après son exécution, on passe immédiatement à l'étape 711 qui consiste en une incrémentation du pointeur d'instruction - si, au contraire, cette instruction concerne le bus, alors va se dérouler la suite des opérations 721 et suivantes.

L'étape 721 consiste à analyser la table de description des échanges. L'unité de gestion va y trouver un message bus à engendrer, ainsi que des traitements orientés gérant ("traitements - gérant") qu'il devra effectuer.

L'étape 722 consiste à envoyer sur le bus le message ainsi défini, qui va essentiellement consister en une demande à l'intention d'un ou plusieurs coupleurs, en principe assorti d'un accusé de réception.

A l'étape 723, le coupleur gérant va faire comme les coupleurs abonnés, c'est-à-dire lire sa table d'accès aux données selon le mot de commande associé au message transmis.

Dans cette table se trouvent l'adresse du tampon de données concernées, désignant l'emplacement des données en question dans la mémoire MBDA (figure 4), ainsi que l'indication de traitements orientés abonné ("traitements - abonné") associés.

En 724 se produit alors un échange de données sur le bus.

En 725, le coupleur gérant réalise les traitements - abonné de fin d'échange.

Et en 726 il réalise les traitements - gérant de fin d'échange, qui vont se traduire par l'élaboration de comptesrendus d'actions et d'erreurs à destination de son équipement hôte, comme exposé à propos de la figure 4.

Après cette dernière opération 726, on retourne à l'étape 711 qui incrémente le pointeur d'instruction, et le cycle recommence.

La figure 8 illustre le cas d'une unité de transfert d'abonné, dont le fonctionnement est naturellement plus simple.

On retrouve en 801 et 802 des étapes d'initialisation interne, et d'accès à la table de configuration, respectivement.

L'étape 802 comporte la désignation d'un numéro d'abonné, ainsi que des adresses de départ des autres tables.

Ensuite, le coupleur d'abonné procède à l'étape 820, qui consiste en une écoute du bus, pour déterminer si cet équipement se trouve "adressé", c' est-à-dire qu'il circule sur le bus un message comportant un en-tête désignant le coupleur associé à cet équipement, par son numéro d'abonné.

Si la réponse est non, on retourne en 820.

Si la réponse est oui, on effectue en 823 une lecture de la table d'accès aux données selon le mot de commande du message circulant sur le bus.

La table d'accès aux données donne alors l'adresse du tampon de données concerné, pointant vers l'emplacement de ces données dans la table MBDA (figure 4, mais pour un coupleur abonné seulement), accompagné des traitements orientés abonné.

En 824 se produit un échange de données sur le bus comme précédemment.

Enfin, en 825, le coupleur d'abonné va procéder à des traitements d'abonné de fin d'échange, qui pourront ce traduire par l'envoi d'un compte-rendu à l'équipement hôte, si celuici le permet, par l'intermédiaire d'un organe CRAI tel que celui de la figure 4 (restreinte au cas d'un coupleur abonné).

La structure qui vient d'être décrite offre des avantages essentiels, en ce sens qu'elle permet a priori de concevoir une application pour un système bien déterminé, comme le char de la figure 1, d'une telle manière qu'elle soit rendue totalement indépendante du type de bus concerné. On peut ainsi prévoir un char qui fonctionne soit avec un bus de type digibus, soit avec un bus de type 1553, au choix. Le passage d'un type de bus à l'autre consiste simplement en l'échange des coupleurs de l'équipement concerné, en fait même seulement de leurs unités de gestion, respectivement unités de transfert d'abonné puisque c'est dans celles-ci que se trouvent logés les mécanismes d'analyse des différentes tables utilisées pour le fonctionnement de l'ensemble du système.

L'usage d'un décodeur numérique de bus contribue à la sécurité, en permettant sans difficulté le passage d'un type de bus à un autre, même si ceux-ci ont des structures de messages qui leur donnent des contraintes physiques différentes quant aux distances entre équipements, longueurs de câble, et autres difficultés connues de l'homme de l'art.

Les coupleurs sont aussi rendus totalement interchangeables, ce qui exclut tout compromis au niveau d'un coupleur particulier, tendant par exemple à diminuer le prix de ce coupleur en vertu du fait qu'il a peu de travail à effectuer, et ne nécessite pas une structure aussi sophistiquée que les autres. En effet, pareils compromis sont de nature à empêcher l'évolution ultérieure du matériel, notamment vers un autre type de bus.

Le dispositif proposé-présente d'autres avantages, notamment celui de permettre la déconnexion d'un équipement sous la commande d'un message circulant par le bus.

Il peut aussi procurer une fonction de contrôle du nombre de mots échangés sur le bus, et aussi la fonction essentielle de synthèse d'échanges. Comme le sait l'homme de l'art, le mode normal de fonctionnement d'un bus ici envisagé est asynchrone, c'est-à-dire que ce qui se passe au niveau des coupleurs est totalement indépendant, temporellement parlant, de ce que perçoit l'utilisateur.

Cet asynchronisme s'accompagne de l'écriture d'un mot de synthèse d'échange, associé à chaque bloc de données transmises. L'usage d'un tel mot de synthèse d'échange est indispensable en fonctionnement asynchrone. En effet, l'exploita- tion étant différée de la réception, il est nécessaire de garder une trace des conditions de transmission.

L'émission d'interruption simple ou prioritaire, à la diligence du coupleur gérant, permet un traitement synchronisé pour des messages particuliers, comme ceux concernant la transmission d'une heure commune aux différents équipements, ou encore de certaines anomalies.

Le contrôle du nombre de mots échangés permet de ne jamais déborder les tampons associés à chaque coupleur, et de signaler éventuellement une erreur grave.

Enfin, le système permet l'indication en permanence, à l'hôte, du tampon de mémoire en cours, ce qui est également une garantie de fiabilité et d'intégrité des informations mises à disposition de l'application par le coupleur.

La disposition proposée est également parfaitement compatible avec l'usage de répéteurs (tels que celui de la figure 1), ou bien de branchements à des bus complémentaires rapides, fonctionnant par exemple de 16 à 20 mégabits/secon de, comme les bus complémentaires dits digibus II, ou STA
NAG 3910 pour le bus de base 1553.

Là encore, la compatibilité ascendante peut être aisément prévue, en ce sens qu'il suffit simplement d'échanger les coupleurs associés aux équipements nécessitant ces bus com plémentaires pour un transfert de données à haute vitesse.

Si l'on revient maintenant à la version de base des bus, la Demanderesse a réalisé des coupleurs gérants sous forme de modules de circuits intégrés hybrides ne différant que par leur unité de gestion, que la Demanderesse appelle ADG pour le gérant digibus, ou AL53 pour le bus 1553-B.

Des coupleurs abonné peuvent être réalisés de la même manière, avec des unités principales portant la référence ADA pour le bus digibus, et AL53 pour le bus 1553.

On relèvera que les références sont identiques à chaque fois pour le bus 1553, le circuit intégré étant en mesure de traiter d'une manière simple aussi bien les fonctions de gérant que celles d'abonné, ce qui améliore encore la modularité du système.

Cette compatibilité digibus 1553 va plus loin.

Habituellement, le digibus comporte une ligne unidirectionnelle de procédures, et une ligne bidirectionnelle de données (et accusés de réception). Un coupleur gérant émet et reçoit sur les deux lignes (écoute locale pour la ligne de procédure).

Un coupleur abonné reçoit sur la ligne de procédure, tandis qu'il émet et reçoit sur la ligne de données.

Le bus 1553 peut se contenter d'une seule ligne bidirectionnelle pour les procédures (commandes), les accusés de réception et les données. Tout coupleur émet et reçoit sur cette ligne.

On aura observé que les coupleurs ici proposés sont toujours émetteurs et récepteurs pour 2 lignes. En effet, la Demanderesse a observé que, là où un digibus à deux lignes peut suffire, il faudrait souvent, à la place, un bus 1553 redondant, c'est-à-dire à deux lignes bidirectionnelles. Les coupleurs proposés permettent donc dans des conditions optimales la transition du digibus au bus 1553, par exemple.

Ceci vaut aussi pour deux lignes supplémentaires ultra-rapides, nécessaires en mode digibus II ou STANAG 3910 lorsque l'application nécessite une telle rapidité.

Claims (12)

Revendications

1. Dispositif de communication entre plusieurs équipements, comportant - un milieu de transmission (BSM), - au moins un coupleur gérant (CG), comprenant une isolation galvanique à transformateur (GT) montée entre ledit milieu et une unité d'émission/réception (UER), connectée à une unité de gestion (UGC) possédant un bus interne (BIG) qui communique avec au moins une mémoire < MVG, MFG) et un circuit de base de temps (BTG), - des coupleurs d'abonné (CA), comprenant une isolation galvanique à transformateur (ICT) montée entre ledit milieu et une unité d'émission/réception (UER), connectée à une unité de transfert (UTA) reliée à au moins une mémoire (MVA,

MFA) ainsi qu'à une interface (TDA, TCA) vers un équipement associé, - l'unité de gestion (UGC) du coupleur gérant étant associée à un moniteur d'enchainement des échanges, propre à définir sur ledit milieu une trame de communication asynchrone, du type bus série multiplexé, où chaque échange d'informations comporte une phase de commande, laquelle peut être suivie d'une phase de transfert de données, caractérisé en ce que la ou les unités de gestion (UGC) et les unités de transfert d'abonné (UTA) sont rendues totalement interchangeables fonctionnellement, en ce que le moniteur d'enchaînement des échanges est contenu dans des tables de gestion (TCNX, TGC1, TGC2, TDEG) associées au coupleur gérant, en ce que l'adressage de destination des blocs de données est réalisé exclusivement à l'aide d'une table d'accès aux données (TADA) associée à chaque coupleur d'abonné, en ce que le mécanisme d'analyse desdites tables de gestion (TCNX, TGC1, TGC2, TDEG) est inscrit en mémoire fixe dans l'unité de gestion (UGC) du coupleur gérant, et en ce que le mécanisme d'analyse de la table d'accès aux données (TADA) est inscrit en mémoire fixe dans l'unité de transfert (UTA) de chaque coupleur d'abonné, ce qui permet la compatibilité dudit dispositif de communication avec plusieurs types de bus série asynchrones opérant sur des milieux de transmission semblables, à des cadences d'horloge voisines, et avec une structure semblable d'échange d'informations, d'une manière transparente pour les équipements connectés.

2. Dispositif selon la revendication 1, caractérisé en ce qu'à chaque coupleur est associée en outre une table de configuration (TCNF), en ce que le mécanisme d'analyse de cette table de configuration est également inscrit en mémoire fixe dans l'unité de gestion, respectivement de transfert, du coupleur gérant, respectivement abonné, concerné, et en ce que la table de configuration définit la structure des autres tables incorporées au coupleur.

3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que lesdites tables sont remplies par l'équipement connecté au coupleur préalablement à la mise en ser vice de l'unité de gestion, respectivement de transfert, de celui-ci.

4. Dispositif selon la revendication 3, prise en combinaison avec la revendication 2, caractérisé en ce que la table de configuration (TCNF) contient l'adresse de départ des autres tables, et, le cas échéant, un numéro d'abonné.

5. Dispositif selon la revendication 4, caractérisé en ce que le démarrage d'une unité de gestion, respectivement de transfert, s'effectue sur ordre de l'équipement hôte, avec communication de l'adresse de départ de la table de configuration.

6. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les tables associées à un coupleur gérant comprennent - la table de configuration (TCNF), - une table des contextes (TCNX), - au moins une table de canal, (TGC1, TGC2), 'et - une table de description des échanges < TDEG).

7. Dispositif selon la revendication 6, caractérisé en ce que la table de description des échanges (TDEG) contient pour chaque échange une définition de celui-ci et la définition des traitements de gestion associés.

8. Dispositif selon la revendication 6, caractérisé en ce que la table d'accès aux données (TADA) contient la défini tion de chaque accès et la définition des traitements d'abonné associés.

9. Dispositif selon l'une des revendications précédentes, caractérisé en ce que lesdites tables sont contenues à chaque fois dans le coupleur concerne.

10. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le coupleur gérant possède également une fonction de coupleur abonné.

11. Dispositif selon l'une des revendications précédentes, caractérisé en ce que chaque unité d'émission/réception (UER) comporte, en réception, un décodeur numérique de bus.

12. Dispositif selon l'une des revendications précédentes caractérisé en ce que le milieu de transmission comprend deux lignes physiques, susceptibles de servir soit comme une ligne unidirectionnelle de commande et une ligne bidirectionnelle de données, soit comme deux lignes bidirectionnelles banalisées en redondance.