ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ

Transcript

1 ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΣΧΟΛΗ ΕΦΑΡΜΟΣΜΕΝΩΝ ΜΑΘΗΜΑΤΙΚΩΝ ΚΑΙ ΦΥΣΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΔΙΑΤΜΗΜΑΤΙΚΟ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ ΤΗΣ ΣΧΟΛΗΣ ΦΥΣΙΚΗ ΚΑΙ ΤΕΧΝΟΛΟΓΙΚΕΣ ΕΦΑΡΜΟΓΕΣ CERN-THESIS //2009 ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ Χαρίλαος Τσαρουχάς Επιβλέπων: Θεόδωρος Αλεξόπουλος Αναπληρωτής Καθηγητής Αθήνα, Δεκέμβρης 2008

2 ΕΙΣΑΓΩΓΗ Η διπλωματική αυτή αναφέρεται στην ανάπτυξη του συστήματος αυτομάτου ελέγχου των ηλεκτρονικών των ανιχνευτών ολίσθησης του πειράματος ATLAS του CERN. To CERN είναι το ευρωπαϊκό κέντρο φυσικής υψηλών ενεργειών, το μεγαλύτερο στον κόσμο σήμερα. Ιδρύθηκε το 1954 και σήμερα περιλαμβάνει 20 χώρες μέλη, μεταξύ των οποίων είναι και η Ελλάδα. Η κύρια έρευνα που γίνεται στο CERN αφορά την μελέτη των δομικών μονάδων της ύλης και των δυνάμεων που τα συγκρατούν μαζί. Τα κύρια εργαλεία για μια τέτοια έρευνα είναι οι επιταχυντές σωματιδίων και οι ανιχνευτές. Ο επιταχυντής που βρίσκεται στο CERN σήμερα είναι ο LHC (Large Hadron Collider) και είναι αυτός που θα ψάξει πιο βαθιά στην ύλη από οποιονδήποτε πριν. Όταν τεθεί σε λειτουργία κατά το 2009, θα συγκρούσει δέσμες πρωτονίων στην ενέργεια των 14TeV. Ο ανιχνευτής ATLAS είναι το πείραμα που φιλοδοξεί να ανακαλύψει τον βασικό μηχανισμό προέλευσης της ύλης, και τις βασικές δυνάμεις αλληλεπίδρασης που διαμορφώνονται στο σύμπαν. Αξίζει να τονισθεί ότι ο ATLAS είναι η μεγαλύτερη ερευνητική συνεργασία που έχει γίνει ποτέ στον χώρο των φυσικών επιστημών. Στο πείραμα παίρνουν μέρος 1800 φυσικοί από 150 πανεπιστήμια και ερευνητικά κέντρα 35 χωρών. Στο πείραμα ATLAS όπως και σε κάθε πείραμα φυσικής υψηλών ενεργειών, είναι απαραίτητη η ανάπτυξη ενός συστήματος που θα ελέγχει τα διάφορα μέρη του ανιχνευτή, αυτό το σύστημα λέγεται Σύστημα Ελέγχου Ανιχνευτή,ή διεθνώς γνωστό ως Detector Control System (DCS). Κύριος σκοπός αυτού του συστήματος είναι η συνεπής και ασφαλής λειτουργία του ανιχνευτή. Επίσης, η αλληλεπίδραση του χρήστη του ανιχνευτή με τις ηλεκτρονικές και λογισμικές μονάδες γίνεται μεσώ του DCS. Αυτό είναι το υπεύθυνο σύστημα της παρακολούθησης των λειτουργικών παραμέτρων και της ολικής κατάστασης του ανιχνευτή, της προώθησης των συναγερμών, και τις αλληλεπίδρασης με το σύστημα που παίρνει τα δεδομένα. Η παρούσα διπλωματική, είναι ένας οργανωμένος σχεδιασμός ανάπτυξης ενός τέτοιου συστήματος ελέγχου ανιχνευτών και η υλοποίησή του.. Σε γενικές γραμμές ο σχεδιασμός περιλαμβάνει

3 Συγκέντρωση των διαθέσιμων πληροφοριών για τις ηλεκτρονικές τιμές των θαλάμων ολίσθησης (τάσεις, ρεύματα, θερμοκρασίες) Σύνδεση με διάφορες βάσεις δεδομένων για την συγκέντρωση των απαραίτητων πληροφοριών που χρειάζονται κατά τον σχεδιασμό του συστήματος. (είδος ανιχνευτικών θαλάμων, ελαττωματικοί αισθητήρες) Σύνδεση σε βάση δεδομένων για την αποθήκευση χρήσιμων πληροφοριών όπως η θερμοκρασία των ηλεκτρονικών. Σχεδίαση γραφικού περιβάλλοντος διεπαφής χρήστη. Μοντελοποίηση του ανιχνευτή ως μηχανή πεπερασμένων καταστάσεων Χειρισμός των συναγερμών Το λογισμικό που χρησιμοποιήθηκε είναι το πακέτο PVSSII που είναι ένα λογισμικό ελέγχου και αποθήκευσης δεδομένων. Τα κύρια στοιχεία του PVSSII είναι Μια βάση δεδομένων Χειρισμός συναγερμών Γραφική Σχεδίαση Γλώσσα προγραμματισμού βασισμένη στην C++. Οδηγοί επικοινωνίας PVSSII ηλεκτρονικών. Η χρήση πακέτων αυτομάτου ελέγχου (όπως το PVSSII) και γενικότερα του συστήματος αυτομάτου ελέγχου, είναι τόσο αναγκαία και διαδεδομένη στο CERN τα τελευταία χρόνια που στα τέλη του 1990 αποφασίστηκε να οριστεί μια ομάδα που δημιούργησε ένα λογισμικό πλαίσιο (JCOP framework) από οδηγίες και εργαλεία λογισμικού, που διευκολύνει την ανάπτυξη του αυτομάτου ελέγχου στα διάφορα πειράματα του CERN. Αυτό το πλαίσιο δίνει οδηγίες για Οργάνωση βιβλιοθηκών Συμβάσεις ονομάτων Συμβάσεις εμφάνισης Προγραμματιστικά εργαλεία Το πρώτο κεφάλαιο της διπλωματικής αναφέρεται στον οργανισμό CERN, τον επιταχυντή LHC και τον ανιχνευτή ATLAS. Το δεύτερο κεφάλαιο μιλάει για το λογισμικό πακέτο PVSSII, το λογισμικό πλαίσιο JCOPfw και του μοντέλου μηχανής πεπερασμένων καταστάσεων ένα μοντέλο πολύ διαδεδομένο στην αρχιτεκτονική συστημάτων ελέγχου. Το τρίτο κεφάλαιο, για το συγκεκριμένο σύστημα ελέγχου των ανιχνευτών ολίσθησης που έχει να κάνει με τα ηλεκτρονικά των θαλάμων. Δίνονται λεπτομέρειες πάνω στην αρχιτεκτονική αυτού του συστήματος στην σύνδεση με τους διάφορους υπολογιστές και βάσεις δεδομένων, και την εσωτερική του λογική. Επίσης σε αυτό το κεφάλαιο βρίσκεται η καθεαυτού πληροφορία των ηλεκτρονικών των θαλάμων ολίσθησης.

4 Το τέταρτο κεφάλαιο, επικεντρώνεται στην μοντελοποίηση του ανιχνευτή ως μηχανή πεπερασμένων καταστάσεων. Η επιτυχία αυτής της ιεραρχίας γίνεται φανερή όταν ο αριθμός των δομικών και λογικών μονάδων του συστήματος ελέγχου γίνεται αρκετά μεγάλος. Στο ίδιο κεφάλαιο αναφέρονται και οι βασικές ιδέες της κεντρικής ομάδας του συστήματος αυτομάτου ελέγχου ολόκληρου του ανιχνευτή. Το πέμπτο κεφάλαιο ασχολείται με το σημαντικό θέμα της διαχείρισης των συναγερμών. Ποιες σημαντικές πληροφορίες συνδέονται με τους συναγερμούς και ποια είναι τα όρια των αντιστοίχων τιμών που θα πρέπει να ενεργοποιούν τους συναγερμούς. Το έκτο κεφάλαιο, έχει να κάνει με την διαχείριση των μασκών. Η διαδικασία της Μάσκας έχει να κάνει με την απενεργοποίηση των αισθητήρων αυτών που μας δίνουν ασαφή νούμερα για τις διάφορα μετρούμενα ηλεκτρονικά μεγέθη. Στο έβδομο κεφάλαιο παρουσιάζεται η επιφάνεια διεπαφής του χρήστη με το σύστημα. Περιγράφονται όλα τα λειτουργικά παράθυρα καθώς και πως γίνεται ο χειρισμός τους.

5

6 NATIONAL TECHNICAL UNIVERSITY OF ATHENS SCHOOL OF APPLIED SCIENCES DEPARTMENT OF PHYSICS HIGHT ENERGY PHYSICS LABORATORY MDT DCS ELECTRONICS SYSTEM DIPLOMA THESIS Charilaos A. Tsarouchas Advisor: Theodoros Alexopoulos Associate Professor Exam committee.... Theodoros Alexopoulos Associate Professor... Evangelos Gazis Professor... Georgios Tsipolitis Assistant Professor Athens, (June of 2006).

7 ... Charilaos A. Tsarouchas c (2006) NATIONAL TECHNICAL UNIVERSITY OF ATHENS. All rights reserved.

8

9 Abstract This note has the aim to present the Detector Control System for the Monitoring of the electronics values of MDT chambers in ATLAS experiment in CERN. This system is decided to be called in short ELTX. The principal task of DCS is to enable and ensure the coherent and safe operation of the detector. The interaction of detector expers, users or shifters to the detector hardware is also done via DCS. This is the responsible system of monitoring the operational parameters and the overall state of the detector, the alarm generation and handling, the connection of hardware values to databases and the interaction with the DAQ system. Through this thesis, one can see what ELTX system has to offer as a Detector Control System and in detail, what is the hardware to be controlled and monitored. Moreover it is presented the mainstream of central Atlas DCS concerning the active interfaces.eltx is a system following these standards. 5

10

11 Contents Contents 7 List of Figures 11 1 Introduction CERN in a nutshell The Name The Mission CERN Around the World Large Hadron Collider The past the present and the future Interesting statistics and facts The ATLAS Detector The ATLAS collaboration Interesting facts From Fundamental Science to Everyone s Life Detector Control System in ATLAS The Task of Detector Control System and a small history Tools for Detector Control System PVSS-II JCOP framework The Finite State Machine Concept This thesis, a Detector Control System MDT Electronics Detector Control System ELTX DCS, The architecture of the project Front End Back End Connection to the Power Supply system Connection to the MDM systems Connection to the Databases Connection to the Configuration Databases

