LEADE Post Mortem Markus Zerlauth 9

LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 LHC Post Mortem Data Transfer from client systems Markus Zerlauth, Nikolai Trofimov AB-CO 1

Outline èThe LHC Post Mortem System – Main requirements and purpose LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 – Infrastructure – Client systems during HWC èClient API and data formats èConclusions 2

The LHC Post mortem System - Requirements Main Requirements for LHC (beam) Post Mortem: – Data repository for transient data recordings from equipment systems (LHC Logging for slow acquisition rates) LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 – needs to reveal cause of emergency beam abort / possible equipment damage to improve operational procedures and protection systems • Initiating event • Event sequence leading to dump/incident – Validate correct funtioning of protection systems (redundancy within system, etc. . ) – Automated analysis modules in view of systems, complexity and data volume 3

LHC Machine Interlocks LHC LHC Devices Safe Beam Parameter Distribution LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 Safe LHC Parameter Movable Detectors Beam Loss Experimental Monitors Magnets BCM Software Sequencer Operator LHC Interlocks Buttons Experiments CCC Safe Beam Flag Collimator Positions Transverse Feedback Beam Aperture Kickers Environmental parameters Collimation System Beam Dumping System Beam Interlock System Powering Interlocks sc magnets Powering Interlocks nc magnets Magnet Current Monitor RF System Power Converters MPS Power AUG UPS Cryo (several Converters OK 1000) ~800 Special BLMs Injection Interlock Beam loss Beam Access Vacuum Screens / monitors Lifetime System Mirrors BLM FBCM BTV Timing System (Post Mortem Trigger) Monitors aperture in arcs limits (several (some 100) 1000) Doors EIS Vacuum valves Access Safety Blocks RF Stoppers 4

PM infrastructure – Preparing for the LHC ( beam) n FE servers … LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 BE server q Redundant and scalable services in CCR and TCR q Redundancy for client connections q Multiple FE servers for primary data storage, BE servers with large disks for complete data image n FE servers … BE server 5

LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 PM infrastructure - details … • n front end servers for primary data collection (main and spare server for each client) • Backend server(s) for complete data image, event building (and data conversion) 6

Current clients of PM system LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 è Post Mortem system already in use during ongoing HWC – LHC Power Converters – Quench protection system è First beam client tests ongoing – BI (BLM, BPM, BCTs, …) – FMCM – Collimators, RADMON? è Two main possibilities for sending data – FESA (mainly used by VME based systems) – C++ client API (used by Power PCs / gateways) è Recommended data format. pmd è Two possible trigger mechanisms for sending of PM data used by equipment systems – Self triggering of device (e. g. internal fault of power converter) – External trigger (PM event being sent via GMT – HX. PM 1 -CT, HX. PM 2 -CT) 7

PM client API LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 è Client system is preparing data file and calls the client API, which will take care of the data transfer to the PM system 8

LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 . pmd data format è Data file contains some header information (system, class, source, timestamp) and actual pm. data – Timestamp = time of self-triggered PM acquisition or global PM event from the LHC timing system (important for correlation with beam event!) 9

PM Data structure - Example è. pmd data can contain many different data objects LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 – – – – Parameters Signals Descriptions Units Enum Labels Bit. Labels 2 dim Arrays, . . . 10

Advantages of using. pmd format è Existing data converter to SDDS è Existing Data viewers LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 è No conversion/interpretation file necessary 11

Conclusions è Standardised means of data transfer to PM system via client API è Some uncertainties for experiements to be looked at in detail (platform diversity > , RDA, TN and CMW dependencies) è Details on client lib and examples for. pmd data format LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 – General: http: //wwwpsco. cern. ch/private/mw/RDA/pm/html/ – PMData formats: http: //wwwpsco. cern. ch. /private/mw/RDA/pm/tmp/html/ è In case of further questions don‘t hesitate to contact us (Nikolai Trofimov, Markus Zerlauth) Thanks a lot for your attention - Questions? 12

LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 13

Data flow and analysis Global PM Analysis: Global Event sequence, summaries, advised actions, event DB, … Global event sequence Machine Prot OK Advised Actions … LEADE – Post Mortem, Markus Zerlauth, , 9 th June 2008 Individual System Analysis/Checks: Validation of machine protection features, pre-analysis of PM buffers into result files, flagging of interesting systems/data reduction, database catalogue BLM, BPM > threshold IPOC-BIS Event Sequence Circuit events I/XPOC Data completeness and consistency check at system and global level (minimum data, configurable) Upon beam dump / self triggering, systems start pushing data to PM system, Logging, Alarms, etc… BLM BPM … FGC QPS PIC/WIC FMCM BIS XPOC … 14