EDOC101

Au VIVITRON de Strasbourg

ACQUISITION DE DONNEES

Document de travail

Edition 1.3 12 avril 1991

G.ZEHNACKER

SATD du Centre de Recherches Nucléaires CNRS-IN2P3 France

Remerçiements

Ce document de travail réunit la réflexion des chercheurs et des ingénieurs du CRN. Il décrit les idées émises et les décisions déjà prises pour l’Acquisition auprès du VIVITRON.

Je remercie pour leur collaboration, les collègues chercheurs : F.A.Beck, Th.Byrski, D.Curien, Ph.Dessagne, G.Guillaume, B.Lott et les collègues Ingénieurs : J.B.Bueb, B.Humbert, J.D.Michaud, A.Muser, L.Michel, Ch.Ring, L.Wendling, P.Wittmer, J.Zen. Ce document sera complété ultérieurement par les nouvelles options, choix, décisions.

2

Chapter 1

INTRODUCTION

Les expériences de physique nucléaire auprès du VIVITRON (dont le démarrage est prévu au 2ème semestre 1991) concerneront plusieurs dispositifs expérimentaux.

Il s’agit :

• de EUROGAM (développé dans une collaboration avec France-UK),

• de DEMON (développé en collaboration avec les laboratoires de Louvain la Neuve et du LPC de Caen),

• de ICARE plus spécifiquement strasbourgeois,

• de compteurs couplés au Spectromètre Q3D,

Ces nouveaux équipements expérimentaux devront pouvoir fonctionner soit seuls, soit couplés entre eux. Nous devons donc développer un système global d’acquisition (électronique et informatique), capable de satisfaire ces deux ations avec la caractéristique très importante d’être facilement maîtrisée par le physicien en expérience.

D’autre part, ces équipements se faisant en collaboration, tout le travail scientifique et technique de réalisation devra être partagé entre les différents membres des collaborations associées au Centre de Recherches Nucl

Le présent rapport se propose :

• de résumer les objectifs scientifiques des différents projets de détecteurs

• d’expliciter les besoins des chercheurs auprès des nouvelles machines

• de les traduire en objectifs techniques pour la définition de système d’acquisition

• de bien préciser les fonctions à réaliser par le logiciel

• d’établir les critères de choix du matériel informatique

• de proposer un planning pour le développement du logiciel

Nous précisons encore :

• que de nombreuses décisions, options, orientations sont prises ; • que certaines restent encore à prendre ;

• que les développements en électronique ont commencé

• que les études informatiques se poursuivent,

• que certaines réalisations de logiciel démarreront plus tard. La voie est tracée. Les concrétisations iront en s’amplifiant ! Le présent rapport montrera que de nombreuses options et orientations sont dès à

présent bien définies ; certaines sont encore à préciser. L’état d’avancement des réalisations électroniques permettra d’ici oc 1990 d’avoir toutes les données nécessaires pour la réalisation du software.

LES MULTIDETECTEURS

2.1 EUROGAM

Ces dernières années, le développement des systèmes multidétecteurs de rayonnements γ a permis un essor spectaculaire en physique nucléaire ; les récentes découvertes de certaines propriétés surprenant la matière nucléaire (superdéformation en particulier) a soulevé plusieurs questions fort intéressantes et il est clairement apparu que seule, une nouvelle génération de systèmes multicompteurs ayant à la fois ouvoir de résolution et une efficacité de détection photopic sensiblement améliorés, pourrait répondre à ces questions.

La France et la Grande Bretagne, reconnaissant l’intérêt actuel dans les développements d’équipements en spectroscopie des rayonnements gamma en Europe, et considérant les sites complémentaires en physique nucléaire dispo s dans ces deux pays, ont souhaité collaborer au développement, à la construction et à l’utilisation d’un ensemble de détecteurs de rayonnements gamma appelé EUROGAM.

EUROGAM se présentera comme un système compact comprenant 70 détecteurs Ge entourés de ceintures anti-Compton en BGO ; pour assurer un assemblage efficace de ces détecteurs Ge autour de la cible, il est prévu que ces enceinte i-Compton seront d’épaisseur réduite et seront communs à deux ou plusieurs compteurs Ge adjacents. Ce système de détection se présentera sous forme de 12 pentagones réguliers, 10 d’entre eux comprenant chacun 6 détecte e et les deux autres, 5 détecteurs Ge.

Les détecteurs Ge de gros volume (70 % d’efficacité relative) constitueront les détecteurs de base mais des développements sont en cours sur les nouveaux types de détecteurs pour la phase 2 , ils permettront entre autre une augm ion d’efficacité

L’utilisation d’EUROGAM se fera en deux étapes : pendant la première phase de son utilisation, EUROGAM sera situé au laboratoire de Daresbury en Grande Bretagne et ce, pendant une période de un an ; le système comprenant 45 dćteurs Ge et associé au spectromètre de masse, devrait être opérationnel au début 1992.

Après cette première période, EUROGAM sera installé à Strasbourg auprès du VIV-ITRON ; le nombre de détecteurs Ge passera de 45 à 70 : EUROGAM sera alors associé à d’autres systèmes de détection, tels q ule intérieure BGO, détecteurs 4p particules, etc...

2.2 DEMON

DEMON, DEtecteur MOdulaire de Neutrons, est un ensemble de 96 compteurs de neutrons pouvant être associés dans des géométries diverses et dont l’utilisation s’inscrit principalement dans le cadre de l’étude des mécanismes d’i ction entre ions lourds.

Fruit d’une collaboration Franco-Belge, l’ensemble multidétecteurs est en cours d’élaboration dans trois laboratoires : CRN de Strasbourg, IPN de Louvain la Neuve et LPC de Caen. Cet instrument devrait être opérationnel débu 2, pour fonctionner auprès des accélérateurs CYCLONE (Louvain la Neuve), VIVITRON (Strasbourg) et GANIL (Caen).

Les neutrons constituent des sondes idéales de la matière nucléaire chaude (excitée) puisqu’ils ne subissent pas d’interaction coulombienne; leurs émissions, qui se produisent à toutes les étapes de la réaction, ne so nc pas perturbées par le champ électrique des noyaux et sont caractéristiques du bain de température qui les a générées.

DEMON offrira la possibilité unique d’une étude très complète des interactions entre ions lourds, en particulier des mécanismes de dissipation de l’énergie et de relaxation des divers degrés de liberté du système sionnel. Citons à ce sujet quelques uns des travaux qui pourraient être menés de façon satisfaisante avec DEMON et qui concernent :