12 3.6.2 connection to the Condition Data Base MDT ELTX Copy Manager Finite State Machine Finite State Machine FSM hierarchy Global Control Station Subdetector Control Station Local Control Station State and Status Concept FSM Types FSM Device Types FSM Object Types FSM of ELTX project ELTX Device Type ELTX Object Type FSM transition diagrams FSM Creation tool Alarm Handling Values to be Alarmed Alarms of Mezzanine Cards Alarms of the CSM Card Alarms of the Control Manager Running Alarm Handling tool Comments on the Alarms Alarm Screen Mask Handling Mask Alarm mechanism Bad Sensor Report to ATONR DB Bad Mezzanine Report to ATONR CONF DB Cases of Not Working Mezzanine Cards Mask Algorithm in Steps Operation Interfaces Operation Interfaces Atlas DCS Navigation Buttons Atlas DCS Main Panel Atlas DCS Secondary panel Partition FSM panel Sector panel Chamber panel Partition information panel

13 7.1.8 Sector information panel Chamber information panel Endcap Partition Panel Parallel Panel Navigation Chamber in state NOT READY A Material Concerning CERN, ATLAS and LHC 91 A.1 A Giant Takes On Physics Biggest Questions A.2 The First Official Announcement of the LHC Start B Libraries Used From ELTX project 103 B.1 ELTX Libraries B.1.1 MDT ELTX CopyMechanism.lst B.1.2 MDT ELTX CopyMyDpsFromMDMs.ctl B.1.3 MDT ELTX AlarmMechanism.lst B.1.4 MDT ELTX AlarmHandling.ctl B.1.5 MDT ELTX LIB 3D.ctl B.1.6 MDT ELTX LIB Alarms.ctl B.1.7 MDT ELTX LIB Comments.ctl B.1.8 MDT ELTX LIB ConditionDB.ctl B.1.9 MDT ELTX LIB Constants.ctl B.1.10 MDT ELTX LIB Contact.ctl B.1.11 MDT ELTX LIB Copy.ctl B.1.12 MDT ELTX LIB Database.ctl B.1.13 MDT ELTX LIB General.ctl B.1.14 MDT ELTX LIB Masks.ctl Bibliography 173

14

15 List of Figures 1.1 A black and white reproduction of the Swiss postage stamp issued in honour of CERN In pursuit of some of the most exciting science of our time, the Large Hadron Collider has pushed the boundaries of technology and the scale of science experiments to new extremes The ATLAS detector will search for new discoveries in the head-on collisions of protons of extraordinarily high energy The 35 ATLAS experiment collaborating nations are shown in Figure At the same time as they pursue fundamental developments, ATLAS scientists are taking the knowledge they have gained in their ATLAS work and applying it in other fields The concept of managers The concept of distributed systems The concept of datapoints The different elements of DCS software The Detector Control system Modeling Schematic diagram of the architecture of the ELTX DCS project, how it is connected to the various systems and databases Schematic diagram of readout electronics of MDT chambers On the right there is the block diagram of a mezzanine card. On the left is the mezzanine card itself On the left, the passive interconnect board. On the right the CSM card(one can notice the TTC fiber connector on the top) The ELTX project connected to the PS machines The datapoint (dp) structure inside the power supply system. ELTX project is interested and is connected to the LV datapoint element. On the left the dp structure of Power Supply system on the right the dp structure of ELTX system The ELTX project connected to the MDM machines The datapoint (dp) structure inside an MDM system on the left while on the right the dp structure of ELTX system

16 3.9 The ELTX project connected to the Databases The ELTX project connected to the configuration DB for information about the masking of mezzanine cards.the update of this information is done automatically every 12 hours The ELTX project connected to the configuration DB for information about the masking of the electronics sensors.the update of this information is done automatically every 12 hours The ELTX project connected to the condition DB.The information uploaded concerning the temperature, the analog and the digital voltage of the mezzanine cards.moreover these values are written in the database after the filtering of an appropriate smoothing The information retrieved from the condition database on the chamber panel. One can see the temperature value of the mezzanine card number 2 of the chamber BML3A01 for the last eight hours (the time interval can be changed on line) The responsible manager for the connection of the project to the various systems and databases. This control manager is the heart of the project and should be always running The coffee machine FSM. The usage of FSM in High Energy Physics projects and other real life application, like the coffee machine, can be very different. On the other hand the representation of the states or actions of a coffee machine can still be done with the use of an FSM diagram The Global Control Station inside the ATLAS control room SCX1. From this station, one can navigate to all the integrated ATLAS DCS systems The Muon Subdetector Control Station inside the ATLAS control room SCX1. One can navigate to the ELTX DCS project through this control station The ATLAS FSM hierarchy from the top level the GCS to the bottom level the LCS. Following the tree one can find the ELTX project branch The four central DCS predefined status names with their color convention. For the states, there is not such strict enumeration while each system has its own needs and definitions.nevertheless color convention and basic naming conventions are centrally defined for the states too

17 4.6 In the picture one can see the Device Editor and Navigator panel, a tool from JCOP fw used to make the various Device and Object types a DCS project may need. On the left panel there is the hierarchy of ELTX project represented in this tool while on the right is the two areas, on top the Device units Types and on bottom the object types The FSM hierarchy of ELTX project.there are four layers, the bottom is a device type representation of the chambers while the upper levels are represented of object types Device unit types represent the lower parts of the FSM hierarchy, the chambers Object types represent the upper layers of the FSM hierarchy, the sectors and the partitions A transition diagram of FSM. This one, is the transition diagram of the sector level The panel - tool that creates the FSM hierarchy inside the ELTX project Alarm ranges and limit texts of Mezzanine card temperature Alarm ranges and limit texts of Mezzanine card analog Voltage Alarm ranges and limit texts of Mezzanine card digital Voltage The picture displays the alarm ranges and limit texts of the CSM temperature alarm as it appears in the alarm configuration of the correspondent datapoints The picture displays the datapoints connecter to the control managers of the project that should always run. In case of a manager stop, the information propagates in the alarm configuration datapoints and from there to the alarm screen The panel to configure the alarms of the ELTX project The different functionalities of the alarm configuration tool Datapoint parametrization, one can see the alert hdl config and the common config for the comments The alarm screen as it appears in the control room. A correspondent filter is applied in order to display only the alarms of ELTX projected The ATONR database updated the project datapoints concerning the defective sensors. The ATONR CONF database, updates the project datapoints concerning the not working mezzanine cards The ATONR database information about the defective sensors The ATONR CONF database information about the not working mezzanines The alarm configuration of the masked datapoints. As one can see the alarm text is in this case Masked and the alarm handling is inactive

18 6.5 Schematically the three cases that chambers appear with masked mezzanines in the ATONR database The operation Interface of ATLAS DCS. The screen is divided in three main parts, the navigation buttons, the secondary panel and the main panel Panel to give an overview of a hole partition concerning the electronic values of MDT chambers. By clicking on the corresponding chamber rectangle one can navigate directly to the panel of this chamber Panel to summarize information of MDT chambers concerning electronics values on a sector level Panel to display information about an MDT chamber. The main information of this panel has to do with the chambers electronics values - the electronic values of CSM card and the electronic values of Mezzanine cards Panel as a statistics and debugging tool this panel is empty.in future it will be used for the display of 3d view objects Panel to display extra information about an MDT chamber. The main information of this panel has to do with the electronic view of MDT chambers. It displays the canbus node this chamber is connected to and all the rest chambers connected to the same canbus with the right sequence Panel to display information about the front end electronics for endcap partitions The use of the main and information panel in parallel. The main panel is on the sector level while the information panel is on the partition level In case the state of the chamber is NOT READY, there is not mean to display the information to panels. This way confusion of shifters is avoided

19 Chapter 1 Introduction 1.1 CERN in a nutshell CERN is the European Organization for Nuclear Research, the world s largest particle physics center. It sits astride the Franco-Swiss border near Geneva.Founded in 1954, the laboratory was one of Europe s first joint ventures and includes now 20 Member States. CERN is a laboratory where scientists unite to study the building blocks of matter and the forces that hold them together. CERN exists primarily to provide them with the necessary tools. These are accelerators, which accelerate particles to almost the speed of light and detectors to make the particles visible. Figure 1.1: A black and white reproduction of the Swiss postage stamp issued in honour of CERN. 15

20 1.1.1 The Name The name CERN is derived from the French Conseil Europien pour la Recherche Nucliaire, or European Council for Nuclear Research, a provisional body founded in 1951 with the mandate of establishing a world-class fundamental physics research organization in Europe. At that time, pure physics research concentrated on understanding the inside of the atom, hence the word nuclear. Today, our understanding of matter goes much deeper than the nucleus, and CERN s main area of research is particle physics the study of the fundamental constituents of matter and the forces acting between them. Because of this, the laboratory operated by CERN is commonly referred to as the European Laboratory for Particle Physics The Mission As soon as CERN was founded back at 1954, a convention was established which clearly laid down the main missions for the Organization. The Organization shall provide for collaboration among European States in nuclear research of a pure scientific and fundamental character (...). The Organization shall have no concern with work for military requirements and the results of its experimental and theoretical work shall be published or otherwise made generally available. Today 54 years later, this main mission remains essentially the same. The Convention also states that CERN shall organize and sponsor international cooperation in research, promoting contacts between scientists and interchange with other laboratories and institutes. This includes dissemination of information, and the provision of advanced training for research workers, which continue to be reflected in the current programmes for technology transfer and education and training at many levels CERN Around the World CERN is run by 20 European Member States, but many non-european countries are also involved in different ways. Scientists come from around the world to use CERN s facilities. The current Member States are: Austria, Belgium, Bulgaria, the Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Italy, the Netherlands, Norway, Poland, Portugal, the Slovak Republic, Spain, Sweden, Switzerland and the United Kingdom. Besides there are many non-member states and some others called observer states, that are currently involved in several CERN programmes. Scientists from some 580 institutes and universities around the world use CERN s facilities. Some 8000 visiting scientists, half of the world s particle physicists, come to CERN for their research. They represent 580 universities and 85 nationalities.

21 1.2 Large Hadron Collider The Large Hadron Collider (LHC) is a particle accelerator which will probe deeper into matter than ever before. Due to switch on in 2007, it will ultimately collide beams of protons at an energy of 14 TeV. Beams of lead nuclei will be also accelerated, smashing together with a collision energy of 1150 TeV. The LHC is the next step in a voyage of discovery which began a century ago. Back then, scientists had just discovered all kinds of mysterious rays, X-rays, cathode rays, alpha and beta rays. Where did they come from? Were they all made of the same thing, and if so what? These questions have now been answered, giving us a much greater understanding of the Universe. Along the way, the answers have changed our daily lives, giving us televisions, transistors, medical imaging devices and computers. On the threshold of the 21st century, we face new questions which the LHC is designed to address. Who can tell what new developments the answers may bring? The past the present and the future During the first half of this century, achievements in Europe dominated progress in the physics, from the discovery of the electron to the atomic nucleus and its constituents, from special relativity to quantum mechanics. Sadly, the conflicts of the 1930s and 40s interrupted this as many scientists had to leave for calmer shores. The return of peace heralded some decisive changes. By the early 50s, the Americans had understood that further progress needed more sophisticated instruments, and that investment in basic science could drive economic and technological development. While scientists in Europe still relied on simple equipment based on radioactivity and cosmic rays, powerful accelerators were being built in the US. Table-top experiments were being overtaken by projects involving large teams of scientists and engineers. A few far-sighted physicists, such as Rabi, Amaldi, Auger and de Rougemont, perceived that co-operation was the only way forward for front-line research in Europe. Despite fine intellectual traditions and prestigious universities, no European country could cope alone. The creation of a European Laboratory was recommended at a UNESCO meeting in Florence in 1950, and less than three years later a Convention was signed by 12 countries of the Conseil Europien pour la Recherche Nucliaire. CERN was born, the prototype of a chain of European institutions in space, astronomy and molecular biology, and Europe was poised to regain its illustrious place on the scientific map. CERN exists primarily to provide European physicists with accelerators that meet research demands at the limits of human knowledge.in the quest for higher interaction energies, the Laboratory has played a leading role in developing colliding beam machines. Notable firsts were the Intersecting Storage Rings (ISR) protonproton collider commissioned in 1971, and the proton-antiproton collider at the

