FR2476349A1 - Systeme de traitement de donnees reparti - Google Patents

Abstract

SYSTEME DE TRAITEMENT DE DONNEES REPARTI COMPRENANT PLUSIEURS SYSTEMES LOCAUX SL ENTRE LESQUELS LA COMMUNICATION EST EFFECTUEE A TRAVERS LES COUCHES FONCTIONNELLES CLAIREMENT DEFINIES COMPRENANT UNE COUCHE FONCTIONNELLE DE COORDINATION GEREE PAR DES PROCESSEURS D'INTERCOMMUNICATION SIP RESPONSABLES POUR LES FONCTIONS DE COORDINATION, COMMUNICATION, CONTROLE, INITIALISATION ET SIMULATION RELATIVES AUX SL; UNE COUCHE FONCTIONNELLE DE COMMUNICATION GEREE PAR DES MODULES DE COMMUNICATION CM RESPONSABLES POUR LES PROTOCOLES DE COMMUNICATION ENTRE LES SL ET UNE COUCHE FONCTIONNELLE DE TRANSPORT COMPRENANT DES MODULES DE TRANSMISSION TM, UN BUS OPTIQUE EN BOUCLE ET UN ORGANE DE BOUCLAGE LIG. UNE DESCRIPTION DE CHAQUE SL EST CONTENUE DANS SON SIP SOUS FORME DE TABLES DESCRIPTIVES CE QUI PERMET L'UTILISATION DES RESSOURCES DU SYSTEME GLOBAL PAR N'IMPORTE QUEL SL AU MOYEN DE TRANSLATIONS DES PARAMETRES, LOCALGLOBALLOCAL, CHAQUE COMMUNICATION ENTRE SL ETANT EXECUTEE SOUS FORME D'UNE TRANSACTION COMPRENANT DES ETAPES DISTINCTES D'INTERROGATION, AUTOSELECTION, PRESENTATION, TRAITEMENT ET RETOUR DU RESULTAT. APPLICATION: SYSTEME DE TRAITEMENT DE DONNEES.

Description

SYSTEME DE TRAITEMENT DE DONNEES REPARTI.

La présente invention concerne un système de traitement de données réparti comprenant plusieurs systèmes locaux (SL) 10, chacun desdits SL aO)comprenant au moins une unité de traitement (36) avec les mémoires, les périphériques et les processus associés (30 à 32) et un

moniteur local (37 à 41), la communication entre lesdits SL(lO)étant ef-

fectuée à travers un réseau de communication général.

Les progrès de la technologie dans le domaine des cir-

cuits intégrés (LSI) et le faible coût de ceux-ci conduisent à une évo-

lution de l'architecture et de l'utilisation de systèmes informatiques vers les systèmes répartis (distribués). On peut voir apparaître des

processeurs (Unité de traitement, ou CPU ou unité informatique) exclu-

sivement réservés aux utilisateurs, des processeurs orientés (allocation des ressources, gestion des bases de données, communication, etc.) et

des processeurs de service.

D'autre part l'interconnexion locale de systèmes informa-

tiques répartis sur les sites d'application d'une organisation, avec comme objectifs la communication et le partage de ressources, conduit à

définir des procédures et protocoles permettant l'initialisation des sys-

tèmes répartis, la communication entre applications et l'utilisation op-

timale des ressources partageables entre ces dernières. Aujourd'hui, les systèmes de ce type sont l'objet de recherche et de développement par un

nombre d'organisations importantes et l'Annexe contient un certain nom-

bre de références sur l'état de l'art antérieur.

Toutes les références mentionnées dans l'Annexe ont un

caractère général. Dans la référence (1) il semble que le contrôle répar-

ti du système global réside dans chacun des SL, qui est un processeur

avec sa mémoire principale dans ce cas. Les références (2) et (3) décri-

vent un réseau de communication réparti pour la transmission de données

par paquets, dans lequel les applications et ressources sont partagées.

Mais dans ce système, toutes les unités sont faites par une hiérarchie de "bus". Les références (4) à (7) décrivent soit le traitement réparti

(référence 4) soit le contrôle réparti (références 5 et 6) soit la répar-

tition de tous les composants d'un système (référence 7). Dans la présen-

te invention, les diverses fonctions caractéristiques d'un système répar-

ti sont séparées des SL et sont situées dans leurs couches fonctionnel-

les; par exemple les fonctions de coordination (partage des ressources

entre les SL, etc.) sont situées dans la couche fonctionnelle de coordi-

nation et gérées par les processeurs spécialisés (SIP), les procédures de communication entre les SL sont situées dans la couche fonctionnelle de communication et gérées par les CM, et les organes relatifs à la transmission physique sur un bus optique entre les SL sont situés dans

la couche fonctionnelle de transport et gérés par les TM et le LIG.

La présente invention a les caractéristiques suivantes

- Le système réparti est un système à échelle moyenne (MSDS) avec la ca-

pacité d'interconnecter plusieurs systèmes locaux sur le réseau de com-

munication général et de traiter un ensemble d'applications diverses.

- Le réseau de communication général utilisé pour communiquer entre les

systèmes locaux est un bus optique (boucle ou étoile).

- Le débit de transmission sur le bus optique permet une vitesse de

transfert bidirectionnel de environ 300 K mots/seconde par système local.

- Les caractéristiques physiques du bus optique limitent la distribution des systèmes locaux à des longueurs de quelques kilomètres pour chaque MSDS. La couche de coordination gérée par le SIP, et la couche de communication gérée par le CM, font l'objet des demandes de brevet

françaises n0 79 27 410 et nO 79 31 468 respectivement, mais leur utili-

sation globale dans la présente invention est décrite du point de vue

de la structure, des fonctions et mécanismes de communication.

Donc, la présente invention est caractérisée en ce que le-

dit système réparti comprend en outre un module extension moniteur (EM 42) associé avec chacun desdits SL(10),la communication entre SL(l0)étant assurée par:

a- une couche fonctionnelle de coordination (12) gérée par des proces-

seurs d'intercommunication (SIP 11) comprenant un matériel et logiciel

spécialisés assurant les fonctions de coordination, communication, con-

trôle, initialisation et simulation relatives aux SL(10), la communica-

tion entre lesdits SL(lO)et lesdits SIP (l)étant effectuée à travers

l'interface SL/SIP au moyen dudit EM (42)et des mécanismes d'intercom-

munication SL/SIP commandés par lesdits SIP(ll) b- une couche fonctionnelle de communication (14) gérée par des modules

de communication (CM 13) comprenant un matériel et logiciel dur spé-

cialisés, assurant la gestion des protocoles de communication entre lesdits SL c0) lesdits protocoles de communication comprenant les moyens pour établir les liaisons logiques adressées et diffusées, les moyens de contrOler le débit d'information, les moyens de présenter le même ordre d'événements globaux au niveau de chaque SL (10), ainsi

que des procédés de détection d'erreur et de récupération, la communi-

cation entre lesdits SIP Il)et lesdits CM 13)étant effectuée à travers l'interface SIP/CM au moyen des mécanismes d'intercommunication SIP/CM

commandés par lesdits SIP XV et les CM U3) la communication entre les-

dits CM 13 et des modules de transmission (TM 15)étant effectuée à tra-

vers l'interface CM/TM au moyen de mécanismes d'intercommunication CM/TM commandés par lesdits CM (3)et lesdits TM (15 c- une couche fonctionnelle. de transport (18) comprenant en outre les TM (5j un bus optique en boucle (16) et un organe de bouclage (LIG 1 lesdits TM (5)comprenant un matériel et logiciel dur spécialisés pour

contrôler les erreurs de parité et pour effectuer la conversion élec-

trooptique et optoélectronique, et pour maintenir la synchronisation entre lesdits CM a3)et ledit bus optique 6)respectivement, ledit LIG

(7)comprenant un matériel et logiciel dur spécialisés pour coder et dé-

coder chaque trame de transmission sur ledit bus optique (6) les

moyens pour gérer la procédure d'initialisation permettant la synchro-

nisation de la transmission sur ledit bus optique a6) ainsi que les moyens pour assurer l'émission et la réception correctes des données dans les cadres alloués aux SL M0) Un but principal de la présente invention est de tirer

profit de la technologie en réalisant un système qui peut donner des so-

lutions optimales pour une variété d'applications (base de données, temps réel, industriel, gestion, etc..). La séparation dans la présente

invention d'un système réparti en couches fonctionnellesavec les inter-

faces.clairement définies entre elles. permet la séparation des fonc-

tions et d'avoir une vue globale claire du système.

Donc, les fonctions de coordination, communication, ina-

û5 tialisation et simulation incorporées dans la couche de coordination gé-

rée par le SIP,permettent: lapossibilité d'échanger des informations,

des programmes et des services en temps réel, l'optimisation de l'utili-

sation des ressources du système global ce qui entraîne une diminution

des coûts, la disponibilité accrue des ressources du système et la pos-

sibilité pour celui-ci de survivre aux défaillances, la possibilité d'avoir un système qui coïncide parfaitement avec les applications à

traiter mais qui puisse évoluer facilement avec la croissance de l'orga-

nisation. Les protocoles de communication,gérés par le CM situé dans la couche fonctionnelle de communication, sont spécifiés dans le but de répondre de façon souple et efficace aux caractéristiques du MSDS définies, c'est-à-dire à un ensemble d'applications nécessitant un temps

de réponse court et des débits d'information élevés sur le système glo-

bal. La définition de deux modes de liaison logiques, diffusé et adressé, fournit une grande souplesse. Par exemple, le mode diffusé ayant une

priorité supérieure à celle du mode adressé est particulièrement effica-

ce pour mettre à jour les fiches multiples dans une application de base de données, ou pour localiser rapidement les ressources demandées par un

SL dans une application de temps réel. Le mode adressé est efficace lors-

qu'un SL veut communiquer avec un autre. Par exemple, le mode diffusé peut être utilisé pour localiser certaines ressources demandées et le mode adressé utilisé ensuite pour communiquer de façon efficace avec ces

ressources localisées.

Un autre but des protocoles de communication est de per-

mettre à un SL (source) d'appeler toutes les destinations dans le mode diffusé, sans connaître le nombre de destinations liées sur le système global, ce qui réalise un mode très efficace de communication tolérant

la défaillance d'une unité.

Encore un autre but des protocoles de communication est

de présenter le même ordre d'événements globaux à tous dans le mode dif-

fusé, pour que chaque SL ait une vue cohérente de l'état global du sys-

tème réparti, car dans un tel système, chaque SL n'a qu'une vue fragmen-

taire de l'état du système global au travers des événements globaux. Il

est donc indispensable, afin de maintenir une certaine cohérence du sys-

tème global, que l'ordre de ces événements soit le même au niveau de

chaque SL. Ceci permet à une destination désynchronisée de se resynchro-

niser en se référant au comportement des destinations synchronisées.

- La couche de transport physique gérée par les TM a pour but de permettre une vitesse de transmission élevée (réalisé par le bus optique), et une fiabilité supérieure réalisée par le bus optique qui est peu susceptible de phénomènes électromagnétiques, et par le contrôle d'erreur réalisé par le contrôle de parité et par le codage (3B-4B) de

chaque transmission sur le bus optique.

Un autre but est d'assurer que toute requête de service

faite au moniteur d'un SL soit systématiquement communiquée, via l'ex-

tension moniteur, à la couche de coordination (phase d'interrogation) pour localisation et sélection des meilleuresressources satisfaisant à

cette requête.

La phase d'interrogation et de sélection des meilleures

ressources est suivie dans la présente invention par les phases de pré-

sentation, de traitement et de retour du résultat. C'est-à-dire que l'ob-

jectif est de communiquer la requête au(x) SL sélectionné(s), de traiter la requête entrante comme dans un SL isolé par le moniteur local et de

retourner le résultat au moniteur du SL origine.

Encore un autre but est de maintenir un descriptif des

ressources, seulement localement. Ces tables de description des ressour-

ces qui doivent être fournies à la couche de coordination ne concernent que les ressources locales du SL. Donc, la nécessité de mettre à jour les

tables globales (nécessaire dans un système réparti avec le contrôle cen-

tral) est évitée, principe très important du point de vue del'efficacité.

Ces avantages et certains autres de la présente invention

apparaîtront clairement dans la description suivante d'un mode de réali-

sation préféré. La description fait référence à la série P 800 de mini

et micro-ordinateurs fabriqués par Philips Data Systems. Seule l'archi-

tecture du P 800 pertinente à la présente invention (interface et ins-

tructions d'Entrée/Sortie par exemple) est décrite. Les descriptions dé-

taillées d'architecture P 800 peuvent être trouvées dans les références citées. Dans la liste des figures suivante: La figure 1 est un diagramme synoptique d'un système de traitement de

données réparti montrant les principaux sous-systèmes et couches fonc-

tionnelles. La figure 2 montre un exemple de type de liaisons possible dans le cadre

de la présente invention.

La figure 3 est un diagramme synoptique de plusieurs SL isolés.

La figure 4 est un diagramme synoptique de plusieurs SL tels qu'utilisés

dans la présente invention.

La figure 5 est un bloc diagramme du SIP montrant les éléments princi-

paux et leursconnexions.

La figure 6 montre le principe du mécanisme d'allocation d'un tampon d'Entrée/Sortie. La figure 7 montre le séquencement du mécanisme d'allocation entre les

éléments concernés.

Les figures 8a - 8d montrent les liaisons logiques permises.

La figure 9 est un bloc diagramme du CM montrant les éléments principaux

et leurs connexions.

La figure 10 est un diagramme synoptique montrant le cheminement des

données à travers le CM.

La figure 11 montre la structure du bus contrôleur d'interface (BIC)

avec le SIP.

La figure 12 montre la structure du séquenceur au niveau bloc (BLS).

La figure 13 montre la structure de l'automate au niveau paquet (PLA).

La figure 14 est un diagramme synoptique du CM au point de vue contrôle.

La figure 15 est un diagramme de synchronisation de l'interface entre le

CM et le TM.

La figure 16 est un diagramme synoptique de la couche de transport.

La figure 17 montre le coupleur entre le TM et le bus optique.

La figure 18 est un bloc diagramme du TM montrant les éléments princi-

paux et leurs connexions.

La figure 19 est un bloc diagramme du LIG montrant les éléments princi-

paux et leurs connexions.

La figure 20 est un organigramme décrivant le traitement d'une requête

de service par les SIP connectés sur un MSDS.

La figure 21 montre le principe d'autosélection.

La figure 22 est un organigramme décrivant la phase d'analyse d'une re-

quête au niveau de chaque SL.

La figure 23 est un d'un numéro de code La figure 24 est un gine d'une réponse à La figure 25 est un SIP origine dans le La figure 26 est un d'un code fichier à La figure 27 est un La figure 28 est un organigramme décrivant la séquence d'assignation

fichier à un périphérique.

organigramme décrivant

g une requête.

organigramme décrivant

cas d'erreurs.

organigramme décrivant

un fichier temporaire.

organigramme décrivant organigramme décrivant

tiples de fichiers.

L'Annexe contient:

1) Une description de l'interface physique

local P 800.

2) Une description de l'interface physique

3) Une description de l'interface physique

le traitement par le SIP ori-

la séquence effectuée par le la séquence d'assignation

la phase d'autosélection.

la mise à jour de copies mul-

entre le SIP et un système

entre le SIP et le CM.

entre le CM et le TM.

4) Une liste de références de l'art antérieur dans le cadre de la présen-

te invention.

L'architecture des mini et micro-ordinateurs P 800 est décrite dans les références suivantes, publiées par Philips Data Systems - P 856M/P 857M CPU Service Manual 5111-991-2695X - P 856M/P 857M System Handbook 5122991-26931

- P 851M Vol.I CPU & Memories Technical Manual 5122-991-28073.

La figure 1 est un diagramme synoptique d'un système de traitement de données réparti de type MSDS déjà décrit. Dans la figure 1, représente les différents systèmes locaux (SL L...SLN). Les SIP correspondant à chaque SL sont représentés par 11 et sont situés dans la couche fonctionnelle de coordination représentée par 12. Les modules de communication (CM) représentés par 13, qui sont responsables du contrôle des protocoles de communication entre les différents SL, sont situés

dans la couche fonctionnelle de communication représentée par 14.

Les CM 13 communiquent entre eux via le réseau de commu-

nication qui utilise un bus optique 16. La couche de transport physique 18 est constituée du bus optique 16 organisé en boucle, de modules de transmission (TM) 15 réalisant l'interface entre le bus optique et les

CM 13, et d'un organe de bouclage (LIG) 17.

Plusieurs systèmes de type MSDS peuvent être liés entre

eux et/ou avec un réseau de communication public, et la figure 2 er mon-

tre un exemple. Les MSDS 1 et 2 représentés par 20 et 21 ont un déb:t de transmission relativement faible et sont plus spécifiquement destinés à

interconnecter des micro-ordinateurs n'ayant pas de ressources (interf a-

ces homme-machine, contrôle de processus...etc.). MSDS 3 qui a un débit

plus élevé, représenté par 22, permet l'interconnexion des systèmes pos-

sédant les ressources partageables de l'organisation. N'importe quel système des MSDS 1 et 2 peut utiliser ces ressources, via les frontaux 25 et 26 et leurs stations de transport associées, TS 27. Chaque TS 27 est constituée d'un CM 13 et d'un TM 15. Les ressources partageables

peuvent être des bases de données réparties sur plusieurs mini-ordina-

teurs, des frontaux permettant l'accès à des réseaux publics ou privés de communication (Transpac, communication par satellite, des unités de

traitement spécialisées.

Le MSDS 3, 22, peut communiquer avec un système "host" 24, qui peut être un système central avec les ressources indisponibles aux niveaux de MSDS, via la TS 27. La communication entre le MSDS 3 et le

réseau de communication public' 23 est effectuée via une TS 27 et un in-

terface de traitement 28. L'interface 28 peut être un ensemble des mini-

ordinateurs, par exemple, qui adapte les protocoles utilisés dans le MSDS 3 à ceux utilisés par le réseau de communication 23, protocole

X 25 par exemple, et inversement pour l'information venant du réseau 23.

Donc, un utilisateur situé dans n'importe quel MSDS peut communiquer soit avec les utilisateurs dans le même MSDS, soit dans les autres 1SDS,

soit à travers le réseau de communication public. De plus, les utilisa-

teurs peuvent accéder aux ressources du système "host" 24.

Les éléments mentionnés dans la figure 1 et les mécanis-

mes de communication entre eux sont prochainement décrits à l'aide des

figures appropriées.

La figure 3 est un diagramme synoptique de plusieurs SL

isolés, situés sur plusieurs sites. Dans cette figure, 30 à 32 repré-

sentent les périphériques tels que les disques, bandes magnétiques, pro-

cessus, etc., contrôlés par les unités de contrôle 33 à 35. L'unité de traitement (CPU) de type P 800 est représentée par 36. Ceci inclut la

mémoire principale du SL.

Lorsqu'un utilisateur ou un processus veut utiliser une ressource (disque magnétique par exemple), ce dernier fait une requête

de service au moniteur, via une instruction LKM (Requête au Moniteur).

Cette instruction produit une interruption de niveau élevé qui active le

"dispatcher" 37. La requête est analysée par le "dispatcher" 37 du moni-

teur et communiquée aux modules du moniteur (38 à 41) chargés du traite-

ment de la requête. Lorsque la requête est traitée, un bit d'événement

(E) est positionné dans le bloc de contrôle-des événements (ECB) de l'uti-

lisateur et celui-ci est informé de la fin du traitement de sa requête.

Un tel système nécessite de posséder toutes les ressour-

ces indispensables au traitement des tâches sur le site local; les res-

sources sont mal utilisées et sont, la plupart du temps, inactives. De

plus, si l'on désire une grande sécurité, il est nécessaire de duplica-

ter les ressources du système.

Dans la plupart des applications, il y a un besoin de partager les ressources et d'optimiser le partage afin d'augmenter la disponibilitédusystème global, d'en accroître l'extensibilité et d'en

diminuer le coût. La figure 4 est un diagramme synoptique montrant com-