• l’émission à partir d’un complexe dinucléaire

• la compétition entre processus d’équilibre et de prééquilibre

• l’évolution du degré de thermalisation avec celui de dissipation

• la dynamique du mécanisme de fusion-fission et sa relation avec la viscosité nucléaire.

• la sélection du mécanisme par l’émission neutronique associée

• la mesure de la taille de la source émettrice par interférométrie de neutrons

• la mise en évidence d’ondes de compression nucléaire.

• etc

Les observables à mesurer ont, bien sûr, conditionné la définition du projet. Une grande efficacité de détection neutronique avoisinant 50% (pour une energie ≃ 30 MeV neutron) a nécessité des détecteurs de d volume (16cm de diamètre pour 20cm de profondeur). La sélection des neutrons est assurée par discrimination n-γ en analysant la forme de l’impulsion délivrée par des photomultiplicateurs rapides couplés aux scintillat liquides NE213. L’énergie des neutrons est mesurée avec une bonne précision sur une base de vol de 1,75m. Enfin, les 96 détecteurs discrets donneront rapidement des distributions angulaires dans différents plans permettant de fixe s ambiguiïté les nombreux paramètres décrivant les sources émettrices, tandis que la signature des mécanismes sera assurée par les déclencheurs (maîtres) en provenance de fragments lourds.

Demon doit fonctioner en association avec d’autres multidétécteurs, tel que Icare, le spectrométre Q3D ou Eurogam, utilisés selon le cas en totalité ou en partie. Mais il doit également pouvoir fonctionner de façon autonom librations etc ...). Pour ce faire cet ensemble instrumental doit être pourvu d’un systéme performant d’acquisition propre et compatible avec les différents accélérateurs ci-dessus.

2.3 ICARE

ICARE est un multidétecteur de fragments complexes et de particules légères chargées, qui sera principalement utilisé au VIVITRON.

Les principaux thèmes de physique étudiés en utilisant ICARE seront les suivants:

• étude des mécanismes de réaction à des énergies incidentes supérieures à 15 MeV/u ; en particulier, équilibration des degrés de liberté du système (partage de l’énergie d’excitation et du moment a ire), processus de prééquilibre dans la fission ou la diffusion très inélastique,

• étude du comportement du noyau à haute énergie d’excitation,

• études de spectroscopie pour la recherche des voies de sortie à faible rendement, isolées difficilement par le seul usage d’un détecteur 4πγ.

La sélection obtenue en imposant la présence d’une décroissance par particule chargée est en effet importante dans le cas de collisions entre ions lourds, où un grand nombre de voies de sortie sont ouvertes. Par exemple, ICARE p it être utilisé dans la mise en évidence de bandes superdéformées dans les régions de masse intermédiaire, où la distribution en énergie des particules légères fournirait une information très intére e sur la déformation du noyau émetteur.

Ce multidétecteur sera composé de :

• 8 télescopes gaz-Si-CsI de grande dynamique en identification, principalement destinés aux fragments complexes ;

• 40 télescopes solides pour la mesure de particules légères chargées, divisés en 16 détecteurs ”avant” et 24 ”arrière”, suivant leur disposition prévue par rapport à l’axe du faisceau.

Les détecteurs ”arrière” sont composés d’une diode silicium mince (40μm) suivie d’un membre CsI, une diode silicium épaisse (300μm) étant ajoutée derrière le membre mince, dans le cas des détecteurs ”avant”. Le nnement de scintillation émis par le CsI est recueilli par une photodiode, ce qui supprime les inconvénients liés à l’emploi de photomultiplicateurs. La mesure des temps de vol des particules légères chargées permettra d’a er les seuils en énergie jusqu’à 0,1 MeV/u.

Principalement, 2 géométries seront utilisées :

• dans la première, les détecteurs de particules légères chargées seront disposées sur plusieurs demi-couronnes mobiles, permettant de réaliser des mesures de corrélation angulaire fragment complexe-particule gée.

• dans la seconde, le montage sera beaucoup plus compact, les détecteurs é étant placés près de la cible afin de couvrir un angle solide maximum.

2.4 Q3D

Le spectromètre magnétique Q3D comprend 3 dipôles à champ uniforme dont le rôle premier est de fournir une grande dispersion (- 20% à + 30% en énergie) dont on peut tirer partie en disposant dans le plan focal des d

L’analyseur permet la sélection des produits issus de la cible sur un grand domaine angulaire (- 150^{o} à + 90^{o}), avec un angle solide de 10msr et une résolution en impulsion de 10^{−4} la base de vol est pour la trajectoire ale de 6.82 m.

Le spectromètre associé à un faisceau d’ions ayant une bonne définition en énergie est un outil performant pour :

• l’étude de noyaux loins de la vallée de stabilité (spectroscopie et mesure de masse).

• la mise en évidence et la caractérisation de niveaux à configuration particulière (corrélation 2p, 2n, α...).

• l’étude des réactions de nucléons (1 à 4 voir plus).

• la compréhension de certains mécanismes de réaction. En particulier les réactions quasiélastiques qui permettent d’améliorer la connaissance du champ moyen, d’analyser le rôle des excitations collectives et des t erts dans la diffusion profondément inélastique.

• des mesures de coïncidences (désexcitation du noyau résiduel et détection de l’éjectile ) qui peuvent être réalisées entre le point cible (équipé d’une détection γ ou de particules) et le plan .

2.4.1 Dispositif de détection auprès du spectromètre magnétique Q3D

Actuellement le plan focal de l’analyseur est équipé d’une chambre ”hybride”, composée de trois compteurs proportionnels et d’une chambre d’ionisation, et d’un scintillateur plastique. Ces détecteurs fournissent respectivement 10 et amètres qui assurent l’identification de l’éjectile et fournissent l’angle de sortie après la cible, la rigidité magnétique et le temps de vol (start fourni par un compteur disposé au voisinage de la cible ou par la pulsation isceau , le stop étant donné par le plastique scintillant). Pour chaque voie de détection, les signaux recueillis sont codés sur 4K. Durant l’acquisition il est nécessaire d’effectuer un contrôle du bon fonctionnement des divers détecteurs d’une part, et de pouvoir réaliser un certain nombre de calculs à partir des informations brutes venant des codeurs d’autr t.

2.4.2 Passage des informations codées aux quantités calculées