22 Figure 1.2: In pursuit of some of the most exciting science of our time, the Large Hadron Collider has pushed the boundaries of technology and the scale of science experiments to new extremes. Super Proton Synchrotron (SPS), which came on the air in 1981 and produced the massive W and Z two years later, confirming the unified theory of electromagnetic and weak forces. The main impetus at present if from the Large Electron-Positron Collider (LEP),two years later, confirming the unified theory of electromagnetic and weak forces. The main impetus at present if from the Large Electron-Positron Collider (LEP),where measurements unsurpassed in quantity and quality are testing our best description of sub-atomic Nature, the Standard Model, to a fraction of 1% soon to reach one part in a thousand. By 1996, the LEP energy was doubled to 90 GeV per beam in LEPII, opening up an important new discovery domain. More high precision results are expected in abundance throughout the rest of the decade, which should substantially improve our present understanding. The LEP/LEPII missions will by then be largely completed.

23 1.2.2 Interesting statistics and facts Below we can see a summary of the vital statistics of the large hadron collider. Particles used: Protons (in proton- proton collisions) and then somewhat later heavy ions (Lead, full stripped 82+) Circumference: 26,659 m. Nominal beam energy in physics: 7 TeV (protons) Magnetic field at 7 TeV: 8.33 Tesla Operating temperature: 1.9 K Number of magnets: 9300 Number of main dipoles: 1232 Number of quadrupoles: 858 Number of correcting magnets: 6208 Field strength at top energy 5.5 MV/m Power consumption: 120 MW Gradient of the tunnel: 1.4 Difference between highest and lowest points: 122 m. Following some interesting facts about the machine. The combined strands of the superconducting cable being produced for the LHC would go around the equator 6.8 times. If you added all the filaments of the strands together they would stretch to the sun and back 5 times with enough left over for a few trips to the moon. Part of the LHC will be the world s largest fridge. It could hold fridge full of sausages at a temperature colder than deep outer space. The vacuum in the LHC is comparable to outer space, if it were a car tyre with a leak, there are so few gas molecules that it would take years to go flat. When the 27km long circular tunnel at CERN was excavated, between lake Geneva and the Jura mountain range, the two ends met up with just one centimeter of error. LEP was sensitive to the departure of the TGV from Geneva train station, DC current feeds the tracks but the ground return is not good. The LEP electrical earthing network is a better conductor and so some of the train current returned back through the LEP vacuum chamber.

24 The Large Hadron Collider at CERN could be the most ambitious scientific undertaking ever. The results of LHC experiments will probably change our fundamental knowledge of the universe. CERN is the world s largest laboratory dedicated to the pursuit of fundamental science Many of the parts for the ATLAS detector of the LHC were manufactured using the expertise of ex-arms scientists and factories, through collaboration with the International Science and Technology Centre. If the Higgs boson exists the LHC will be able to make this particle detectable. Confirming or contradicting the first evidence of the Higgs particle is an exciting prospect! The Nobel prize in physics has twice been awarded to scientists whose experiments were conducted at CERN. The laboratory also boasts several additional Nobel Laureates among its physicists. On 1st October 2003 CERN and the California Institute of Technology set a new Internet Land Speed Record by transferring 1.1 terabytes of data in less than 30 minutes across 7000km of network. The equivalent of transferring a full length DVD movie in 7 seconds. In the 1960 s CERN s main data network was the famous bicycle on line. Tapes of data were loaded into a basket on the bike and then rushed over to the computer centre. Verification of the theory that explains why the sun shines - the weak force - is one of CERN s biggest achievements. The discovery of the neutral current was announced at CERN in The theory was finally confirmed in 1983 with the direct observation of W and Z particles. Since 1962, 38 heads of state have visited CERN. The CERN Fire and Rescue remit covers 40km of underground tunnels, radiation and chemical risks as well as the buildings above ground. CERN firemen train in abseiling and rope rescue techniques in preparation for a tunnel emergency. In 2003, 6.1% of traffic at Geneva International Airport was related to CERN, a total of passengers. X-ray and radiopharmaceutical techniques in medical imaging were developed by particle physicists, as was radiotherapy for cancer patients.

25 Particle accelerators are used to dry the paint on soft drinks cans. The moon and snow/water load on the Jura mountains flexed the earth s crust a little bit which alters the circumference of the LEP ring, in this way the orbit of the moon was detected by LEP. Understanding all of the different forces of nature within one framework is one of the ultimate goals of physics. Decades of experiments at CERN are working towards this % of an atom s volume is empty space. If the proton were a pea, the electron would be in the back of the strands at Old Trafford. When protons arrive in the LHC they are traveling at times the speed of light. Each proton goes around the 27km ring over times a second. A nominal proton beam in the LHC will have an energy equivalent to a person in a Subaru driving at 1700 kph. CERN predicted total for the year 2009 with LHC fully operational is around 1000 GWh of which around 700 GWh might be attributed to the LHC (machine, experiments, baseload). The canton of Geneva uses around 11.4 TWh, so CERN comes in at less that 10% of the total energy consumption of the canton

26 1.3 The ATLAS Detector ATLAS is a particle physics experiment that will explore the fundamental nature of matter and the basic forces that shape our universe. The ATLAS detector will search for new discoveries in the head on collisions of protons of extraordinarily high energy. ATLAS is one of the largest collaborative efforts ever attempted in the physical sciences. There are 1800 physicists (Including 400 students) participating from more than 150 universities and laboratories in 35 countries Figure 1.3: The ATLAS detector will search for new discoveries in the headon collisions of protons of extraordinarily high energy.

27 1.3.1 The ATLAS collaboration The project of making a detector involves more than just following a sheet of instructions. It is a collaboration of over 1850 individuals who have to work together as a team while being thousands of miles apart. This, by its own, is a extremely difficult task. Figure 1.4: The 35 ATLAS experiment collaborating nations are shown in Figure Interesting facts 2100 scientist from 37 countries and 167 universities and labs The weight of ATLAS is the same as 747 (empty) jets. The size of ATLAS is roughly the half of the size of Notre Dame Cathedral 122 kms of superconducting wire in magnets 3000 kilometers of ordinary cable The precision measurement comes to centimeters ( inches) The data recorded will be 3200 terabytes per year equivalent to 7 kilometers of CDROMs stacked on top or 600 years of listening to songs. CPU time planned for reconstruction of a full event 15s

28 estimated lines of code (C++) about 5 million more than 200 software developers worldwide are involved The protons that will collide will be per cent of the speed of light or times per second circling the 27 km ring From Fundamental Science to Everyone s Life The ATLAS experiment, like the other CERN experiments is a basic research project that uses state-of-the-art instruments to explore the outer reaches of our understanding of the universe. At the same time as they pursue these fundamental developments, ATLAS scientists are taking the knowledge they have gained in their ATLAS work and applying it in other fields. There are several applications of the knowledge gained mainly divided in three categories, medical applications, technical applications and culture applications. As for medical applications we can enumerate the multi picture element counters, the computer tomography and the retina project. 1. The innermost layers of the ATLAS experiment will be composed of silicon pixel detectors. The same type of pixel detector can be used for biomedical imaging when a high spatial resolution is needed, for instance in mammography. The detector simply counts the absorbed X-ray quanta individually and the method gives a truly digital image of the absorbed X-ray dose. 2. PIXSCAN is a new method for Computer Tomography (CT). It uses the XPAD, a photon counting detector based on the ATLAS pixel chip. PIXSAN improves the contrast for soft tissues and produces up to 400 images in two seconds. 3. Together with neurobiologists, ATLAS physicists have studied the information that is transmitted from the eye to the brain. The retina is a sophisticated biological pixel detector that converts a visual image into electrical signals, called spikes. These experiments help neurobiologists to understand how living neural systems process and encode information and could one day give artificial sight for the blind. As for technical applications we can enumerate the X-ray detector, the Ultrasonic analysis and the Emergency personnel location. 1. XPIX is an X-ray detector using the XPAD chip developed for ATLAS. It is adapted to a new generation of high-intensity X-ray sources. This radiation is used for the study of the structure of proteins and solid state material

29 2. In ATLAS an ultrasonic analysis technique has been developed to measure the fluorocarbon vapours in the cooling system of the inner detector. This technique has also been used to analyse the gas mixtures in semiconductor production. The analysis of hydrocarbons in oil refinery operations has also employed this technique. 3. A system for finding and rescuing persons in case of an accident in the ATLAS area has been conceived by ATLAS members. The system can be installed at very low costs in virtually all types of environments and is suitable in large areas such as mines where people are often difficult to find. In case of emergency, especially if smoke or fog is present, it helps a rescue team to locate persons in danger. As for culture applications we can enumerate the sound reproduction, the grid computing and education. 1. Precision optical image processing methods were used by ATLAS members to measure and align each of the 16,000 individual silicon detectors of the ATLAS SemiConductor Tracker. Inspired by this approach the same strategy was applied to measuring precisely the shape of the groove on mechanical sound carriers such as phonograph discs and cylinder records. As there is no physical contact with the material, the method can be used to restore and preserve delicate or damaged samples and historical sound recordings. 2. The ATLAS collaboration is taking part in the development of a global computing Grid for data storage and analysis. Via the computing Grid, data from ATLAS and the other LHC experiments will be distributed around the globe and be accessible to all the 5,000 scientists of the LHC experiments located all over the world 3. In participating institutes worldwide, graduate and undergraduate students as well as high school teachers and students are involved in the development, construction and testing of parts of the new detectors. This work provides experience in modern laboratory work, state-of-theart research, cooperation in international teams, and complex problem solving. Figure 1.5: At the same time as they pursue fundamental developments, ATLAS scientists are taking the knowledge they have gained in their ATLAS work and applying it in other fields

30

