FR2610157A1 - Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel - Google Patents

Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel Download PDF

Info

Publication number
FR2610157A1
FR2610157A1 FR8701017A FR8701017A FR2610157A1 FR 2610157 A1 FR2610157 A1 FR 2610157A1 FR 8701017 A FR8701017 A FR 8701017A FR 8701017 A FR8701017 A FR 8701017A FR 2610157 A1 FR2610157 A1 FR 2610157A1
Authority
FR
France
Prior art keywords
transmission
message
installation according
server
equipment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR8701017A
Other languages
English (en)
Inventor
Bernard Pons
Georges Le Navennec
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Dassault Electronique SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dassault Electronique SA filed Critical Dassault Electronique SA
Priority to FR8701017A priority Critical patent/FR2610157A1/fr
Publication of FR2610157A1 publication Critical patent/FR2610157A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/161Computing infrastructure, e.g. computer clusters, blade chassis or hardware partitioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

DANS UN SYSTEME EMBARQUE TEMPS REEL, ON PREVOIT UN SERVEUR 10 RELIE PAR DES COUPLEURS TELS QUE 12 ET 14 A DES BUS NUMERIQUES TELS QUE 13 ET 15. LE CONTROLEUR 10 EST RELIE A UNE MEMOIRE DE MASSE 11 QUI EST DIRECTEMENT ADRESSABLE, TELLE QU'UNE MEMOIRE VIVE SAUVEGARDEE, OU BIEN UNE MEMOIRE PROGRAMMABLE ET EFFACABLE ELECTRIQUEMENT. LES ECHANGES DE DONNEES ENTRE CHACUN DES EQUIPEMENTS ET LE SERVEUR SE REALISENT PAR DES LIAISONS LOGIQUES TELLES QUE CHAQUE EQUIPEMENT SE SENTE EN LIAISON AVEC UN SERVEUR VIRTUEL QUI LUI SERAIT PROPRE.

Description