ment le problème de partage des ressources est résolu dans la présente invention, au niveau du moniteur. Dans cette figure, les SL 10 situés sur les site i, j et k sont les mêmes que ceux décrits dans la figure 3,

à l'exception qu'un module extension moniteur (EM) 42 est ajouté à cha-

que SL 10.

Lorsque le moniteur local reçoit une requête de service provenant d'un processus ou d'un utilisateur, le "dispatcher" 37 active

l'extension moniteur (EM) 42 qui remet en forme la requête et la commu-

nique au SIP 11 sous la forme d'un bloc de commande.

Le SIP Il transmet cette requête sur le bus optique 16, via la TS 27, à tous les SL 10 interconnectés. Les SIP 11 distribués sur

les différents sites prennent en charge la requête et.déterminent et lo-

calisent la (les) unité(s) chargée(s) du traitement. La requête est alors présentée au(x) moniteur(s) sélectionné(s) et traitée comme si

elle était issue du SL. A la fin du traitement, le résultat est communi-

qué au SIP source 11 qui le fait parvenir au processus origine de la re-

quête.

Les ménanismes de communication entre le SIP et le

Système Local (SL) sont maintenant décrits. Le SIP interprète les ins-

tructions d'entrée/sortie d'un système P 800.

Commandes (CPU + SIP): Le SL (CPU 36) utilise une instruction d'Entrée/Sortie (CIO début) pour

signaler au SIP (synchronisation) qu'une commande lui est communiquée.

Cette commande peut être directement transférée sur le bus P 800 (conte-

nu du registre spécifié par la CIO), lors de l'exécution de l'instruc-

* tion, si sa longueur n'excède pas un mot de 16 bits. (L'interface physi-

que du SIP avec le bus P 800 est défini dans l'Annexe). Dans le cas con-

traire, l'adresse d'un bloc de commande situé dans la mémoire principa-

le sera alors spécifiée (contenu du registre indiqué par l'instruction d'E/S). Ce bloc contient toutes les directives, paramètres et données

nécessaires à l'exécution de la commande.

Requête entrante (SIP + CPU): Une commande émise par un SL peut donner naissance à une ou plusieurs

requêtes entrantes communiquées au(x) système(s) concerné(s).

La communication d'une requête entrante se fait par

émission d'une interruption vers le CPU 36 du SL concerné, lequel exécu-

te alors une instruction d'E/S (SST) afin de connaître la raison de

l'interruption. Après exécution de la SST, le registre spécifié par cet-

te instruction contient l'adresse d'un bloc de requête entrante, situé en mémoire principale et contenant toutes les informations relatives à

cette requête. Le SIP utilise un bloc qui lui aura été préalablement al-

loué par le SL pour réceptionner les requêtes entrantes.

Emission d'un résultat (CPU a SIP):

Après traitement d'une requête entrante, le SL envoie un résultat rela-

tif à celle-ci vers le SIP. Ce résultat est communiqué au moyen d'une instruction d'E/S (CId début) exécutée par le CPU. Le registre spécifié

par l'instruction contient alors l'adresse d'un bloc résultat préalable-

ment chargé en mémoire principale.

Communication d'un résultat (SIP + CPU) Un résultat relatif à l'exécution d'une commande sera communiqué au SL origine de celle-ci au moyen d'une interruption envoyée au CPU, lequel exécutera alors une instruction d'E/S (SST). Le registre spécifié par la SST contient, après exécution de cette dernière, l'adresse d'un bloc en mémoire principale préalablement chargé avec le résultat considéré. Le il bloc utilisé aura été alloué au moment de l'émission de la commande par

le SL.

Instruction d'E/S: CIO début G|10 01 000 Ri 11 1 AD. SIP -v--I type d'instruction Pendant l'exécution de l'instruction le contenu de

R1 (3 bits) est envoyé sur le bus de données.

Le registre condition (CR) est positionné de la façon suivante: 00 Instruction acceptée (RBL vide) 01 Instruction refusée (RBL plein) ll Adresse non reconnue RBL est un registre boîte aux lettres servant au passage des commandes

entre le PM (module de traitement) du SIP et le CPU.

AD. SIP = 6 bits.

Le contenu du registre spécifié dans le champ R1 est, soit directement une commande, soit l'adresse en mémoire principale d'un bloc de commande

ou de résultat.

Commandes directes: CIO IPL (Rl) | 0 - O0-- -- - |

Cette commande permettra de déclencher le téléchar-

gement et le télédémarrage du SL demandeur par un SL possédant des capa-

cités d'initialisation (système pilote).

CIO Allocation du tampon au SIP (R1) Adresse du tampon alloué É 0 0o Cette commande permet l'allocation d'un tampon au

SIP, autorisant ainsi la communication d'une requête entrante au SL.

CIO Mode (Rl) 0 - - - - - - - - - o | 0 O

Cette commande fait passer le SIP d'un mode d'ini-

tialisation dans un mode opérationnel, interdisant alors certaines actions de l'extérieur risquant de perturber le système local (exemple:

simulation d'ordres envoyés au panneau de contrôle).

Commande indirectes: (Rl) Adresse du bloc de commande ou résultat =k 0 1

Cette commande permet de communiquer au SIP l'adres-

se d'un bloc, situé en mémoire principale, contenant les informations

relatives à une commande ou à un résultat.

SST (ETAT LECTURE)

0 1 0 0 1 Rl I AD. SIP Durant l'exécution de l'instruction, le contenu du

bus de données est chargé dans le registre spécifié par le champ R1.

Le registre condition (CR) est positionné de la façon suivante: 00 Instruction acceptée 01 Instruction refusée

ll Adresse non reconnue.

Le contenu du registre spécifié par R1 est alors, soit directement une

requête entrante, soit l'adresse en mémoire principale d'un bloc de re-

quête entrante ou de résultat.

SST directe:

SST ACK

(R) 0 - -0

Une telle réponse signifie que la dernière commande indirecte a été mémorisée par le SIP:donc éventuellement, que le tampon ayant servi à communiquer celle-ci est de nouveau disponible pour le système. SST Libération de mémoire dans SIP (Rl) 0 O- --- - - - - - - -| 1 | Cette réponse signifie qu'après un dépassement de capacité mémoire du SIP il y a de nouveau de la place disponible pour

recevoir des commandes ou résultats.

SST Commande inconnue (RI) Adresse du bloc de commande inconnue =S 0 0 Une telle réponse signifie que la commande envoyée

par le SL est inconnue du SIP et n'a pu être interprétée par celui-ci.

SST indirecte (RI) Adresse du bloc de requête entrante ou de 1 résultat ai Q Dans ce cas, le registre spécifié par Rl contient l'adresse en mémoire principale d'un bloc de requête entrante ou d'un

bloc résultat.

Le SIP est muni d'un mécanisme d'accès direct à la mémoire principale du SL, lui permettant de transférer directement des

informations de ses tampons d'E/S (Entrée/Sortie) dans la mémoire prin-

cipale et de la mémoire principale dans ses tampons d'E/S. Ce mécanisme

sera décrit plus tard.

La figure 5 est un bloc diagramme du SIP 11 montrant les éléments principaux avec leurs connexions. Le SIP peut être partagé en quatre modules assurant les fonctions de traitement et de communica-

tion attribuées à celui-ci. Les quatre modules sont: le Module de Trai-

tement (PM) 50, le Module Local de Communication (LCM) 51, le Module de Communication Interface (CMI) 52 et le Module contrôlant les tampons d'Entrée/Sortie ou Data Buffer Management Module (DBMM) 53. Les PM, LCM

et CMI travaillent en parallèle tandis que le DBMM est utilisé pour as-

surer la communication entre ceux-ci. Les interconnexions principales entre les quatre modules du SIP sont montrées, c'est-à-dire les lignes d'adresse, de données et de contrôle. Les interfaces physiques du SIP

avec un SL P 800, 10 et le SIP via le CM 13 sont décrits dans l'Annexe.

L'utilisation des principaux signaux d'interface et de contrôle sera dé-

crite plus en détail par la suite.

Les interconnexions entre les quatre modules du SIP (le bus interne) se composent des mêmes lignes d'adresse (16 lignes) et

de données (16 lignes) que pour les interfaces externes.

Le PM 50 est constitué d'un micro-ordinateur compre-

nant principalement un microprocesseur 58,INTEL 8086, 64 K mots de mémoi-

re vive (RAM) 54, et 2 K mots de mémoire morte reprogrammable (PROM) 55.

Un automate de contrôle du PM est représenté par 56. Cet automate de contrôle (AC) 56 est constitué d'une logique câblée (PROM) connectée à un FPLA (arrangement de circuits logique programmables). Les contenus du

FPLA définissent le séquencement exécuté par l'AC 26, suivant les-diffé-

rents états possibles. Un système d'interruption et de contrôle de prio-

rité est représenté par 57 et un système de deux minuteries par 58. Un système d'horloge 59afournit les signaux de rythme utilisés dans le SIP 11. Un registre boite aux lettres 59 assure la communication entre le PM 50 et le LCM 51. Le PM 50 assure les fonctions de coordination, de

contrôle et d'initialisation. La RAM 54 contient l'exécutif de coordina-

tion (CCE) et les tables descriptives des objets et ressources du SL qui

seront décritesplus tard. La PROM 55 contient les processus d'initiali-

sation, de téléchargement et de télédémarrage du système. Les programmes contenus dans les mémoires 54 et 55 sont exécutés par le microprocesseur 58. Le LCM 51 assure les fonctions de communication avec un SL P 800 10, c'est-à-dire avec le CPU 36 au moyen des instructions d'Entrée/Sortie et du mécanisme des interruptions, et avec la mémoire principale d'un SL par accès direct sur celle-ci. De plus, le LCM 51 est chargé de la fonction de simulation d'ordres du panneau de contrôle (PAN.SIM. dans la figure 5). Le LCM 51 est constitué d'un automate de

contrôle 60 microprogrammé, des circuits d'interface et de contrôle re-

présentés symboliquement par 61 à 67. Ceux-ci comprennent les circuits d'interface 61 et 62 pour assurer la compatibilité (niveau logique, puissance, etc.) entre le LCM et un SL. Les circuits qui contrôlent le bus et décodent les instructions sont représentés par 63. Le compteur 66 définit l'adresse d'accès direct de la mémoire principale (DMA) et le compteur 67 définit l'adresse du tampon du DBMM. Les portes logiques 64

contrôlent l'adresse reçue du SL et le multiplexeur 65 sélectionne l'en-

trée lorsqu'une simulation du panneau de contrôle est effectuée.

Le CMI 52 assure la gestion de l'interface avec le CM 13 présentant vis à vis de celui-ci, soit un interface processeur,

soit un interface mémoire en fonction de transferts initialisés (l'in-

terface est décrit en Annexe). Le CMI est constitué d'un automate de contrôle 68 microprogrammé et des circuits représentés symboliquement

par 69 à 76. Les portes logiques 74 à 76 sont les circuits d'interface.

Les registres 69 et 70 définissent l'adresse du bloc de commande et de résultat, transférée entre le CMI 52 et le CM 13 et le registre 71 est utilisé comme boite aux lettres pour l'adresse du CM 13. Le comparateur 72 compare l'adresse du tampon alloué au CM à la fin de l'exécution de

la commande avec l'adresse envoyée par le CM, donc le PM peut être in-

formé du tampon à libérer. Le comparateur 73 compare l'adresse du tam-

pon du SIP avec l'adresse envoyée par le CM.

Le DBMM 53 est constitué de deux tampons d'Entrée/ Sortie (E/S) triple accès représentés par 77 et 78 et d'un mécanisme d'allocation bidirectionnelle entre - le PM et le SL P 800, via le LCM - le PM et le CM, via le CMI

- le SL P 800 et le CM, via les LCM et CMI.

Le mécanisme d'allocation des tampons est situé dans l'automate de contrôle microprogrammé du DBMM 79 qui, à son tour, est piloté par le PM. Les systèmes des multiplexeurs 80 et 81 permettent l'accès approprié sous le contrôle de 1'AC 79, tandis que les circuits

d'interface avec le CM sont symboliquement représentés par 82.

Le mécanisme de communication interne du SIP et les tampons d'E/S du DBMM sont maintenant décrits. La situation du SIP

entre un SL et le réseau de communication entraîne pour celui-ci la né-

cessité de gérer un grand nombre d'informations le traversant. Ces in-

formations suivent des chemins différents en fonction de leur nature et de leur origine. Il faut distinguer:

- Les ordres au SIP, émis par le SL et reçus par le PM du SIP qui effec-

tue un prétraitement dessus.

- Les requêtes sortantes, émises par le PM vers le réseau de communica-

tion.

- Les requêtes entrantes, provenant du réseau de communication et en-

voyées au PM pour analyse. Après analyse, ces requêtes sont éventuel-

lement communiquées par le PM au SL.

- Les données, émises par un SL vers le réseau de communication.

- Les données provenant du réseau de communication et envoyées au SL.

D'autre part, le réseau de communication qui per-

met d'écouler un trafic permanent bidirectionnel de 300 K mots par se-.

conde implique des transferts rapides à travers le SIP. Il est donc im-

portant, en dehors du temps de traitement par le PM, que le temps de transit des informations dans le SIP soit le plus bref possible. Afin d'atteindre cet objectif l'invention exploite les deux possibilités suivantes - Utilisation de modules (LCM, CMI) commandés par le PM1 et travaillant

en parallèle avec celui-ci.

- Utilisation d'un mécanisme de communication facilitant les échanges entre les trois éléments considérés (SL, PM, réseau de communication

via le CM).

Le mécanisme de communication comprend les deux tampons d'E/S 77 et 78 (qui sont les RAM de 256 mots chacune) triple accès et un mécanisme d'allocation associéà chacun d'eux. La figure 6

montre le principe de ce mécanisme pour un tampon (77 par exemple>.

Dans la figure 6, le tampon 77 peut être alloué indépendamment à l'un des trois éléments concernés (PM, SL, CM) via respectivement le bus PM, le bus SL ou le bus CM et les multiplexeurs 80a, 80b, 80c (80 dans la figure 5 et renumérotés pour la clarté). La commande d'allocation est

effectuée par le PM lui-même et le mécanisme d'allocation 82 est un mé-

canisme logique câblé et contenu dans l'AC 79 du DBMM. Un élément ayant obtenu l'allocation d'un tampon peut l'utiliser en exclusivité tant qu'il n'a pas été restitué au PM. En fait, l'utilisation d'un tampon

d'E/S par l'un des trois éléments consiste à effectuer un échange d'in-

formation soit avec le SL, soit avec le réseau de communication via le CM.

La sélection des mémoires et périphériques est ef-

fectuée par décodage des bits d'adresse et de certains bits de commande par le PM. Le tableau I ci-dessous spécifie ces décodages et sélections

Tableau I

MIO0 A19M A17M A15M A14M A13M A12M AllM A1OM A9M Sélection O X X 0 O O O O O O Sélection du CM (1) O X X O O O I O O O Sélection du LCM O X X O O 1 O O O O Allocationtamponnlau PM O X X O O 1 O O O 1 Allocationtamponn 2au PM O X X O O 1 O O i O Allocation tamponn lau CM 0 X X O O i O O 1 1 Allocation tampon rPn 2au CM O X X O O 1 0 i O O Allocation tampon n l au LCM 0 X x o 0 1 0 1 0 1 Allocation tampon n 2 au LCM 0 X X O 0 1 1 1 I O Horloge temps réel (2) 0 X X 0 1 0 0 0 0 0 Initialisation minuterie (3) 0 X X 1 O O O O 0 O Initialisation système

IT (4)

O O O 0 Poids forts d'adresse Sélection RAM 64K (5) 1 O 1 O O O 0 0 O O Sélection tampon rn l (5) i 0 1 0 0 0 0 i0 0 1 Sélectiontampon rn 2(5) 1 1 1 1 1 1 1 Poids forts Sélection PROM (5)

Le bit MIO définit le type d'accès mémoire au périphérique.

(1) les bits d'adresse AlM à A8M spécifient l'adresse du CM concerné et

la nature de la commande.

(2) l'interruption horloge temps réel est remise à zéro.

(3) les bits d'adresse AIM, A2M spécifient le numéro de la minuterie ini-

tialisée.

(4) A1M spécifie le mot de commande envoyé.

(5) A1M à A8M indiquent les poids faibles d'adresse de la mémoire.

Les bits marqués avec un "X" ne sont pas significatifs.

Le mécanisme d'allocation est commandé par le PM au moyen des instructions d'E/S suivantes (référence au Tableau I) Allocation du tampon au PM Allocation du tampon au LCM

Allocation du tampon au CM qui a un accès direct sur ce tampon.

Le tampon alloué contient l'ordre d'exécution qui

est interprété par le module responsable du traitement de l'échange de-

mandé. Le PM est informé de la fin du traitement par voie d'interruption; il peut alors, soit analyser les informations reçues, soit utiliser le

tampon concerné pour un autre échange.

La figure 7 montre le séquencement du mécanisme

d'allocation entre les trois modules PM, LCM et CM.

Le LCM 51 est essentiellement chargé des transferts entre la mémoire principale d'un SL et les tampons d'E/S 77 et 78 qui lui sont alloués. Il est également chargé de gérer l'interface avec le

CPU 36 et de simuler les commandes opérateur du panneau de contrôle.

L'interface avec le CPU 36 est géré suivant les

principes ci-dessous.

1) Sur décodage d'une CIO début adressée au SIP deux cas peuvent se pré-

senter: - Le LCM est dans un état d'échange. Dans ce cas le LCM charge le contenu du bus de données dans le registre boite aux lettres (59, figure 5), émet une interruption vers le PM et évolue dans l'état

exécution. Le LCM revient dans un état d'échange lorsque le PM exé-

cute une instruction de lecture du registre boite aux lettres 59

via la sélection du LCM (Tableau I).

- Le LCM est dans un état d'exécution. Dans ce cas le LCM refuse la

CIO début (CR = 1).

2) Sur décodage d'une SST adressée au SIP deux cas sont également possi-

bles: - Le LCM n'est pas prêt à fournir un mot d'état au SL, la SST est

alors refusée (CR = 1).

- Le LCM est prêt à communiquer un mot d'état au SL, via une inter-

ruption; dans ce cas, sur décodage de l'instruction SST, celle-ci

est acceptée et le mot d'état est envoyé sur le bus de données.

L'AC 60 du LCM contrôle l'évolution des états né-

cessaires pour gérer correctement l'interface CPU/LCM.

La simulation d'une commande opérateur du panneau

de contrôle est exécutée lors de l'allocation d'un bloc de commande si-

tué dans un tampon d'E/S. Le format d'un bloc de commande de simulation

est défini dans le Tableau II.

Tableau II mot- 1 mot 2

Le mot 1 contient 2 bits définissant une commande de simulation (00).

Le mot 2 contient les bits définissant chaque commande à simuler Bit MCN: remise à zéro générale (pas de paramètre) Bit INT: interruption du panneau de contrôle (pas de paramètre) Bit INST: exécution d'un programme instruction par instruction (pas de paramètre)

IPL: programme de chargement initial (paramètres sur clé du pan-

neau de contrôle) RUN: démarrage d'un programme (pas de paramètre) LR: chargement d'un registre, numéro spécifié dans REP (4 bits), (paramètres contenus à charger) HALT: arrêter le CPU

X: non utilisé dans ce contexte particulier.

*25 Donc, ces commandes peuvent être simulées par pro-

gramme, via les tampons d'E/S, ou directement envoyées par le panneau de

contrôle, via le multiplexeur 65 (figure 5). L'interprétation de cescom-

mandes par le CPU est effectuée par un module situé dans le CPU.

On décrit maintenant l'échange de blocs d'informa-

tions entre le SIP et le SL par accès direct à la mémoire. L'échange de

blocs d'informations est demandé explicitement par le PM au LCM lors-

qu'un tampon d'E/S est alloué à celui-ci. Ce tampon contient alors les directives concernant l'échange demandé. Le format d'un bloc de commande

est défini dans le Tableau III.

O O non significatif X

M I I I R H L

X X C N N P U X REP A X R X

N T S L N L

T T