Les codeurs physiques (ou données brutes) sont dans le cas de l’utilisation de la chambre hybride et du plastique scintillant, au nombre de 12. Ils permettent tout d’abord d’identifier l’éjectile (paramètres ΔE1, ΔE2, PMG e ) de déterminer sa position sur le plan focal (paramètre X) et son angle de sortie de la cible (paramètres X, Y et Z). En ce qui concerne l’identification de l’éjectile, il est nécessaire de constituer tout d’abord un ou des spectres bidimensionnels au vol et/ou en mémoire (par exemple ΔE*E). Ceci permet de reconnaître les divers noyaux analys s par le spectromètre et ensuite sélectionner, en imposant des conditions sur des codeurs physiques ou calculés (contour), une espèce nucléaire pour obtenir les distributions monoparamétriques ou bidimensionnelles qui la carac risent (rigidité magnétique, angle de réaction versus rigidité......).

2.4.3 Contrôle en ligne

La rigidité magnétique qui est la quantité X, est obtenue à partir de deux informations brutes XG et XD à l’aide d’une expression analytique simple.

L’angle de sortie de la particule issue de la cible est déterminé à partir des quantités X, Y et Z déduites respectivement des informations brutes (XD, XG), (YD, YG) et (ZD, ZG). On peut, en définissant des limites en angle, ir la distribution angulaire sur toute l’ouverture du spectromètre.

La procédure de contrôle en ligne nécessite donc la constitution des spectres relatifs à chaque codeur et aux diverses quantités calculées. Sur ces distributions on désire définir des contours conditionnant ainsi l’ ’ementation de spectres monoparamétriques ou bidimensionnels. Le mode de visualisation est de deux types : ”au vol” ou en mémoire.

10

BESOINS DES CHERCHEURS

L’évolution de l’informatique a été spectaculaire et rapide. Pour aborder de nouveaux développements il est impératif de connaître :

• d’un côté les besoins et les souhaits des physiciens

• et de l’autre les nouveaux outils mis à la disposition des informaticiens Le point commun est la nécessité de définir les données manipulées et les traitements

à leur appliquer.

3.1 Les données

Il faut définir :

• leur origine

• leur structure

• leur volume

• leur destination

3.1.1 Origine

• EUROGAM comprendra à Strasbourg 70 germaniums et 5 à 10 BGo par Ge

• DEMON comprendra 96 détecteurs + quelques voies.

• ICARE comprendra 8 détecteurs fragments complexes et 40 détecteurs particules légères.

• Au spectromètre Q3D sont associés des multicompteurs, une chambre d’ionisation et un scintillateur plastique.

3.1.2 Structure des infos brutes

Les informations peuvent provenir soit d’un seul multidétecteur (EUROGAM, DEMON, ICARE, Q3D) ou de plusieurs à la fois. Il est donc impératif que l’événement contienne l’information :

• nombre de codeurs touchés

• le codeur touché

• le détecteur touché

• la valeur du codeur

• un numéro d’événement

3.1.3 débit

Les prévisions de débit ne sont pas encore définitivement connus.

3.1.4 Destination

Il est souhaité un stockage d’événements pour l’instant sur support magnétique amovible (cassette video 8 mm). Les différents spectres bidimensionnels (matrice de coïncidence), ou les spectres mono seront stockés sur di de bonne capacité (quelques gigaoctets). De plus pour DEMON, ICARE et Q3D il n’est pas possible d’attendre la fin du remplissage de l’exabyte. Un stockage temporaire d’événements sur disque est demandé pour pouvoir former des spectres itionnels avec suffisamment de statistique et pouvoir refaire des spectres avec les mêmes événements mais d’autres conditions. Pour EUROGAM il est prévu un remplissage de cassettes en quelques heures.

3.2 Les traitements

• histogrammes de contrôle des détecteurs

• histogrammes des dispositifs expérimentaux

• histogrammes spécifiques à la physique étudiée

• spectre bidimensionnel constitué en ligne et en différé

3.2.1 Spectres de contrôle détecteur

• pour EUROGAM (en cours de discussion)

• pour DEMON 5 à 10 paramètres par compteur

• pour ICARE 5 à 10 paramètres par événement

• pour Q3D 12 voies codées (information brute)

3.2.2 Spectres conditionnés en plaçant des contours polygonaux

Il est souhaité pouvoir afficher les spectres bidimensionnels sur écran permettant la saisie d’un contour polygonal à l’aide d’une souris, de les stocker sur disque et pouvoir les appeler à la demande. Les conditions sur les codeurs nt à prendre soient à l’intérieur soit à l’extérieur du domaine sélectionné.

Pour bien surveiller l’expérience, des spectres visibles lors de leur constitution fournissent une bonne aide. D’autres opérations faciliteront l’évolution de l’expérience : des opérations de zoom, de sortie sur papier, de car erisation de pics, d’extraction de fond, de fit etc. (voir logiciel graphique de GPSI de Strasbourg , celui de Daresbury et celui d’Orsay sur Sun).

3.2.3 Codeurs calculés

A partir des codeurs physiques il doit être possible de former de nouveaux paramètres (appelés codeurs calculés) obtenus en définissant une formule composée des valeurs de codeurs physiques, de coefficients variables, de f ons mathématiques. Ces nouveaux codeurs seront à leur tour pris en compte comme les codeurs physiques pour constituer des spectres mono ou bidimensionnels. Le traitement doit être possible en ligne ou en différé.

3.2.4 Formation de spectres matrices

Sous ce vocabulaire nous entendons toute la partie ”sorting” c’est à dire tri des événements en fonction de contours polygonaux et de conditions sur les codeurs. Il est demandé de trouver une solution qui permette au chercheur de pr parer facilement ses données pour le sorting, de pouvoir les modifier facilement de préférence sans programmation. Le chercheur souhaite préparer ses données dans un fichier ASCII qui seront

• soit directement incluses dans un programme exécutable

• soit soumises à un programme spécial de tri.

La solution choisie dépendra du système et du matériel choisi. Une bonne convivialité est souhaitée. Un langage proche de l’application du physicien devrait dispenser le chercheur d’utiliser un langage de programmation classique tran)

14

FONCTIONS DU SYSTEME

4.1 Description du système

Le système se compose d’un ensemble de modules ayant chacun une fonction bien déterminée reliées les uns aux autres par des liens logiques et physiques :

Acquisition

• trigger

