A. NORDT2012-11-06, AD Seminarino

What is a POST MORTEM SYSTEM ?

Tuesday, November 6, 2012

C O N T E N T

• General Introduction to PMA in Accelerators

• Example: BLMs and UFOs in the LHC

• How to support Operations

• Summary

Tuesday, November 6, 2012

Post Mortem Analysis for Accelerators?

Similar...but not quite the same

In accelerators we talk about ”Killing” the beam

Or: the beam was lost...there was a beam trip.... In all cases: We must understand in detail why the beam is gone

mainly in order to know whether we can proceed operating the machine

SKIP THIS!

A. Nordt, ESS AD Seminarino, 2012-11-06 1/13 Tuesday, November 6, 2012

There are 3 standalone systems which can kill the proton beam @ ESS

Small Reminder

A. Nordt, ESS AD Seminarino, 2012-11-06 2/13 Tuesday, November 6, 2012

How can we know what happened?MPS will consist of a

machine interlock system (MIS) which receives status signals (OK/NOK) from MIDs about the health of machine.

The MIS will trigger mitigation devices (MODs) upon detection of non-nominal conditions (NOK signal from MID).

If we synchronize all MPS devices with the timing system and timestamp all their data, then we know which device triggered first a mitigation request and also why. MID = MPS Input Device // MOD = MPS Output Device

A. Nordt, ESS AD Seminarino, 2012-11-06 3/13 Tuesday, November 6, 2012

Question...Data Logging vs PM

We are logging all the machine data and we can use these data and analyze the origin of an event leading to a beam stop. Why would we need a PM system?

But: Are we really logging all the data?

BLMs: every 2 microseconds 1 value and ~200 BLMs -> (100 million values/second)

We will not be able to store all the data but a filtered version of the original data-set (e.g. only max. value per second, log on change, etc..)

However: during a beam dump we must see clear again (ie BLM data with 2 microsecond resolution, etc.) and thus need post mortem high resolution data

A. Nordt, ESS AD Seminarino, 2012-11-06 4/13 Tuesday, November 6, 2012

LHC BLM PM Automated Analysis

PM analysis GUIinforms theoperators about the origin of beamdump event

@ 2010-07-07:1 BLM in the ringdetected criticallyhigh losses andrequested MPS todump the beam.

1 green bar = signal from 1 BLM

Red dots: BLM thresholds

Zoom into losses of 1 BLM which went above threshold

At this point in time operators had never seen a loss pattern like this

Logging Data (low resolution: 1/s)

Post Mortem Data (high resolution: 1/40e-6s)

A. Nordt, ESS AD Seminarino, 2012-11-06 5/13

0.08 s before dump

Tuesday, November 6, 2012

LHC BLM PM Manual Analysis

Use longPM buffer,zoom intobumpsand checkother BLM signals

A. Nordt, ESS AD Seminarino, 2012-11-06 6/13

1.72 s before dump

1st bump

2nd bump 3rd bump

Tuesday, November 6, 2012

Discovery of the UFO @ LHC

Correlation of event from 2012-07-07 with losses due to wire-scanner

OK..Something falls through the beam... but what???

UFO = Unidentified Falling Object

UFO? But which?

A. Nordt, ESS AD Seminarino, 2012-11-06 7/13 Tuesday, November 6, 2012

PM Support for Operations

Fraction of false beam dump triggers from MPS

Causes of beam dumps @ LHC for 2010, 2011

Courtesy of M. Zerlauth CERNA. Nordt, ESS AD Seminarino, 2012-11-06 8/13 Tuesday, November 6, 2012

PM Support for Operations

Fraction of beam dump triggers from BLMs

Beam dumps during different beam modes

Courtesy of M. Zerlauth CERNA. Nordt, ESS AD Seminarino, 2012-11-06 9/13 Tuesday, November 6, 2012

PM Support for Operations

Causes of beam dumps @ LHC for 2011

A. Nordt, ESS AD Seminarino, 2012-11-06 10/13 Courtesy of A. McPherson CERN

Tuesday, November 6, 2012

PM Support for Operations

Causes of beam dumps: keep track!

A. Nordt, ESS AD Seminarino, 2012-11-06 11/13

Example from LHC

Tuesday, November 6, 2012

Post Mortem System Plans @ ESS

The PMS is part of MPS and aims to:

• Provide an automated post-operational analysis of high resolution data from the machine equipment systems

• Support machine protection, operations and system experts in understanding machine/system performance and beam trip events

• Must identify the system initiating the event first and preferably the reason for the failure (NOK signal propagation to MIS)

• Must validate that all protection systems performed as expected

• Must assist in longterm and trend analysis, completion of failure event catalogue and comparison with simulations, statistics, optimization of machine performance (early fault detection, implementation of mitigation)

A. Nordt, ESS AD Seminarino, 2012-11-06 12/13 Tuesday, November 6, 2012

Summary

The Post Mortem system is needed to support operations in understanding the origin of a beam trip and to decide whether it is safe to continue operations or not

Further operation might be blocked if the operator does not approve PMA result

In order to built an efficient system it is needed to define specification early in the design process (amount of data, frequency, correlations with other systems, definition of criticality of events/trips, etc..)

Help from all systems experts is needed to define requirements asap and assure a common data acquisition which allows for proper data merging across different systems

A. Nordt, ESS AD Seminarino, 2012-11-06 13/13 Tuesday, November 6, 2012

Outlook

From an UFO towards... ...the Hyllie Water Tower?

tbc...

Tuesday, November 6, 2012