31 Chapter 2 Detector Control System in ATLAS 2.1 The Task of Detector Control System and a small history The principal task of a Detector Control System (DCS) is to enable the coherent and safe operation of the ATLAS detector. The interaction of detector experts, users or shifters to the detector hardware is also done via DCS. This is the responsible system of monitoring the operational parameters and the overall state of the detector, the alarm generation and handling, the connection of hardware values to databases and the interaction with the DAQ system. Despite the truth that the tasks described above are the principal tasks of any DCS in any era, the way to reach contemporary standards each time are different. For example, although the work done in LEP experiments feed us with a useful and important experience and knowledge, the implementation and integration of DCS in the LHC era, seems to be much different. The basic change has to do with the tools to be used. Taken again as reference the experiments of LEP, one can see the big problem of the lack of standardization. DCS in LEP experiments, based on different programming languages, different protocols or even custom hardware. The problems appeared had to do with difficulties in the integration, difficulties in the maintenance and duplication of work some times. In the times of LHC, CERN has taken more conclusive and straightforward solutions. In the late 90-s the decision taken relied as much as possible in Commercial Off-The self (COTS) components. The main tool chosen for the integration of the back-end was the commercial PVSS-II from the SCADA market. On the same time the Joint COntrols Project (JCOP) is constantly developing a software framework in order to ease the individual DCS integration by supporting control 27

32 systems centrally. Originally the JCOP framework was influenced by the software engineering standard on which development started at the European Space Agency (ESA). 2.2 Tools for Detector Control System In the late 90-s, the four LHC experiments made in common the decision to use the commercial PVSS-II as the SCADA tool to construct their back-end control systems. The very next step was the integration of a software framework based on the chosen package, in order to integrate, sequence and automate the control process at the LHC experiments PVSS-II PVSS is a SCADA system which stands for Supervisory Control And Data Acquisition. The name PVSS is a German abbreviation for Process Visualization and Control System. PVSS provides the following main components and tools: 1. A run time database 2. Alarm generation and handling 3. Graphical Editor 4. Graphical Parameterization tool connected to the structure of database 5. Scripting language following C syntax 6. Drivers for the connection between the PVSS and hardware

33 Figure 2.1: The concept of managers A first concept of high importance is the concept of modularity. The architecture design of PVSS is highly modular. Any function required is handled by a manager. Manager (as called in PVSS) is a functional module especially designed for different tasks. The figure that follows shows a typical PVSS application which is composed of a number of managers. As we can see from the picture, each manager has a specific role. The following lines explain the role of the most important managers. EVM (Event Manager) is a manager responsible for all communications. It is the central processing unit in PVSS. DBM (DataBase Manager) is a manager which provides information to the (run time) database Ctrl (Control Manager) and API Manager are the two main methods for implementing ones own algorithms and routines. The language to be used is C with extensions. UIM (User Intrface Manager) manager forms the interface with the user. These include a graphical editor, a database editor and the general user interface of the application. Another important concept of PVSS is its distribution to various systems. This feature provides a transparent access to all distributed system data, the commands of a subsystem can be kept local or sent from every connected system,the connection (modem, ISDN, LAN) between the individual systems can be permanent or temporary and alarms from connected systems can also be displayed and acknowledged on other systems. All the above features are of vital importance in the ATLAS-scale projects as the machines and subsystems are integrated in a very sophisticated and complex way.

34 Figure 2.2: The concept of distributed systems Finally another important PVSS concept worth to be mentioned is the data point concept. In PVSS the devices are modeled using data points (DPs) under data point types (DPTs). A data point contains the information related to a particular instance of such a device. The DPTs structure is user definable and can be as complex as required. The example which follow represent a DPT of a High Voltage Channel. In the left image we can see the DPT which in our case is FwCaenChannel. This data point is a special type that includes CAEN channels like the channels that will be used from MDT chambers for High Voltage or Low Voltage. Under this type there are the several data points which represent the CAEN channels itself. Moreover in the right image we can see the internal parameters, e.g. imon stands for the current the channel that is above has. Furthermore every internal parameter holds a number of sub elements (address, original, lock ) known as configs and enable specific behavior to be configured for a data point element.

35 2.2.2 JCOP framework Figure 2.3: The concept of datapoints At the instigation of the four LHC experiments, the Joint Controls Project was set up at the late of 90-s. Given the increasing constraints on manpower, as well as the evident similarity in technical requirements for controls amongst the experiments, the project should enable more efficient use of resources to be made. The JCOP framework is an integrated set of guidelines and software tools which is used by DCS developers during the implementation of their own control system application. The framework will include as far as possible all templates, standard elements and functions required to achieve a homogenous control system. The framework provides guidelines for Integration and development Organization of libraries, panels, scripts Naming convention (PVSS system names, DPT names, panel names ) Look and feel conventions (panel size, trend display, colors ) Programming (control script) The following figure gives an overview of a DCS where we can distinguish the elements added by the framework, the devices and the user supervisory.

36 Figure 2.4: The different elements of DCS software Besides the main functionalities referred above, the JCOP framework support its user with even more specific tools. Such tools can be used for trending, for access control or connection with databases. But the most important offer of this framework that should be underlined is that this is the main component for the organization and automation of the DCS of the back end system.

37 2.3 The Finite State Machine Concept FSM Integration is developed from the AWG (Architecture Working Group) of JCOP framework which is intended to cover the common needs of all four experiments. The framework implemented by JCOP teem using the standard selected tools, PVSS and SMI++. (SMI++ is a Finite State Machine toolkit developed firstly for DELPHI needs and then used from other experiments) AWG defined a method for modeling the control system as a hierarchy of finite state machines. In this model there is a state/command interface between the parent and its children. Commands are passed from the parent to its children and the states of the children passed to the parent. In the same model alarms are also propagated upwards through the hierarchy. Moreover AWG defined two types of objects in the FSM hierarchy; those are Control Units (CUs) and Device Units (DUs). The image that follows is a simple example of a control system based on this modeling Figure 2.5: The Detector Control system Modeling As we can see from the above modeling there are two basic representations of physical hardware components or detector systems. DUs typically model a specific piece of equipment e.g. High Voltage Channel. They derive their states from hardware values read by PVSS and convert commands received from their parents to the hardware CUs can model and control the sub tree below them and typically model abstract or logical items. They derive their states from the states of their children and are modeled using a FSM toolkit which is in our case SMI++. Except from DUs and CUs, there is another unit type the Logical Unit (LU). LU also represents an abstract object like CU. Its functionality is more restricted compared with CU, but on the other hand the machine processes are reduced and the performance is improved.

38 An FSM may be thought as a data driven mechanism for modeling the functionality of a piece of equipment or a subsystem. The item to be modeled has several states and between these states it can move by making transitions. These transitions can be triggered by two ways, commands that the developer has chosen before or state changes of a dependent FSM. 2.4 This thesis, a Detector Control System This thesis has the aim to present the Detector Control System for the electronics of the Muon Drift Chambers of ATLAS experiment in CERN. The system that controls and monitors the DCS data come from the electronics of MDT chambers, decided to be called in short ELTX. ELTX DCS as a system under ATLAS DCS, keeps track of all central recommendations and it is developed and organized in a way that can be directly incorporated in the big ATLAS Detector Control System. One of the basic mainstreams of central DCS followed are the active interfaces between the detector and the user. This ensures a coherent and user friendly environment to interact with the detector/system one is interested to. In the beginning the reader can see the purpose and the use of this project. Following, it will be presented the hardware that is to be monitored and controlled, or the front end as it is called in the DCS terminology. Furthermore, one can see the architecture of the project, the connection to the various other systems and databases, and the place it seats, the back end. The heart of the project is the FSM, implemented under the standards of ATLAS DCS and finally incorporated in the big ATLAS tree. In the end it is presented the top level operation interface, the connection of the project to the human level and the alarm propagation mechanism.

39 Chapter 3 MDT Electronics Detector Control System 3.1 ELTX DCS, The architecture of the project ELTX DCS like most of DCS systems integrated in ATLAS detector, is a very modular and complex system. It is a project distributed with several other projects connected with databases or even communicating with the world out of the control room of ATLAS. The following sections ignore the technical details and give an emphasis on the architecture of the project. PS1 Condition DB PS2 ELTX project MDM1 ATONR_conf DB MDM2... MDM8 ATONR DB Figure 3.1: Schematic diagram of the architecture of the ELTX DCS project, how it is connected to the various systems and databases. 35

40 3.2 Front End Front end is the system connected directly to the detector hardware. The following section is a simple presentation of the design of the readout electronics of the MDT system and in particular the electronics monitored and controlled from ELTX DCS. In the following schema we can have an overview of the readout system. The signals of 24 tubes are routed via interconnection cards - hedgehogs, to the readout card, mezzanines. On the mezzanine board eight tubes are processed by one Amplifier/Shaper/Discriminator (ASD) chip and then are routed to the Time to Digital Converted (TDC). Each mezzanine card is then connected to a CSM card. Then another node the CANbus node which is usually called ELMB for Extended Local Monitor Board, is connected to the CSM card. This board in addition to supply the JTAG string to the CSM, is also used to supply configuration code to the CSM and to monitor temperature sensors and supply voltages on the mezzanine boards. Figure 3.2: Schematic diagram of readout electronics of MDT chambers. A first component of MDT chamber electronics is the Mezzanine board. This board houses the electronics of 24 MDT channels and according to the type of MDT chamber (chamber of three or four tube layers) it comes in different configurations. Each mezzanine contains three ASD and one TDC chip. The picture below is a mezzanine of a three-tube layer chamber and side of it is the block diagram of the card. Each mezzanine board draws about 270mA for the analog part and 140mA for the digital part at about 4 Volts. The 4V are regulated to 3.3V by regulators on board.finnaly the consumption per mezzanine is 1.6W.

41 Figure 3.3: On the right there is the block diagram of a mezzanine card. On the left is the mezzanine card itself. A second electronic component that ELTX project monitor is the CSM card.this Chamber Service Module (CSM) is also known as chamber multiplexer. It is composed of two boards, a passive interconnect board and an active board. These boards do several functionalities such as receiving the trigger, timing, and control signals from the TTC system. Then delivering these signals to all mezzanine cards. Moreover CSM multiplex all serial data from the mezzanine cards to a single output stream. Following the output data stream is delivered to a gigabit fiber link connected to the MROD. Finally the CSM card is useful in providing the DCS monitoring function of voltage and temperature sensing. The CSM consumption comes up to 5W.

42 Figure 3.4: On the left, the passive interconnect board. On the right the CSM card(one can notice the TTC fiber connector on the top). 3.3 Back End The back end system manage the information comes from the frond end system and provides a control operation interface for the user. The back end system for the Electronics system of MDT chambers is organized in 1 pc in USA15 room of ATLAS point one. The pc runs on windows XP operational system. The SCADA (Supervisory Control And Data Acquisition) product used is PVSS-II from ETM company. Over PVSS runs the JCOP framework.this framework is the software engineering platform especially designed to easy the development of the control systems for all the four experiments of LHC. 3.4 Connection to the Power Supply system The ELTX project will monitor the electronics of MDT chambers of ATLAS detector. In order to take into consideration the various values collected to the project from the hardware, the information of the low voltage supply is crucial.in case low voltage is off, electronics are not powered on to provide any data. In order to take into consideration the information of a Low Voltage channel, the electronics project is connected to the Power Supply DCS project. In that