• acquisition des paramètres

• formation d’histogrammes

• formation des événements Traitement et visualisation en ligne

• formation de spectres mono ou biparamétrique

• formation matrices (conditionnés ou non) Stockage sur bande

• sauvegarde des événements bruts

• sauvegarde des spectres

• sauvegarde des matrices Contrôle

• préparation d’expérience

• du dispositif expérimental

• des spectres du châssis histogramme Analyse et visualisation des matrices et spectres Services • stockage des matrices, spectres sur disque

• serveur de logiciel public et privé

• serveur de périphériques (imprimante, traceur)

• serveur de documentation, mailing, base données schéma de principe du système

17

4.2 Acquisition

4.2.1 Trigger

Cette fonction déclenchera les modules pour former des événements à partir des paramètres codés dans les différents châssis d’instrumentation. Ce trigger sera capable de prendre les paramétres des évé ts de tous les détecteurs mentionnés dans le présent rapport . Des études sont en cours pour satisfaire cette condition .

4.2.2 Acquisition des paramètres

Elle se fait dans des modules rassemblés en châssis VXI dans lequel s’insèreront les éléments qui fourniront les paramètres des événements (chaînes d’amplification, codeurs, module de transfert vers l’E Builder).

4.2.3 Formation d’histogrammes

Dans un châssis histogrammé en VME pour contrôler le bon fonctionnement de la chaîne d’acquisition, nous formerons des spectres provenant directement des codeurs. Cette formation se fera dans un châssis spécial appelé ch sis histogramme. Des spectres monoparamétriques seront constitués par un dispositif matériel appelé DMI implanté dans ce châssis (direct memory increment), des spectres biparamétriques seront eux constitués par logici l sera possible d’accéder à ces spectres à travers le réseau Ethernet, de les mémoriser sur un support magnétique (disque, bande) et même de les visualiser à distance.

4.2.4 Formation des événements

Elle se fera dans un module appelé ’evt builder’ ; celui-çi prendra les paramètres venant des différents châssis VXI pour constituer la structure en bloc d’événements. Ces événements seront envoyés sur un bus ibre optique ou non) sur lequel est branché le module de sauvegarde sur bande, le module de tri et éventuellement d’autres modules.

Ce module est composé d’un châssis VME avec le bus VSB relié à différents modules : Il collecte les paramètres à travers une carte HSM (high speed memory) à partir de carte ROC (read out controller) dans un châssis VXI par l’intermédiaire d’un bus Ferra étendu à 32 bits. Il est initialisé à travers le réseau Ethernet. Il transmet à la machine de tri (sorting) et au module de stockage sur le médium par une liaison à haut débit (par ex : du type FDDI sur fibre optique à 100 M bits) les événements qu’il aura formatés.

Ce module devra donc disposer d’une CPU très rapide avec de la mémoire et un coupleur Ethernet. Les contraintes de temps seront importantes. Un véritable noyau temps réel est souhaitable pour ne pas introduire des temps morts sur l’a ition. Un processeur flottant ne semble pas nécessaire. Le protocole de liaison rapide avec la machine de ”sorting” pourrait être développé à partir de communications interprocess (remote procedure call).

4.3 Traitement et visualisation en ligne

Ce module ”sorting machine” sera chargé de former des spectres mono ou multiparamétriques à partir des événements arrivant de l’Event Builder. Un langage de définitions de codeurs, de spectres, de choix de fenêtres, de polygones de sélection, de conditions multiples, de corrections de gains précisera tous les éléments nécessaires pour la formation des spectres. module de tri doit être capable à la fois

• d’accepter tous les événements venant de l’Event Builder sans introduire de temps morts

• d’aiguiller éventuellement ces événements vers le serveur bande sans traitement préalable

• de former des spectres conditionnés mono ou multiparamétriques

• de stocker ces spectres sur un support d’informations bande

• de stocker une partie des événements bruts sur un disque d’où ils pourront être relus pour former de nouveaux spectres.

Ces spectres constitués pourront être visualisés sur un ou des écrans connectés ou non à cette machine. Au vu de la taille des spectres bidimensionnels 4K * 4K par exemple, il est raisonnable de les visualiser directement et de les déplacer sur le réseau à travers Ethernet. Pour visualiser ces gros spectres bidim dans des délais raisonnables (1 à 2 mn), ces écrans couleur doivent être très performants. Les organes de recopie devront avoir itesses de sortie de quelques minutes seulement pour ne pas dissuader le chercheur en expérience.

L’objectif final est de constituer des matrices 1K * 1K * 1K et de pouvoir les visualiser et les analyser.

Au vu de ces demandes, le choix se portera :

• soit sur un châssis VME avec plusieurs processeurs et un noyau temps réel

• soit à l’aide des nouvelles techniques des transputers liés à du VME

• soit à l’aide d’une ou de plusieurs stations de travail UNIX très performantes.

Le laboratoire de Daresbury utilisera un système à base de VME dans la phase 1 ; pour la phase 2 les différentes solutions vont être étudiées à Strasbourg.

4.4 Stockage des événements

Les événements seront stockés sur un support d’information : bande magnétique ou cassette exabyte. Pour des raisons de coûts et de capacité de stockage (2,4 Goctets) le choix s’est porté sur la cassette Vidéo 8 mm Exa

Pour EUROGAM, les débits d’informations des multidétecteurs seront très importants. Il sera nécessaire de brancher plusieurs exabytes en parallèle pour satisfaire ces débits.

4.5 Contrôle

4.5.1 Préparation acquisition

Le chercheur doit pouvoir préparer facilement les paramètres d’expérience et pouvoir les modifier rapidement s’il le souhaite en fonction des choix qu’il aura fait. Un genre de tableau de bord lui permettra à tout moment d’obtenir des informations sur cette acquisition ; débit des événements, taux de remplissage des supports magnétiques, taux d’erreur du médium, intégrale de spectres savoir instantanément si un châssis VXI ou des codeurs sont en panne etc. Le démarrage, l’arrêt ou la suspension de l’acquisition se fera à partir de la même console que celle prévue pour l’initialisation d’expérience.

4.5.2 Du dispositif expérimental

Les dispositifs expérimentaux comporteront un certain nombre d’éléments à vérifier. Ceuxci détermineront le bon fonctionnement du multidétecteur (par exemple le niveau d’azote, les THT, le maintien de la pression etc..).