1 PARAMETRES

Tableau III

mot 1 mot 2 mot 3 mot 4 * indicateur

I 'I

Données 1 Mot d'état Bit IT émission d'une interruption vers le CPU dès que l'opération de transfert a été effectuée (IT = 1). Dans ce cas le mot d'état est

transféré sur le bus au moment o la SST est exécutée par le CPU.

MAD 128, MAD 64: deux bits de poids fort définissant l'adresse de 128 K

mots.

Bit S indique le sens de l'échange.

Le mécanisme d'échange avec le SL est commandé par

un microprogramme stocké dans l'AC 60 du LCM 51. L'échange peut être ef-

fectué dès qu'un tampon d'E/S est alloué au LCM. Certains paramètres dé-

finissant le bloc de commande sont chargés dans les registres 66 'adres-

se mémoire) et 67 (adresse tampon). A la fin de l'exécution de la com-

mande, le PM 50 est informé par voie d'interruption.

Les protocoles de communication gérés par le CM 13 assurent l'échange d'informations et la coopération entre les différents SL connectés sur le réseau de communication, en suivant les principes ci-dessous.

i X-

1 O X - - - - - - - - - - - - -X

Adresse début de bloc I MAD MAD Longueur du bloc T S 128 64 X (8 bits) Adresse début dans tampon non (8 bits) significatif

1 1

- A chaque moment, n'importe quel SL peut commencer une communication

avec un autre (mode adressé) ou plusieurs autres SL (mode diffusé).

- Lorsque plusieurs SL sont concernés par le même message, celui-ci est

diffusé quand tous les SL concernés sont prêts à le recevoir.

- La cohérence du message est assurée quel que soit le débit d'informa-

tion des différents SL.

- L'ordre des événements globaux est maintenu identique au niveau de

chaque SL.

- Ni la connexion ou déconnexion, ni la défaillance, ni la différence de

débit entre SL ne cause une perturbation au niveau des autres SL.

La fonction principale du protocole de communica-

tion est d'identifier les partenaires concernés dans une communication

et de maintenir la cohérence du message pendant toute la communication.

Afin d'éviter la pénalité en temps ("overhead") due aux procédures for-

melles et de contrôler le débit d'information, le protocole de communi-

cation "deux parties" utilise une conception de liaison logique entre

partenaires. C'est-à-dire, après l'identification des partenaires concer-

nés et l'acceptation de la liaison par les destinations concernées, un message qui est fragmenté en paquets de taille prédéterminée peut être

échangé sans nécessité d'une nouvelle identification et acceptation jus-

qu'à la fin de la liaison logique.

Les différents types de liaison permis dans la pré-

sente invention sont montrés dans les figures 8a à Bd. La figure 8a mon-

tre une liaison logique unidirectionnelle entre SLi source (S) et SL% destination (D). Dans la figure 8b cette liaison logique entre SLi et SL. est bidirectionnelle (full duplex), c'est-à-dire que chaque SL émet

et reçoit simultanément. La liaison dans la figure Bc est multiple bidi-

rectionnelle entre SLi, SL. et SL., tandis que la liaison montrée dans

la figure Bd est une liaison diffusée et SLi (source) diffuse une commu-

nication à tous (SL., SLk, SLn et SLi lui-même).

Dans la présente invention, la liaison logique mul-

tiple source, o plusieurs SL source émettent vers un SL destination par-

ticulier est interdite afin d'éviter la surcharge du tampon d'entrée de la destination et d'éviter un chargement complexe de plusieurs messages

entrant simultanément.

Les.liaisons logiques entre SL sont prédéterminées au niveau de chaque SL. Les liaisons logiques montrées dans les figures

22 2476349

* 8a à 8c sont toujours permises tandis que la liaison Bd est permise seu-

lement via une table de connexion programmable (PCT)-. Le but de cette PCT est de définir les cadres qui seront analysés au niveau de chaque SL pendant un appel diffusé. Cette sélection est nécessaire afin d'éviter

la perturbation des SL qui ne peuvent pas tolérer ce mode de communica-

tion, ou qui n'appartiennent pas au même groupe d'applications que la

source concernée.

Les mécanismes d'échange entre le SIP 11 et le CM

13 sont maintenant décrits.

Le SIP utilise ses tampons d'E/S (256 mots) pour communiquer avec le CM par l'interface SIP/CM défini dans l'Annexe. Un tampon d'E/S contient les directives, paramètres et éventuellement les données à transmettre. Le CM est capable d'interpréter la commande reçue et de l'exécuter. Après exécution le CM charge un mot d'état, concernant

celle-ci, dans le tampon d'E/S ayant contenu la commande. Le CM a la ca-

pacité d'accéder directement sur les tampons d'E/S qui lui sont alloués.

L'allocation d'un tampon au CM est effectuée par émission d'une instruc-

tion d'E/S (écriture) vers celui-ci. Le contenu du bus spécifie alors l'adresse du tampon devant être traité et sa nature. Une fin d'exécution est signalée au SIP par l'envoi d'une interruption provenant du CM. Le SIP peut alors connaître l'adresse du tampon contenant le résultat en exécutant une instruction d'E/S (lecture). Deux tampons de sortie et

deux tampons d'entrée peuvent être simultanément alloués au CM. Ce der-

nier permet des transferts bidirectionnels, traite un bloc de chaque es-

pèce (d'entrée et de sortie) simultanément et enchaîne sur les tampons

en attente dès la fin d'exécution des tampons courants. Les tampons d'En-

trée/Sortie peuvent être situés dans tout l'espace mémoire adressable ac-

cessible par le bus SIP/CM (64 K mots).

Instructions d'Entrée/Sortie utilisées: Commande Ecriture

Cette instruction est utilisée pour synchroniser le module de communica-

tion (CM) en vue de l'exécution d'une commande explicitement décrite dans le tampon d'E/S associé. Quatre commandes différentes peuvent être distinguées:

1) Connexion d'un SL au réseau de communication. Dans ce cas des paramè-

tres relatifs aux communications prévues sont fournis.

2) Déconnexion de SL.

3) Emission de données. Se traduit par une demande d'émission d'un bloc

de données (< 64 K mots) avec spécification de paramètres d'émission.

4) Réception de données. Se traduit par la mise à disposition d'un bloc

vide (< 64 K mots) utilisé pour la réception de données entrantes.