43 PS1 PS2 ELTX project Figure 3.5: The ELTX project connected to the PS machines. project, the information of the status of LV is stored in datapoints.(in detail, the information if the LV is On or Off is a datapoint of type boolean, with name LV. e.g. for chamber BIS1A02 the information can be found from the datapoint SystemName:BIS1A02.Mapping.LV. The datapoint type it belongs to is named Fw DUwithScript ) Figure 3.6: The datapoint (dp) structure inside the power supply system. ELTX project is interested and is connected to the LV datapoint element. On the left the dp structure of Power Supply system on the right the dp structure of ELTX system In order to connect this information between the two projects the PVSS function dpconnect() is used. This function registers a work to attributes of individual datapoint elements (in our case the LV datapoint elements).thev work is the name of the control function ( Callback function ) that is called when the values or at-

44 tributes are changed. So, when a LV value changes e.g. from Off to On, this function updates directly the information in the ELTX project. 3.5 Connection to the MDM systems The main information ELTX project monitors come from the MDM systems. This information is the temperature of the each mezzanine card, the analog Voltage of each mezzanine card, the digital voltage of each mezzanine card and 10 values of CSM card. Some of these values are very important like the Temperature of the CSM card and the 2.5V reference value (that should always be 2.5 in order to take trustful data) while others are just for an extra information. ELTX project MDM1 MDM2... MDM8 Figure 3.7: The ELTX project connected to the MDM machines. There are 8 MDM systems with names MDM1, MDM2,... MDM8 that are connected to the, on chamber electronics and read all these data from the hardware. All this information is stored inside the PVSS projects in each of these 8 machines. The datapoint structure inside the MDM systems follow the electronic view. This view is based on the electronic channels of CSM. For example the channel 0 (chann00) value corresponds to the temperature of the 17th mezzanine card. On the other hand, in ELTX system an effort was made in order to keep this information as human oriented as possible. For example the datapoint structure does not contain numbers but mezzanine numbers and sensor strings. The picture below gives an idea of the structure of electronics information in the MDM and ELTX project. In order to connect the information between these projects, the PVSS function dpcopy() was used. If one check the PVSS help can see that dpcopy() copies a datapoint including the parametrization. In more detail under PvssProject/scripts/ there is a.ctl library that contains the function mdteltx CopyMDMdata(). As long as the corresponding manager is running, this function is called every 30 seconds.in

45 Figure 3.8: The datapoint (dp) structure inside an MDM system on the left while on the right the dp structure of ELTX system this way all data exist in the 8 MDM machines are copied in the ELTX machine. It worths to be referred that 30 seconds is a reasonable time for refresh since the update rate of the hardware to the MDM machines is 30 seconds. 3.6 Connection to the Databases There are two configuration databases that the system is taking information from, and one condition database the system is writing values to. The configuration databases are used mainly for some static or semi-static information that the project needs to take into consideration and the condition database is used for writing the values of mezzanine temperatures and voltages.

46 Condition DB ELTX project ATONR_conf DB ATONR DB Figure 3.9: The ELTX project connected to the Databases Connection to the Configuration Databases The first database is take into consideration is the configuration database with the name ATONR CONF. A first functionality of this database is the update of the number of Mezzanine cards each chamber has. This step is needed actually only once during the first setup of the project. The sql query used inside PVSS to retrieve this data is the following: SELECT CHAMBER,MULTILAYER,MEZZANINE,CSM FROM TABLE(atlas conf mdt.dcs r.mezz map()) Another information stored in this database is the information of the canbus node each MDT chamber belongs to and the sequence on this chamber along this canbus line. This information is needed for the electronic view of the chambers, seating in the information panel of the chamber level as one can see in the chapter that refers about the Operation Interface. Again this step is needed actually only once during the first setup of the project. The sql query used inside PVSS to retrieve this data is the following: SELECT CANBUS,CHANNEL,EMDT FROM TABLE(atlas conf mdt.canbus.get canbus for mdt(null)) A third information this database can provide is the information concerning the mapping of mezzanine cards as we physically see them from the read out side of the chambers. There are several rules for the numbering of mezzanine cards, the most important is that the card number 0 must be placed in the side and in the multilayer that is closer to the interaction point. On the other hand there are various exceptions in this rule but all of them stored properly in the database. As long as DCS has this information, can easily display them in a panel as really they should like in read out side, an information useful at least in the commissioning