Un écran centralisant toutes les informations relatives à ces équipements donnerait immédiatement une vue d’ensemble de tout ce qui n’est pas lié à la physique et aux spectres. Toutes les alarmes y seront centralisées. sûr comme ce module sera branché sur le réseau, il sera possible de suivre ces informations à distance suivant des droits d’accés à préciser et éventuellement de faire du télédiagnostic et téléassistanc s pas d’interventions à distance.

4.5.3 Des spectres

Le suivi d’expérience devrait être automatisé autant faire ce peut. Par exemple mémoriser 50 centres de gravité de pics et de les faire vérifier périodiquement s’il y a un ”shift”, afficher des valeurs d’échelle de co e, faire une sorte d’histogrammes des codeurs (faire + 1 par codeur touché) pour vérifier si chaque codeur marche encore etc...

Le contrôle peut se faire à partir des spectres dans le châssis histogramme. Tous ces spectres doivent pouvoir être consultés à partir de n’importe quelle station de travail connectée sur le réseau Ethernet (de contrôle et commande de l’acquisition). Ils doivent pouvoir également être stock

4.6 Analyse et visualisation

Le physicien souhaite voir des spectres formés, les analyser pour en tirer des conclusions sur le déroulement de son expérience. Certains spectres pourraient être affichés en permanence, d’autres pourraient être choisis en fo n de différents critères.

4.6.1 Fonction des écrans

Le chercheur aura à sa disposition des écrans pour

• surveiller des paramètres (spectres d’expériences)

• pour intervenir sur ceux ci

• pour visualiser des spectres

• pour analyser ces spectres Tous ces paramètres permettront de suivre le déroulement des expériences tant du point de vue de la physique que du bon fonctionnement du matériel (détecteurs, dispositifs expérimentaux ; VXI, codeurs, events builder etc..).

La séparation des fonctions

• de surveillance hard

• de constitution de spectres

• d’analyse permettrait à une équipe en expérience de bien maîtriser tous les éléments en présence.

Le chercheur devrait pouvoir appeler une de ces fonctions à partir de n’importe quelles unités de visualisation du laboratoire y compris de son bureau et non pas seulement de la salle de mesure.

4.6.2 Style des écrans

Les plus récents développements en informatique permettent de fournir des interfaces très conviviaux pour le chercheur.

4.6.3 Type des écrans

Le dialogue avec l’utilisateur se fera par l’intermédiaire d’écrans (frame) spécifiques pour certaines fonctions :

• accés aux aides d’utilisation du logiciel

• entrée des paramètres d’expérience et de run, leur affichage etc.

• affichage d’un ou de plusieurs spectres choisis sélectivement

• affichage permanent de spectres de contrôle

• application de traitements sur ces spectres (fit, recherche automatique de pic, intégration, étalonnage, suppression de bruit de fond, addition, soustraction)

• modification des paramètres de visualisation des spectres

• affichage d’info sur le spectre (canal pointé, contenu, marquage titre etc.)

• recherche, sauvegarde de spectres transfert à distance de spectres

• préparation des infos pour la base de données pour le sorting

• infos sur la base données de spectres

4.6.4 Outils de convivialité

Pour faciliter l’entrée des données, la sélection des commandes, des options, différents outils sont à notre disposition :

• souris ou touche du clavier

• sélection des options choisies par bouton sur écran

• génération de boîte de dialogue

• zone de dialogue ASCII

• zone d’affichage d’informations pour sélection

4.6.5 Types des spectres bidimensionnels

La taille des spectres augmentant il ne sera pas toujours possible de tout voir. Trois possibilités sont envisageables :

• soit l’affichage des spectres au vol (un point représente un canal touché en entier ou en partie) sur écran monochrome de préférence en mémoire et sur écran

• soit l’affichage de spectres bidimensionnels complets ou partiels sur des écrans couleur permettant ainsi de se rendre compte des contenus des canaux

• soit la présentation des spectres bidimensionnels sous formes spatiales, avec des fonctions de rotation éventuelle.

4.6.6 Affichage multiple

Les détecteurs produiront un gros volume d’informations. Pour suivre leur validité il sera nécessaire de pouvoir afficher sur un écran une multitude de spectres sélectionnés judieusement en appelant simplement successivement les spectres voulus. Une alarme indispensable affichera sur un écran spécial toutes les informations décrivant une situation anormale permettant d’intervenir. Celles- ci donneront des informations sur le remplissage des cassettes 8 mm, la place encore dispon le taux d’erreur etc....

4.7 Services

4.7.1 Stockage des matrices, spectres sur dique

Toutes les données doivent être accessibles depuis toutes les stations du réseau ; il sera donc très important de déterminer exactement la taille des disques, leur débit, un temps d’acçes, de connaître la taille max d’un fichier.

4.7.2 Serveur logiciel

Les logiciels d’analyse graphique, les programmes de formation de matrice, les logiciels des utilisateurs seront disponibles depuis toutes les stations.

4.7.3 Serveur périphérique

Les périphériques communs : imprimante rapide, laser, traceur à plume, à jet d’encre couleur

4.7.4 Base de données documentaires

Elle contiendra toutes les contributions des collaborations. Un logiciel de ’serveur de documentation’ a été installé permettant l’accés à distance à tous les documents.

4.7.5 Mailing

Il permet d’échanger avec d’autres laboratoires (DARESBURY, ORSAY, BORDEAUX, LOUVAIN LA NEUVE etc ) des articles, des comptes rendus, des messages, des logiciels.

24

MOYENS TECHNIQUES

5.1 ’Resource Manager’

Pour piloter VXI il faut utiliser un module logiciel appelé resource manager. Ce module doit comprendre des fonctions de traitement, de mémorisation, de communication, d’écriture et de lecture dans les tiroirs VXI. Ce module est donc gé d’initialiser les registres des cartes VXI à partir d’une base de données prédéfinie. Ces registres sont accessibles par un nom de voie et un nom d’élément. Le logiciel n’a pas besoin d’être optimisé du point de du temps de réponse. Différentes solutions sont en étude ; différents noyaux temps réels sont en étude et les choix devront être faits rapidement. Son électronique de commande et de surveillance sera installée dans des châssis VXI pilotés par un Resource Manager. Ses fonctions sont multiples : Ce sont celles d’un système de contrôle et commande en boucle ouverte ou fermée. Elles devront :

• initialiser les châssis VXI et leurs modules

• renvoyer à la demande les valeurs des paramètres des modules

