Burn-In Software Development. Taras Fedorchuk, Taras Shevchenko National University of Kyiv 3rd September 2018

Transcription

1 Burn-In Software Development Taras Fedorchuk, Taras Shevchenko National University of Kyiv 3rd September 2018

2 LHC Schedule Higher integrated luminosity higher radiation dose = Radiation damage to the detector!! Detector needs to be upgraded!! Higher instantaneous luminosity = High pileup, high trigger rate Page 2

3 CMS Tracker Upgrade New silicon tracker with trigger capability Page 3

4 New Outer Tracker Module Concept On-board pt discrimination: Signals from two closely spaced sensors are correlated. Local rejection of low-pt tracks: so-called stubs formed and transmitted to the L1 trigger, when a high-pt event occurs. The strong magnetic field of CMS makes it possible to measure pt locally with reasonable effort. Page 4

5 Data Flow The stub data will be used to form Level-1 tracks Stubs will be sent at bunch crossing frequency (40 MHz) Data readout at ~750 khz Page 5

6 Phase 2 Outer Tracker Upgrade: 2S and PS Modules 2S ( Two-Strip ) Module PS ("Pixel-Strip") Module Page 6

7 Module Production Modules arrived from another university Several thousands of modules will be produced and assembled DESY takes part in production - end-cap is planned to be assembled here Production includes sequence of tests: Reception test Burn-in test Integration test Reception test Burn-in test Test for some time Modules will be tested in a weekly production at different temperatures Tested successfully Yes Mount on the end-cap Large scale of a fully assembled segment No Fix or throw away Integration test Page 7

8 Demo burn-in setup DAQ system Some features of the setup: Demo version for only one module Module is placed inside the insulated box and cooled using the liquid and Peltier element combination Raspberry Pi is used for the monitoring purposes Raspberry pi Power supply Cooling system Page 8

9 Software structure SystemController Class: main control class, which supervises al the other classes. All the procedures are defined here. Power Control Class: is responsible for the control of the power supplies EnvironmentControl Class: interfaces all environmental periphery, such as chiller, sensors, Peltier element. DatabaseInterface: gets module information from the database and publishes test results there(will be implemented later). DAQControl: interfaces the DAQ system. ConnectionInterface Class: gets information from Raspberry Pi sensors. Graphical User Inteface: independent from all other classes, forms a wrapper around the SystemController Class Page 9

10 GUI Sequence of added commands List of commands for the test (depends on devices) Checks connection to all devices listed in config file Reads a hardware configuration file to get information about devices Page 10

11 GUI Power control tab Changing of voltage/current settings present Possibility to manually aplly the voltages Monitoring of the applied voltages Page 11

12 GUI Widget for monitoring sensors status Chiller control widget: Monitoring of chiller`s features Setting work temperature Page 12

13 Summary Software has been developed in C++ using Qt and VISA libraries Software is able to interaface: Power supplies of different type new models can be easily added Colling devices currently only JulaboFP50 is implemented, the other can be easily added Monitoring devices socket connection to Raspberry Pi Things to do: Interface with DAQ software Interface to the module database(currently the database itself is in active development) Page 13