Informations présentes sur le bus SIP/C[-1 pendant l'exécution de cette instruction: Bus adresses (SIP -> CM) sans signification 1 A 1 1 1 1 l 1 1 CM CM CM CM C M C2D CD CM1 à CM6 spécifient l'adresse du CM

CD1, CD2 indiquent la nature de la commande définie ci-dessous.

Pendant une commande directe le bus de données spécifie la commande.

Dans les autres cas le bus de données contient l'adresse du tampon à

exécuter.

Définition de bus de données pendant une commande directe CD2, CD1 = 1 0 > Bus de données 0 0 DEST. ADRESSE G P C (8 bits) (6 bits)

GPC: envoyer une commande de caractère général à la destination dé-

finie. Cette commande est interprétée par le CM et peut être utilisée pour des

actions différentes dépendant de la programmation du CM.

CD2 CD1 Nature de commande 0 0 Emission de données (indirecte) 0 1 Réception de données (indirecte) 1 0 Commande précisée sur Bus de données (directe) 1 1 Connexion (indirecte)

D16 D15 D1

o 1 Source adresse (6 bits) sans | l signif. D1 = 0 connexion de la source définie (création d'un canal logique)

D1 = 1 déconnexion de la source définie (suppression d'un canal logi-

que)

D16 D15

1 0 I Source adresse (6 bits) | sans signif.

Déconnexion générale du réseau de communication (la source travaille en

isolation par exemple).

Etat Lecture (SST) Cette instruction est utilisée pour synchroniser le SIP après exécution

par le CM d'une commande envoyée à celui-ci. Sur réception d'une inter-

ruption provenant du CM, le SIP exécute une instruction Etat Lecture et

récupère donc l'adresse du tampon exécuté.

Informations présentes sur les bus SIP/CM pendant l'exécution de cette instruction: Bus adresses (SIP -> CM) sans signification A

1 1 1 1 1 1 1 1 CM6 CM5 CM4 CM3 CM2 CM, 0 G

CM1 à CM6 spécifient l'adresse du CM.

Bus de données (CM + SIP) Bloc de connexion du SIP sur le réseau de communication: | Adresse du tampon exécutée dans la commande Ecriture mot 1 mot 2 mot 3 mot 4 mot 5 mot 6 mot 7 mot 8 mot 9 mot i La définition du bloc est la PSI: taille du paquet TTV: valeur de l'horloge (OT) suivante: de garde utilisée en émission à déterminer MNN indique le nombre de RNR maximum admis pendant lequel un SL

source répétera son appel après réception. Cette minuterie per-

met de détecter l'occupation permanente et anormale d'un SL ap-

pelé. RNR est un signal définissant que la destination (récep-

teur) n'est pas prête à accepter une transmission.

MORYN: nombre maximum d'essais en mode de sortie, définit le nombre maximum de réessais sur une erreur de parité ou sur détection de

AB avant de signaler une transmission impossible au niveau supé-

rieur.

MIRYN: nombre maximum d'essais en mode d'entrée sur une erreur de pari-

té ou sur détection de AB avant de signaler une réception impos-

sible au niveau supérieur.

Pour le mode diffusé le SL NO définit les SL connectés ou déconnectés, un maximum de 64 connexions étant possible. Le bit de poids plus faible

définit une connexion ou non.

Connexion Mot d'Etat (16 bits) X X PSI (8 bits) X X TTV (8 bits) X X MNN (8 bits) X X MORYN (8 bits) X X RTV (8 bits) X X MIRYN (8 bits) Longueur du bloc de connexion (CTL) _(6 bits) S L NOX X 0/1 (6 bits) S L NO X X O/i S L Nu X X /

26 2476349

OR = RTV.FD indique l'intervalle de temps maximum admis entre l'émis-

sion de deux mots par un SL origine. Cette minuterie permet de

détecter la défaillance du SL émetteur.

OT = TTV.FD indique l'intervalle de temps maximum au bout duquel tout

SL connecté doit avoir répondu lors d'un appel (ASK). Cette mi-

nuterie permet de détecter une défaillance du SL appelé lors d'un appel adressé et déclenche l'émission des données lors

d'un appel diffusé (synchronisation).

FD est une horloge de base située dans le TM.

Le mode de connexion permet de définir.des groupes fermés d'utilisateurs (d'applications) et permet d'interdire le mode diffusé pour des systèmes ne possédant pas de mécanisme de filtrage (SIP) en

fonction des capacités locales.

Pour modifier les paramètres de connexion il est nécessai-

re d'effectuer une déconnexion avant d'effectuer une connexion spécifiant

une nouvelle valeur des paramètres. Après une connexion le SIP peut ef-

fectuer une transmission.

Définition du bloc de transmission mot 1 W | B | TSW (transmission mot d'Etat) mot 2 Longueur du bloc de données (16 bits) mot 3 Adresse du bloc de données à transmettre (16 bits) mot 4 Cl C2 Adresse dest. (6 bits) Priorité niveau j de communication indicateur } Bloc de données W attendre RNR en mode diffusé

Si W = 0, sur réception de 1 RNR on n'attend plus, mais on émet le messa-

ge aux SL qui sont prêts.

Si W = 1, sur réception de 1 RNR on attend et on recommence l'appel.

B = 1: mode diffusé (broadcast)

B = 0: mode adressé.

En mode adressé l'adresse destination spécifie le SL des-

tination. En mode diffusé, si Adresse dest.:E O le message est destiné

à tous.

C2, Cl indiquent la situation du bloc dans le message comme décrit ci-

dessous.

La priorité du niveau de communication (8 bits) est uti-

lisée en cas de conflits (choix du plus prioritaire).

Après une transmission, un bloc définissant le résultat

de la transmission est constitué.

Définition du bloc de résultat mot 1 (TSW) OO | SL NO (6 bits) X X | 53|2 | mot 2 RODBL mot 3 RODBA Le résultat de la transmission est chargé dans le TSW (mot 1) du bloc de

transmission.

S1 = 1: réseau non opérationnel S2 = 1: SL appelé anormalement occupé

S3 = 1: défaut de transmission sur le réseau.

Le SL NO qui est la cause du problème en cas de mode diffusé est aussi

chargé en TSW.

RODBL: définit la longueur courante du bloc de données qui reste à

transmettre (chargé en mot 2) en cas de défaut.

RODBA: définit l'adresse courante du bloc de données à transférer en

cas de défaut (chargé en mot 3).

C2 Cl Situation du bloc O O Intermédiaire O 1 Début de message 1 O Fin de message 1 1 Message complet Après une connexion, un SL peut recevoir une émission d'un autre SL, soit en réponse à urie transmission, scit parce qu'un SL

particulier a quelque chose à émettre.

Définition du bloc de réception mot 1 RSWI O= 0 mot 2 Longueur du bloc de réception alloué au CM mot 3 Adresse du bloc de réception Espace libre pour réception des données

RSW: mot d'Etat de réception initialement à zéro.

Définition du résultat d'un bloc de réception mot 1 RSW Source Adresse (6 bits) X - X 3 S2 St mot 2 X X mot 3 X X C2|1 C| Source Adresse Longueur du paquet (8 bits) Paquet C21Cl| Source Adresse | Longueur du paquet (8 bits) Paquet 0 0 10 t 0

Le résultat est chargé dans le RSW (mot 1).

S1 = 1: réseau non opérationnel S2 = 1: transmission erreur

S3 = 1: défaut de réception sur le réseau.

En cas de défaut, l'adresse de la source est chargée. Les mots 2 et 3 dans le bloc de réception sont gardés sans modification. Les

données par paquet sont chargées dans l'espace alloué au CM. La signifi-

cation de C2 C1 est comme définie. PlusieJrs paquets peuvent etre recus-

chacun défini par sa longueur et son adresse de source. A la fin d'un

paquet le mot chargé avec les zéros définit la fin de la réception.

29 2476349

Implicitement la commande sera considérée comme étant ex& cutée a - si le tampon d'entrée est plein, b - après la fin d'un paquet en cours de réception si un autre tampon est alloué, c - sur réception d'une fin de texte (ETX),

d - sur détection d'une défaillance.

On décrit maintenant l'architecture de la couche fonc-

tionnelle de communication et le module de communication CM 13 lui-même.

Deux types de mots peuvent être distingués: - Les mots de données qui ne sont pas interprétés (traités) au niveau du

CM (CM transparent). - Les mots de supervision (contrôle) qui permettent la gestion des pro-

tocoles de communication au niveau du CM.

Donc, le format d'un mot est défini ci-dessous 16 bits C | K Données ou supervision C: bit de parité

K: type de mot; K = 0, données; K = 1, supervision.

Le Tableau IV définit le codage et les fonctions des mots de supervision qui sont nécessaires pour contrôler les liaisons logiques

entre les sources et destinations.

Tableau IV

Supervision Codage C 1 0 0 Adresse Communication Requête pour envoyer un paquet

destination niveau d'un message (ASK).

C 1 i 0 Adresse GPC Code Commande de caractère général

destination (GPC).

C 1 1 i 1 1 1 1 i1 1 1 1 1 i 1 1 Motd'initialisation(IW).

C 1 1 1 Adresse O O O O 0 O O 0 Destinationn'est pas prête

destination (RNR).

C 1 1 1 Adresse 0 0 0 0 0 0 0 I Destination prête en mode

destination adressé (RRA).

C 1 1 1 Adresse O O O O O O 1 1 Destination prête en mode

destination diffusé (RRB).

C 1 i 1 Adresse O O O O O 0 1 0 Coupe communication (AB).

destination, C 1 1 1 Adresse O O O O O 1 1 0 Signal demandant une rupture de

destination liaison logique (BR).

C 1 1 1 Adresse O O O O O 1 0 0 CM synchronisation (SY).

destination

C 1 1 1 Adresse 0 O O O O 1 0 1 Réessai paquet commande (RY).

destination C I 1 1 1 O O O O O t 1 0 0 0 0 0 0 0 REPOS

C 1 0 1 Réservé Communication Appel à tous (ASK diffusé).

_! niveau ASK: envoyé par la source pour demander l'établissement d'une liaison

logique soit à une destination adressée soit à tous.

GPC: commande de caractère général envoyée par la source et utilisée

pour commander à distance certaines parties des SL.

IW: envoyé par la source pendant la phase d'initialisation, utilisé pour synchroniser la boucle de phase (PLL) sur le bus optique et

pour assurer la transmission des mots dans les canaux alloués au SL.

-1 2476349

-31 RNR: envoyé par la destination lorsqu'une requête de communication est

refusée à cause de son incapacité temporaire à stocker un paquet com-

plet.

RRA: envoyé par la destination et indiquant l'acceptation, après sélec-

tion, d'une communication dans le mode adressé.

RRB: envoyé par la destination et indiquant l'acceptation, après sélec-

tion, d'une communication dans le mode diffusé. Cette supervision est utilisée par les destinations qui ont perdu leur synchronisation,

afin de se resynchroniser.

AB: envoyé par la destination et utilisé, soit pour annuler une super-

vision ou un paquet de données sur détection d'erreurs, soit pour

annuler une liaison logique à cause du silence anormal d'une source.

BR: envoyé par la source et utilisé pour interrompre une liaison logi-

que à la fin du transfert d'un paquet, soit parce que la source dest pas prête à émettre un nouveau paquet, soit lorsque le dernier mot

d'un message est envoyé.

SY: envoyé par la source et utilisé pour syncnroniser toutes les desti-

nations afin d'éviter la dispersion des réponses RR pour le mode dif-

fusé.

RY: envoyé par la source et utilisé pour indiquer que le paquet de don-

nées suivant est un paquet récupéré.

Les interfaces physiques entre le CM et le SIP, le CM et

le TM, sont définis dans l'Annexe.

La figure 9 est un bloc diagramme fonctionnel du CM 13

et montre les éléments principaux avec leurs connexions (données, adres-

se et contrôle). Le CM 13 est en principe un chemin de communication phy-

sique entre le SIP 11 et le réseau de communication, via le TM 15,

contrôlé par trois éléments principaux travaillant en parallèle: le con-

trôleur d'interface bus avec le SIP (BIC) 90, le séquenceur au niveau

bloc (BLS) 91, et l'automate au niveau paquet (PLA) 92.

Le BIC 90 est chargé du contrôle d'interface SIP/CM, de

l'interprétation de commandes venant du SIP et de l'accès sur l'interfa-

ce SIP/CM pour l'échange de données directement entre les boîtes aux let-

tres (MB) du CM et les tampons d'Entrée/Sortie du SIP.

Le BLS 91 analyse et exécute les commandes venant du SIP

et retourne les résultats à ce dernier dès que les commandes sont complé-

tement exécutées, ou lors d'événements anormaux. Les commandes acceptées par le BLS 91 sont: connexion d'un SL sur le réseau de communication,

transmission d'un bloc de données, réception d'un bloc de données, émis-

sion d'une commande de caractère général (GPC), connexion ou déconnexion

du SL à un SL distant défini, déconnexion d'un SL du réseau de communi-

05. cation, comme déjà décrit.

De plus, le BLS reprend l'échange de données sur détec-

tion d'une erreur et reprend aussi un appel (ASKi sur réponse RNR. Le

nombre maximum de réessais est défini dans le bloc de connexion.

Le PLA 92 est chargé du contrôle des liaisons logiques

sous directives du BLS 91.

Les autres éléments de la figure 9 sont brièvement dé-

crits. Les boites aux lettres de sortie (OMB) et d'entrée (IMB) sont re-

présentées par 93 et 94 et le tampon d'adresse du SIP (SIPAD) par 95. Un groupe de 32 registres de type "scratch pad" (SP) est représenté par 96 et mémorise des paramètres. Les portes logiques 97 font l'interface sur le bus interne Bloc Interface Bus (BIB) 98, l'unité arithmétique (AU)est

99. Les compteurs 100 et 101 représentent respectivement les deux horlo-

ges OR et OT. Le registre transparent 102 conserve la valeur RTV. Un compteur paquet réception sémaphore.(PRS) définissant la taille du paquet en réception est représenté par 103 et une mémoire 104 (256 W x 1 bit) contient la table de connexion (CT) Le multiplexeur (MX) 105 permet un accès multiple à la CT. L'adresse de la source courante est chargée dans le registre (SAD) 106, celle-ci étant utilisée à la fin du transfert d'un paquet. Un registre 107 (DAD) spécifie l'adresse de la destination, et le registre 108 (DPL) le niveau de priorité de la communication en sortie. Les portes logiques 109 et 110 font l'interface CM/TM (adresse, source et destination), tandis que les FIFO 111 et 112 (mémoire de type premier à entrer, premier à sortir) sont les FIFO d'entrée (IFIFOG et de sortie (OFIFO), chacune ayant la capacité de stocker au moins un paquet complet de données. Un registre d'entrée (latch) est représenté par 113,

et une PROM (mémoire morte programmable) qui contient le champ de comman-

de des mots de supervision est représentée par 114. Le bus interne PBB

(paquet bloc bus) assure l'interface entre les niveaux bloc et pa-

quets.

La figure 10 est un diagramme synoptique montrant le che-

min de données à travers le CM. Les données venant d'une source sélec-

tionnée (données d'entrée) sont transférées par PLA 92, du registre d'en-

trée 113 dans IFIFO 111 qui peut stocker un paquet complet (RR est en-

voyé à la source lorsque IFIFO a une capacité adéquate pour stocker un

paquet). Les données passent à travers IFIFO 111, et le BLS 91 a la res-

ponsabilité de transférer un mot de données vers le tampon d'entrée du SIP alloué, via l'AU 99, les portes logiques 97 et les portes logiques 97 et l'IMB 94. Cette dernière est contrôlée via le BIC 90 qui demande le bus CM/SIP et effectue le transfert physique du mot de données. L'adres se courante du tampon d'entrée du SIP est chargée dans le registre

d'adresse (SIPAD) 95 par le BLS 91.

Dans le mode de sortie, dès que l'OFIFO 112 a la capaci-

té de stocker un mot, une requête de sortie est envoyée au BLS, qui à son tour demande au BIC de transférer un mot du tampon de sortie, du SIP dans l'OMB 93. Dès que le mot est chargé dans 0MB 93, le BIC active un "flag" (bit) pour informer le BLS. Ce dernier commande le transfert du

mot de données à travers le SP 96 dans OFIFO 112. Le mot de données pas-

se à travers OFIFO et est envoyé sur le réseau de communication par le PLA dès qu'un paquet complet est chargé dans OFIFO, ceci étant effectué

au moyen d'une requête de transmission (RTS), activée par le BLS.

Les différents éléments mentionnés sont contrôlés par les microcommandes (/uc) appropriées des BIC, BLS et PLA. Les chemins de

données sont montrés par les lignes en pointillés. L'AU 99 est un comp-

teur de 16 bits qui, après chargement d'une valeur, peut effectuer les opérations d'incrémentation ou de décrémentation sur cette valeur, le passage par 0 de la valeur étant détecté par un signal BORROW (passage à 1). L'AU est utilisée afin de mettre à jour les adresses et les longueurs

des blocs de données en cours de transfert (entrée et sortie), de décou-

per les blocs de données en paquets, de reconstituer les paquets et de compter le nombre de réessais pendant une transmission ou une réception

de bloc. Les portes logiques 97 de type trois états permettent le con-

trôle du bus interne BIB 98.

Les paramètres de commande relatifs aux connexions et transferts sur exécution sont mémorisés dans le SP 96 et la mise à jour

est faite pendant l'exécution de commandes. L'organisation de ces para-

mètres dans le SP 96 est montrée dans le Tableau V et leur définition est donnée ci-dessous. Quelques adresses dans le SP 96 sont vides, ce qui donne la possibilité d'ajouter d'autres paramètres ou de les utiliser

pour les opérations temporaires.

34 2476349

Les paramètres PSI, TTV, MNN, MORYN, RTV, MIRYN, RODBL

et RODBA sont définis dans la description des mécanismes d'échange entre

le SIP et le CM.

CTL: compteur qui spécifie la longueur courante de la CT 104. Initia-

lement CTL est chargé de la longueur de la table de connexion pen-

dant le traitement d'une commande de connexion, et est décrémenté chaque fois que l'état d'un canal est chargé dans CT. Lorsque CTL

est O la mise à jour du CTL est terminée.

CNN: compteur qui spécifie le nombre courant de réessais sur une ré-

* ponse RNR. Il est décrémenté chaque fois après réception d'une ré-

ponse RNR pendant une phase d'appel (sauf dans l'état WAIT.RNR).Dès

que la liaison logique demandée est établie, ce compteur est rechar-

gé avec MNN. Si CNN = O, un mot d'état "destination occupée" indi-

quant l'impossibilité de la transmission est envoyé au niveau supé-

rieur.

CIRYN: nombre de réessais courant en réception. Ce compteur indique le

nombre d'erreurs pendant la réception d'un paquet. Initialement chais-

gé avec MIRYN il est décrémenté sur chaque erreur détectée. Si CIRYN = 0, un mot d'état "défaut de réception" est envoyé au niveau

supérieur.

CORYN: spécifie le nombre de réessais courant sur une erreur de parité ou sur AB détection, pendant une transmission d'un paquet de données Dès qu'un paquet de données est transféré complètement, ce compteur

est encore chargé avec MORYN. Si CORYN = O un mot d'état "transmis-

sion impossible" est envoyé au niveau supérieur.

IEPL: spécifie la longueur effective du paquet en réception, qui est utilisée pour indiquer la taille du paquet reçu, cette valeur étant

associée à chaque paquet de données chargé dans IFIFO.

IEPLR: spécifie la longueur effective du paquet à récupérer. Celle-ci

est utilisée lorsqu'une erreur de parité est détectée, pour suppri-

mer, pendant la récupération du paquet, la partie qui a été correc-

tement reçue avant l'erreur.

OEPLN: spécifie la longueur effective du paquet en émission, et permet à un bloc d'être divisé en paquets. Initialement ce compteur OEPLN est chargé avec PSI, et chaque fois qu'un mot est chargé dans OFIFO, OEPLN est décrémenté. Dès que OEPLN = 0, un bit d'état EOP (fin de

paquet) est chargé avec le dernier mot dans OFIFO, et RTSest activé.

CIEPLR * compteur qui spécifie la valeur courante de IEPLR pendant la

récupération d'un paquet.

NOBSA: spécifie l'adresse début du prochain bloc en émission à trans-

férer. Ce bloc est pris en compte dès que le bloc courant est trans-

féré.

NIBSA: spécifie l'adresse début du prochain bloc en réception alloué.

Ce bloc est chargé avec les données entrantes dès que le chargement

du paquet courant est effectué dans le tampon d'entrée.

COBSA: spécifie l'adresse début du bloc en émission courant.

CODBL: spécifie la longueur du bloc de données courant à émettre.

NODBL: définit la longueur du prochain bloc de données à émettre.

CODBA: définit l'adresse courante du bloc de données à émettre.

NODBA: définit l'adresse début du prochain paquet de données à émettre.

CIBSA: définit l'adresse début du bloc courant de données en réception.

CIDBL: définit la longueur courante du bloc de données en réception.

CIDBA: définit l'adresse courante du bloc de données en réception.

CWA: définit l'adresse du mot réservé, pour charger les caractéristi-

ques relatives au paquet reçu (numéro de la source et longueur du

paquet par exemple).

TDATA: définit un mot réservé pour stocker temporairement des données

en transit entre 1'OMB 93 et l'0FIFO 112.

SLADR: définit un mot, réservé pour stocker temporairement une comman-

de GP-C ou l'adresse de la destination et le niveau de priorité en

transit avant son chargement dans l'OFIFO 112.

Tableau V

mot 1 mot 2 mot 3 mot 4 mot 5 mot 6 mot 7 mot 8 mot 9 mot 10 mot 11 mot 12 mot 13 mot 14 mot 15 mot 16 mot 17 mot 18 mot 19 mot 20 mot 21 mot 22 mot 23 mot 24 mot 25 mot 26 mot 27 mot 28 mot 29 mot 30 mot 31 mot 32 a PSI! I

TTV |

MNN i

IMORYN

RTV MIRYN CTL CNN CORYN CIRYN t IEPL IEPLR

DOEPLN

CIEPLR

NOBSA NIBSA COBSA CODBL RODBL NODBL CODBA RODBA NODBA CIBSA CIDBL CWA CIDBA

TDATA.

SLADR

ADRESSE O

ADRESSE 31

v2476349 Le BIC 90 est un automate de type "Moore" permettant de contrôler l'interface avec la couche supérieure, c'est-à-dire la couche fonctionnelle gérée par le SIP. Les fonctions précises du BIC 90 sont

définies ci-dessous.

Sur une requête venant du BLS 91 - Emission d'une interruption au niveau supérieur (SIP) afin de fournir

un mot d'état contenu dans l'IMB 94.

- Demande pour contrôler le bus CM/SIP à accès direct sur les tampons

d'Entrée/Sortie du SIP pour lire/écrire un mot.

" Sur les instructions d'Entrée/Sortie venant du niveau supérieur (SIP) Réponse à une commande d'écriture et chargement d'OMB 93 avec le contenu du bus CM/SIP, suivi par l'activation d'un bit de signalisation

pour synchroniser le BLS 91.

- Réponse à une commande de lecture en transférant le contenu d'IMB 94.

Le SP 96 est un groupe de 32 registres d'accès aléatoire (mot 1 à mot 32). Les paramètres qui sont chargés dans les mots 1 à 14

utilisent seulement B bits d'un mot chacun, tandis que les autres para-

mètres utilisent la capacité complète du mot (mots 17 à 32). Certains mots (mots 15, 16 et 30 par exemple) ne sont pas utilisés mais peuvent

l'être ultérieurement pour mémoriser de nouveaux paramètres.

La figure 11 montre la strcuture du BIC 90. Dans la figu-

re 11, 120 représente un FPLA (arrangement de circuits logiques program-

més) dont les sorties sont liées à un registre d'état 121. Le registre 121 est à son tour relié à l'entrée du FPLA 120 et à une PROM 122. En

fonction de l'état actuel du FPLA 120 (contenu du registre 121) et d'in-

formations venant du BLS 91 et de l'interface CM/SIP, le registre 121 est

chargé avec l'état suivant, qui sélectionne les microcommandes Muc) ap-

propriées de la PROM 122. Ces microcommandes sont émises vers les élé-

ments concernés tels le BLS 91, les boites aux lettres, le SP 96 et l'in-

terface CM/SIP.

Le BLS 91 a la responsabilité d'exécuter les commandes venant du niveau supérieur. Celles-ci sont exécutées à l'aide des BIC et PLA travaillant en parallèle avec le BLS. Les commandes venant du niveau supérieur sont directement communiquées du BIC au BLS qui les exécute et

envoie un mot d'état au niveau supérieur à la fin de l'exécution. Pen-

dant l'exécution, le BLS traite les événements venant du niveau du PLA.

Le BLS peut exécuter le transfert bidirectionnel des données et peut en-

chalner les blocs de données (en émission et en réception).

La figure 12 montre la structure du BLS 91, qui est un automate microprogrammé. La PROM microprogrammée 125 a une taille d'au moins 1024 W x 40 bits et contient toutes les microcommandes 5uc) pour contrôler les diverses séquences et fonctions contrôlées par le BLS, c'est-à-dire les microcommandes et événements transmis aux BIC 90 et PLA

92, et au séquenceur d'état (SS) 126 du BLS qui est un FPLA. Le séquen-

ceur d'état 126 évolue dans l'état suivant en fonction de son état cou-

rant mémorisé dans un registre (CSA) 127 et de la microcommande de la

PROM 125.

Les débuts d'adresse des séquences à exécuter sont char-

gés dans un FPLA adresse début de séquence (SSAD) 128, soit par /UCS (dans l'état de repos), soit en fonction de l'état du séquenceur et des événements venant du BIC 90 et du PLA 92 (E.BIC + E.PLA). Ces adresses

qui sont prises en compte à la fin des séquences courantes, sont trans-

férées dans le registre adresse courant (CAR) 129 qui agit directement

sur la PROM 125. La PROM 125 a une partie associée avec les microcomman-

des (32 bits) et les parties d'adresse inconditionnelle INAD1 et INAD2 (4 bits chacune); INAD1 et INAD2 sont contrôlées par les microcommandes /ucI1 etucI2 lorsqu'une adresse directe est fournie. Une commande de

priorité venant du BIC doit être exécutée pendant l'exécution d'une sé-

quence du BLS; chaque commande venant du BIC via le SS 126 (montré par

CBR) a la priorité la plus élevée pour que l'OMB puisse être libérée.

Dans ce cas, le contenu d'INADl et/ou d'INAD2 est concaténé (compacté) avec le bit CBR (+ 256 défini par le bit d'adressage CBR) et devient la prochaine adresse (adresse du branchement). L'adresse courante au moment

de l'interruption de la séquence est mémorisée dans un registre d'adres-

se retour (RAR) 130, pour que la séquence en question puisse être exécu-

tée plus tard. Dans le cas d'un branchement conditionnel (la fin du transfert du paquet par exemple) le bit de condition BITT est testé dans BAR 131 (registre d'adresse de branchement) ce qui permet d'effectuer un

branchement conditionnel vers la microinstruction appropriée. Les micro-

commandes/ucR et/ucB contrôlent RAR 130 et BAR 131 respectivement.

Le signal IDLEN définit le bit d'adressage de poids fort

de la PROM 125. Lorsque IDLEN = O, l'automate du BLS est inactif et ce-

lui-ci attend une commande de connexion (adresse O - 255 de la PROM 125).

Sur réception d'une commande de connexion (CBR = 1) la séquence de con-

nexion est exécutée (adresse 256 - 511). A la fin de l'exécution de cet-

te séquence, l'automate devient actif (IDLEIN = 1) et les différents évé-

nements peuvent être pris en compte, entraînant l'exécution de séquences situées dans la PROM (adresse 512 - 767). Dans le cas d'une commande de

priorité provenant du BIC, l'adressage de la PROM 125 évolue dans la zo-

ne 768 - 1024 (adresse courante + 256).

Le BLS 91 travaillant en parallèle avec le BIC 90 et le PLA 92 contrôle l'exécution des séquences suivantes: séquence 1: chargement des paramètres de connexion du tampon d'E/S du SIP dans le SP 96 et dans la CTI 104 relative à un bloc de données

pour émission.

séquence 2: chargement de l'adresse de début du prochain bloc pour émis-

sion dans le SP 96 au commencement de l'émission du bloc courant.

séquence 3: initialisation de l'émission du bloc courant.

séquence 4: division du bloc d'émission courant en paquets, chargement des paquets dans l'OFIFO 112 suivi par une demande de transmission

du premier paquet.

séquence 5: chargement du nombre de réessais à effectuer dans le SP 96

si l'appel pour transmission n'est pas accepté.

séquence 6: demande de retransmission du paquet sur réception de RNR de la ou des destination(s) si, après décrémentation,le paramètre de réessai n'est pas à zéro. Avertissement du SIP si le paramètre

de réessai atteint zéro.

séquence 7: chargement de la valeur de l'horloge de garde en émission

dans le compteur eT définissant si rien n'est reçu de la (des) des-

tination(s) relative(s) à un appel pendant OT.

séquence 8: réessai d'une transmission sur détection d'une faute de

transmission, si le paramètre de réessai après décrémentation n'at-

teint pas zéro. Avertissement du SIP si ledit paramètre atteint zéro.

séquence 9: avertissement du SIP d'une transmission aboutie.

séquence 10: soit retransmission d'un paquet, soit abandon et avertis-

sement du SIP, si le paramètre de réessai atteint zéro après décré-

mentation. séquence 11: avertissement du SIP lorsque le réseau de communication

est non opérationnel.

séquence 12: chargement d'une commande GPC dans l'0FIFO 112.

séquence 13: mise à jour de la CT 104.

séquence 14: chargement d'adresse de début d'un bloc en réception dans

le SIP.

séquence 15: initialisation des paramètres relatifs au bloc en récep-

tion. séquence 16: assemblage des paquets en réception dans l'IFIFO 111 et

leur chargement dans le tampon d'E/S du SIP alloué.

séquence 17: décrémentation du paramètre de réessai en réception sur dé-

tection d'une erreur de parité. Evolution vers l'état de réessai si ledit paramètre n'est pas à zéro, avertissement du SIP s'il atteint

zéro.

séquence 18: mise à jour des paramètres de réessai et de récupération

sur détection d'une erreur de parité.

séquence 19: avertissement du SIP sur détection d'un silence anormal de

la source.

séquence 20: assemblage des paquets en réception dans l'IFIFO 111, sur détection d'une requête de réessai de la source, suivi par leur

chargement dans le tampon du SIP alloué.

séquence 21: avertissement du SIP lorsque le réseau de communication en

réception est non opérationnel.

Le PLA 92 est composé des quatre éléments suivants - l'automate de transmission (TA) responsable pour la transmission de paquets sous contrôle du BLS 91; - l'automate de réception (RA) responsable pour la sélection de sources

(contrôle du début de transmission) et pour la réception de paquets va-

lides;

- l'automate de niveau mot (WLA) responsable pour émettre les mots dety-

pesdivers (données, GPC, supervision des destinations, supervision des sources, etc.) dans les canaux des SL appropriés, lesdits mots venant des TA et RA;

- un décodeur pour le décodage des informations en provenance du TM.

La figure 13 montre la structure du PLA 92. Tous les au-

tomates du PLA sont des automates de type "Moore" comme déjà décrit pour le BIC 90 (figure 11). Dans la figure 13, les automates TA, RA, et WLA sont représentés par 140, 141 et 142 respectivement. Les FPLA et les PROM de TA, RA et WLA sont représentés par 143, 144, 145 et par 146, 147 et 148 respectivement. Les registres d'état liés avec le FPLA (entrée et

sortie) et la PROM de chaque automate sont montrés de 149 à 151. Le dé-

codage des informations venant du TM est effectué par un décodeur de

mots (WDEC) 152. La communication entre les automates et les niveaux su-

périeur (BLS) et inférieur (TM) est décrite dans le Tableau VI ci-des-

sous. Tableau VI

Le TA 140 se compose de deux parties spécialisées: l'au-

tomate TPA chargé de la transmission de paquets et l'automate TTA chargé d'analyser et de synchroniser les supervisions venant des destinations, ces deux automates travaillant en synchronisation. Le TA contrôle les phases principales suivantes des liaisons logiques en mode adressé et diffusé: REDY (prêt à transmettre), CAL (appel de la ou des destination(s) ), CALAG (rappel de la ou des destination(s)), SND (transmettre un paquet) ,

WAT (attendre une réponse cohérente), CLOS (fermeture de la liaison logi-

que), DEL (supprimer les données déjà correctement transmises dans les

conditions appropriées).

Le RA 141 contrôle les mécanismes de sélection relatifs

à l'état de la destination, c'est-à-dire que la prochaine liaison logi-

que et la réponse envoyée à la source sont effectuées en fonction: de l'état courant de la destination (état repos ou occupé),du type de la

liaison logique (adressé ou diffusé) et du type de la liaison logique dé-

jà établie (adressé ou diffusé). De plus, le RA est responsable pour re-

synchroniser la destination en mode diffusé en cas de perte de synchro-

nisation, en analysant les réponses des autres destinations synchronisées Automate Entrant de Sortant à

TA BLS BLS

WLA

WDEC WLA

RA BLS BLS

WLA WLA

WDEC

WLA TA TA

RA RA

TM (interface)

L'automate RA contrôle les séquences d'événements nécessaires pour la ré-

ception de paquets valides, ou dans le cas contraire, si un paquet n'est pas correctement reçu, pour avertir les modules appropriés (comme le SIP, le BLS, etc.). Dans ce cas, soit le paquet en question est réémis par la source, soit la communication est abandonnée en cas d'impossibilité de transmission. Le WLA 142, sur requête venant du TPA du TA, charge les canaux appropriés avec l'information d'émission (données ou supervision), ou l'information de réception (supervisions) nécessaire pour contrôler les liaisons logiques bidirectionnelles. Les supervisions de réception

ont une priorité supérieure aux supervisions d'émission.

La figure 14 est un diagramme synoptique du CM au point de vue contrôle. Au niveau 1 (BIC) le contrôle de l'interface physique

SIP/CM est effectué par le BIC 90. Au niveau 2 (bloc), l'accès direct bi-

directionnel ("full duplex") des tampons d'E/S du SIP, le contrôle encas

de réessai et de défaut, et la division des blocs en paquets sont effec-

tués par le BLS 91. Au niveau 3 (paquet) le contrôle des protocoles de communication est effectué par les TA 140 et RA 141 du PLA 92. Au niveau

4 (mot), le contrôle des mots de types différents en émission et récep-

tion, et le contrôle d'interface physique CM/TM sont faits par les WLA

142 et WDEC 152 du PLA 92. Les flèches définissent les directions de con-

trôle et de communication entre les différents éléments et niveaux. A chaque niveau, les événements particuliers définissent la communication

avec le niveau supérieur et inférieur.

La figure 15 est un diagramme de synchronisation de l'in-

terface CM/TM. Les trames et les cadres dans une trame (FS) sont fournis par le TM. Chaque trame (F) consiste en N cadres en émission T1, T2...TN et N cadres en réception R1, R2... RNo N dépend du nombre des SL liés

sur le réseau de communication.

Phase d'initialisation La phase d'initialisation (synchronisation etcalage des données dans le bon cadre) est signalée par ECM (fin de calage) venant de TM, qui est remis à zéro dès que le TM est opérationnel. Lorsque le TM n'est plus opérationnel (décalage ou désynchronisation) l'événement NOTOP apparaît, ECM est mis à 1, et une information sur l'état du TM est

envoyée au SIP.

Phase de réception des données Cette phase est indiquée par le signal RCI = 1 provenant

du TM. Durant cette phase tous les mots reçus sont mémorisés dans un re-

gistre type D du WDEC 152, sur le front montant de FCM (horloge de ré-

ception venant du TIMl) et analysés jusqu'au front montant suivant (adres-

se, code, etc.). Les données en réception provenant du TM consistent en