• recevoir des ordres extérieurs à partir de console de surveillance (qui pourront être par exemple des stations de travail)

• reconnaître ces ordres

• les satisfaire en agissant sur les modules dans les châssis VXI

• fournir les éléments pour un tableau synoptique

Les fonctions du Resource Manager doivent comporter tous les éléments pour réaliser un système temps réel à la fois :

• du matériel un processur, de la mémoire, un mécanisme d’interruption, de synchronisation de tâches, communication avec le monde extérieur, Ethernet, ligne série)

• et du logiciel (un noyau temps réel)

5.2 Noyau temps réel

Deux solutions avec des avantages et défauts s’offrent à nous :

• soit un système temps réel OS9 ou OS9000 à télécharger et mise au point sur un châssis extérieur relié par ethernet au Resource Manager

• soit un noyau temps réel mis au point directement dans son environnement VX-WORKS sous UNIX.

L’OS9 ne contient pas tous les outils de développements d’un UNIX. Ce système OS9 ne tourne que sur cartes à processeur de la famille 68000 et pas encore sur d’autres dont nous aurons sans doute besoin dans l’avenir par ex.des cartes d es familles de processeur notamment RISC ayant des puissances de 10 à 20 MIPS. Le système VX-WORKS, par contre, est très bien intégré dans l’environnement UNIX. Un choix de noyau temps réel est possible. Ce système permet aussi de bien répondre à une demande nouvelle de puissance avec les plus r centes cartes processeur sur le marché. Plusieurs laboratoires de l’IN2P3 ont choisi cette solution que nous développerons pour l’acquisition VIVITRON.

5.3 Liaison entre modules

Dans ce système distribué les modules doivent être accessibles par un protocole standard et rapidement mis en oeuvre.

Dans ce système les fonctions seront réparties sur plusieurs châssis VXI, VME et stations de travail. Chacun d’eux disposera d’au moins un processeur, une mémoire, un contrôleur ethernet et suivant le cas un écran, un disque, bande. Ainsi il sera possible de les initialiser, de les surveiller, d’y afficher et analyser des spectres. Différentes possibilités sont actuellement testées pour permettre aux différents logiciels sur chaque module fonctionnel d’

5.4 Outils graphiques

Pour mettre en oeuvre les interfaces graphiques, travaillant sur des stations SUN , nous avons choisi Open Look de SUN. Les bibliotheque sont Xview de SUN et la Xlib sous X-Window R11.4. Les langages de programmation choisis sont : le langage FORTRAN pour les fonctions de traitement spectres et le langage C et C++ pour l’interface graphique. L’interfaçage entre les 2 langages est possible.

5.5 Documentation

Les collaborations françaises ou étrangères nous font parvenir des textes en format TEX et LATEX. Nous avons donc installé le logiciel reconnaissant et imprimant du TEX et LATEX. Il permet aussi de créer des textes, de les anal syntaxiquement et d’imprimer les publications, articles sur une laser. Pour gagner du temps dans la composition des textes le complément à installer serait un logiciel qui a un interface plus convivial et qui permette de faire apparaitre eellement le texte qui sortira sur papier ( en WYSIWIG ). Pour préparer les maquettes des écrans nous avons utilisé le logiciel Idraw faisant partie de la distribution Interview de l’Université de Stanford. Il fonctionne sous X sur les stations Sun 3/50 et les Stations Sparc ( mono ou polyc ). Ce logiciel génère des fichiers postscript.

28

STRUCTURE DES DONNEES

6.1 Type des informations

Les informations manipulées en Physique Nucléaire sont de plusieurs types:

• spectre mono, bi ou multiparamétrique (matrice)

• événements bruts

• data quelconque (positions de pic, emplacement de zones marquées, valeur quelconque).

Il est important d’accompagner les valeurs numériques (par ex: canaux ou counts pour les spectres) par des informations descriptives (appelées suivant les cas: label, descripteur de spectres, attributs, bloc header, titre, commentaires etc.) Dans la suite nous retiendrons le terme label. La taille du label devrait être identique pour tous les types d’informations. Bien entendu la taille des données numériques pourra être variable.

6.2 Médias

Les informations seront mémorisées sur bande magnétique, cartouche Exabyte, disque et en mémoire centrale.

6.2.1 Les spectres

Les spectres sont soit le résultat de l’acquisition, soit le résultat de traitement. Dans les 2 cas au moment de la création du spectre (les canaux), le label de spectre doit être aussi créé. Celui-ci suivra le spectre toute e. Nous créerons donc en mémoire une zone regroupant tous les labels et sur disque un fichier de labels. Dans les deux cas il est possible d’accéder rapidement aux canaux : dans un cas par un pointeur, dans l’autre par un nom de fichier. abels et les données ne seront donc pas nécessairement contigus. Cela simplifiera aussi le ”hardware” du DMI prévu pour former directement des histogrammes.

En mémoire, la place sera demandée au fur et à mesure des besoins. Le système fournissant un pointeur sur la zone fournie. Par la même, les zones obtenues ne seront plus jointives. Une zone ainsi obtenue pourra contenir un ou plu s spectres (les labels étant aussi mis à jour en cascade).

La question se pose sur la possibilité de stocker les canaux d’un spectre dans un fichier ou de stocker les canaux de tous les spectres dans un fichier.

La première solution permet si on y stocke aussi le label, une recherche rapide si on est certain que le spectre existe tout en permettant une connaissance rapide sur tous les spectres grâce au fichier des labels. Il est évident que tous spectres devront se trouver sous un répertoire réservé aux spectres. La deuxième solution éventuellement ne nécessite pas un répertoire spécifique pour les spectres, mais de toute façon l’accès est moins rapide es fichiers risquent de devenir trop gros.