Installation pour L'échange de données informatiques, en particulier Pour système embarqué temps réel.
L'invention concerne les systèmes informatiques, plus particulièrement les systèmes embarqués destinés à fonctionner en temps réel.
Les systèmes embarqués sont constitués d'équipements reliés entre eux par l'intermédiaire de liaisons numériques ou bus, telles que le Digibus de la Demanderesse, ou encore les bus 1553 ou AMINCI connues des hommes de 1tart. Ces systèmes embarqués sont soumis à deux contraintes essentielles : - le volume qu'ils occupent car, dans un système embarqué sur aéronef, la place est très limitée, et généralement définie une fois pour toutes; - la rapidité de fonctionnement : en temps réel, le système doit être en mesure de répondre dans un délai très court (typiquement quelques dizaines de microsecondes) aux requê- tes ou wstimuli" en provenance de l'extérieur.
Ces deux contraintes ont pour effet de limiter l'évolution des systèmes existants : d'une part la taille des logiciels devient de plus en plus grande; d'autre part, ils doivent traiter une quantité de données de plus en plus importante.
Or, ce besoin d'évolution dans le temps doit être satisfait sans modifier l'architecture physique des équipements individuels qui composent le système.
Pour pouvoir augmenter la capacité de travail de tous les équipements, il devient donc nécessaire de posséder un appareil, et en particulier une mémoire capable de stocker, restituer et modifier les informations utiles au bon fonctionnement du système. Ces informations peuvent être des parties de logiciel, des tables de constantes, ou des enregistrements d'anomalies, par exemple.
Les systèmes qui existent actuellement, fondés sur une mémoire de type disque dur ou bande magnétique, ne sont pas satisfaisants à l'égard des contraintes évoquées ci-dessus. En effet, leurs temps de réponse sont de l'ordre de la dizaine de milliseconde, donc très loin des quelques microsecondes ou dizaines de microsecondes requises pour le bon fonctionnement d'un système temps réel embarqué sur aéronef.
D'autre part, ces systèmes actuels sont de fonctionnement "mono-utilisateur". C'est-à-dire qu'ils sont incapables de renseigner plusieurs équipements de façon simultanée, à l'échelle des temps de réponse requis.
La présente invention vient apporter une solution à ce problême.
Un but de l'invention est de fournir un système informatique qui soit très rapide, pour pouvoir s'appliquer comme système embarqué temps réel.
Un autre but de l'invention est de fournir un tel système qui puisse satisfaire conjointement les demandes de plusieurs utilisateurs.
L'invention a également pour but de fournir un système capable de travailler avec une mémoire directement adressable.
Elle a aussi pour but de permettre que la mémoire de masse soit accessible en mode autonome par les différents équipements, tout se passant comme si chaque équipement disposait d'une mémoire de masse qui lui est propre.
Bien entendu, ceci doit être fait en conservant les performances, quel que soit le nombre d'équipements demandeurs, dans une limite fixée à l'avance.
L'invention a encore pour but d'apporter une solution à ces problèmes tout en observant une compatibilité aussi grande que possible avec les normes actuellement existantes, et notamment les normes dites ISO ainsi que GAM-T-103.
L'installation proposée pour l'échange de données informatiques, en particulier pour système embarqué temps réel, du type comprenant un organe serveur ou contrôleur, muni de moyens de mémoire de masse,estpropreà communiquer par l'intermédiaire d'au moins un bus numérique avec une multiplicité d'équipements utilisateurs.
Très généralement, cette installation se distingue selon l'invention par la combinaison de moyens suivante - les moyens de mémoire de masse sont constitués de mémoires entièrement adressables, en accès rapide et direct, - il est prévu une phase d'initialisation ou négociation permettant d'établir une liaison logique entre le serveur et l'un quelconque des équipements, et - les échanges de données entre cet équipement et le serveur peuvent ensuite s'effectuer dans le cadre d'une phase de communication ou transmission, utilisant ladite liaison logique, jusqu'à la rupture de celle-ci, cette phase de communication portant sur des enregistrements, qui sont chacun définis comme un ensemble d'informations accessibles à l'aide d'une clé.
Selon un autre aspect de l'invention, lesdites phases s'effectuent à l'aide d'un jeu prédéterminé de messages logiques, comprenant, au moins - un message de demande de transmission par un équipement, - un message d'acquittement d'une demande de transmission par le serveur, - un message du serveur indiquant qu'il est prêt à transmettre des données, - un message de demande de reprise de transmission, et - un message de demande d'interruption de transmission.
Avantageusement, ces messages ont en commun le fait qu'ils comprennent une partie de définition, puis une partie de code identifiant le mode d'adressage, l'opération à effectuer et le type d'accès requis, une partie indiquant le numéro de ressource attribuée, cette ressource définissant la liaison logique, et une partie formant clé d'accès à un enregistrement.
Dans un mode de réalisation plus particulier, il est prévu que le message de demande de transmission comprenne aussi l'adresse logique du récepteur, et le nom du fichier concerne.
Il en est avantageusement de même pour les messages d'acquittement et le message dont la signification est Prêt à transmettre.
Pour leur part, ces messages d'acquittement et de prêt à transmettre comprennent en outre une partie de réponse à la demande de transmission initiale, dans un mode de réalisation particulier de l'invention.
D'un autre côté, il est avantageux que les messages de demandes de reprise de transmission et de demandes d'interruption de transmission comprennent en outre une partie de compterendu de transmission.
Selon un autre aspect de l'invention, les messages de données comprennent une partie de contrôle, suivie des données proprement dites, lesquelles sont avantageusement limitées à un nombre prédéterminé de mots, pour chaque message de données.
De préférence, la partie de contrôle d'un message de donnée contient au moins le numéro de ressource et le numéro d'enregistrement en cours de transmission.
Selon encore un autre aspect de l'invention, tous les messages peuvent prendre, en position prédéterminée, un code choisi, les rendant inactifs, ce qui permet d'éviter la prise en compte d'informations erronées.
Dans la pratique, les échanges d'informations sur le ou les bus s'effectuent par "secteurs" qui forment des "tampons", chaque tampon étant constitué d'un secteur accompagné de ses mots d'identification et de contrôle.
Enfin, et selon un autre aspect important de l'invention, la mémoire de masse est avantageusement du type mémoire programmable et effaçable électriquement (EEPROM). Elle peut être aussi du type mémoire vive sauvegardée.
L'homme de l'art comprendra que l'invention offre un nouveau mode d'échange de données informatiques, nouveau mode que l'on peut mettre en oeuvre avec une installation telle que définie ci-dessus.
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 le schéma de principe d'une installation selon l'invention; - les figures 2A et 2B sont deux autres schémas montrant l'interconnexion avantageuse entre le serveur et les équipements, selon l'invention; - la figure 3 est un organigramme des différentes fonctions mises en oeuvre par le dispositif selon l'invention; - les figures 4, 5, 6, 7 et leurs sous-ensembles montrent de façon plus détaillée la structure et l'usage des messages dans le dispositif selon l'invention; - les figures 8 à 12 montrent différents modes de base pour l'échange de données dans l'installation selon l'invention; - les figures 13 à 16 sont des chronogrammes illustrant différents modes d'application de l'invention; et - les figures 17 à 22 sont des schémas d'automates utiles pour la mise en oeuvre de l'invention.
Les dessins annexés comportent à de nombreux titres des éléments de caractère certain. En conséquence, ils pourront non seulement servir à mieux faire comprendre la description ci-après, mais aussi contribuer à la définition de l'invention, le cas échéant.
Sur la figure 1, le serveur de l'installation selon l'invention est désigné par la référence 1.
Ce serveur 1 comporte comme unité de traitement un contrôleur 10, constitué avantageusement d'un microprocesseur de la famille 68000 vendu par MOTOROLA. Ce contrôleur 10 communique avec une mémoire de masse 11, par un bus interne.
La mémoire de masse ll peut être une mémoire vive sauvegardée. On supposera dans la suite qu'il s'agit d'une mémoire de type EEPROM, c'est-à-dire électriquement effaçable et programmable. Des structures de mémoires de ce genre ont déjà été décrites, pour une application particulière, dans la Demande de Brevet NO 85 00 671 déposée par la Demanderesse le 17 janvier 1985 et publiée sous le ND 2 576 131.
En utilisant une mémoire de masse de ce genre, il advient que tous les mots de la mémoire de masse sont directement adressables, et ce avec un temps d'accès constant. Ceci est une amélioration sensible par rapport aux mémoires du type bande ou disque dur, pour lequel le temps d'accès à un mot dépend aussi du temps de déplacement de la tête de lecture sur la bande ou le disque.
La structure des informations enregistrées dans la mémoire peut être définie de la manière suivante un "secteur" est le plus petit ensemble d'informations servant de base aux échanges; un "tampon" est une unité d'informations de données échangées sur le bus. C'est donc un secteur accompagné de ses mots d'identification et de contrôle, un "bloc" est la plus petite entité que l'on peut écrire séparément, une "page" est un ensemble de mots qui constitue un sousmultiple de la taille totale de la mémoire de masse, un "enregistrement" est un ensemble d'informations accessibles à l'aide d'une clé, un fichier n est un ensemble d'enregistrements regroupés de façon logique.
Comme précédemment indiqué, le contrôleur 10 est un microprocesseur de la famille 68000, par exemple le modèle 68020, de MOTOROLA. Il est muni d'une mémoire de travail ou mémoire vive de 16 kilos octets, et d'une mémoire de programme qui est par exemple du type REPROM effaçable par ultra-violets, d'une capacité de 64 kilos octets.
La puissance de calcul du contrôleur et le temps d'accès à la mémoire de masse peuvent alors être rendus compatibles avec les performances d'un bus dont le débit est de 1 Megabits par seconde.
Sur la figure 1, le contrôleur 10 est muni d'un coupleur 12 vers un premier bus numérique 13 et d'un second coupleur 14 vers un second bus numérique 15.
Le bus 13 est par exemple une liaison de type Digibus, associée à un coupleur du type MAB (Module Autonome de Bus) commercialisés par la Demanderesse.
La seconde liaison numérique du bus 15 peut être réalisée à travers un coupleur série 14, cette liaison étant alors du type RS 232.
En variante, on peut utiliser tout type de liaison numérique comme les bus ARINC ou 1553, déjà mentionnés à travers des coupleurs du commerce ou développés par la Demanderesse.
Ainsi, le contrôleur 10 est en mesure d'assurer les fonctions de dialogue avec le ou les bus numériques par l'intermédiaire des coupleurs d'entrée/sortie. Il est, également en mesure d'acquérir les informations en contrôlant la validité des blocs.
Le contrôleur 10 assure encore l'écriture/lecture dans la mémoire de masse 11, par l'intermédiaire d'une interface mémoire spécialisée, adaptée aux caractéristiques du composant mémoire utilisé.
Pour la gestion de la mémoire de masse, le contrôleur 10 est muni d'un logiciel propre à effectuer les fonctions suivantes - lecture physique de la mémoire de masse, par page ou par bloc, - lecture d'un fichier, soit entier, soit par paquets d'enregistrements, soit par enregistrement, - écriture physique dans la mémoire de masse, par page ou par bloc, - écriture dans un fichier, entier, par paquets d'enregistrements ou par enregistrement.
Les fichiers contenus dans la mémoire de masse peuvent être l'un des trois types suivants : fichier séquentiel; fichier indexé, fichier séquentiel-indexé. De plus, les enregistrements composant ces fichiers sont de taille variable.
La figure 3 résume les fonctions réalisées par le contrôleur.
Il gère la liaison numérique 30 par l'intermédiaire du coupleur 31 et de l'interface de coupleur 32. Ces fonctions peuvent être réalisées de manière classique.
Interviennent alors les fonctions 33 et 34 consistant à gérer un protocole dit de transmission, et un protocole dit de négociation, respectivement, qui sont des aspects essentiels de l'invention.
Ensuite, en 35, le contrôleur 10 analyse les commandes issues de ces protocoles. En 36, il va assurer en conséquence la gestion logique des fichiers, d'où il s'ensuit en 37 une gestion physique des fichiers.
Les fonctions 35 à 37 sont de nature classique, et pourront aisément être mises au point par l'homme de l'art,après qu'il aura pris connaissance des éléments 33 et 34 décrits ci-après.
Avant de décrire en détail la structure des différents messa ges utilisés par ces fonctions, il est fait référence aux figures 2A et 2B.
La figure 2A montre la liaison physique du serveur 1 par le bus 13 (par exemple) avec des équipements 2-1, 2-2, 2-3.
Le but de l'invention est de transformer cette liaison pour qu'elle devienne une liaison logique, comme illustré sur la figure 2B, telle que pour chacun des équipements 2-1, 2-2, 2-3, tout se passe comme si celui-ci disposait d'un serveur virtuel respectif 1-1, 1-2, 1-3, qui ne correspond qu'avec lui.
La figure 4 illustre un message de demande de transmission, noté DEM. Ce message, désigné par la référence numérique 40, comprend dix mots de deux octets chacun.
Le premier mot 41 du messsage comporte 9 bits réservés, suivis de 7 bits constituant définition du message.
On précisera dès maintenant que tous les messages comportent 7 bits de définition, qui, lorsque tous ses bits sont à 0, rend le message inactif. Selon une caractéristique intéressante de l'invention, ceci permet d'éviter la prise en compte d'informations erronées.
Un véritable message de demande DEM sera donc caractérisé par le fait que ses 7 bits de définition possède des zéros partout, sauf à son bit le moins significatif.
Le second mot 42 du message 40 comporte un bit initial, le plus significatif, qui indique si l'adressage est physique ou logique. En mode de fonctionnement normal de l'ins- tallation selon l'invention, l'adressage est logique. Des adressages physiques ne seront utilisées que pour la maintenance, avec des équipements spéciaux. Le premier bit est à 0 pour un adressage physique et à 1 pour un adressage logique.
Les deux autres bits indiquent que le niveau d'adressage s'effectue par enregistrement, par bloc d'enregistrement ou par fichierwentier, suivant qu'ils sont à 00, 01 ou 10.
Le reste du premier octet est réservé.
Le second octet du mot 42 indique un code opération sur huit bits. Il peut prendre les valeurs suivantes 00000001 pour l'ouverture en lecture, 00000010 pour ltouverture en modification, 00000011 pour une lecture aléatoire, 00000100 pour une lecture séquentielle, 000000101 pour une écriture aléatoire, 00000110 pour une écriture séquentielle, 00000111 pour un effacement aléatoire, 00001000 pour un effacement séquentiel, 00001001 pour un positionnement aléatoire, 00001010 pour un positionnement séquentiel, 00001011 pour une fermeture de liaison logique, 00001111 pour une demande des paramètres de transmission.
Le troisième mot du message 40 est un numéro de ressource attribué, codé en binaire sur un octet, ce qui autorise le numéro de ressource, donc de liaison logique allant de 0 à 255.
Le mot suivant 44 peut avoir deux types de structures, qui définissent d'une manière différente la clé d'accès à un enregistrement.
S'il s'agit d'un enregistrement d'un fichier séquentiel, la structure est celle de la figure 44A. Le premier octet est le numéro d'enregistrement, et le second octet est le nombre d'enregistrements de ce fichier séquentiel.
S'il s'agit au contraire d'un fichier à accès direct ou bien séquentiel indexé, le premier octet est une clé d'accès à l'enregistrement en cours, tandis que le second octet est une clé d'accès au dernier enregistrement du fichier.
Le mot suivant 45 définit l'adresse logique du récepteur.
Son octet de gauche est réservé. Les deux premiers bits de l'octet de droite définissent un numéro de coupleur de sous-bus, le code 00 étant par exemple réservé au bus principal.
Le bit suivant indique s'il s'agit du bus avant (valeur 0) ou du bus arrière (valeur 1). Les cinq derniers bits du second octet indiquent l'adresse du bus.
Interviennent ensuite quatre mots qui servent à coder le nom du fichier concerné par le message 40. Le nom du fichier se trouve donc ainsi codé en ASCII sur quatre mots, ce qui représente des noms significatifs pouvant avoir huit caractères. Le dernier mot du message 40 est réservé.
On décrira maintenant, en référence à la figure 5, les messages d'acquittement d'une demande de transmission par le serveur, notée en bref DAC, ou bien les messages émis par le serveur pour indiquer qu'il est prêt à transmettre les données, notés en bref PAT. Ces deux messages ont une structure commune.
Un tel message 50 commence par un premier mot de définition du message, illustré en 51. La structure générale est la même que pour le message 40 de la figure 4. L'état inactif est représenté par 0000000. L'acquittement d'une demande est défini par 0000010, tandis que le prêt à transmettre est défini par 0000011 (valeurs décimales respectives 2 et 3).
L'octet de gauche du code opération 52 est défini comme pour le message 40. Il en est de même pour l'octet de droite.
Le mot suivant du message 50 est un numéro de ressource attribué, également défini comme précédemment pour le message 40.
Ceci vaut aussi pour la clé d'accès à un enregistrement, qui peut prendre les deux variantes 54A et 54B.
L'adresse logique du récepteur est définie par le mot 55, là encore comme pour le message 40. Intervient alors ensuite le nom du fichier, exprimé sur quatre mots, comme précédemment.
L'élément nouveau essentiel du message 50 est la réponse à une demande, qui vient après le nom du fichier, et qui peut prendre différentes valeurs comme demande acceptée 0000 demande refusée 0001 pour nom de fichier inconnu
0010 pour un fichier qui n'est pas du type
demandé
0011 lorsque l'équipement n'a pas accès
au fichier demandé,
0100 lorsqu'il n'y a plus de ressources
disponibles
L'homme de l'art comprendra qu'un tel message est de nature à couvrir les différentes situations possibles dans le premier échange entre un équipement demandeur et le serveur, comme on le verra plus loin.
Le message de la figure 5 comporte 13 mots.
On décrira maintenant en référence à la figure 6 un message 60 qui comporte dix mots. Cette structure permet la définition des messages des demandes de reprise de transmission, ainsi que des demandes d'interruption de transmission, qui sont en principe à l'initiative d'un équipement.
Le premier mot 61 sert à la définition du message comme précédemment, avec les valeurs 0000000 pour inactif, 0000100 pour demande de reprise de transmission, et 0000101 pour une demande d'interruption de transmission.
Le mot 62 relatif au code opération est le même que précédemment. Ceci vaut aussi pour le mot suivant qui désigne le numéro de ressource.
On retrouve ensuite les deux variantes 64A et 64B pour la clé d'accès à un enregistrement.
Intervient alors la particularité des messages 60, qui est de comporter un compte-rendu de transmission, codé sur un mot de deux octets. Ce compte-rendu de transmission reflétera par exemple des états d'erreur quant à l'auto-test de la mémoire de masse, ou encore l'indication d'une coupure d'alimentation de cette mémoire de masse.
Les autres mots du message 60 sont réservés.
La figure 7 illustre le cas d'un message de données, dont la référence est 70.
Il comprend tout d'abord deux mots de contrôle. Le premier mot de contrôle 71 possède en son deuxième octet un bit le plus significatif qui est représentatif d'une fin de transmission (EOT). Ce bit vaut 1 si le tampon qui va être transmis est le dernier de la transmission à effectuer.
Les 7 bits restant du second octet du mot 71 comportent la définition du message. Le message est inactif si tous les bits sont à 0. Il s'agit d'un message de données si le contenu de ce second octet du mot 71 est 0000110.
Le premier octet du mot 71 concerne le numéro de la ressource allouée à la transmission.
Dans le second mot de contrôle 72, on trouve pour premier octet le numéro ou la clé d'accès à l'enregistrement en cours de transmission. Le second octet est le numéro du dernier mot constituant l'enregistrement en cours de transmission dans le tampon. Cet octet vaut 0 tant que le dernier mot de l'enregistrement n'a pas été transmis.
Les autres mots du message 70 sont des mots de données, au nombre maximum de 126.
On décrira plus loin comment les messages ci-dessus vont être décodés et interprétés, d'une part au niveau du serveur, d'autre part au niveau de l'équipement.
On décrira maintenant en référence aux figures 8 à 12 différents modes de communication au moyen de l'installation selon l'invention.
Une liaison logique est établie à partir du moment où l'un des équipements émet un message DEM.
Ce message peut ne comprendre qu'un simple ordre d'ouverture, sa valeur étant 1 ou 2 dans le code opération du mot 42 (figure 4). On parle alors d'une "ouverture explicite".
Mais le message DEM peut aussi comprendre dans son code opération la demande d'une action, qui peut être une lecture, ou une écriture, voire un effacement ou un positionnement.
On parle alors d'ouverture implicite. Comme on le verra plus loin, le serveur va émettre ou recevoir les données à la fin de la phase de négociation.
Comme précédemment indiqué, la première phase de communication dans l'installation selon l'invention est une phase de "négociation". Cette tâche a pour but d'établir les paramètres de transmission, et d'allouer une ressource à cette transmission, de telle sorte que ce numéro de ressource définisse la connexion logique entre l'équipement et le serveur, et soit le seul numéro nécessaire à la transmission de données.
Quand un équipement désire recevoir ou émettre des données, il émet un message DEM de demande.
Dans le cas de la figure 8, on suppose que le serveur peut donner suite à la demande. Il répond donc par un message d'acquittement DAC possédant dans sa partie définition, au mot 51, le code 2 (contre-valeur décimale du code binaire déjà exposé). Ce message DAC comprend aussi l'indication du numéro de ressource alloué pour définir le lien logique entre l'équipement concerné et le serveur. A réception du message DAC, l'équipement redevient inactif.
Le serveur continue ensuite, en recherchant les données requises, le cas échéant, et en tous cas en créant la ressource à laquelle il vient de donner un numéro. Lorsque ceci est terminé, le serveur émet un message de prêt à transmettre, possédant la structure 50 (figure 5), mais cette fois avec le code 3 dans la partie définition du message au mot 51.
Bien entendu, le numéro de ressource est indiqué à chaque fois.
La connexion logique est alors effectuée, et l'échange des données peut se réaliser tampon par tampon, à l'aide de messages de données possédant la structure 70 de la figure 7.
La figure 9 illustre le cas où le serveur ne peut pas donner suite à la demande formulée par un message DEM. Dans ce cas, la réponse DAC ne contient pas de numéro de ressource alloué, mais possède la valeur fermeture (valeur décimale 11 dans le code opération du mot 52). La communication est immédiatement terminée du côté du serveur et à réception d'un tel message DAC, l'équipement redevient inactif. Tels sont les deux cas de figures qui peuvent se présenter pour le protocole de négociation, le cas le plus fréquent étant naturellement celui où la liaison logique a pu être établie.
On examinera maintenant la phase de transmission ou communication entre l'équipement et le serveur.
Au cours de cette phase, l'équipement et le serveur ne se servent plus d'un adressage physique, mais seulement du numéro de ressource attribué lors de la phase de négociation.
En fait, pour l'équipement, tout se passe maintenant comme si son seul interlocuteur était la ressource qui lui a été attribuée pour la transmission, et avec laquelle il communique par l'intermédiaire du protocole de communication.
On a décrit précédemment en référence à la figure 8 le cas d'une ouverture implicite, dans laquelle la demande initiale de l'équipement comportait l'indication d'une action désirée, par exemple une lecture ou une écriture.
Si la phase de transmission ne suit pas une phase de négociation dans laquelle l'équipement a fait une telle demande de lecture ou d'écriture, l'équipement doit alors envoyer une nouvelle demande dans laquelle il précise les enregistrements désirés. Mais le message DEM qu'il envoie alors comporte maintenant le numéro de la ressource, les autres indications sur les enregistrements requis.
La figure 10 suppose qu'il s'agissait initialement d'une ouverture explicite, et la transmission proprement dite commence donc par un nouveau message DEM.
En réponse à ce message, le serveur envoie l'enregistrement
N01 sous la forme d'un message de données qu'analyse l'équi- pement. Tant qu'il ne reçoit pas de messages DRT ou DIT, le serveur continue à envoyer des enregistrements. Cela se passe à chaque fois dans le cadre de messages de données tels que défini en référence à la figure 7. De son côté, l'équipement effectue des contrôles qui peuvent être synchrones ou asynchrones avec l'arrivée des enregistrements.
On suppose maintenant que l'équipement a détecté une erreur dans le ième enregistrement. Il envoie alors un message
DRT pour demander la reprise de la transmission à partir de cet ième enregistrement. Ceci est effectué par le serveur, jusqu'au dernier bloc.
Comme on l'a déjà vu, ce dernier bloc comprend non seulement les données, mais aussi l'indication binaire qu'il s'agit d'une fin de transmission (valeur 1 du premier bit du deuxième octet du mot 71 du message de données 70 sur la figure 7).
L'équipement aura bien entendu continué à analyser les données.
Si tout s'est passé correctement, l'équipement ferme la session, et envoie un ultime message DEM pour clore la transmission . La valeur du code opération du message DEM est alors 11, dans son code opération, à savoir le second octet du mot 42 du message 40 (figure 4).
Du côté du serveur, la ressource est alors désallouée, et le fichier est fermé.
Ceci concerne une transmission relativement simple. Il se peut bien sûr que l'équipement, au lieu de demander la fermeture du fichier, émette une nouvelle demande de lecture ou d'écriture concernant le fichier déjà ouvert. On reprend alors l'ensemble du mécanisme décrit en référence à la figure re 8. Bien entendu, la ressource est alors conservée.
Avantageusement, on peut aussi mettre en oeuvre selon l'invention une phase de contrôle. Dès que l'équipement désire vérifier la cohérence des paramètres de transmission, il émet une demande spéciale à cet effet, en réponse à laquelle l'équipement renvoie les paramètres sous la forme d'un message
DAC, qui permet à l'équipement de contrôler la cohérence des informations, comme illustré sur la figure 11.
La structure du message de demande est alors la suivante valeur décimale 15 (00001111) dans le code opération du mot 42.
La réponse DAC du serveur possède comme précédemment le format du message 50. La nature spéciale de ce message DAC, destiné ici à contrôler la cohérence des informations, est exprimée comme suit valeur décimale 2 (0000010) dans le champ de définition du message.
Il peut également arriver que l'équipement désire interrom pre la transmission, ce qui sera maintenant décrit en réfé rente à la figure 12.
L'équipement envoie alors un message de demande d'interruption de transmission DIT possédant la structure 60 de la figure 6. L'interruption est représentée par l'existence d'un code 5 en décimales dans la partie définition du message, c'est-à-dire l'octet de droite du mot 61. Le serveur enregistre cette demande d'interruption, mais ne mettra effectivement fin à la transmission qu'en réponse à une répétition du message DIT de la part de l'équipement, et ceci afin d'éviter des interruptions indues.
La Demanderesse a conduit des expérimentations avec une installation selon l'invention fondée sur un bus numérique d'un débit de 1 Megabits par seconde, du type Digibus.
Les figures 13 à 16 sont des chronogrammes illustrant sur deux lignes adjacentes d'une part la procédure et d'autre part les transferts de données sur le Digibus.
La figure 13 correspond au cas d'une ouverture explicite, c'est-à-dire constituée d'une première demande sans action, suivie des messages DAC puis PAT, après quoi l'équipement doit émettre une seconde demande pour que puisse enfin se faire un échange de données, par un premier et un second tampon de données.
Le délai DT1 qui se trouve entre la première demande et le message DAC/PAT est d'environ 60 microsecondes, dont 20 microsecondes dues au Digibus. Le délai suivant DT12, compté de la même manière, est au minimum de 20 microsecondes dues au Digibus, mais ce délai peut être modifié à l'initiative de l'équipement, qui émet sa seconde demande quand bon lui semble. Le délai DT13 est, pour une opération de lecture, de 40 microsecondes dont 20 microsecondes dues au Digibus. Pour une opération d'écriture, il est de 20 microsecondes dues au Digibus.
Le délai DT14 est de 20 microsecondes dues au Digibus en lecture.
S'il s'agit d'une opération d'écriture dans une mémoire vive sauvegardée, le délai est également de 20 microsecondes dues au Digibus.
S'il s'agit au contraire d'une opération d'écriture dans une mémoire EEPROM, ce délai est de 2 millisecondes.
Globalement, il s'écoule entre le moment où la seconde demande circule sur le bus et l'apparition du premier tampon de données - 280 microsecondes qui sont entièrement dues au temps de transmission en écriture, - 300 microsecondes dont 280 sont dues au temps de transmission en lecture.
Le cas d'une ouverture implicite sera maintenant étudié en référence à la figure 14.
Compté comme précédemment, l'intervalle de temps DT21 est de 60 microsecondes dont 20 microsecondes dues au Digibus.
Le délai DT22 est de 20 microsecondes dues au Digibus. Le délai DT23 est de 20 microsecondes dues au Digibus en lecture, de 20 microsecondes dues au Digibus en écriture sur une mémoire vive sauvegardée, et de 2 millisecondes en écriture sur une mémoire EEPROM.
Il s'écoule dans cet exemple 680 microsecondes entre le moment où la demande circule sur le bus et le moment où le premier tampon de données est disponible sur ce même bus.
En référence à la figure 15, on examinera maintenant le cas de deux ouvertures implicites simultanées émanant de deux équipements, individualisés par EQ1 et EQ2.
Les délais DT31 et DT32, égaux, valent tous deux 60 microsecondes dont 20 microsecondes dues au Digibus. Le délai
DT 33 vaut 20 microsecondes dues au Digibus, et le délai
DT34 vaut également 20 microsecondes dues au Digibus.
L'homme de l'art comprendra que les performances données dans ces exemples dépendent essentiellement de la rapidité du bus employé. En effet, le serveur est capable, pour ce qui le concerne, de répondre simultanément aux deux équipements avec les mêmes délais que pour une transmission moto utilisateur.
Enfin, dans le cas de la figure 16, on examine une demande de reprise de transmission. Le délai DT41 est là encore de 60 microsecondes dont 20 microsecondes dues au Digibus.
Les exemples qui précèdent montrent bien que l'installation selon l'invention résout intégralement les différentes composantes du problème posé, à savoir : grande rapidité pour pouvoir fonctionner comme système embarqué temps réel; aptitude à satisfaire conjointement la demande de plusieurs utilisateurs; mémoire directement adressable; traitement des différents équipements comme s'ils étaient individuellement reliés à la mémoire de masse; indépendance du nombre d'équipements demandeurs.
On décrira maintenant comment les messages décrits plus haut vont être décodés et interprétés, d'une part au niveau du serveur, d'autre part au niveau de l'équipement.
En référence aux figures 17 à 22, on décrira les blocs séquentiels des traitements sous la forme d'un automate. Dans la représentation graphique, les noeuds du graphe représentent les états et les relations correspondent aux transitions - un état correspond à la surveillance d'un événement et à une action, - une transition correspond à un aiguillage et à la réception ou à l'émission d'un message.
Il est estimé que l'homme de l'art peut définir des logiciels d'interprétation des messages conformes à ces automates.
L'interprétation des messages au niveau serveur comprend la négociation, la gestion des interruptions, ainsi que la lecture et l'écriture.
La tâche de négociation est toujours active. C'est elle qui gère le protocole de négociation pour le serveur de système embarqué temps réel.
Les états de la tâche de négociation (figure 17) sont (170) Attente d'une demande
Cet état correspond à une phase passive de la tâche,
il est associé à un message de type inactif.
(171) Vérification de la conformité de la demande
Dès réception de la demande, la tâche doit vérifier
la cohérence des informations de la demande avec celles
résidant dans le répertoire du serveur.
1) Elle vérifie l'existence du fichier demandé.
2) Elle vérifie que le mode d'accès au fichier est correct.
3) Elle contrôle que l'équipement
- a accès au fichier
- peut utiliser le mode demandé
- peut utiliser l'opération demandée.
4) Elle regarde si le fichier n'est pas déjà ouvert en mo
dification.
5) Elle vérifie que la clé d'accès est adaptée au mode d'ac
cès du fichier et que le ou les enregistrements existent.
6) Elle contrôle que le mode d'acquittement est autorisé.
7) Elle vérifie enfin qu'il reste des ressources disponibles.
Après ces différents contrôles, la tâche envoie un DAC à destination de l'équipement où elle indique la réponse et précise un numéro de ressource si la communication peut être établie.
(172) Création et allocation d'une ressource
La tâche crée dynamiquement à partir du numéro défini
A l'état précédent une ressource qui est affectée
à la communication.
La tâche envoie ensuite un PAT à l'équipement pour
lui signaler que la liaison logique est établie, en
répétant les paramètres de la demande et en précisant
le numéro de ressource.
La tâche de gestion des demandes d'interruption (figure 18) est toujours active. C'est elle qui gère les DIT.
Les états de cette tâche sont (180) Attente d'une demande d'interruption
A tout moment, peut survenir un DIT. Dans ce cas,
la tâche attend le prochain message.
(181) Attente d'une seconde demande d'interruption
Si le message est de nouveau un DIT, la tâche demande
la désactivation de la ressource concernée, sinon
la transmission continue.
(182) Désactivatiôn de la ressource
La tâche émet une requête en direction de la tâche
maîtresse pour lui signaler la ressource à désactiver.
La ressource en lecture (figure 19) est créée dynamiquement par la tâche de gestion du protocole de négociation. Elle est allouée à une communication.
Ses états sont (190) Segmentation des enregistrements
La ressource lit et découpe les enregistrements en
fonction de la taille des tampons pouvant circuler
sur le bus. Elle rajoute en tête du tampon les mots
de contrôle nécessaire à la reconstitution et au con
trôle des enregistrements.
(191) Désactivation de la ressource
La ressource émet une requête en direction de la tâche
maîtresse pour lui signaler qu'elle peut être désacti
vée.
La ressource en écriture (figure 20) est créée dynamiquement par la tâche de gestion du protocole de négociation. Elle est allouée à une communication.
Ses états sont (200) Reconstitution des enregistrements
La ressource reçoit les différents tampons et recons
titue les enregistrements à l'aide des mots de contrôle
situés en tête de tampon.
(201) Contrôle des enregistrements
Une fois l'enregistrement reconstitué la ressource
contrôle la validité de la transmission de ltenre-
gistrement. En cas d'erreur, la ressource émet un
DRT en direction de l'équipement émetteur en redonnant
les paramètres de la transmission ainsi que la clé
d'accès à l'enregistrement erroné.
(202) Mise à jour de l'enregistrement
La ressource met à jour l'enregistrement grâce au
système de gestion de fichier du serveur.
(203) Désactivation de la ressource
La ressource émet une requête en direction de la tâche
maîtresse pour lui signaler qu'elle peut être désactivée.
L'interprétation au niveau équipement, en lecture, est illustrée sur la figure 21.
Ses états sont (210) Inactif
L'équipement n'a pas initialisé de phase de transmission.
(211) Attente d'un acquittement
L'équipement attend l'acquittement de sa demande par
la mémoire de masse.
(212) Attente d'un prêt à transmettre
L'équipement attend un PAT de la mémoire de masse.
(213) Attente d'un tampon
L'équipement attend un tampon.
(214) Reconstitution de l'enregistrement.
L'équipement reconstitue les tampons en enregistrements.
(215) Contrôle de la validité de l'enregistrement
L'équipement contrôle que l'enregistrement qu'elle
vient de reconstituer est valide (au moyen d'une "somme
de contrôle" par exemple).
(216) Recopie de l'enregistrement
L'équipement écrit l'enregistrement dans sa mémoire.
(217) Fin de transmission.
En écriture, l'interprétation au niveau de l'équipement s'effectue comme illustré sur la figure 22.
Ses états sont (220) Inactif
L'équipement n'a pas initialisé de phase de trans
mission.
(221) Attente d'un acquittement
L'équipement attend l'acquittement de sa demande par
la mémoire de masse.
(222) Attente d'un prêt à transmettre
L'équipement attend un PAT de la mémoire de masse.
(223) Lecture d'un enregistrement
L'équipement lit un enregistrement dans sa mémoire.
(224) Segmentation de l'enregistrement
L'équipement segmente l'enregistrement en tampons.
(225) Emission d'un tampon
L'équipement émet un tampon.
(226) Test de fin d'enregistrement :
L'équipement teste si l'enregistrement en cours est
fini.
(227) Fin de transmission.
Bien entendu, la présente invention n'est pas limitée au mode de réalisation décrit, mais s'étend à toute variante conforme à son esprit, et couverte par les revendications ci-après.

Claims (12)

Revendications.
1. Installation pour l'échange de données informatiques, en particulier pour systèmes embarqués en temps réel, du type comprenant un organe serveur ou contrôleur (1), muni de moyens de mémoire de masse (11), et propre à communiquer par l'intermédiaire d'au moins un bus numérique (13, 15) avec une multiplicité d'équipements utilisateurs (2), caractérisée en combinaison - en ce que les moyens de mémoire de masse (11) sont constitués de mémoires entièrement adressables en accès rapide et direct, - en ce qu'il est prévu une phase d'initialisation ou négociation permettant d'établir une liaison logique entre le serveur (1) et l'un quelconque des équipements (2), et - en ce que les échanges de données entre cet équipement et le serveur peuvent ensuite s'effectuer dans le cadre d'une phase de communication ou transmission, utilisant ladite liaison logique, jusqu'à la rupture de celle-ci; cette phase de communication portant sur des enregistrements, qui sont chacun un ensemble d'informations accessibles à l'aide d'une clé.
2. Installation selon la revendication 1, caractérisée en ce que lesdites phases s'effectuent à l'aide d'un jeu prédéterminé de messages logiques, comprenant, au moins - un message de demande de transmission par un équipement (DEM); - un message d'acquittement d'une demande de transmission par le serveur (DAC); - un message du serveur indiquant qu'il est prêt à transmettre des données (PAT); - un message de demande de reprise de transmission (DRT): et - un message de demande d'interruption de transmission (DIT).
3. Installation selon la revendication 2, caractérisée en ce que lesdits messages comprennent une partie de définition, puis une'partie de code identifiant le mode d'adressage, l'opération à effectuer et le type d'accès requis, une partie indiquant le numéro de ressource attribué, définissant la liaison logique, et une partie formant clé d'accès à un enregistrement.
4. Installation selon l'une des revendications 2 et 3, caractérisée en ce que le message de demande de transmission (DEM) comprend aussi l'adresse logique du récepteur, et le nom du fichier concerné, de même que les messages d'acquittement (DAC) et prêt à transmettre (PAT).
5. Installation selon la revendication 4, caractérisée en ce que les messages d'acquittement (DÂC) et prêt à transmettre (PAT) comprennent en outre une partie de réponse à la demande de transmission initiale (DEM).
6. Installation selon l'une des revendications 2 à 5, caractérisée en ce que les messages de demande de reprise de transmission (DRT) et de demande d'interruption de transmission (DIT) comprennent en outre une partie de compterendu de transmission.
7. Installation selon l'une des revendications 2 à 6, caractérisée en ce que les messages de données comprennent une partie de contrôle, suivie des données proprement dites.
8. Installation selon la revendication 7, caractérisée en ce que les données proprement dites sont limitées à un nombre prédéterminé de mots, pour chaque message de données.
9. Installation selon l'une des revendications 7 et 8, caractérisée en ce que la partie de contrôle contient au moins le numéro de ressource et le numéro d'enregistrement en cours de transmission.
10. Installation selon l'une des revendications 2 à 9, caractérisée en ce que tous les messages peuvent prendre, en position prédéterminée, un code choisi, les rendant inactifs, ce qui permet d'éviter la prise en compte d'informations erronées.
11. Installation selon l'une des revendications précédentes, caractérisée en ce que les échanges d'informations sur le ou les bus s'effectuent par "secteurs", qui forment des "tampons" accompagnés de leurs mots d'identification et de contrôle.
12. Installation selon l'une des revendications précédentes, caractérisée en ce que la mémoire de masse (11) est du type mémoire programmable et effaçable électriquement, ou bien du type mémoire vive sauvegardée.
FR8701017A 1987-01-28 1987-01-28 Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel Withdrawn FR2610157A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR8701017A FR2610157A1 (fr) 1987-01-28 1987-01-28 Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR8701017A FR2610157A1 (fr) 1987-01-28 1987-01-28 Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel

Publications (1)

Publication Number Publication Date
FR2610157A1 true FR2610157A1 (fr) 1988-07-29

Family

ID=9347358

Family Applications (1)

Application Number Title Priority Date Filing Date
FR8701017A Withdrawn FR2610157A1 (fr) 1987-01-28 1987-01-28 Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel

Country Status (1)

Country Link
FR (1) FR2610157A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4253144A (en) * 1978-12-21 1981-02-24 Burroughs Corporation Multi-processor communication network
EP0163577A2 (fr) * 1984-06-01 1985-12-04 Digital Equipment Corporation Réseau local pour système de traitement de données numériques

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4253144A (en) * 1978-12-21 1981-02-24 Burroughs Corporation Multi-processor communication network
EP0163577A2 (fr) * 1984-06-01 1985-12-04 Digital Equipment Corporation Réseau local pour système de traitement de données numériques

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PROCEEDINGS 11TH CONFERENCE ON LOCAL COMPUTER NETWORKS, Minneapolis, Minnesota, 6-8 octobre 1986, pages 4-10, IEEE, US; R.N. LINEBARGER et al.: "Resource sharing local networks" *
SOFTWARE PRACTICE & EXPERIENCE, vol. 15, no. 4, avril 1985, pages 343-358, John Wiley & Sons, Ltd, Chichester, Sussex, GB; T. NAKAMURA et al.: "Network management in a local computer network" *

Similar Documents

Publication Publication Date Title
EP0349371B1 (fr) Système informatique à interconnexion centrale
EP0283350B1 (fr) Serveur à large bande, en particulier pour la transmission de musique ou d'images
EP0755013B1 (fr) Système informatique multinodal et procédé de transfert de messages dans ledit système informatique multinodal
EP0524070B1 (fr) Dispositif universel de couplage d'un bus d'ordinateur à un contrôleur d'un groupe de périphériques
WO2006072500A1 (fr) Dispositif de stockage de donnees
FR2826141A1 (fr) Procede et dispositif de gestion de l'espace memoire d'un disque dur, en particulier pour un recepteur de signaux de television numerique par satellite
FR2765706A1 (fr) Lecteur de cartes a puces a protocole de transmission rapide
FR2807532A1 (fr) Dispositif et procede de memorisation de donnees de journalisation dans un reseau de communication
FR2834361A1 (fr) Module de securisation de donnees par chiffrement/dechiffrement et/ou signature/verification de signature
FR2493562A1 (fr) Systeme d'utilisation de disques en commun et d'intercommunication entre disques
EP0580727B1 (fr) Circuit coupleur et son utilisation dans une carte et procede
FR2780589A1 (fr) Agent de communication entre un administrateur de systeme informatique et un systeme de ressources distribuees et outils de creation d'un tel agent
FR2610157A1 (fr) Installation pour l'echange de donnees informatiques, en particulier pour systeme embarque temps reel
EP0866410B1 (fr) Système informatique à stockage de données distribué
CA2067902C (fr) Procede et dispositif de detection et de controle du gabarit de messages numeriques transmis a un dispositif de reception
FR2834154A1 (fr) Unite electronique incluant des moyens de cryptographie capables de traiter des informations a haut debit
CA2067890A1 (fr) Procede et dispositif de selection d'informations utilisables par une unite locale reliee a un systeme de transmission numerique
EP0822495A1 (fr) Distribution de tickets dans un système informatique multinodal
FR2737031A1 (fr) Procede de transfert de donnees dans un systeme informatique multinodal
EP0547976B1 (fr) Dispositif universel de couplage comprenant un contrÔleur de transfert multiple de données entre une pluralité de mémoires et un bus d'ordinateur
EP0908828A1 (fr) Procédé et système contrÔle d'accès partagés à une mémoire vive
FR2866729A1 (fr) Dispositif a memoire virtuelle partagee auto-administree apte a gerer au moins un flux de donnees multipiste
FR2538140A1 (fr) Dispositif de couplage de bus pour systeme de traitement de donnees a bus multiples
FR2662523A1 (fr) Dispositif controleur d'unites de memoire de masse multiprocesseur a bus central unique.
EP1679608A2 (fr) Procédé de conception d'un périphérique compatible DMA

Legal Events

Date Code Title Description
CD Change of name or company name
ST Notification of lapse