18 bits (16 bits de données AlO à A15, + 1 bit de parité P, + 1 bit spé-

cifiant la présence ou l'absence d'une erreur E).

Phase d'émission des données

Le TM fournit au CM une impulsion de référence REFM per-

mettant de préparer les données en avance afin de les transmettre dans le cadre sélectionné par le CM (3 cadres en avance). Le CM peut utiliser

plusieurs cadres non consécutifs en fonction d'une allocation fixe effec-

tuée au niveau de chaque CM. En fonction des cadres alloués au CM, celui-

ci peut envoyer une demande pour émettre (RTS) afin de transmettre ses

mots qui doivent être stables pendant RTS. Le TM effectue la transmis-

sion par une horloge d'émission FREFM. Les données en émission provenant du CM consistent en 17 bits (16 bits de données A0O à A015, + 1 bit de procédure K). La figure 15 montre l'émission des données dans le cadre T2 par exemple. La division d'une trame (F) dans les phases d'émission et de réception permet à tous les SL désirant communiquer, d'émettre dans

leurs cadres propres pendant la phase d'émission et ensuite, le TM réé-

met les mêmes informations pendant la phase de réception permettant à

tous les SL de recevoir les communications qui leur sont destinées. Pen-

dant la phase d'émission le WLA 142 est responsable de la synchronisa-

tion, c'est-à-dire de la génération de RTS et de la stabilité des don-

nées. Pendant la phase de réception le WDEC 152 mémorise et analyse les

mots en réception.

La couche de transport physique 18, montrée dans la fi-

gure 16, est constituée d'un bus optique 16, des modules de transmission TM 15, du boudeur (LIG) 7 et d'uncoupleur passif 160. Le bus optique 16 est formé de fibres optiques à gradient d'indice, diamètre coeur

/um, diamètre "cladding" 100/um à gainage plastique. Son ouverture nu-

mérique est de 0,2. La longueur totale du bus peut atteindre quelques km.

Ce bus est prévu pour réaliser l'interconnexion de 8 SL au maximum, cha-

cun travaillant à un débit de -à 350 K mots/S. Le coupleur passif 160 est un connecteur de 4 voles en croix comme montré dans la figure 17, avec

une lame séparatrice 161 dont le traitement (miroir) détermine le coeffi-

cient de couplage. Le coefficient de couplage du coupleur 4 voies étant différent de 2 pour des raisons de bilan de liaison, le signal vu en 2 venant de 1 doit avoir la même amplitude que celui vu en 2-venant de 4

{modulation à 2 niveaux), le signal vu en 3 venant de 1 est bien infé-

rieur à celui vu en 3 venant de 4. Des limiteurs écrêteurs permettent ensuite de séparer les voies transversales P3,1 et directes P3,4. Le TM et le LIG 17 sont nécessaires pour assurer la synchronisation et le

transport physique des bits d'information.

La figure 18 est un bloc diagramme fonctionnel du TM 15

qui est composé de deux parties: -

1) Une partie logique dont les fonctions sont les suivantes synchronisation au niveau bit - synchronisation au niveau mot synchronisation au niveau trame - base de temps - codage-décodage multiplexage-démultiplexage - initialisation et calage temporel

- détection d'erreurs.

Du fait de la haute vitesse de transmission cette partie est réalisée

en grande partie en logique ECL 10000.

2) Une partie analogique assurant les fonctions suivantes - émission et conversion électro-optique - réception et conversion optoélectronique récupération d'horloge - régénération des signaux

*- détection de synchronisation.

Dans le mode émission, les données provenant du CM 13 et devant être émises par le TM 15 sont codées (codeur 3B-4B) pour les raisons suivantes: - maintien de la composante continue constante (c'est-à-dire autant de niveau 1 que de niveau 0), - utilisation de symboles réservés pour les en-têtes de trame,

- possibilité de récupérer le rythme sur le flot de données.

Le code 3B - 4B montré dans le Tableau VIa est un bloc code binaire qui transforme un mot binaire de longueur 3 (bl, b2, b3) en un mot codé (ai,, a2 a3, a4) composé par 4 symboles binaires. Ce code

est très utile dans la transmission optique pour les raisons déjà men-

tionnées et parce que la redondance dans ce code réduit la fréquence

d'erreurs. Deux modes de ce code sont possibles.

Tableau VIa Code 3B - 4B Mot Binaire Mode 1 Mode 2

000 0101 0101

001 1001 1001

010 1 1 1 0 0 0 01

011 1101 0010

0111 1000

101 1011 0100

0110 0110

111 1010 1010

Le codeur 3B - 4B est réalisé à l'aide des PROM (32 mots x 8 bits chacune) 170 et transforme 18 bits en 24 bits. Un bit de parité est calculé dans un circuit 169 sur les mots émis par le CM, et

ajouté aux 17 bits d'information. Les informations codées sont alors sé-

rialisées par un registre à décalage en sortie (RDS) 171 et émises vers la fibre optique à travers un élément de retard (T) 172, permettant d'ajuster le positionnement de mot de données dans son cadre (procédure

d'initialisation). Le circuit d'attaque analogique (CA) 173 permet d'ap-

pliquer le signal sur la diode laser (DL) 174, qui est polarisée et ré-

gulée par un élément de polarisation et régulation (POLDL) 175. La diode

laser (DL) 174 à 0,85/um de longueur d'onde fait la conversion électro-

optique vers la fibre optique.

En mode réception, la conversion optoélectronique de don-

nées (détection) est réalisée par une photodiode à avalanche (PDA) 176.

Un convertisseur DC-DC, élément ALHT 177, produit la haute tension

(= 200 V) nécessaire à son fonctionnement et stabilise le gain d'avalan-

che en fonction de la température et des variations d'alimentation. Le

signal converti est alors amplifié et régénéré par un circuit d'amplifi-

cation (DAE) 178. Le signal amplifié peut alors attaquer un intégrateur de commande (COMTRIAC) 179 permettant la détection de lumière, ce qui commande la mise sous tension du reste du TM et du CM au moyen d'un

triac 180.

Le signal en sortie de DAE 178 subit un traitement non linéaire par un élément (TNL) 181, de façon à faire apparaître des raies à une fréquence multiple de la fréquence bit. Les raies sont appliquées à une boucle de verrouillage de phase (PLL) 182 contenant un oscillateur

de contrôle de tension (VCXO), ce qui-permet de maintenir l'horloge lo-

cale (TM) synchronisée avec l'horloge du LIG 17. L'horloge bit ainsi ré-

cupérée est appliquée à un circuit de décision 183,permettant de récupé-

rer le flot de données reçu en série, o le seuil et l'instant d'échan-

tillonnage sont contrôlés. La transformation série-parallèle est effec-

tuée par le registre à décalage (RDE) 184 et les 24 bits de données enpa-

rallèle sont appliqués à un décodeur 4B-3B 185, également réalisé à l'ai-

de des PROM (32 mots x 8 bits chacune).La parité est calculée sur les

données reçues et comparée,dans un circuit comparateur 186,au bit de pa-

rité calculé en émission. Si une différence est trouvée, une information

erreur (ER) est transmise au CM.

Le séquenceur d'état (SFQ) 187 qui est un automate pro-

grammé, contrôle la séquence d'initialisation entreprise par le LIG 17 et gère les trames d'Emission/Réception par détection de l'en-tête et comptage des bits reçus. Il fournit les informations d'horloge et d'état au CM. Le décodage de l'en-tête et des mots de synchronisation et Blancs est effectué par le décodeur 4B - 3B 185, et communiqué au séquenceur d'état. La partie du TM qui est alimentée en permanence par une batterie

d'accumulateurs est représentée par 189.

La figure 19 est un bloc diagramme fonctionnel du LIG 17.

Les fonctions principales sont les suivantes:

- Gestion de l'initialisation permettant l'accrochage et la synchronisa-

tion des PLL et assurant l'émission correcte des données dans le(s) ca-

dre(s) alloué(s) au SL.

- Envoi systématique d'une trame d'émission suivie d'une trame de récep-

tion. Ces trames contiennent un certain nombre de cadres (24 bits) qui

sont partagés statiquement entre les SL interconnectés.

- Effacement de la trame de réception lors de son retour.

Un exemple des trames d'Emission/Réception est montré ci-dessous.

En-tête Si f2 3S<4 5 S61571 S8 S 53fS41 551S6 f7 586 Trame Emission |Trame Réception Les cadres vides de la trame émission sont remplis au fur et à mesure de leur passage devant les SL auxquels ils sont alloués,

si ces derniers ont des informations à envoyer.

L'allocation des cadres est faite par comptage à partir de l'en-tête (modula N, N étant le nombre de cadres d'émission) et par

positionnement d'un bit à I,dans une PROM adressée, par le numéro de ca-

dre pour indiquer que le cadre est alloué au SL. Le décodage est antici-

pé de façon à ce que le CM puissse envoyer une demande d'émission au TM suffisamment tôt pour émettre un mot dans le cadre lui étant alloué,

comme déjà décrit.

Dans la figure 19, une horloge maître (H) 190 émet des impulsions à la fréquence bit (140 M bits/S). Cette horloge attaque un registre à décalage en émission (RDE) 191 contenant 24 bits permettant la constitution des trames. Ce registre RDE 191 est chargé soit avec des

bits émis d'une PROM 192: en-tête, mot de synchronisation, blanc (ab-

sence de lumière) pendant la phase de synchronisation et d'émission, soit

avec les mots d'information reçus dans la FIFO 193 et devant être répé-

tés dans une trame de réception. La FIFO 193 est utilisée afin de mémo-

riser une trame de réception complète si celle-ci arrive alors qu'une trame d'émission ou de réception est déjà en cours d'envoi; cette trame est chargée dans la FIFO 193, via un registre à décalage en réception (RDR) 193a, qui à son tour est commandé par l'horloge 190,et un circuit de décision 198. La longueur de la trame à mémoriser est fonction de la

longueur de la boucle. Le séquenceur d'état (SEQ) 194 qui est un automa-

te programmé assure le séquencement de l'initialisation et de l'émis-

sion/réception des trames.

En émission, la diode laser (DL) 196 de type déjà décrit

pour le TM est attaquée par le flot binaire après passage par les cir-

cuits d'attaque (CA) 196. La polarisation et la régulation de la DL 196

sont effectuées par un élément de réglage (REG) 197 du même type que ce-

lui décrit pour le TM. En réception, l'horloge maître (H) 190 est appli-

quée à un circuit de décision 198 permettant d'échantillonner correcte-

ment les bits d'information reçus. Ces informations reçues par la photo-

diode à avalanche (PDA) 199, de type utilisé pour le TM, sont amplifiées

et régénérées dans un circuit de détection, amplification et régénéra-

tion (DAE) 199a avant d'être appliquées au circuit de décision. Le con-

vertisseur 197a (ALHT) est du même type que celui utilisé pour le TM

(référencé par 177).

Dans la procédure d'initialisation on peut distinguer trois phases Mise sous tension des SL Dès que le LIC 17 est alimenté, il génère des mots de synchronisation

dans tous les cadres.

Sur détection de lumière sur la boucle, la partie réception 189 du TM

, qui est en permanence alimentée par une petite batterie d'accumula-

teurs (juste les circuits nécessaires à la détection de lumière et à

l'amplification), émet un signal continu qui attaque un triac 179 permet-

tant la mise sous tension automatique du reste du SL de transport (reste

TM et CM).

Accrochage des boucles à verrouillage de phase (PLL) Dès que le reste du TM est mis sous tension, les PLL vont s'-accrocher

sur la fréquence d'horloge bit émise par le LIC. Un traitement non liné-

aire du signal reçu permet de récupérer une horloge synchrone avec la

fréquence bit sur le signal lui-même, cette horloge permettant de syn-

chroniser la PLL qui produit l'horloge bit.

Ajustement des mots dans les cadres Après quelques centaines de millisecondes, lorsque l'on est sûr que le système global est stabilisé (temps de monté des alimentations) et les

PLL synchronisées, le LIG entreprend l'ajustement des mots dans les ca-

dres alloués aux SL. Ceci consiste, de la part du LIG, à arrêter d'émet-

tre de la lumière dans le cadre considéré. Le TM détectant cette absence de lumière va émettre un mot et contrôler qu'il reçoit bien ce mot sans erreur. Si le mot reçu est erroné, le TM insère ou enlève un incrément de ligne à retard pour retarder ou avancer le signal. Il y a à nouveau contrôle et itération de cette procédure jusqu'à ce que le mot émis soit correctement reçu. Le LIG contrôle également l'émission du TM;dès qu'il

trouve que le mot est bien calé dans le bon cadre, il passe au cadre sui-

vant et ceci jusqu'à ce que tous les mots soient bien ajustés dans leurs cadres respectifs. Dès que les SL sont synchronisés (bits et mots), le

LIG émet un mot d'en-tête qui fait passer tous les SL en mode opération-

nel. A partir de ce moment, le LIG émet en permanence une trame de tra-

vail ci-dessous décrite.

|SYNCHRONISATION SYNCHRO. SELECTIVE SW | EM | REC

Mise sous tension et Synchronisation synchronisation bit cadre Phase de travail

N O T O P

O P La séquence d'initialisation peut être redéclenchée du LIG à tout moment si l'on détecte qu'un SL est désynchronisé. Le signal

NOTOP est alors remis à 1 et un événement NOTOP est envoyé aux SL infor-

matiques ayant des transfert de données en cours.

Le séquenceur d'état (SEQ) 194 gère les fonctions du LIG état, essentiellement composé des trois états représentés ci-dessus. Les mots de synchronisation et d'en-tête sont contenus dans la PROM 192. La trame d'émission remplie par les SL est mémorisée dans la FIFO 193 en

attendant d'être transmise à la fin d'émission de la trame émission cou-

rante. Les trames réception reçues par le LIG sont effacées.

On décrit maintenant la coopération entre les SL pour optimiser le partage des ressources du système global et permettre la

communication entre processus. Le partage de ressources se fait directe-

ment, au moyen d'un mécanisme de diffusion, à toutes les unités répar-

ties des requêtes de service, au moniteur local de toute unité. Afin de soulager les unités locales des fonctions de localisation, de sélection,

de translation de paramètres...etc, un processeur spécialisé dans la coor-

dination des systèmes d'exploitation (SIP 11) est utilisé. Son rôle es-

sentiel est donc, par des échanges de message avec ses homologues de dé-

terminer, en fonction des souhaits des utilisateurs, des ressources ré-

parties sur les sites d'application, de la disponibilité de ces ressour-

ces et de la charge des ressources annexes o sera traité chaque regis-

tre de service ou commande. Les SIP commandent la coopération entre SL à

l'aide des mécanismes déjà décrits sur commande de l'exécutif de coordi-

nation (CCE).

Chaque requête de service ou commande peut être considé-

rée comme une transaction constituée de plusieurs étapes et caractérisée

par l'échange de messages et de données entre les SIP, avant de communi-

quer la requête de service au moniteur local sélectionné.

Une transaction est constituée des étapes suivantes

1) Interrogation: elle est directement adressée au SL concerné lors-

qu'il n'y a pas de choix possible et lorsque le processus consommateur peut localiser cette ressource. Une interrogation est adressée à tous

lorsqu'un choix est possible de M ressources parmi %, ou lorsque le proces-

sus consommateur ne peut pas localiser la ressource.

2) Auto sélection: si l'on n'a pas le choix, la ressource sélectionnée est celle explicitement demandée. Si l'on a le choix de M ressources parmi N, un mécanisme d'auto sélection est entrepris pendant lequel

chaque SL, sur examen des réponses envoyées, sélectionne les M SL res-

ponsables du traitement de la requête de service; ces M SL s'auto sé-

lectionnent tandis que les N-M autres annulent la requête considérée.

Le mécanisme d'auto sélection est rendu possible, par la propriété que possède le réseau de communication local, de permettre à tous les SL d'avoir une vue identique de l'ordre des événements globaux, même dans

le cas de fautes. Ces mécanismes seront décrits plus tard.

3) Présentation: une fois qu'un ou plusieurs SL a (ont) été sélection-

né(s) la requête de service est présenté aux SL retenus. Pour cela l'Extension Moniteur (EM) 42 simule la requête de service en donnant

l'image d'un processus local.

4) Traitement: il est effectué par un moniteur local exactement de la même façon que lorsque la requête est issue d'un processus local. La

fin du traitement de la requête entraîne le retour du résultat au pro-

cessus consommateur (extension moniteur).

) Retour du résultat: le résultat est retourné vers le SL dans lequel se trouve le processus consommateur origine de la requête. Ce résultat est réceptionné par l'extension moniteur (EM) de ce SL et communiqué

au processus local, ce qui termine la transaction.

La phase d'auto sélection nécessite de posséder au ni-

veau de chaque SIP 11 une description même succincte des ressources in-

formatiques localement disponibles et de leur répartition sur l'ensemble

des applications concurrentes de l'organisation. Cette description est

effectuée au moyen de tables descriptives des ressources et processus lo-

caux. Ces tables peuvent être formées lors de la génération du système et rechargées aux moments de l'initialisation du système global, dans la RAM 54 du SIP. Elles peuvent également être mises à jour dynamiquement

en fonction des besoins des utilisateurs et de l'évolution du système.

En plus de ces tables descriptives, des tables de translation de paramè-

tres et de correspondance de numéros de code source sont utilisées. Ces

dernières sont décrites par les Tableaux VII à IX ci-dessous. Ces ta-

bleaux permettent la translation de paramètres d'un SL dans un autre et facilitent la recherche d'un bloc descriptif dans lestableaux descriptifs

des ressources.

Tableau VII

Base + 0 Base + 255 Base + 0 Base + 255 ICode fichier global (GFC) i i

I I

I y Code fichier global (GFC)

Tableau VIII

Code ligne global (GLC) I Code ligne global (GLC) t 256 mots de 16 bits

0 si non assigné.

256 mots de 16 bits