Le choix à faire est donc entre les 2 solutions ou une solution mixte (un fichier pour les petits spectres 4 à 8 k et un fichier pour les spectres multiparamétriques (de quelques kilos ou mega octet).

De toutes façons, il est préférable d’avoir un fichier de données pour un spectre multiparamétrique. Notons aussi qu’il n’y a pas de différence de structure des données pour les spectres mono, bi ou multiparamétriques

6.2.2 Les événements bruts

Les événements créés par l’acquisition seront stockés soit sur Exabyte, soit sur bande par l’intermédiaire d’un buffer en mémoire centrale. Pour y accéder nous pourrions utiliser le pointeur associé au label d’

6.2.3 Les autres types de données

D’autres informations peuvent être nécessaires aux cours des expériences. Celles-ci seront caractérisées par un label et des valeurs numériques. Leur structure sera connue dans le label. Les valeurs numériques seront stoc es dans un bloc identifié différemment des spectres et des événements bruts. mouvement des informations

31

6.3 Structure

Les informations comporteront toujours un label et des valeurs numériques quel que soit le type d’informations.

6.3.1 label

Pour définir le label nous nous sommes inspirés de la norme bande IN2P3. Nous résumons schématiquement quelques unes des zones du label. Les informations sont stockées en général en ASCII dans des blocs de 80 octets.

• nom du run, du propriétaire

• nom et numéro du spectre

• date de création

• type (spectre, matrice, événements, data quelconque)

• taille et type de la donnée élémentaire (en bits, entier ou réel)

• taille des dimensions (x,y,z)

• zone d’usage libre (commentaires, valeurs d’étalonnage etc.)

6.4 données

Sur bande ces données sont regroupées en bloc de 512 octets. Sur disque comme pour tout fichier UNIX il n’y pas de structure en blocs. Le fichier est une suite d’octets accessibles directement.

6.5 Réalisation

6.5.1 mémoire, ram disque, disque

La table de labels est automatiquement implantée en mémoire après chaque login. Lors de chaque création de spectres, de buffer d’événements bruts ou de données numériques quelconques la table de label est mise à j t une demande de place mémoire stockera son emplacement (valeur d’un pointeur) dans la table de labels. Chaque destruction de spectre provoquera sa mise à jour de la table des labels et la restitution de place. Bien entendu les zones de donn s numériques ne sont pas contigues.

Sur disque un stockage d’informations créera la table des labels si elle n’existe pas ou la mettra à jour si elle existe déjà. Puis on créera le fichier des données numériques. Il est souhaité de créer si néce e un répertoire spécifique informations (spectres, événements ou données quelconque). Une commande d’écriture spécifique sur disque est à créer. La commande cp n’est donc pas directement utilisable.

La table des labels sera accessible indépendamment des valeurs des canaux. Une liste de spectres sera faite à partir de cette table (ou fichier) labels sans avoir besoin de scruter tous les spectres...

6.5.2 bande

Le format retenu est conforme à la norme ANSI qui a été adapté pour les besoins de la Physique Nucléaire.

• chaque bande contient des blocs label de volume (VOL1, UVL1, UVL2)

• un fichier de données est précédé d’un groupe de bloc (HDR1, HDR2 ) séparé par un tape marque et suivi d’une tape marque puis d’un groupe de blocs (EOF1, EOF2 )

• les blocs autres que de données ont 80 octets

• chacune de ces entités se termine par une tape marque

• chaque bande se termine par une double tape marque Tout en étant conforme à la norme, nous proposons quelques choix pour simplifier l’acçes aux informations. Nous allons les résumer.

• les fichiers devraient être de type monovolume

• les blocs de données seront de taille variable plus petit ou égal à 8192 octets.

• les champs commencent tous par un espace

• les valeurs numériques sont cadrées à droite et complétées à gauche par zéro ou espace • les zones non utilisées devront être mises à espace.

6.6 Norme bande

6.6.1 Label de volume

VOL1, UVL1, UVL2

6.6.2 Label

HDR1, HDR2, EOF1, EOF2

6.6.3 Fichier de données

COMMENT, SCALER, PARAM, EVENTH, EVENTD, SPECTH, SPECTD 34

REALISATION DU SYSTEME

Ce système (voir schéma plus loin) se compose de fonctions qui pourront être implantées matériellement dans des châssis VXI ou VME. Il pourra évoluer pour accepter sans problèmes majeurs les nouveaux détecteurs. ent compte des études et des réalisations faites dans les collaborations internationales pour les multidétecteurs.

7.1 Trigger

Cette fonction déclenchera les modules pour former des événements à partir des paramètres codés dans les différents châssis d’instrumentation. Des cartes spécifiques sont déjà développées dans le c du projet EUROGAM en standard VXI.

7.2 Acquisition paramètres

Pour réaliser des expériences avec les multidétecteurs, le choix des châssis pour l’électronique associée s’est porté sur le standard VXI. Nous voulons nous placer dans la même philosophie pour l’acquisition locale.

Toute l’électronique dans un autre standard que VXI nécessitera une adaptation spécifique pour transférer les données sur le bus DT32 vers l’event builder. Ceci nécessite donc l’achat d’un châssis VXI, d’un ’Resource er’ et d’une carte ’Read Out Controler’. Une adaptation bus Fera - bus DT32 est en cours dans le cadre de EUROGAM.

7.3 Formation des événements

Cette fonction est réalisée dans un châssis appelé ’Event Builder’. Les événements venant du trigger sont réceptionnés, mis en forme (rajout ou suppression de champs de bits), pour être renvoyés rapidement attente vers le module de tri des événements avec une carte de sortie rapide. D’autres fonctions vont encore être rajoutées à l’ ’Event Builder’; elles seront implantées dans un châssis VME relié au réseau à t s Ethernet. Un logiciel spécifique s’exécutera sous le contrôle d’une CPU rapide. Les événements seront stockés dans une mémoire rapide HSM.

7.4 Formation d’histogramme

Pour contrôler le bon fonctionnement des détecteurs, il est important de pouvoir disposer de moyens de formation de spectres mono et bidimensionnels - dans un châssis VME comportant une CPU, de la mémoire à double acçes d’u pacité suffisante pour stocker les spectres, d’un contrôleur Ethernet permettant de rechercher ces spectres pour les visualiser depuis n’importe quelle station du réseau, les analyser ou les stocker sur support magnétique. Les spectr ront formés par un dispositif ’hardware DMI’ (direct memory increment). Ce châssis sera sous le contrôle d’un logiciel temps réel réalisé avec VX works dans un environnement UNIX. Une station couleur ’Low Cost’ de SUN permettr e voir directement cetains spectres en cours de constitution. Ce châssis sera branché directement sur le bus DT32 de sortie des châssis d’acquisition VXI.

7.5 Stockage des événements

Par une liaison à fort débit les événements viendront de l’event builder dans une carte à développer. Cette liaison sera une liaison en fibre optique dont le protocole peut être assez simple, celle-ci étant en point point et monodirectionnelle. Dans ce châssis VME sera connecté le nouvel exabyte à haute densité et de capacité de 5 GO sur lequel seront rangés les événements. Une CPU avec contrôleur Ethernet, une carte HSM (High d Memory) avec un noyau temps réel permettra avec un logiciel spécifique d’accepter les événements sans introduire de temps morts sur l’acquisition proprement dite. Une autre carte pourra transmettre ces événements vers la sta de tri. Comme le châssis histogramme, toutes les cartes réalisant cette fonction de stockage seront insérés dans un châssis VME.

Ce module servira aussi pour stocker les spectres formés par le châssis histogramme et par la station de travail de tri.

7.6 Contrôle de l’acquisition

L’expérience X-Window acquise au Château de Cristal au cours du 1er semestre 1990 a montré l’utilité d’un affichage permanent des paramètres, le contrôle de l’acquisition et des signaux d’alarme.

Cet affichage sera intégré dans une fenêtre d’interface graphique développée spécifiquement sous X-window (actuellement disponible sur la quasi-totalité des stations de travail).

7.7 Traitement et visualisation en ligne

Une base de données contiendra toutes les indications nécessaires pour le tri des événements. Un langage spécialisé permettra au chercheur de définir facilement toutes les informations sur les codeurs choisis, les domaine sélection, les traitements spécifiques sur les paramètres etc... Un logiciel de tri utilisera ces indications sans programmation pour le chercheur. Une station de travail est l’outil indispensable en complément de l’acquisition. Les s es seront donc affichés directement sur la station supprimant des transferts sur le réseau. Cette station comportera une entrée rapide d’informations par fibre optique, un processeur puissant, avec une mémoire suffisante pour former b up de spectres bidim, un disque de 1 GO (notamment pour stocker temporairement des événements; des spectres et des matrices) et un écran couleur avec accélérateur graphique.

7.8 Extensions futures

La demande d’AP 1991 couvre un seul système d’acquisition. Dans le futur, voir plus haut, il faudra pouvoir disposer de deux systèmes (un pour l’expérience, un autre pour la préparation de l’expérience suivante).

38

AUTORISATION DE PROGRAMME 1991

8.1 Trigger

• cartes spécifiques à développer

8.2 Acquisition paramètres

• un châssis VXI

• un resource manager

• une carte spécifique pour chaque détecteur

• une carte Read Out Controler

• une adaptation bus Ferra - bus DT32

8.3 Event Builder

• un châssis VME

• une carte de sortie rapide (FDDI, du type Lambda, VMV)

• une CPU

• un contrôleur Ethernet

• une carte HSM (high speed memory)

8.4 Formation d’histogrammes

• un châssis VME

• une carte DMI (direct memory increment)

• une carte CPU

• un contrôleur ethernet

• une mémoire double acçes

• une station ’low cost’ de SUN

• une licence VXWORKS

8.5 Stockage des événements

• un châssis VME

• une carte d’entrée rapide (FDDI, du type Lambda, VMV)

• une carte de sortie rapide (FDDI, du type Lambda, VMV)

• un CPU

• un contrôleur Ethernet

• un contrôleur et un exabyte haute densité 5GO

8.6 Contrôle de l’acquisition

• un contrôleur X-Window avec son écran

8.7 Tri des événements et visualisation des spectres

formés

Une station de travail avec:

• un CPU (25 mips - 5 Mflops) avec Ethernet et une mémoire de 32 Moctets

• un disque 1G Octets

• un écran couleur avec accélérateur graphique

• une entrée de données rapide

• un système UNIX avec TCP/IP réalisation de l’acquisition

41 42

Contents

1 INTRODUCTION 3

2 LES MULTIDETECTEURS 5 2.1 EUROGAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 DEMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 ICARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Q3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1 Dispositif de détection auprès du spectromètre magnétique Q3D . . 8 2.4.2 Passage des informations codées aux quantités calculées . . . . . . . 8 2.4.3 Contrôle en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 BESOINS DES CHERCHEURS 11

3.1 Les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 Origine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Structure des infos brutes . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 débit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.4 Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Les traitements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Spectres de contrôle détecteur . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Spectres conditionnés en plaçant des contours polygonaux . . . . . 13 3.2.3 Codeurs calculés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 Formation de spectres matrices . . . . . . . . . . . . . . . . . . . . 13

4 FONCTIONS DU SYSTEME 15 4.1 Description du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Acquisition des paramètres . . . . . . . . . . . . . . . . . . . . . . 18 4.2.3 Formation d’histogrammes . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4 Formation des événements . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Traitement et visualisation en ligne . . . . . . . . . . . . . . . . . . . . . . 19 4.4 Stockage des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5 Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5.1 Préparation acquisition . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.2 Du dispositif expérimental . . . . . . . . . . . . . . . . . . . . . . . 20

4.5.3 Des spectres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6 Analyse et visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6.1 Fonction des écrans . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6.2 Style des écrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.6.3 Type des écrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.6.4 Outils de convivialité . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.6.5 Types des spectres bidimensionnels . . . . . . . . . . . . . . . . . . 22 4.6.6 Affichage multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.7 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.7.1 Stockage des matrices, spectres sur dique . . . . . . . . . . . . . . . 22 4.7.2 Serveur logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.7.3 Serveur périphérique . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.7.4 Base de données documentaires . . . . . . . . . . . . . . . . . . . . 23 4.7.5 Mailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 MOYENS TECHNIQUES 25 5.1 ’Resource Manager’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2 Noyau temps réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3 Liaison entre modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4 Outils graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.5 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 STRUCTURE DES DONNEES 29 6.1 Type des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 Médias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2.1 Les spectres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.2 Les événements bruts . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.2.3 Les autres types de données . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3.1 label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4 données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.5.1 mémoire, ram disque, disque . . . . . . . . . . . . . . . . . . . . . . 32 6.5.2 bande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.6 Norme bande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.6.1 Label de volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.6.2 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.6.3 Fichier de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 REALISATION DU SYSTEME 35 7.1 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Acquisition paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3 Formation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.4 Formation d’histogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.5 Stockage des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.6 Contrôle de l’acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.7 Traitement et visualisation en ligne . . . . . . . . . . . . . . . . . . . . . . 36 7.8 Extensions futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 AUTORISATION DE PROGRAMME 1991 39 8.1 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.2 Acquisition paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.3 Event Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.4 Formation d’histogrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.5 Stockage des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.6 Contrôle de l’acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.7 Tri des événements et visualisation des spectres formés . . . . . . . . . . . 40