47 phase of the experiment. Again this information can be characterized quite static so the query is done once in the setup of the project. The sql query used inside PVSS to retrieve this data is the following: SELECT CHAMBER,MULTILAYER,MEZZANINE,CSM FROM TABLE(atlas conf mdt.dcs r.mezz map()). Furthermore there is another very useful information comes from the same database. This information concern the mezzanines that for various reasons are not readable or are damaged. In this case detector people know about these cards and have uploaded this information. Since we know that these electronic cards should not be read then we have to mask them from both panels and alarm mechanism form DCS side too. The function connected to the database and does this work is the function mdteltx UpdateMaskedMEZZflags() that seats under MDT ELTX LIB Masks library. This function is called once every 12 hours and checks what mezzanines are reported as not-to-be-read-out from the database.as soon as this information is downloaded to the project, the alarms of these mezzanines are removed and their display in the panels does not appear. In case that a broken mezzanine is replaced and this is referred to the database, the project is smart enough to reactivate the alarms and the display. The sql query used inside PVSS to retrieve this data is the following: SELECT CSM,MASK FROM TABLE(atlas conf mdt.dcs.csm mask()). ELTX project ATONR_conf DB 12h Figure 3.10: The ELTX project connected to the configuration DB for information about the masking of mezzanine cards.the update of this information is done automatically every 12 hours. Parallel with the information of the mezzanine masking, one can have the information of the electronics sensor masking.this information has to do with e.g. the sensor of a mezzanine card, the temperature sensor or the digital Voltage sensor or the analog Voltage sensor. This information is generated automatically inside the MDM projects and then is reported to the ATONR database. The function connected to the database and does this work is the function UpdateMaskForChamber () that seats under MDT ELTX LIB Masks library. This function is called once every 12 hours (like the function for the mezzanine masking) and checks what sensors are reported as not-to-be-read-out from the database.as soon as this information is downloaded to the project, the alarms of these sensors are removed. In case that a broken sensor is alive again this is referred to the database and the project is smart enough to reactivate the alarms. The sql query used inside PVSS to retrieve this data is the following: SELECT EFF PARENT ELEMENT,CHANNEL,FLAG STATE FROM TABLE(MDT ON LINE SENSOR DATA.ge

48 ELTX project ATONR DB 12h Figure 3.11: The ELTX project connected to the configuration DB for information about the masking of the electronics sensors.the update of this information is done automatically every 12 hours connection to the Condition Data Base In the previous paragraphs, one can see how the ELTX project uses various databases to retrieve useful information. In this paragraph, it is explained how the project writes to one other database, the conditions database. There are some electronics values that are of great importance and some times it would be useful for the shifter to have a quick way to see the history of these data. The values that are decided to be useful and to be written in the conditions database are the data of the temperature of the mezzanine board, the analog and the digital voltage of the mezzanine board. In order not to overload the database a time interval is set to 3400 seconds and a time interval of 3600 is set and a dead band of 0.2 Volts for the voltages and 1.0 Celsius degrees for the temperatures.the writing is done in the condition database using the standard framework function fwarchive start(). ELTX project Conditions DB Figure 3.12: The ELTX project connected to the condition DB.The information uploaded concerning the temperature, the analog and the digital voltage of the mezzanine cards.moreover these values are written in the database after the filtering of an appropriate smoothing These data from the condition DB can be retrieved in the chamber panel. A right click on the values of mezzanine cards will pop up a trending plot. This plot is actually a framework tool that one can choose to display the axis or not and to choose the time interval he is interested to see the history of these values. (The chapter referring to Operation Interface explain this panel with more details). 3.7 MDT ELTX Copy Manager...

49 Figure 3.13: The information retrieved from the condition database on the chamber panel. One can see the temperature value of the mezzanine card number 2 of the chamber BML3A01 for the last eight hours (the time interval can be changed on line). Figure 3.14: The responsible manager for the connection of the project to the various systems and databases. This control manager is the heart of the project and should be always running.

50

51 Chapter 4 Finite State Machine 4.1 Finite State Machine Searching on books or in the world wide web, one can find several definitions for the FSM. For example A mathematical model of an entity that describes its behavior as a result of its past history and current inputs. or Finite state machines (FSM s) are machines (generally computer programs) which proceed in clearly separate and discrete steps from one to another of a finite number of configurations or states. Another definition is a machine with a fixed number of states and no memory, eg the processor in a Turing Machine; used as a theoretical basis for creating efficient algorithms for, eg, communication protocols, lexical analysis and pattern matching. or another is A finite state machine (FSM) or finite state automaton (plural: automata) is a model of behavior composed of a finite number of states, transitions between those states, and actions For the application in DCS like the use done in this thesis and in ATLAS in general, one can say that FSM is a modeling of the detector objects (parts or devices) where each object can have a finite number of states, transition between these states and actions. 4.2 FSM hierarchy During the ATLAS detector operation, many different subdetectors and subsystems have to collaborate as efficient as possible. In order to achieve such high demands the adopted solution of the Back End organization is modularity. In detail the BE system is organized in three functional horizontal layers. This hierarchy match the control model closely to the physical system of ATLAS detector and can provide on the same time global or stand alone operation of the detector and its partitions or systems. The three different horizontal layers are presented in detail below. 47

52 Figure 4.1: The coffee machine FSM. The usage of FSM in High Energy Physics projects and other real life application, like the coffee machine, can be very different. On the other hand the representation of the states or actions of a coffee machine can still be done with the use of an FSM diagram Global Control Station On the top level it is the Global Control Station (GCS) of the detector which has the overall control of the detector. The GCS is able to access all parts of the FSM hierarchy, can monitor all the different panels of the various systems, can execute actions or can include and exclude the different parts.on the other side, GCS is able to see all the alarms of the detector collected in its alarm screen. In one line, GCS ideally can run the ATLAS detector as far as DCS concerned. The Global Control Station is available in the ATLAS control room SCX Subdetector Control Station One level below the GCS seats the Subdetector Control Station (SCS). This station is can have the overall control of the subdetector. The SCS is able to access all parts of the subdetectors FSM hierarchy, can monitor all the different panels of the subdetector, can execute actions or can include and exclude the different parts. On the other side, SCS is able to see all the alarms of the subdetector collected in its alarm screen. One can say that the SCS is a subgroup of the GCS. Each ATLAS subdetector has its own Subdetector Control Station which is available in the ATLAS control room SCX1. Finally one important duty of the SCS is the connection to TDAQ. The interaction of DCS and TDAQ is done in this level.

53 Figure 4.2: The Global Control Station inside the ATLAS control room SCX1. From this station, one can navigate to all the integrated ATLAS DCS systems. Figure 4.3: The Muon Subdetector Control Station inside the ATLAS control room SCX1. One can navigate to the ELTX DCS project through this control station Local Control Station The Local Control Station (LCS) is the lower level of the hierarchy. The LCS is usually responsible of a part of the subdetector or a system of the subdetector like the High Voltage System. One example of a LCS is a station that controls the High Voltage system of the barrel of MDT chambers. The LCS can propagate

54 commands that received from the upper levels of the hierarchy but on the same time can have its own more specific actions to the hardware connected. GCS GCS SCS CIC IDE PIX SCT TRT LAR TIL MDT TGC CSC RPC TDQ TTC partition EA BA BC EC LCS PS MTM ELTX... Figure 4.4: The ATLAS FSM hierarchy from the top level the GCS to the bottom level the LCS. Following the tree one can find the ELTX project branch.

55 4.3 State and Status Concept The DCS information of any node or any level and part of the hierarchy is decided from central ATLAS DCS to be propagated in two ways in parrel.the first information is the information of the state and the second information is the information of the status.these two information roads, are distinct and supplement the one each other. The State information defines the operational mode of the system. (e.g. the chamber BIS1A02 is in state READY) The Status information gives an extra detail on how well is the system working in that particular state. (e.g. the chamber can be in state READY, but the status can be WARNING and reflect an temperature over the presumable in one mezzanine card) The concept of State and Status, is a concept that helps the description of a project in more detail. Moreover another important attribute of this concept is the no-loss of the operational conditions. For example a chamber is ramping up, an operation that can take up to 2 minutes, but during this time a reference voltage of its electronics declines from the presumable value.in this case the status information will carry the alarm information while the state will still be ramping up, giving this way a clear view of the shifter what actually is going on. Figure 4.5: The four central DCS predefined status names with their color convention. For the states, there is not such strict enumeration while each system has its own needs and definitions.nevertheless color convention and basic naming conventions are centrally defined for the states too. 4.4 FSM Types All devises, logical entities, or partitions of the ATLAS detector are built from FSM bricks that are called FSM types. In order to insert a device, or a logical node in the FSM hierarchy you have to create first its prototype brick. This brick is a gathering of FSM rules, State definitions, Status definitions, actions and color conventions. But as soon as this prototype building block is ready, a name of the corresponding object is passed and then the FSM hierarchy is builded.there

56 are two different kinds of such bricks, the Device FSM types and the Object FSM types. Figure 4.6: In the picture one can see the Device Editor and Navigator panel, a tool from JCOP fw used to make the various Device and Object types a DCS project may need. On the left panel there is the hierarchy of ELTX project represented in this tool while on the right is the two areas, on top the Device units Types and on bottom the object types FSM Device Types The device types are the types that usually represent the hardware inside FSM. For example a High Voltage channel, can have its own device type while a temperature sensor can have another device type. Nevertheless, many times in order to reduce granularity and improve the performance of the machines these projects run on, developers form a bigger entity like a chamber as a device unit.

57 This device unit takes into consideration all the hardware belongs to that chamber and this way sets the state and the status. It worths to be mentioned that this part of FSM, the device unit, that is the lower part of FSM, deals directly with datapoints and PVSS script. On the other hand Object types deal with FSM rules based on SML language interacting with PVSS. This language allows detailed specification of objects, such as states and actions and this way enables the finite state machine behavior of the objects inside the control system FSM Object Types The object types are types that represent logical objects or parts inside FSM. These parts usually follow a geometrical segregation. For example a sector of the MDT chambers can be represented as a device type, the object type of sectors. Another important logical entity represented from object types are the partitions, and partitions inside FSM are represented from the object type of partitions. Besides, there are occasions that the geometrical diastasis is not the most suitable one, like for example the canbus node of elmbs. In such cases a logical entity should be based on the electronic view of the hardware, but even in these cases the representation inside FSM is done via the object types.

58 4.5 FSM of ELTX project The FSM tree of the ELTX project follows all the conventions indicated from JCOP fw and central ATLAS DCS. The hierarchy consists of four horizontal layers. The top is the layer of the ELTX project. Right below is the layer of the partitions, there are four partitions according to TDAQ. Below the partitions lies the level of sectors and on the bottom suspends the layer of the chambers. Starting with the opposite directions from chambers to the top of the hierarchy, one can see that the chambers are the only Device Units Types and all the rest are Object Types. MDT_Eltx ECA BA BC ECC SECTOR 01 SECTOR 02 SECTOR 16 BIS1A02 Figure 4.7: The FSM hierarchy of ELTX project.there are four layers, the bottom is a device type representation of the chambers while the upper levels are represented of object types ELTX Device Type All MDT chambers inside the FSM tree is represented from a Device Unit Type. This name of this type is MDT ELTX chamber DU. This device unit that images a chamber has three different states, READY, NOT READY and UNKNOWN and these are all the states an MDT chamber can be characterized as far as the electronics concerned. Besides the states there are four different status conditions, the OK, WARNING, ERROR, FATAL (but actually only the three of them are used since the ELTX project is mainly a monitoring project and should not propagate any threatening alarms like FATAL. Both the state and the status of the chamber are defined through a pvss script. This script connects to all the interesting datapoints that concern the specific

59 chamber and returns an output for the state and the status. Of course the connection mechanism to the datapoints is the dpconnect() function of PVSS and this mean that whenever a change appear in these datapoints,this will trigger the execution of the script with a new output. In detail, for each chamber, there are four datapoints that are used as data validation flags, one datapoint that informs about the Low Voltage supply and then several datapoints concerning temperature and voltage sensors in the read out electronics. The number of the sensor datapoints varies accordingly to the number of mezzanine cards a chamber caries. Determination of States and Status As soon as the information of all relative datapoints described above is collected then the PVSS script of the device unit determines the state and the status of the chamber. It is easy to follow the decision enumerating the condition steps. 1. The first check is the value of the datapoint that checks whether the control manager responsible for the gathering of information from other projects and databases is running (the procedure described in chapter 3). In case the value of this datapoint is FALSE it means that the manager is not running and the state turns to UNKNOWN and the status turns to ERROR. In case the value of this datapoint is TRUE, the manager is running and the check can proceed with the other datapoint values. 2. The second check has to do with the Low Voltage datapoint. In case this datapoints value is FALSE that means that the LV is Off for this chamber so there is no need to check what are the values of the electronics. In such case the state goes to NOT READY and the status goes to OK. Contrarily, in case the value of this datapoint is TRUE, the LV of the chamber is On and the check can proceed with other datapoints. 3. The third check of has to do with some flag datapoints that inform about the quality of the DCS data we take. These three datapoints are the datapoins of the node state, of the csm state and the csm 2.5V reference value. In order to take trustful data the first value should always be 0, the second value should always be 0 and the third value should always be 2.5. In case any of these three values do not follow this rule, that means that the data we take are not trustful and the state goes to NOT READY and the status go to ERROR. In the other case that all these values are the expected ones, the check can proceed. 4. In this step the script checks the real hardware values, in case the analog and digital voltages of Mezzanine cards are 3.3V +/- 0.1V the state stays READY and the status OK. As for the temperature sensors of electronics, in case the temperature stays between Celsius Degrees the state stays READY and the status OK. In the other case that even one temperature

60 sensor or Voltage sensor refers a value different from the expected range, then the state remains READY but the status goes to WARNING 5. In case that all the checks are finished, the control manager is running, the low voltage is on, the untrustful data flags are not raised and all the sensors return proper values the chamber is in state READY and in status OK MDT_Eltx ECA BA BC ECC SECTOR 01 SECTOR 02 SECTOR 16 BIS1A02 Figure 4.8: Device unit types represent the lower parts of the FSM hierarchy, the chambers ELTX Object Type All the layers over the layer of chamber, are represented from Object Types. The number of object types is the same as the number of the rest FSM layers. In detail in ELTX project there are: The MDT SECTOR ELTX object type that represents the sectors as logical objects. This object type defines the state of the sector according to the state of its children - its chambers. The MDT PARTITION ELTX object type that represents the partitions as logical objects. This object type defines the state of the partitions according to the state of their children - their sectors. The ATLAS STATUS object type that propagates the information for all the various nodes of the hierarchy. The ATLAS STATUS object is the same for both the sector and partition level.

61 MDT_Eltx ECA BA BC ECC SECTOR 01 SECTOR 02 SECTOR 16 BIS1A02 Figure 4.9: Object types represent the upper layers of the FSM hierarchy, the sectors and the partitions 4.6 FSM transition diagrams

62 READY UNKNOWN NOT_READY Figure 4.10: A transition diagram of FSM. This one, is the transition diagram of the sector level. 4.7 FSM Creation tool The creation of the FSM hierarchy inside the ELTX project is made by using the panel MDT ELTX FsmConfigurator.pnl that seats under /panels/mdteltx tools folder. A first step before the creation of FSM is the creation of the chamber datapoint types and datapoints themselves inside the project.this is done using the same panel by pressing the button MDT ELTX Create Dp Type and MDT ETLX Create chamber dps. The FSM creation is done in two steps. Firstly,by pressing the button Create Base Structure, this tool creates the FSM hierarchy until the level of sectors. The second step is to insert the chambers into the FSM. Using this tool the user can select what chambers want to be plugged in the hierarchy and what not. Of course finally all MDT chambers should exist in the FSM tree. Finally this is the responsible panel for the start of the archiving of mezzanine values in the Condition database. The values stored are the Mezzanine temperature, the Mezzanine analog voltage and the Mezzanine digital voltage. The archiving starts by pressing the Start Archiving button while there is an option to be stopped by pressing the Stop Archiving button.

63 Figure 4.11: The panel - tool that creates the FSM hierarchy inside the ELTX project

64

65 Chapter 5 Alarm Handling 5.1 Values to be Alarmed ELTX DCS project deals with the values come from the read out electronics of MDT chambers. The project monitors a big variety of data, some of them are for pure monitoring (e.g. voltage values of the csm cards parts) while others are also important to propagate alarms in order to take actions (e.g. temperature of mezzanine cards) Alarms of Mezzanine Cards Each mezzanine card can provide three values, all of them are important for alarm handling. These values are, Temperature of the Mezzanine card Analog Voltage of the mezzanine card (should be around 3.3V) Digital Voltage of the mezzanine card (should be around 3.3V) 61

66 T ( ) Figure 5.1: Alarm ranges and limit texts of Mezzanine card temperature. T ( ) Figure 5.2: Alarm ranges and limit texts of Mezzanine card analog Voltage. T ( ) Figure 5.3: Alarm ranges and limit texts of Mezzanine card digital Voltage.

67 5.1.2 Alarms of the CSM Card The CSM card can provide 10 different values for monitoring.most of these values are voltage reference values in the several parts of the card. Only one of these values decided to be important to be incorporated to the alarm handling mechanism, this value is the value of the temperature of the CSM card. The alarm configuration of the temperature of CSM card is the same as the one of the temperature of mezzanine cards (e.g. same range texts, alarm limits). Temperature of the CSM, the only value to propagate an alarm from this card. 3.3V) T ( ) Figure 5.4: The picture displays the alarm ranges and limit texts of the CSM temperature alarm as it appears in the alarm configuration of the correspondent datapoints Alarms of the Control Manager Running Up to now there are presented alarms that are connected to datapoints which correspond to physical values of the electronics. This subsection describes another type of alarm that does not reflect any sensor value but is also important to be raised in case of need. This alarm checks whether a specific controller is running or not. In the ELTX project there are two managers which should run all time. 1. The first manager should always run is the manager with the predefined number 20 and named MDT ELTX CopyMechanism. This manager is responsible for the connection of the project to the various systems and databases that it should be connected. The detailed information of how this manager works is explained in chapter 3. In case for any reason this manager is not running, the data controlled from the project are not updated and the alarm

68 propagation does not work anymore. The check of the running of this manager is of high importance and the alarm connection informs the shifter as soon as the manager is down. 2. The second manager should always run is the manager with the predefined number 21 and named MDT ELTX AlarmMechanism.This manager is responsible of the alarm custom handling of the project. This manager is made of the need of a reasonable number of alarms in the alarm screen. The project is connected to 1150 MDT chambers. Each chamber has a number of mezzanine cards that vary in most cases between 10 to 18. If we take into consideration that each mezzanine caries three sensors (one of temperature and two of voltages) the final number of sensors connected to the alarm mechanism becomes too big for handling. In addition each activation of the analog and digital voltages should always be in agrement to the supply of Low Voltage. For example in case of no LV, the alarms of the mezzanine voltages should be deactivated. In order to achieve such big number of activations/deactivations without crashing the event manager of the project a new approach is taken concerning these values. For each chamber a new datapoint,.alarms.v sensor Alarm, is created under the chambers folder. This alarm is connected to the values of all voltage sensors of the chamber and in case any of them is triggered it propagates the information to the alarm screen. Moreover the number of activations/deactivations according to the LV supply is now reduced to max 1150 (the number of chambers). In few words, this manager concentrates the alarm information of all analog and digital voltages of mezzanine cards to one datapoint per chamber. This operation, by reducing a lot the computing power needs, makes the connection of the project to the alarm screen feasible.

69 Figure 5.5: The picture displays the datapoints connecter to the control managers of the project that should always run. In case of a manager stop, the information propagates in the alarm configuration datapoints and from there to the alarm screen. 5.2 Alarm Handling tool The alarm configuration of the project is done with the help of the panel - tool, MDT ELTX AlarmConfiguration, that seats under panels/mdteltx tools. This panel is responsible for the configuration of the alarms for both datapoints and managers. Moreover using the selection filter on the left, one can have the list of the chambers that have active alarms, their state of their node is not ok, the case of all temperature values equal to 0 (that means the chamber is not read from MDM machines) and all their possible combinations. The same panel can be used in future for a new alarm configuration, like new alarm range limits for temperature and voltages. In detail, the next lines will present the numerous functionalities of this panel that concern the alarm handling. 1. Firstly by pressing the button Display All MDT, one can have all the MDT chambers in the list with title chambers. Choosing the wanted chambers, with the selection buttons, one can send these chambers to the list Chambers to be Actioned.Since the chambers are on this list, further actions can be applied to them - these actions are on the part 3 of the picture. 2. A first very important action are the Set Chambers Alarms, Set Custom

70 Figure 5.6: The panel to configure the alarms of the ELTX project. Alarm, Activate Temp Alarms and Activate Custom Alarms As soon as this step is done, the selected chambers will be connected and inform alarm screen. In case of any abnormal value the alarm will be propagated and the shifters will be informed. 3. Another couple of important alarms are the alarms that check the running of the vital project managers. The activation of these alarms is done by pressing the button Check Manager in part Apart from the first configuration this tool can be used for future needs of the project. On part 3 one can see the button Set New Alarm Limits that takes into consideration the range limits of the frames like part 4 and propagate this change to all the selected chambers.

71 5. Moreover, on the left, in part 1, there is a selection of chambers with different attributes. For example, one can choose the chambers which have any of their temperature alarm active, the node state that they belong to is indifferent and not all temperature values are 0. Then press the Apply Filter button and have all the chambers with these characteristics in the Chambers list Figure 5.7: The different functionalities of the alarm configuration tool. 5.3 Comments on the Alarms In order to have a full description of the alarm, comments should be added. In principle, an alarmed datapoint propagated its information in the alarm screen. In case that this datapoint does not have any comment configuration, the column description of the alarm screen, returns the datapoint name inside pvss. Most of the cases this datapoint name has a strange name, or is an abbreviation, or has a special meaning for the developer of the project, so, in the same time, in most

72 of the cases this datapoint name is not useful at all in the shifter or user of the alarm screen. In order to have a meaningful name in the Description column of the alarm screen, a comment configuration should be added to the datapoint. This is done easily inside PVSS using the function dpsetcomment(). The only restriction, this description name has, come from the central DCS rules. In detail the rule is : Each DPE for which the alert config is set must have a meaningful descriptor which should not exceed 50 characters, convention subdetector id(3 letters) partition id or system id if infrastruture logical and/or geometrical identification of dp device ELTX project follows these rules and has some main types of alarm comments. example of Mezzanine temperature comment: MDT BA ELTX BIS1A06 Mezz Number 10 Temperature example of Mezzanine Voltage - custom alarm comment: MDT BC ELTX BML6C05 Mezz Voltage example of CSM card temperature comment: MDT BA ELTX BIL1A01 CSM card Temperature example of running manager check dp comment: MDT ELTX script MDT ELTX CopyMechanism.lst

73 Figure 5.8: Datapoint parametrization, one can see the alert hdl config and the common config for the comments 5.4 Alarm Screen Alarm screen is a self-contained panel for the display of all various alarms can occur in the detector. This screen is of great importance and the first to look at in case of any abnormal response. The alarms contained can be filtered in various ways according always to the importance and the user needs. Alarm screen in parallel with the ATLAS DCS OI are the two active interfaces that the DCS user needs in order to drive the experiment at least from the DCS side. This snapshot of the alarm screen was taken in at 9:56. As one can see, this moment appear 25 alarms. All these alarms are of severity: WARNING. The description column gives the details of these alarms. For example, there is the MDT EA ELTX BIS7A10 Mezz Number 10 Temperature alarm. This informs the shifter that in chamber BIS7A10 (belongs to partition Endcap A) of the system ELTX there is a temperature alarm and this alarm comes from the mezzanine number 10. Besides, there is another alarm MDT BA ELTX BIS6A14 Mezz Voltage. This alarm informs that there is a bad voltage value in chamber BIS6A14 in one of its mezzanine cards. The shifter has then to navigate to the chamber and check which mezzanine card raises this alarm.

74 Figure 5.9: The alarm screen as it appears in the control room. A correspondent filter is applied in order to display only the alarms of ELTX projected

75 Chapter 6 Mask Handling 6.1 Mask Alarm mechanism The ELTX project will have to monitor about sensors from the read out electronics of MDT chambers. These sensors are temperature and voltage sensors and are connected to alarms. Due to the very big number of such sensors, the possibility to find a defective one is big. This defective sensor usually returns a very big or negative value, this value triggers the alarm mechanism and finally is propagated to the alarm screen. Now if we take into consideration this very big number of sensors and the possibility to have some of them defective the final number of alarms is very big. This big number of alarms in the alarm screen is not just a theoretical estimation. In the very first days of the project all the bad values came from hardware, alarmed and propagated in the alarm screen. The number of these alarms was so big that finally overloaded the alarm screen. It was for this reason that the first release of the project during the M5 run did not propagated the alarms in the central atlas alarm screen. Soon it was understood that a mask mechanism for known defective sensors should exist. 6.2 Bad Sensor Report to ATONR DB The first step for the masking of defective sensors comes from the MDM machines. As referred in introduction, these machines are responsible for the connection to the hardware (through OPC server) and the acquisition of data. One extra work done inside the MDM projects is the report to a database about hardware that do not send any information for the last 5 minutes. (In detail, firstly there is a check of the node state, the csm state, the csm 2.5V reference value and all these flags that ensure that the data we can get are trustful.if then the check reports trustful data and the update of new values is not happened the last 5 minutes, then a report is sent to the ATONR database). On the picture that follows, on 71

76 ATONR_CONF DB ATONR DB Figure 6.1: The ATONR database updated the project datapoints concerning the defective sensors. The ATONR CONF database, updates the project datapoints concerning the not working mezzanine cards the left there is the query of the chambers that appear to have defective sensors. The channel state corresponds to the mezzanine card that found the defective sensor and the third column corresponds to a flag state. On the right, there is the table that explains the flag state. The tool used for the display of the database is the Benthic Software and on the top section of these panels one can see the sql command. The ELTX project is connected to that database. It makes a query every 2 minutes and in case of changes update its internal datapoints. 6.3 Bad Mezzanine Report to ATONR CONF DB Another step of masking defective sensors comes from the ATONR CONF database. In this database there is the information about the mezzanine cards that for various reasons do not work on the specific chamber. In a case of such a mezzanine, the alarms of temperature, analog Voltage and digital Voltage are masked. This database returns two columns. The first column is the chamber name, and the second column is an integer. This integer contains all the information about how many and which mezzanine cards should be masked. In order to obtain

77 Figure 6.2: The ATONR database information about the defective sensors. the useful information of this integer we have to convert it first to its equal binary number. As soon as one has this number should check if among its digits there are 0s. (In chambers without mezzanine problem only 1s should exist). The numbering of the binary digits should start from the left. It is better to give a small example. Lets say that there is a chamber with 4 mezzanine cards and the binary number we obtain from the database is This means that the 3rd mezzanine card does not work. As soon as the project finds the corresponding not working mezzanines, it masks the alarms the sensors belong to that mezzanine. The ELTX project is connected to that database. It makes a query every 12 hours (defective mezzanines should not detected very often) and in case of changes update its internal datapoints Cases of Not Working Mezzanine Cards There are three kind of sources in the appearance of a masked Mezzanine card in the database. Two of them reflect a real problem in that mezzanine card and

78 Figure 6.3: The ATONR CONF database information about the not working mezzanines. the third one is just a way to inform that there is no mezzanine card in specific position. All MDT chambers have mezzanine cards. Despite the various previous tests before installation, the possibility of some defective cards among this big number, remains appreciable. As soon as one such card is detected, is referred to the ATONR CONF database and as soon as possible is replaced with a new one. In this case the defective card is not yet replaced and should just be masked inside the project in order not to propagate any alarm. There are also cases that the mezzanine cards are working, but the corresponding channel in the CSM card is broken. In such cases, the broken channel is skipped and all the rest mezzanine cards are shifted one position right in the numbering of the CSM channels. When the ELTX project detects such cases, it just copies the proper csm channels in its internal

79 Figure 6.4: The alarm configuration of the masked datapoints. As one can see the alarm text is in this case Masked and the alarm handling is inactive. chamber datapoint structure. So this problem is surpassed in the level of copying mechanism, no alarm mask is needed. Finally there are cases that there are no actually defective mezzanine cards but just cards missing of the read out view of the correspondent chamber due to some geometrical restrictions in that area of the detector (just not enough space there to have MDT tubes and mezzanine cards); 6.4 Mask Algorithm in Steps The procedure of sensors and mezzanine cards masking in accomplished in 2 steps. 1. Proceeds the download of the according information of databases in the project datapoints. (a) A copy from the ATONR CONF db

80 CSM channels: st case: 2 nd case: 3 nd case: : Channel that represents a defective mezzanine (to be replaced) : broken CSM channel, all mezzanines shifted one position right : CSM channel that corresponds to mezzanine that does not physically exists. Just not read out. Figure 6.5: Schematically the three cases that chambers appear with masked mezzanines in the ATONR database. (b) A copy from the ATONR db 2. As soon as the information of the defective sensors/mezzanines exists inside the project, a connection of this information to the corresponding datapoints is established in order to mask (or unmask in case of a fixed problem) them.

81 Chapter 7 Operation Interfaces 7.1 Operation Interfaces A main care of ATLAS DCS is to offer an effective way for the Operation Interface (OI) of the numerous subdetectors/subsystems that belong under its responsibility. The final idea is organized in a single screen window. This interface is armed with a navigation tool that let the user float among all DCS data that come from these different subdetectors/subsystems and are displayed in panels Atlas DCS Navigation Buttons In order to reach easily and quickly any part of the control hierarchy a navigation facility is been integrated within the OI. This navigation tool seats in the top left of the screen. It consists of four self-explained buttons, back, forward, home and go up one level, that allow the navigation to the control node that one is interested to monitor or take action Atlas DCS Main Panel This is the panel that feeds the user with all the basic information concerning the workspace chosen previously with the navigation tool. From this panel the user can see the DCS data in various forms, like numbers,bar trends, tables, plots or geographical representations of the subdetector with the appropriate state connected DCS colors Atlas DCS Secondary panel This is a second small panel, seats on the bottom left and provides its own information for the chosen workspace. This panel is provided with its own navigation tool so one can use it to find supplementary information parallel to the one supplied form the main panel. 77

82 Figure 7.1: The operation Interface of ATLAS DCS. The screen is divided in three main parts, the navigation buttons, the secondary panel and the main panel Partition FSM panel This is a panel to give a graphical representation of MDT chambers presented as rectangles with the corresponding state color, and a circle in the middle with the corresponding status color.(state means the operational state of the chamber while status is an extra parallel information about how well is working the chamber in that state). A useful color map can be found in the bottom. In case of a barrel partition panel, each chamber belongs to a frame, the station frame. This is the barrel station that the chamber belongs to (counting from 1 to 6). With a left click on each chamber rectangle one can navigate directly to the chamber main panel. With a right click on the chamber rectangle, one can navigate to the electronic view information panel of that chamber.

83 Figure 7.2: Panel to give an overview of a hole partition concerning the electronic values of MDT chambers. By clicking on the corresponding chamber rectangle one can navigate directly to the panel of this chamber Sector panel This is a panel to provide a global view of the MDT electronics status in a sector level. On the top, the partition side and the sector information is passed. Then as a main view there is a kind of chamber histogram. On the x-axis the names of the chambers of this sector are displayed. (The letters may be quite small in order to fit all in one panel, but with a mouse over one can see the chamber letters enlarged) On the y-axis, on negative side, the CSM values are displayed. On the positive side the Mezzanine temp values are displayed. Moreover on the top right a Display Mezz values of radio box exists. The default choice is Temperature, but the user can also choose to display the analog voltages or the digital ones. With a mouse over on a mezzanine card rectangle one can also have in a text field the values of analog and digital voltage.

84 Figure 7.3: Panel to summarize information of MDT chambers concerning electronics values on a sector level Chamber panel This is the panel to feed the user with all the necessary information concerning the electronic values that belong to an MDT chamber. The panel is divided in four main frames. The chamber frame (top left) displays the basic information concerning the chamber this panel images. It gives the MDM pc this chambers information is collected. Besides one can see the canbus node name that this chamber belongs to. And the last general information numerates the mezzanine cards built on that chamber. The CSM info frame (top right) presents all the electronics values the CSM can provide. These values are organized in a two column table and among them we can pick out the 2.5V reference value of the CSM card. This value should always be 2.5 (V), in other case the values come from the CSM are not trustful and usually not displayed. In the middle, there is the representation of the MDT chamber from the read

85 Figure 7.4: Panel to display information about an MDT chamber. The main information of this panel has to do with the chambers electronics values - the electronic values of CSM card and the electronic values of Mezzanine cards out side. One can distinguish the mezzanine card. On the top right of each card there is in a white box its own numbering. The first number (no 1 ) always starts in the point of read out side that is closer to the interaction point. Besides the numbering info, other 3 values are displayed per card. These values correspond to the sensors each mezzanine caries (one for temperature, one for analog voltage and one for digital voltage). Finally, in the bottom of the panel, there is the Histogram frame that collects all the mezzanine values of all mezzanines and organize them in three enlightening histograms. With the help of these histograms one can directly see the homogeneity of the chamber electronics or on the other hand any considerable changes.

86 7.1.7 Partition information panel This is a panel to be used as a statistic and debugging tool. It appears with a right click on the navigation button of the sector. On the top, one can see a small statistics of how many chambers are in state READY, NOT READY and UNKNOWN concerning the frond-end electronics. The table below, collects all the info for chambers that are not in READY state and in the four columns it contains, one can find the cause of the problem. 1. The first column passes the information whether the LV of the chamber is On. 2. The second column passes the information about the Node State. Each chamber belongs to a canbus node, in some cases this node may not work properly and the indication BAD informs about that. 3. The next column informs about the CSM card state. The CSM card is an electronic device and in some cases may be defective. That time the CSM state goes to BAD. 4. The last column gives the information of the CSM 2.5V reference value. This value is a value of CSM card that should always be 2.5V. In case this value is not 2.5, the data we obtain from the chamber can not be trustful and the state of the chamber is BAD. On the second bottom part of the panel one can see in what general shape is the project. There are displayed the 8 MDM machines that the project should be connected to in order to take data. In case an MDM X machine is for some reason disconnected, the color of the MDM X box turns from green to red. By the same means is displayed the information about the connection to the power supply machines PS1, PS2. The next important information of this part is the check of the important copying script. This script keeps alive the project as it copies from the various other machines and databases all the information needed for the front end electronics monitoring.

87 Figure 7.5: Panel as a statistics and debugging tool Sector information panel The information panel of the sector for the moment is ready. In future the panel will be used for the display of 3D objects. These objects can be the chambers themselves but also be some histograms or 2-D plots.

88 Figure 7.6: this panel is empty.in future it will be used for the display of 3d view objects Chamber information panel This is the panel to support the user with an electronic view of the canbus the chamber belongs to. It appears with a right click on a navigation button of a chamber. This information panel gives on the top grey rectangle the canbus name the chamber is connected to. Besides, it displays the two leave branches that start from this canbus node and the chambers as buttons, that are connected on the proper sequence. The colors of the chamber-buttons reflect the state color of the chamber (a color map can be found in the partition level panel,on bottom). In case of a mouse over, an information concerning the Low Voltage supply, the canbus state, and the CSM state is displayed. In case the state is fine the state text is OK, while in case there is a problem the state texts is BAD. In case of a left click of a chamber button, the main panel changes to the panel of that

89 Figure 7.7: Panel to display extra information about an MDT chamber. The main information of this panel has to do with the electronic view of MDT chambers. It displays the canbus node this chamber is connected to and all the rest chambers connected to the same canbus with the right sequence corresponding chamber. 7.2 Endcap Partition Panel The next panel is the panel that displays the front end electronics information for the endcap partitions. In this display, each chamber belongs to a frame, the frame of the layer. This is the endcap layer that the chamber belongs to (there are the inner, middle,outer and EE-for EE chambers, layers). With a left click on each chamber rectangle one can navigate directly to the chamber main panel. With a right click on the chamber rectangle, one can navigate to the electronic view information panel of that chamber.

90 Figure 7.8: Panel to display information about the front end electronics for endcap partitions 7.3 Parallel Panel Navigation The main panel as long as the secondary panel have their own navigation tool. This means that one can navigate in the levels of the hierarchy in the main panel, leaving the secondary panel in its initial level. Or on the other hand navigate in all levels of FSM panels while leaving the main panel in one FSM level. Or even navigate in both panels. A good example that shows this functionality and this utility is through the next panel. Lets say that on some time in the control room it is LV - on only the sector 2 of the barrel side A. The shifter finds out that the chamber BMS2A02 is in NOT READY state although the LV is On. Furthermore it is very important to always keep an eye of what is going on in that sector. The solution of understanding the problem will come from the information panel. The shifter can navigate to the secondary panel of the partition that can be used as a debugging tool. There on the table, the shifter understands that the problem comes from the CSM card of

91 this chamber as its state is BAD. The important thing in this procedure is that the shifter found the root of the problem, but on the same time the information of the whole sector was in his eye. The debugging came from a parallel road the information panel. Figure 7.9: The use of the main and information panel in parallel. The main panel is on the sector level while the information panel is on the partition level. 7.4 Chamber in state NOT READY The camber inside ELTX project can have only three states, READY, NOT READY, UNKNOWN. The READY state is the state that all front end electronics work fine and the chamber is READY for data taking as far as electronics concerned. This state maybe also characterized as the boring state from those who seek always fructuous slings. Or the never-exactly-real state, from the suspicious perfectionists. But anyway, this is the wanted state from DCS side that indicates (if all the

92 mechanism is working right) this specific part of the detector works fine. On the other hand, the state UNKNOWN may occurs. This state usually comes when the manager for the copying script is down. This script is responsible of the update of the electronics data in the ELTX project so in case it is not running the data displayed do not represent the current status of the detector and thus the state turns to UNKNOWN. Literally, the state of the chamber is UNKNOWN that time. Moreover, this state may occurs in the case that the alarm handling is not set correctly on the chamber. All the FSM is seating on the alarm handling of the values and not in the values themselves (this is done for computer performance issues). There is not any other predefined way to reach this state neither ever happened in the (small) history of the project. In the end, the most important state for debugging of the detector is the state of NOT READY. This state can be derived from several different occasions numbered below. 1. The first simple case a state can be NOT READY is when the LV is Off. In this case the front end electronics are not supplied and not return any information. 2. In case the LV is On, the state can be NOT READY in the case that Node State is bad. The Node State is the first flag that in case it is raised (bad condition of the canbus the chamber belongs to) the state turns to NOT READY. 3. A second flag to be checked is the CSM state flag.in case this flag is raised (bad condition of the CSM card of the chamber) the state turns to NOT READY. 4. A third flag to be checked is the CSM 2.5V reference value flag.in case this flag is raised (another bad condition of the CSM card of the chamber) the state turns to NOT READY. From the above explanation, one can see that all the abnormal conditions, propagate a NOT READY state to the chamber. Then a question may appear, how the information of the severity of these cases is passed. The answer is very simple, this information is passed via status. Raised flags propagate an ERROR status while outrange values propagate WARNING status.

93 Figure 7.10: In case the state of the chamber is NOT READY, there is not mean to display the information to panels. This way confusion of shifters is avoided.