0 si non assigné.

Tableau IX

0 n0 Unité 0 0 0 0 0 0 0 0 0 1 n Unité 0 0 0 0 0 0 0 0 1 n Unité 1 1 1 1 1 1 1 1 0 n Unité 1 1 11 1 1 1 >512 mots de 16 bits Les code fichier local (SLFC) + code fichier global (GFC) et code ligne local (SLLC) -> code ligne global (GLC) sont décrits par les

Tableaux VII et VIII.

-25 Pour requérir une ressource, chaque processus utilise un code fichier local (SLFC) n'ayant une signification que dans son SL. Ce libre +> assigné + numéro ne peut donc pas être utilisé directement à l'extérieur du SL

sans créer des inconérences dues à l'utilisation de mêmes numéros de co-

de par d'autres SL, pour requérir des ressources différentes.

Il est donc nécessaire d'associer à chaque ressource un seul et unique code global l'identifiant complètement, et d'effectuer la

translation n0 code local + n0 code global + nu code local.

La première translation est effectuée en utilisant la table de conversion SLFC -> GFC dans le SIP source tandis que la deuxième

est effectuée dans le SL producteur du service en prenant le code fi-

chier local assigné au périphérique ou au fichier.

Dans la translation SLFC ou SLLC - GFC ou GLC la corres-

pondance est établie au moment de l'assignation d'un n0 de code à une-

ressource. A ce moment le SIP propose un n0 de code global (GFC ou

GLC) pris parmi ses numéros libres (Tableau IX). Si la ressource considé-

rée a déjà été assignée par un autre processus et possède déjà un n0 de code global, le n0 de code global proposé par le SIP est refusé et le n0

de code global assigné à la ressource lui est communiqué; si le proces-

sus appartient au même domaine que la ressource, le SIP charge le mot adressé par le n0 de code local (Base + CN) avec le code fichier global

assigné à la ressource.

Si la ressource considérée n'est pas encore assignée, le

n0 de code global proposé par le SIP est accepté et assigné à la ressour-

ce.

A chaque assignation un sémaphore d'assignation est in-

crémenté de 1.

Si le n0 de code global proposé est retenu, le bit d'état indiquant que ce n0 de code est assigné est positionné à 1 sinon le n0 de

code reste libre (bit d'état à 0).

Lorsque plusieurs ressources ont le même nom et le même

numéro elles sont toutes assignées simultanément.

La table de codes globaux (GFC ou GLC) libres (Tableau IX) contient 512 numéros de 0 à 511 concaténés avec le n0 d'unité afin

de former 512 n0 de code globaux uniques dans le système global. Ces nu-

méros de code sont utilisés au moment de l'assignation comme déjà décrit.

La table descriptive des ressources système et domaines

est montrée dans le Tableau X. -

Ressources Système

Lorsqu'un processus consommateur ou un utilisateur de-

mande une ressource, cette demande nécessite toujours la présence de res-

sources système au niveau de l'unité responsable du traitement de la re-

quête. Il est donc nécessaire au niveau de chaque SL de préciser quelles sont les capacités système de ce SL,telles que: - type de l'unité centrale (jeu d'instructions disponible) - nature du moniteur et des modules optionnels présents par exemple système d'exploitation disque moniteur (DOS), système d'exploitation en

temps réel (DRTM) etc....

- extensions du moniteur (Datacom, Data file management), - compilateurs (Fortran, Algol, Basic etc.) - processeurs

- utilitaires (Editeur de liens, de texte)...etc.

Les quatre premiers mots de la table descriptive des ressources système sont réservés afin de décrire les capacités système, chaque bit indiquant si telle ressource système est présente ou non dans cette unité. Quelques exemples de ces ressources système sont décrits ci-dessous.

Ressources système générales: gestion de fichiers (FM), gestion de pro-

cédures de télécommunication, etc. Ressources "Background": Fortran, Editeur de liens, Assembleur, etc. Ces ressources sont activées et utilisées lorsque les processus courants

("Foreground") sont arrêtés (Batch).

Ressources "Foreground": processus et ressources utilisateur d'applica-

tion (temps réel).

Domaines d'application

La structuration du système global en domaines d'applica-

tion permet,d'assurer une protection entre applications en contrôlant

les interactions existant entre celles-ci à travers les ressources commu-

nes,et permet d'équilibrer la charge des différentes ressources en répar-

tissant celles-ci de façon équilibrée sur les différents domaines d'ap-

plication. Dans la présente invention on peut spécifier par exemple 8 domaines différents d'application auxquels chaque ressource du système local peut être allouée. L'accès à ces ressources n'est donc autorisé que pour les processus appartenant aux mêmes domaines que celles-ci. Un domaine est identifié par un nom formé de 6 caractères ASCII. Il est possible d'avoir un domaine ouvert à tous (OPEN). Au niveau de chaque

bloc descriptif d'une ressource, un champ de 8 bits spécifie les domai-

nes auxquels la ressource est allouée: Exemple 8 5 domaine n02

1 1 0 0 1 0 0 1 0 1

La ressource est allouée au domaine n'2, n'5, nO8; cet-

te information peut être obtenue en faisant la fonction logique "ET" de

ce champ avec le nO de domaine situé dans le bloc descriptif des domai-

nes. Si le résultat est nul la ressource n'est pas allouée au domaine considéré. Unt C Tableau X Nom de domaine 6 caractères

ASCII

Unité Cetrale 1 Moniteur Ressources système générales Ressources "Background" Ressources "Foreground", Nom du domaine n0 1 Nom du domaine n0 1 Nom du domaine n0 1 Nom du domaine nO 8 Nom du domaine n0 8 Nom du domaine nc 8

1 0 0 0 0 0 0 0

Ressources système >,disponibles localement (4 mots de 16 bits) Domaine d'application n0 1 (4 mots de 16 bits) Domaine d'application n0 8 (4 mots de 16 bits)

La table descriptive des boites aux lettres de communica-

tion est montrée dans le Tableau XI.

Ces boites aux lettres permettent aux processus de commu-

niquer quel que soit leur domaine d'application. Quatre primitives sont possibles pour gérer ces boites aux lettres: - Ouvrir une boîte aux lettres (OPEN) - Fermer une boite aux lettres (CLOSE) Ces deux primitives ne peuvent être exécutées que par le processus créateur. - Mettre une lettre dans une boite aux lettres (PUT)

- Retirer une lettre d'une botte aux lettres (GET).

Tout processus peut envoyer une lettre au processus cré-

ateur mais seul celui-cipeut retirer la lettre. Lorsqu'une ou plusieurs

lettres sont en attente dans la boite aux lettres, un événement est posi-

* tionné de façon à avertir le processus créateur.

Un sémaphore est incrémenté sur réception d'une lettre et décrémenté sur lecture d'une lettre. Tant que le sémaphore n'est pas

égal à 0, l'événement est maintenu.

Le bloc descriptif d'une boîte aux lettres contient - L'adresse du bloc en mémoire principale du SL alloué pour réceptionner

les lettres.

- La taille totale de la botte aux lettres en nombre de lettres.

- Le sémaphore d'état de la boite aux lettres.

- Le numéro de code global du processus créateur de la botte aux lettres, utile pour contrôler les droits d'accès sur la botte aux lettres et pour

réveiller celui-ci lors de la présence d'un événement.

- Le nom de la botte aux lettres.

- Une information permettant d'adresser le bloc descriptif de la botte

aux lettres suivante.

Tableau XI Adresse en Mémoire Taille totale de la bote auxlettres ennombre de lettres Sémaphore d'état de la botte aux lettres Na global Processus créateur Nom de la boîte aux lettres Nom de la boîte aux lettres Nom de labotte aux lettres Nom de la bote aux lettres Adresse du bloc suivant, 8 mots de 16 bits

-O0si der-

nier bloc Les tables descriptives des ressources utilisateur sont

montrées dans les Tableaux XII et XIII.

La table descriptive du Tableau XII décrit les ressources périphériques.

Domaines autorisés (1 octet): indique pour quels domaines d'applica-

tions connus du SL, la ressource est allouée, par exemple les domaines

1, 3 et 8 comme montré dans-le Tableau XII.

Code fichier local (DLFC) ou code ligne local (DLLC)(1 octet): indique le nu de code utilisé localement pour demander le périphérique auquel

il est assigné. S'il n'est pas assigné, ce champ = 0.

Sémaphore d'assignation globale: est incrémenté sur chaque assignation et décrémenté sur chaque libération. Le passage de ce sémaphore par 0

permet la libération d'un numéro de code global.

Numéro de code global (GCN): est unique dans le système global et per-

met de faire une relation entre une ressource ou un groupe de ressour-

ces banalisées, et les processus consommateurs et les utilisateurs.

Le numéro de code est déterminé lors de la première assignation et

est libéré lorsque le sémaphore d'assignation est égal à 0.

Numéro de Processus global (GPN): indique le numéro global du processus auquel le périhpérique est alloué (temporairement pour une I/0),

bit A = 1, ou attaché (en permanence jusqu'a un ordre explicite de dé-

tachement), bit B = 1.

Nom du périphérique (DN) et numéro (DNO): est constitué de deux carac-

tères ASCII suivisd'un numéro de deux chiffres permettant d'identi-

fier le périphérique.

Par exemple DF = Disque MT = Bande magnétique TC = Cassette avec LRC (longitudinal redundancy check) TK = Cassette avec CRC (cyclic redundancy check) S2 = Contrôleur DTC Synchrone A4 = Contrôleur DTC asynchrone

AB = Multiplexeur 8 lignes asynchrone.

Adresse du bloc descriptif suivant (NLA): pointe sur l'adresse du bloc descriptif suivant. Si ce champ est nul cela signifie que ce bloc

descriptif est le dernier de la liste.

Tableau XII

1 0 0 0 1 0 0 1

Non utilisé Domaines autorisés

DLFC/DLLC Sémaphore d'assi-

gnation globale GCN

B A GPN

DN DNO Non utilisé NLA 8 mots de 16 bits

Le Tableau XIII montre les fichiers logiques.

Seul le premier mot et l'identification du fichier sont différents des périphériques. Si le bloc n'est pas significatif (libre)

le champ DLFC/DLLC est égal à 0. La description des droits d'accès des

domaines est la suivante: 2 bits sont alloués par domaine (D2i, Dli) signification 0 = le fichier n'est pas alloué au domaine considéré 0 1 = le fichier est alloué en écriture 1 0 = le fichier est alloué en lecture

1 1 = le fichier est alloué en écriture et lecture.

Nom du fichier (FN): 6 caractères ASCII, identifie le fichier.

Tableau XIII

D Droits d'accès des différents D D _ domaines__ _ DLFC/DLLC Sémaphore d'assignation globale GCN B A GPN 8 mots FN de FN 16 bits

FN

NLA La table de codes locaux libres est montrée dans le Tableau XIV. Cette table contient 2 bits relatifs à l'état du n0 de code fichier (FC) et du n0 de code ligne (LC) désigné par l'adresse Base + n0 code. Si le bit d'état est égal à 0 cela signifie que le n0 de code est libre, tandis que si le bit d'état correspond à 1 cela signifie que le nu de code est localement assigné. Le numéro de code sert pour exécuter

les LKM localement correspondantes auxrequêtes entrantes.

Les n0 de code relatifs aux périphériques sont assignés lors de la génération du système, tandis que les n0 de code utilisés

pour les fichiers logiques sont assignés au moment de la première assi-

gnation reçue en utilisant des n0 de code libres.

Tableau XIV

Base + 0 + Base + 255 + 256 mots de 16 bits La table des adresses de début de chaînes sur n0 de code

global est montrée dans le Tableau XV.

Pour faciliter la recherche d'un bloc descriptif sur ré-

ception d'un n0 de code global, les blocs ayant le même octet de droite

FC 1LC |

1 1

1FC | LC 1 l . sont chaînés ensemble et l'adresse de début de chaîne est donnée dans la

table des adresses de début de chaînes sur no de code global, c'est-à-di-

re que, comme il n'y aura au maximum que 63 unités interconnectées,. il

faudra dans le pire des cas, 63 comparaisons du n0 de code global conte-

nu dans la requête entrante avec les nO de code global contenus dans les

différents blocs descriptifs pour trouver ce dernier.

Tableau XV

Hexadécimal (X) 0 0 0 1 X F F Adresse ler chaînon Adresse ler chaînon s e 1Adresse ler chaînon - 0 pas de chaîne 256 mots de 16 bits

Un exemple de chaînage est montré ci-dessous.

GFC X FF

7 FF --I[lJFF

NLA 3 F

NLA. FF

Lorsque l'on reçoit une requête caractérisée par un n0 de code fichier global (GFC) on prend l'octet de droite pour localiser le début de la chaîne des blocs descriptifs correspondant à ce n0. Cette

adresse est contenue dans la table XV (ex FF pointe sur le ler bloc des-

criptif de la chaîne qui est 1 FF); on compare alors l'octet de poids fort du GFC reçu avec celui situé dans le bloc descriptif. Si il y a égalité, on a trouvé le bloc descriptif de la ressource demandée, sinon on passe au bloc descriptif suivant pointé par NLA (3 FF), on itère ce processus jusqu'à ce que l'on trouve le bloc descriptif de la ressource

demandée ou jusqu'à trouver 0 dans le champ NLA.

La table des adresses de début de chaînes de fichiers sur le code fichier disque est montrée dans le Tableau XVI. Cette table de 16 mots donne l'adresse de début de la table descriptive des fichiers logiques appartenant au même disque et ceci pour chaque disque (maximum 16 disques par SL). Cette table est utile au moment de l'assignation

pour trouver si le fichier demandé a déjà été assigné ou non.

Tableau XVI

| Adresse 1er chaînon 16 mots de 16 bits Adresse ler chaînon

Les requêtes LKM pour le Moniteur type DRTM sont mainte-

nant décrites. Les requêtes de service peuvent être classées en trois groupes.

a - Requêtes relatives à un équipement périphérique, à un fichier logi-

que, ou à une boite aux lettres.

b - Requêtes relatives à la mémoire principale d'un SL.

c - Requêtes relatives aux programmes.

Les requêtes de type (b) ne sont pas diffusées tandis que les requêtes de type (c) seront étudiées ultérieurement. Donc, dans

la présente invention on ne considère que les requêtes de type (a).

Le traitement des requêtes de service et commandes opé-

rateur est décrit ci-dessous.

Assignation Deux cas typiques d'assignation sont traités

- L'assignation d'un numéro de code fichier à un équipement périphéri-

que, de télécommunication, ou à un fichier permanent.

- L'assignation d'un numéro de code fichier à un fichier temporaire.

Assignation d'un numéro de code fichier à un contrôleur synchrone de té-

lécommunication (type S2).

La commande envoyée par l'opérateur est

AD u /NN u S2 30 et signifie: assigner le code fichier NN (hexadé-

cimal) au contrôleur de communication S2 30.

Sur réception de cette commande, le moniteur appelle l'extension moniteur (EM) 42 afin que celle-ci forme un bloc de commande qui sera envoyé au SIP 11. Ce bloc a la forme suivante montrée dans le

Tableau XVII.

mot 1 mot 2 mot 3 mot 4 mot 5 mot 6

Tableau XVII

NI Microtransaction L Code Service demande Nombre de ressources minimum M NN

S 2

3 O

le mot 1: indique la nature du bloc d'information octet gauche (O 0 = requête de service sortante) et l'étape octet droite (O 0 = première

étape).

le mot 2: est le numéro local de la microtransaction affectée à cette commande.

le mot 3: précise le type de s*rvice demandé (assignation).

le mot 4: donne le code fichier (NN) à assigner à la ressource spéci-

fiée (contrôleur de communication dans ce cas) dans les mots 5 et 6 et le nombre de ressources minimum devant être assignées (octet de gauche).

Dès que ce bloc est formé, l'extension moniteur (EM) en-

voie une commande CIO début indirecte au SIP indiquant l'adresse du bloc de commande (CBAd). L'extension moniteur (EM) redonne alors la main au moniteur. Le SIP complète le bloc de commande afin d'en faire un

bloc d'interrogation qui prend la forme décrite dans le Tableau XVIII.

Ceci consiste à transformer les paramètres locaux -> globaux.

Tableau XVIII

I Ressource Domaine I nu code global du processus (source) consommateur Une fois ce bloc formé par le SIP, celui-ci l'envoie en utilisant le mécanisme de diffusion à tous, sur le bus du système global, via le CM. Le numéro de code fichier global proposé (mot 4) est marqué

comme étant utilisé.

Le mécanisme de diffusion à tous est décrit de façon gé-

nérale à l'aide de l'organigramme de la figure 20. Lorsque le SIPi (sour-

ce) reçoit une requête de service d'un processus situé dans son propre SL, il entreprend les actions nécessaires, translation des paramètres

(local + global), assemblage de la requête dans le format de query (in-

terrogation) et transmission de celle-ci à tous (représenté par 200), via

les mécanismes de transmission déjà décrits (CM, TM, bus optique, etc.).

Le SIPi (source) évolue ensuite dans un état attente, référence 201, ceci

étant la phase de sélection.

Cette requête de service est reçue par tous les SIP con-

nectés sur le réseau de communication global, et sur réception d'une re-

quête entrante, chaque SIP analyse les informations associées à cettere-

quête. Dans l'organigramme de la figure 20, la requête est reçue par les SIPi (destination) et SIPj qui sont dans l'état attente, références 202 et 203. L'état attente est relatif seulement à la requête de service. En

réalité les SIP destination peuvent être occupés avec d'autres actions.

(Nature) 0 0 a (Etape) 0 0 n0 Microtransaction global NO i Demande d'assignation no code fichier global

S 2

3:

M S

D S

o 0 no code processus global Niveau du processus

Dans la présente invention, une requête émise sur le réseau de communi-

cation est reçue par tous les SIP, le SIP source inclus, c'est-à-dire

qu'il n'y a pas de système privilégié dans ce contexte. La requête en-

trante est analysée (références 204 et 205) par chaque SIP sur les points suivants:

- La définition de la requête permet un premier filtrage sur les capaci-

tés SL que doivent posséder les unités pour pouvoir traiter celle-ci.

Exemple: un compilateur est nécessaire pour une requête de compilation,

les programmes de télécommunication (réseau protocole et pro-

cédure) sont nécessaires pour traiter une requête de télécommunication.

- Le nom de domaine d'application permet un deuxième filtrage donnant la répartition équitable des applications sur les unités disponibles et par

conséquent sur les SL, et permet de définir aussi les interactions pos-

sibles entre ces applications (protection et équilibrage). Une table des domaines d'application connus est constituée au niveau de chaque SIP

au moment de la génération du système global (après l'initialisation).

- Un troisième filtrage est éventuellement effectué sur la ressource uti-

lisateur demandée par consultation d'une table descriptive des ressour-

ces locales (située dans la mémoire principale du SIP).

Après ces trois filtrages, chaque SIP est en mesure de

déterminer si son SL possède les capacités requises pour traiter la re-

quête, références 206 et 207. Si le résultat de ces analyses est négatif,

les SIP retournent dans l'état attente; s'il est positif, une autre ana-

lyse est effectuée pour déterminer si ces ressources sont disponibles, références 208 et 209; sinon, le SIP attend la disponibilité avant de

répondre. Lorsque toutes les ressources demandées se trouvent disponi-

bles (système et utilisateur) au sein d'un SL, un accusé de réception est renvoyé à tous et toutes les ressources nécessaires sont allouées au SIP source, le SIP lui-même évoluant dans l'état attente, références 210 à 213. Le SIP source, SIPi dans ce cas, sélectionne un SL parmi les SL qui répondent positivement, un critère de sélection utilisé étant que la première réponse positive reçue est sélectionnée. L'architecture du système ne permet qu'une réponse positive sélectionnée par le SIP

source dans le cas o plusieurs SIP émettent une réponse positive simul-

tanément. Dans ce cas particulier, on émet l'hypothèse que les

deux SIP, SIPi (dest.) et SIPj (dest.) possèdent les ressources deman-

dées et que ces ressources sont disponibles. SIPi (dest.) et SIPj (dest.) répondent positivement via OK global (références 210 et 211) mais la réponse du SIPj (dest.) est reçue avant la réponse SIPi (dest.) par le SIPi (source). Le mécanisme d'autosélection assure que le SIPj (dest.)

est sélectionné (références 212 à 214), une propriété du réseau de com-

munication étant qu'une émission globale est reçue par tous au même ins-

tant. Donc, le SIPi (dest.) est informé par cette diffusion globale qu'il n'est pas sélectionné, la requête est annulée (référence 215) et un branchement effectué à l'état d'attente 202. Le SIPj (dest.)

sélectionné attend l'ordre d'exécution du SIPi source, référence 215.

La figure 21 montre le principe d'autosélection. Trois

SIP: SIPi, SIPj et SIPk sont connectés sur le réseau de communication.

Le SIPi émet une requête diffusée à tous (REQUETE), qui est reçue par tous, décalée en temps. Dans la trame d'émission suivante, SIPj et SIPk répondent positivement eOKj, OKk) et ces réponses sont reçues par tous, mais OKj est reçue avant OKk par tous, à cause de sa situation sur le réseau, donc chacun est informé de la sélection de SIPj. SIPi envoie l'ordre d'exécution à SIPj, et SIPk est libéré. La phase d'exécution commence (décrite par les références 216 à 221), dans laquelle l'ordre d'exécution est envoyé au SIPj, 216, les données envoyées éventuellement

217, la translation des paramètres effectuée de global à local, la re-

quête est chargée dans la mémoire principale du SL et une interruption envoyée au CPU pour l'exécution de la requête, 218. Le SIPJ évolue en état d'attente 219 et, à la fin de l'exécution de la requête 219a envoie les données au SIPi, 220. Ensuite, les résultats sont envoyés au SIPi, 221 qui, à son tour, les charge dans la mémoire principale de son SL et l'avertit, via une interruption, 222. Les SIP évoluent dans un état FIN

relatif à la requête concernée.

Dans l'exemple considéré, ce bloc d'interrogation (query) est donc reçu simultanément par tous les SL au niveau des processeurs de coordination qui analysent en parallèle cette interrogation. La phase

d'analyse est décrite à l'aide de l'organigramme de la figure 22.

Test 230 (INTR): Entrée à la séquence de l'interrogation.

Test 231 (CAP SYS): Ce test consiste à vérifier que le SL possède les capacités système nécessaires pour traiter des requêtes de télécommurdatimn

de données (Moniteur, etc... dans la table des ressources système).

Si oui (Y) on exécute la séquence 232, si non (N) un branchement est

effectué à FIN 238.

Test 232 (RES S2 30): Ce test consiste à vérifier que l'unité de contrô-

le S2 30 est présente localement. Si oui (Y) la séquence d'assigna-

tion du n0 de code fichier global à 52 30 est effectuée (ASSG NO GFC -> 52 30) montré par 233, si non (N) un branchement à

FIN 238 est encore effectué.

Test 234 (MSDS 00): Ce test consiste à vérifier que le domaine d'appli-

cation du processus consommateur est connu du SL (recherche dans la

table des domaines, le nom MSDS 00).

Test 235 (RES S2 30 + MSDS 00): Ce test consiste à vérifier que l'unité

de contrôle S2 30 est allouée au domaine MSDS 00.

Les deux premiers tests permettent de savoir si la res-

source 52 30 existe dans le système global. Si c'est le cas, la séquence

d'assignation globale est entreprise (233).

Une réponse positive (REPD) 236 ou négative (REND) 237 est alors envoyée en fonction du résultat des tests 234 et 235, relatifs à l'allocation de la ressource au domaine MSDSOO. Le résultat indique si le code fichier global proposé a été utilisé ou non. Si ce dernier n'a pas été utilisé, dans le cas d'une réponse positive, le code fichier

global utilisé sera indiqué afin d'effectuer le lien avec le code fi-

chier local.

La séquence d'assignation 233 est décrite à l'aide de

l'organigramme de la figure 23.

Test 240 (RES ASS): Le sémaphore d'assignation global est testé.

Si = O non assigné et on exécute la séquence 242.

Si i; O - déjà assigné et on exécute la séquence 241.

Séquence 241: Le sémaphore d'assignation global est incrémenté de 1

(SAG = SAC + 1).

Séquence 242: Le nu de code fichier global est mémorisé dans le mot 3

du bloc descriptif de la ressource 52 30 (GFC - BLD S2 30).

Test 243 (DLFC ASC): On teste si un nu de code fichier local a déjà été assigné à cet équipement (DLFC i4 0). Si (N) on exécute le test 244,

si (Y) on fait un branchement à FIN ASC.

Test 244 (S2 30 - MSDSOO): On teste si la ressource S2 30 est allouée

au domaine MSDS 00. Si (Y) on exécute la séquence 245, si (N) on ef-

fectue un branchement à FIN ASG.

Séquence 245: Assignation locale d'un n de code fichier à l'équipement

S2 30 (ASG DLFC - S2 30) au niveau du SIP.

Séquence 246: On demande à l'extension moniteur (REQ + EM), sous forme d'une requête entrante, d'effectuer l'assignation du code fichier

affecté à la ressource S2 30 (ASG.DLFC + S2 30).

Séquence 247: Dès que le moniteur local a exécuté l'assignation (EXEC.ASG) , l'extension moniteur envoie le bloc résultat suivant au SIP (R.B. + SIP) . L'adresse du bloc de résultat PB Ad) est indiquée

dans le registre lié à la CIO, comme montré dans le Tableau XIX.

Tableau XIX

RB Ad (Réponse) 0 1 (ire étape) 0 + N microtransaction Résultat Le SIP local analyse le résultat: -Sil'assignation a été exécutée et si le nombre minimum d'assignations M

spécifié est atteint, le traitement est terminé. Si le nombre minimum de-

mandé n'est pas atteint une réponse positive diffusée est envoyée.

-Sil'assignation a été refusée par le moniteur local, le bloc descriptif est remis à jour (sémaphore décrémenté de 1), le numéro de code fichier local est libéré et le résultat est retourné au SIP origine au moyen du

mécanisme de diffusion (réponse négative) dans le format décrit au Ta-

bleau XX.

Tableau XX

O 1 1 0 2

NO Microtransaction global Résultat Nu Code fichier global assigné

Le résultat peut être une réponse négative (pas d'assi-

gnation) ou positive, mais la ressource n'est pas allouée au domaine

MSDS 00, ou réponse positive et la ressource est allouée au domaine MSDSOO.

Sur réception de ce message le SIP origine exécute la

séquence (type S1) décrite à l'aide de l'organigramme de la figure 24.

Test 250 (RES.POS): Le résultat positif est attendu.

Test 251: L'assignation sur MSDS 00 (ASG.MSDSO) est testée; si oui (Y),

la séquence 252 est exécutée, si non (N) la séquence 253 est exécu-

tée. Bloc 252: Le n de code global est chargé dans la table de conversion

en face du n de code fichier local (SLFL - GFC) et le nombre mini-

mum d'assignations M est décrémenté par 1 (M = M - 1).

* Bloc 253: Si l'assignation sur MSDS 00 n'est pas faite dans le test 251, l'assignation du code fichier global proposé est mémorisée GFC ASG =

1, et un branchement effectué à WT, 258 o on attend une réponse po-

sitive; en réalité on revient au début.

Au moment de l'interrogation une minuterie 58, dans le SIP, est déclenchée de façon à détecter les défaillances. Si le temps de garde est dépassé, la séquence décrite dans l'organigramme

de la figure 25 est effectuée.

Test 254: Le nombre minimum d'assignations M est testé; si M = O, le

test 255 est exécuté, sinon on attend les réponses positives suivan-

tes, WT 258.

Test 255: Si le code fichier global proposé (GFC PRO) est accepté (Y),

la séquence 256 est exécutée, sinon (N) la séquence 257 est exécutée.

Bloc 256: Dans cette séquence o le GFC proposé est accepté, le résul-

tat positif est communiqué à 1'EM (RES - EM), la microtransaction est

terminée (RST +/uT), le n global de cette microtransaction est li-

béré (LIB.NG./uT) et ensuite, un branchement effectué à FIN.

Bloc 257: Si le GFC proposé dans le test 255 n'est pas accepté (N), ce-

lui-ci est immédiatement libéré (LIB.GFC.PRO), la microtransaction

est terminée (RST -/uT) et un branchement effectué à FIN.

Test 260: La mémorisation de l'assignation du code fichier global est

testée (GFC ASG = 1). Si GFC ASG = 1 (Y) la séquence 261 est exécu-

tée; si GFC ASG =/ 1 (N) un branchement est effectué à la séquence 262.

Bloc 261: Le numéro de code global est libéré (LIB.GFC).

Bloc 262: Le résultat négatif est communiqué à 1'EM (RES(N) + EM), la microtransaction est terminée (RST +/uT) et un branchement effectué

à FIN.

Le résultat est renvoyé sous forme diffusée, de façon à permettre aux SL ayant les capacités mais r'ayant pas encore répondu,

d'effectuer l'assignation mais de ne pas répondre, dès que le nombre mi-

nimum de réponses M est atteint.

- Sur réception de Mi résultats positifs, la microtransac-

tion est terminée, les résultats arrivant après ne sont pas pris en

compte par le SIP origine (identiques si positifs, sinon sans importan-

ce). L'assignation globale s'effectue sur un nom de ressource sans tenir compte du nom des domaines sur lesquels elle est effectuée,

tandis que l'assignation locale s'effectue sur un nom de ressource asso-

cié à un nom de domaine.

L'assignation d'un code fichier à un fichier temporaire

est maintenant décrite. Le format est: LKM U dataLU 23.

Cette requête est significative de l'assignation. Le ty-

pe d'assignation et les paramètres associés sont contenus dans 1'ECB (Bloc de Contrôle d'Evénements) qui a la forme suivante décrite dans le

Tableau XXI, pour l'assignation d'un code fichier (NN) à un fichier tem-

poraire séquentiel situé sur un disque ayant le code fichier DD.

Tableau XXI ECB.Ad. >

ZZ 0 1 NN

a.O DD

O D O O

Non utilisé Non utilisé u F + fichier séquentiel + type de fichier Sur réception de cette requête, le moniteur appelle l'extension moniteur (EM) qui forme le bloc de commande décrit dans le Tableau XXII. &

mot 1 C.B. Ad.

mot 5 mot 6

Tableau XXII

(Nature) 0 0 (Etape) 0 0 NO Microtransaction L Code Service demandé Nombre de copies M NN

_ DD

0 0 0 0

La signification des 4 premiers mots est identique à

l'assignation précédente (Tableau XVII).

Le mot 5 indique le code fichier du (des) disque(s) utilisé(s) pour le

fichier temporaire.

Le mot 6 indique le type de fichier (0000 = séquentiel) et le nombre de

granules demandés dans le cas d'un accès direct (un granule= 8 sec-

tors, et 1 sector = 205 mots sur un disque).

Dès que le blocest prêt, l'extension moniteur EM envoie une CIO début in-

directe au SIP, lui indiquant l'adresse du bloc de commande (CB Ad). Le SIP complète le bloc de commande afin d'en faire un bloc d'interrogation

qui prend la forme décrite dans le Tableau XXIII.

Tableau XXIII

mot 1 mot 2 mot 3 mot 4 mot 5 mot 6 mot 7 mot 8 mot 9 mot 10 mot 11 + assignation (nature) 0 0 t- (étape) 0 0 N Microtransaction globale Nombre de copies M t demande assignation NO Code fichier global DD

00 00

M S

D S

O 0

NO Code global du Processus Niveau du Processus Le mot 2 est modifié par concaténation du numéro d'unité au numéro de

microtransaction local.

Le mot 4 indique le code fichier global proposé.

Le mot 6 indique le type de fichier.

Le motlO indique le niveau du code global du processus.

Le mot 11 indique le numéro de code global du programme demandant l'ou-

verture d'un fichier temporaire, c'est-à-dire le niveau du processus.

Le bloc ainsi constitué est diffusé et reçu par tous les

SL qui l'analysent de la façon montrée dans l'organigramme de la figu-

re 26.

Test 263: Ce test (CAP.SYST) consiste à vérifier que le SL possède les capacités système nécessaires pour traiter la requête. Si oui (Y) on exécute le test suivant, sinon (N) un branchement est effectué à FIN,

c'est-à-dire il n'y a pas.de réponse à la requête.

Test 264: Ce test consiste à vérifier que le domaine d'application du processus consommateur est connu (le SL recherche dans la table des

domaines le nom MSDS 00).

Test 265: Ce test consiste à vérifier si le disque ayant le code fichier

DD est présent (DD PRES.).

Test 266: Ce test consiste à vérifier si le disque ayant le code fichier

DD est alloué à MSDS 00 (AL DD + MSDS 00).

Dans tous les tests décrits ci-dessus, si la vérification est positive (Y) , le test suivant est exécuté, sinon (N) un branchement

est effectué à FIN.

Test 267: Le niveau du processus local (PROC L) est comparé au niveau du processus consommateur (PROC C) (demandeur). Si PROCL > PROCC on attend la fin de l'exécution du PROCL avant de répondre; si

PROCL. PROCC, une réponse positive est diffusée RES(P) 268.

Cette phase d'analyse dure jusqu'à ce que l'autosélec-

tion ait eu lieu ou que le temps attribué à l'horloge de garde du SIP 58

soit écoulé. Sur réception d'une interrogation, le nombre de copies dé-

siré est mémorisé. Les réponses relatives à la microtransaction corres-

pondante sont analysées comme décrit dans l'organigramme de la figure 27.

C'est la phase d'autosélection.

Bloc 270: Au début de la transaction un compteur CPT est initialisé avec la valeur M (CPT = M) o M est le nombre minimum de ressources demandées. Test 271: Une réponse positive est attendue (REP = 1). Sur réception

d'une réponse positive REP = 1, le test 272 est exécuté.

Test 272: Ce test (REP SL) permet de déterminer si la réponse reçue pro-

vient de lui-même (Y) ou d'un autre SL (N). Si (Y) on exécute la

séquence 273, sinon (N) on exécute la séquence 274.

Bloc 273: Dans cette séquence le SL est sélectionné (SEL - SL) et un

branchement est fait à fin de sélection (FIN SEL),ou la transac-

tion passe dans l'étape suivante.

Bloc 274: Si le résultat du test 272 est (N), le compteur CPT est dé-

crémenté (CPT = CPT - 1) et on effectue le test 275.

Test 275: L'état du compteur CPT est testé. Si CPT = 0 (Y) on effectue

la séquence 276, si CPT De O (N) on revient au test 271. Bloc 276: Le SL n'est pas sélectionné (NSEL - SL), la transaction est

terminée pour ce SL et un branchement effectué à FIN.

Lorsque M SL ont répondu positivement (CPT = 0), si la

réponse du SL est comprise dans les M premières réponses, elle sera sé-

lectionnée,sinon l'analyse est terminée et la microtransaction est consi-

dérée comme étant traitéepar celle-ci.

Si le SL est sélectionné, une requête entrante est envoyée à l'extension moniteur (EM) qui transforme celle-ci en LKMU dataU 23 ayant préalablement reconstitué un ECB avec les paramètres communiqués

par le SIP.

Le moniteur exécute l'assignation et retourne à l'exten-

sion moniteur (EM) le résultat qui est alors communiqué au SIP (même

format que pour l'assignation à un équipement périphérique).

Avant de communiquer la requête entrante au moniteur lo-

cal, le SIP a créé un bloc descriptif du fichier temporaire. Ce bloc des-

criptif est confirmé si le résultat de l'assignation par le moniteur lo-

cal est positif, sinon il est annulé.

Le bloc descriptif du fichier temporaire créé est décrit dant le Tableau XXIV. N.

Tableau XXIV

Non utilisé DUNC Non utilisé indique qu'il GCN s'agit d'un fi- 1 1 GPN chier temporaire Non utilisé Non utilisé Non utilisé NLA Dès que l'assignation a été effectuée, le résultat est diffusé à tous

(même format que pour l'assignation à un équipement périphérique).

Dans ce cas d'assignation le SIP origine attend également d'avoir reçu M résultats positifs avant de communiquer le résultat final

à l'extension moniteur (EM) locale. Comme dans le cas précédent, une hor-

loge de garde du SIP 58 est déclenchée au moment de l'interrogation et remise à zéro, lorsque la requête est satisfaite. Si le temps alloué est dépassé avant que la requête ne soit satisfaite, un résultat négatif est retourné à l'utilisateur et une annulation de la requête est envoyée à tous.

On décrit maintenant l'attache d'un périphérique à un pro-

gramme. L'attache d'un équipement périphérique à un programme s'effectue

comme l'assignation d'un code fichier à un fichier temporaire, c'est-à-

dire que le processus source ou le moniteur spécifie un nombre M de péri-

phériques attachés et l'autosélection s'effectue jusqu'à satisfaction de la requête. Lors de l'attache, le ou les périphériques concernés se

voient assigné un nouveau code fichier global uniquement connu du pro-

gramme auquel ils sont attachés. Lors de l'opération de détache, le pé-

riphérique se voit réassigné le code fichier global des périphériques identiques.

L'exécution des Entrées/Sorties utilise les deux mécanis-

mes suivants: Soit toutes les ressources identiques allouées au domaine sont concernées Soit il y a autosélection de M ressources parmi N.

Mise à jour de copies multiples de fichiers.

Afin de conserver la cohérence des copies d'un même fi-

chier, la mise à jour est simultanée.

Requête de service au moniteur.

LKMu datau M; ordre écriture basique (/05). Le ECB associé à cette re-

quête est décrit dans le Tableau XXV.

Tableau XXV

ECB Ad + INN Sur réception de cette commande, le moniteur appelle l'extension moniteur (EM) chargée de former le bloc de commande envoyé

au SIP. Ce bloc est décrit dans le Tableau XXVI.

Tableau XXVI

CB Ad

spécifi-

cation du nombr de copie Dès que recte).

Tableau

e s + écriture basique

le bloc de commande est prêt, le SIP est activé (CIO début indi-

Le bloc d'interrogation est alors formé comme montré dans le

XXVII.

Adresse tampon Longueur tampon Réservé pour le résultat Réservé pour le résultat Non utilisé (nature) 0 0 (étape) 0 0 N microtransaction L Service demandé Nombre de copiesM | NN Adresse du tampon Longueur du tampon

Tableau XVII

O O O O

Numéro microtransaction global Nombre de copies M Ecriture basique Numéro de code fichier global Longueur du bloc de données

M S

D S

0 a Numéro global du programme Niveau du programme Ce bloc d'interrogation est diffusé et chaque SIP exécute la procédure

montrée dans l'organigramme de la figure 28.

Test 280: On teste si le code fichier global contenu dans l'interroga-

tion est connu localement (GFC). Si non (N) le SL n'est pas concerné par cette transmission et un branchement est effectué à FIN, si oui

(Y) le test suivant 281 est exécuté.

Test 281: On teste si le domaine MSDS 00 est connu du SL (MSDS 00). Si non (N) le SL n'est pas concerné et on va à FIN, si oui (Y) le test

282 est exécuté.

Test 282: On teste si le fichier concerné est alloué au MSDS 00 (GFC + MSDS 00). Si non (N) la transaction est terminée, si oui (Y) le test

283 est effectué.

Test 283: On vérifie si le fichier est attaché à un programme particu-

lier (GFC + PROG). Si non (N) on exécute le bloc 284, si oui (Y) on

fait le test 285.

Bloc 284: Une demande d'allocation d'un tampon en zone dynamique est faite au moniteur (REQ TAMP - MONT). Sur réception d'une réponse de

celui-ci, on exécute le test 286.

Test 285: On vérifie si le fichier est attaché au programme origine de la requête (PROG AT). Si oui (Y) on exécute la séquence 284, sinon

(N) on exécute la séquence 288.

10.

Test 286: Sur réponse du moniteur (bloc 284) on regarde si on a pu ob-

tenir l'allocation du tampon demandé (TAMIP AL). Si oui (Y) on exécu-

te la séquence 287, sinon (N) on exécute la séquence 288.

Bloc 287: Une réponse positive est diffusée (REP (P) - DIF), le SL est

sélectionné et la transaction passe dans la phase suivan-

te.

Bloc 288: Une réponse négative est diffusée (REP(N) - DIF) et la tran-

saction est terminée (FIN).

Lorsque le SL source a reçu une réponse positive des M SL -possédant les copies du fichier, il peut effectuer le transfert

du bloc de données de la mémoire principale,de son CPU vers les SL con-

cernés. Le transfert s'effectue en mode adressé si M = 1 et en mode

diffusé si M > 1.

Le format du bloc pour le transfert de données est décrit

dans le Tableau XXVIII.

Tableau XXVIII

(nature) 0 0 (étape) 0 2 NO microtransaction global Longueur de l'enregistrement j Données j

Les SIP possédant une copie du fichier ont d'une part mé-

morisé les paramètres relatifs à la requête de service, et d'autre part

obtenu du moniteur local l'allocation d'un tampon en zone dynamique fai-

sant la longueur demandée. Sur réception des données, celles-ci sont chargées dans le tampon alloué dont l'adresse a été communiquée au SIP

par l'extension moniteur (EM),et ceci jusqu'à ce que la longueur indi-

quée dans le bloc d'exécution après décrémentation, à chaque chargement d'un mot, ait atteint la valeur 0. Dans ce cas une requête entrante d'écriture basique est communiquée à l'extension moniteur (EM) qui la

forme et la présente au moniteur local pour exécution. Dès que l'exécu-

tion a eu lieu, le processus déjà décrit de retour du résultat est exécu-

té.

Le SIP source ne communique le résultat final à son ex-

tension moniteur (EM) que lorsqu'il a reçu un résultat de tous les SL

devant exécuter la mise à jour d'une copie du fichier.

Pour éviter un blocage, lorsque toutes les ressources identiques sont concernées par une requête comme dans cet-exemple, le critère de niveau de priorité des processus interagissant n'est pas pris

en compte.

Lecture d'un fichier.

Le mécanisme d'autosélection est celui utilisé dans le cas de l'assignation d'un fichier temporaire. Un critère de sélection supplémentaire est testé, il s'agit de la longueur du tampon nécessaire en zone dynamique du SL sélectionné, pour assurer le transfert du fichier

vers le SL source.

Si M est égal à 1, l'unité la plus disponible est sélectionnée.

Si M > 1 (3 par exemple), dans ce cas les données reçues des 3 unités

productrices peuvent être comparées mot à mot. S'il y a des différen-

ces, un processus majoritaire est appliqué, c'est-à-dire que le mot

n'est validé que si il y a identité entre 2 mots parmi 3.

A la génération du système, les tables descriptives des ressources et processus sont initialisées. Les ressources sont allouées aux différents domaines d'application afin de protéger les applications entre elles et d'équilibrer l'utilisation des ressources en répartissant

équitablement la charge globale sur celles-ci.

Les ressources identiques (banalisables) possèdent le mê-

me nom. Identique ne signifie pas uniquement d'un point de vue structure mais aussi d'un point de vue facilité d'accès d'un site d'application donné; ex. un TTY se trouvant sur le site de l'opérateur ne lui rendra

pas le même service qu'un TTY identique situé à 1 km.

Les mécanismes de sélection peuvent prendre la forme suivante: - Sélection de toutes les ressources répondant à un certain nombre de

critères mais nécessité de M parmi N (Sî), (assignation d'un code fi-

chier à un périphérique).

- Sélection de toutes les ressources répondant à un certain nombre de critères et nécessité de toutes ces ressources (S2), (mise à jour de

copies multiples d'un fichier).

- Autosélection de M parmi N ressources et nécessité de M parmi N (53),

(lecture d'un fichier).

M pouvant évidemment être égal à 1.

- Lorsque le maintien de la cohérence des données l'exige, une attache

explicite ou implicite est effectuée.

- L'adjonction, la suppression ou la migration de ressources d'un domai-

ne dans un autre peut être effectuée dynamiquement, sous contrôle des

opérateurs, par modification des tables descriptives des ressources si-

tuées au niveau du SIP.

Interface physique SIP/SL P 800 (signaux bus)

Type de Nombre de Description Mnémonique Source Dest. Fonction

fils fils

contrôle 1 Accepté. ACN SIP CPU Dialogue E/S.

contrôle 6 Bus interrompu lignes codées. BIECOO+BIEC0O SIP CPU Interrogations.

données 16 Bus lignes d'E/S. BIOOON+BI015O TOUS TOUS Canal des données.

contrôle 1 Bus occupé. BUSYN SIP SIP Contrôle du bus.

CPU CPU

contrôle 1 Caractère. CHA SIP M6m Echange en mode caractères.

CPU

contrôle 1 Bus requête. BUSRN SIP CPU Requête du bus.

contrôle 1 Acquitter, CLEARN CPU SIP Remise à zéro générale (MCL).

* adresse 18 Lignes d'adresse. ADOO+ MAD15, SIP Mém Adressage.

MAD64,MAD128 CPU SIP

contrôle 1 Maitre sélectionné. MSN SIP SIP Contrôle de priorité.

CPU CPU

contrôle 1 OK Entrée. OKI CPU CPU Sélection du prochain maître.

SIP SIP

contrôle 1 QK Sortie. dKO CPU CPU Sélection du prochain maitre.

SIP SIP

contrôle 1 Défaillance d'alimentation. PWF CPU SIP Contrôle des alimentations.

contrôle 1 Surveiller interruptions externes. SCEIN CPU SIP Echantillonnage des interruptions.

contrôle 1 Surveiller chaîne de priorité. SPYC CPU SIP Contrôle de priorité.

contrôle 1 Horloge maître à périphérique (CU). TMPN CPU SIP Signal de synchronisation d'échange

contrôle 1 Horloge maitre à mémoire. TMRN CPU Mém Signal de synchronisation d'échange.

SIP

contrôle 1 Horloge CU à maître. TPMN SIP CPU Signal de synchronisation d'échange.

contrôle 1 Horloge mémoire à maître. TRMN Mém SIP Signal de synchronisationd'échange.

CPU z o - CD X rrl xi ru os 0% UJ> c Interface physique SIP/CM

Type de Nombre de Description Mnémonique Source Dest. Fonction

fils fils ,__

adresse 16 Lignes d'adresse. ADRON +ADRFN SIP SIP Adressage.

CM CM

contrôle 1 Bus synchronisation. BULKN SIP SIP Synchronisation.

CM

contrôle 1 Bus priorité entrée. BPRNN SIPou SIP Sélection du prochain maître.

CM

contrôle 1 Bus priorité sortie. BPRON SIP SIP Sélection du prochain maître.

ou CM

contrôle 1 Bus requête. BREQN SIP con- Requête pour le bus.

trô- le du Bus

contrôle 1 Bus occupé. CBUSYN SIP SIP Contrôle du bus.

CM CM

contrôle 1 Communication module interruption. CMITN CM SIP Interruption.

données 16 Bus de données. DATON +DATFN SIP SIP Bus de données.

CM CM

contrôle 1 Initialisation. INITN SIP CM Initialisation.

contrôle 1 Commande E/S LIRE. IORON SIP CM Signal de synchronisation d'échange.

contrôle 1 Commande E/S ECRIRE. IOWON SIP CM Signal de synchronisation d'échange.

contrôle 1 Commande mémoire LIRE. MRDON CM SIP Signal de synchronisation d'échange.

contrôle 1 Commande mémoire ECRIRE. MWTON CM SIP Signal de synchronisation d'échange.

contrôle 1 XFER Reconnaissance. XACKN CM SIP Signal de synchronisation

SIP CM d'échange.

no ré3 -s no Interface physique CM/TM

Nombre Description Mnémonique Source Dest. Fonction

de fils

16 Données en réception AIO - AI15 TM CM Commande ou données.

(adresse, commande, données).

1 Bit de parité. P TM CM Contrôle d'erreurs de parité en réception.

1 Bit d'erreur. E TM CM Indique une erreur sur le réseau.

16 Données en émission A00 - A015 CM TM Commande ou données.

(adresse, commande, données).

1 Bit de procédure. K CM TM Type de mot (commande ou données).

1 Signal indiquant la pha- RCM TM CM Permet aux SL de recevoir les données.

se de réception.

1 Horloge de réception. FCM TM CM Mémorisation de données dans CM.

1 Impulsion de référence. REFM TM CM Préparation des données à émettre en avance (synchroni-

sation).

1 Requfte à émettre. RTS CM TM Demande à émettre dans un cadre d'émission.

i Fréquence d'émission. FREFM TM CM Horloge fournie par TM pour l'émission de données.

o i i i r-' V os4

LISTE DE REFERENCES

(1) E. Douglas Jensen

"The Honeywell Experimental Distributed Processor An Overwiew".

Computer, January 1978, p 28-38.

(2) Heart F.E., Ornstein S.M., Crowther W.R. & Barker W.B.

"A New Minicomputer/Multiprocessor for the ARPA Network".

NCC (1973) p 529-537.

(3) Ornstein S.N., Crowther W.R., Kraley M.F., Bressler R.D. & Michel A.

"Pluribus - A Reliable Multiprocessor".

NCC (1975) p 551-559.

(4) Vidas B. Glydys & Judith A. Edwards

"Optimal Partitioning Of Wordload for Distributed Systems".

Digest of Papers, Compcon 76 Fall, September 1976, p 353-357.

(5) Thomas 0. Wolff

"Improvements In Real-time Distributed Control".

Digest of Papers, Compcon 77 Fall, Septamber 1977, p 409a-409g (6) Le Cann G. "A Protocal to Achieve Distributed Control In Failure Tolerant

Multicomputer Systems".

SIRIUS Research Report IRIA CRTI 002 1977

(7) Farber D.J.

"A Distributed Computer System".

Report 4, Dept. Of Information And Computer Sciences, University of California, Irvine, U.S.A.

Claims (11)

REVENDICATIONS:

1. Système de traitement de données réparti comprenant plu-

sieurs systèmes locaux (SL 10), chacun desdits SL (10) comprenant au moins une unité de traitement (36) avec les mémoires, les périphériques et les processus associés (30 à 32), et un moniteur local (37 à 41), la communication entre lesdits SL (10) étant effectuée à travers un réseau de communication général, caractérisé en ce que ledit système réparti comprend en outre un module extension moniteur (EM 42) associé à chacun desdits SL (10), la communication entre SL (10) étant assurée par:

a- une couche fonctionnelle de coordination (12) gérée par des proces-

seurs d'intercommunication (SIP 11) comprenant un matériel et logiciel

spécialisés assurant les fonctions de coordination, communication, con-

trôle, initialisation et simulation relatives aux SL (10), la communi-

cation entre lesdits SL (10) et lesdits SIP (11) étant effectuée à tra-

vers l'interface SL/SIP au moyen dudit EM (42) et des mécanismes d'in-

tercommunication SL/SIP commandés par lesdits SIP (11); b- une couche fonctionnelle de communication (14) gérée par des modules

de communication (CM 13) comprenant un matériel et logiciel dur spé-

cialisés assurant la gestion des protocoles de communication entre lesdits SL (10), lesdits protocoles de communication comprenant les moyens pour établir les liaisons logiques adressées et diffusées, les moyens de contrôler le débit d'information, les moyens de présenter le même ordre d'événements globaux au niveau de chaque SL (10), ainsi que

des procédés de détection d'erreur et de récupération, la communica-

tion entre lesdits SIP (ll) et lesdits CM (13) étant effectuée à travers l'interface SIP/CM au moyen des mécanismes d'intercommunication SIP/CM commandés par lesdits SIP (11) et les CM (13), la communication entre lesdits CM (13) et des modules de transmission TM (15) étant effectuée

à travers l'interface CM/TM au moyen de mécanismes d'intercommunica-

tion CM/TM commandés par lesdits CM (13) et lesdits TM (15); c-'une couche fonctionnelle de transport (18) comprenant en outre les TM (15), un bus optique en boucle (16) et un organe de bouclage (LIG 17 lesdits TM (15) comprenant un matériel et logiciel dur spécialisés pour contrôler les erreurs de parité et pour effectuer la conversion

électrooptique et optoélectronique et pour maintenir la synchronisa-

tion entre lesdits CM (13) et ledit bus optique (16) respectivement, ledit LIG (17) comprenant un matériel et logiciel dur spécialisés pour coder et décoder chaque trame de transmission sur ledit bus optique (16),

lesmoyens pourgérer la procédure d'initialisation permettant la syn-

chronisationdelatransmission sur ledit bus optique (16),ainsi que les moyens pour assurer l'-émission et la réception correctes des données

danslescadresalloués aux SL (10).

2. Système selon la revendication 1, caractérisé en ce que ledit TM (15) comprend en outre: a - un circuit pour calculer la parité (169), lié à un codeur de données en émission (170) qui à son tour est lié via un registre à décalage (RDS 171), un élément de retard (T 172) et un circuit analogique (CA

173), à une diode laser (DL 174), ladite DL (174) contrôlée par un élé-

ment (POLDL 175), émettant des données après la conversion électroopti-

que vers ledit bus optique (16); b - une photodiode à avalanche (PDA 176) stabilisée par un convertisseur (ALHT 177) pour effectuer la conversion optoélectronique des données

venant dudit bus optique (16), lesdites données converties étant ampli-

fiées dans un circuit d'amplification (DAE 178) et ensuite, traitées de façon non linéaire dans un circuit (TNL 181), la sortie dudit TNL (181) étant appliquée à une bouc]e de verrouillage de phase (PLL 182),

les sorties de ladite PLL (182) étant appliquées à leur tour à un cir-

cuit de décision (183), un registre à décalage (RDE 184) contrôlé par

ledit circuit (183) effectuant la transformation série-parallèle des-

dites données en réception,et ledit RDS (171), la sortie dudit RDE (184) étant liée à un décodeur (185), et un circuit de comparaison

(186);

c - un séquenceur d'état (SEQ 187) gérant les trames d'émission et récep-

tion en fonction des informations reçues desdits PLL (182),décodeur (185) et CM (13); d - un intégrateur de commande COM TRIAC (179) lié à la sortie dudit DAE (178) et commandant un triac (180), ledit triac (180) comprenant

les moyens pour mettre sous tension lesdits CM (13) et TM (15).

3. Système selon la revendication 1, caractérisé en ce que ledit LIG (17) comprend en outre:

a- un registre à décalage en émission (RDE 191) lié à un circuit d'atta-

que (CA 195), la sortie dudit CA (195) étant liée à une diode laser (DL 196) contrôlée par un élément de réglage (REG 197), ladite DL (196) émettant les données sous forme optique vers ledit bus optique (16), ledit RDE (191) étant chargé soit par une (FIFO 193), soit par des bits émis d'une (PROM 192); b- une photodiode à avalanche (PDA 199) contrôlée par un convertisseur (ALHT 197a) pour recevoir les données du bus optique (16), la sortie de ladite PDA (199) étant régénérée par un circuit de régénération (DAE 199a), ledit circuit DAE (199a) étant à son tour lié à un circuit de décision (198) permettant le chargement de ladite FIFO (193) via un registre à décalage en réception (RDR 193a); c- une horloge maître (H 190) émettant des impulsions à la fréquence bit pour synchroniser lesdits RDE (191), RDR (193a), circuit de décision

(198) et un séquenceur d'état (SEQ 194), ledit SEQ (194) assurant les-

dites procédures d'initialisation et de synchronisation de la transmis-

sion en contrôlant lesdits RDE (191),PROM (192), FIFO (193) et RDR (193a).

4. Système selon l'une quelconque des revendications 2, 3,

caractérisé en ce qu'une description des ressources disponibles au niveau

de chaque SL (10) est chargée dans la RAM (54) de chacun desdits SIP (11)

au moment de la génération dudit système réparti global, chacune desdi-

tes descriptions locales étant dynamiquement mise à jour en fonction des

besoins des utilisateurs et de l'évolution dudit système réparti.

5. Système selon la revendication 4, caractérisé en ce que

chacune desdites descriptions locales comprend en outre des tables de

translation de paramètres et de correspondance de numéros de code source permettant la translation entre lesdits SL (10), une table descriptive des ressources système et domaines d'application, une table descriptive

des boites aux lettres de communication, des tables descriptives des res-

sources utilisateur, une table de codes locaux libres, des tables des

adresses de début de chaînes sur numéro de codes globalet fichier.

6. Système selon la revendication 5, caractérisé en ce que le

traitement de chaque requête de service provenant d'un processus utilisa-

teur situé dans un SL (10) est effectué au moyen d'une transaction com-

prenant en outre des étapes distinctes d'interrogation, autosélection,

présentation, traitement et retour du résultat, ladite requête de servi-

ce envoyée étant remise en forme par ledit EM (42) et communiquée au SIP origine (ll) à travers l'interface SL/SIP au moyen d'un bloc de commandes

et desdits mécanismes d'intercommunication SL/SIP.

7. Système selon la revendication 6, caractérisé en ce que ladite étape d'interrogation comprend en outre les moyens, pour ledit SIP origine (ll), de communiquer en mode adressé ladite interrogation au SL (10) concerné lorsqu'il n'y a pas de choix possible et lorsque le processus utilisateur peut localiser la ressource demandée, les moyens pour ledit SIP origine (11) de communiquer ladite interrogation en mode diffusé à tous les SL (10) lorsqu'un choix est possible de M parmi N

ressources o N > M, ou lorsque le processus utilisateur ne peut pas lo-

caliser la ressource, ladite requête de service étant mise en forme de bloc d'interrogation par ledit SIP origine (11) et communiquée soit dans le mode adressé, soit diffusé, au SL (10) adressé ou à tous les SL (10) à travers lesdites couches fonctionnelles de coordination (12), communication (14) et transport (18) en utilisant lesdits mécanismes

d'intercommunication entre lesdites couches.

8. Système selon l'une quelconque des revendications 6, 7,

caractérisé en ce que ladite étape d'autosélection comprend en outre les

moyens, lorsqu'il y a le choix, de M parmi N ressources, pour sélection-

ner M SL(10), les moyens pour chaque SL (10) d'analyser les réponses en-

voyées pour savoir quels M SL (10) sont sélectionnés, les moyens pour les (N-M) SL (10) non sélectionnés d'annuler ladite requête de service, ledit mécanisme d'autosélection permettant à tous les SL (10) d'avoir

une vue identique de l'ordre des événements globaux.

9. Système selon l'une quelconque des revendications 6, 7, 8

caractérisé en ce que ladite étape de présentation comprend en outre les moyens de présenter aux SL (10) sélectionnés ladite requête de service

sous la forme d'un bloc de commandes, ledit bloc de commandes étant com-

muniqué par le SIP origine (11) aux SL (10) sélectionnés à travers les-

dites couches de coordination (12), communication (14) et transport (18)

en utilisant lesdits mécanismes d'intercommunication entre lesdites cou-

ches, ledit EM (42) situé dans chaque SL (10) sélectionné simulant ladi-

te requête de service en donnant l'image d'un processus local.

10. Système selon l'une quelconque des revendications 6, 7, 8,

9, caractérisé en ce que ladite étape de traitement comprend en outre

les moyens pour le moniteur local (37 à 41) de chaque SL (10) sélection-

né de traiter ladite requête de la même façon que lorsque celle-ci est

issue d'un processus local, ainsi que les moyens d'interruption pour in-

former 1'EM (42) de la fin du traitement de ladite requête.

11. Système selon l'une quelconque des revendications 6, 7,

8, 9, 10, caractérisé en ce que ladite étape de retour du résultat com-

prend en outre les moyens pour le SL (10) sélectionné de communiquer le résultat du traitement de ladite requête vers son SIP (11) à travers l'interface SL/SIP, les moyens pour ledit SIP (11) de construire un bloc de résultat en fonction du traitement effectué, ledit bloc de résultat

étant communiqué au SIP origine (11) à travers lesdites couches de coor-

dination (12), communication (14) et transport (18), ledit SIP origine

(11) après l'activation d'EM (42) transférant ledit résultat au proces-

sus local utilisateur, via l'interface SIP/SL.