deletions | additions       diff --git a/layout.md b/layout.md  index c9187b5..6e617f5 100644  --- a/layout.md  +++ b/layout.md 
...
sectionCURRENT_STATU.tex  sectionTHE_TASK__We.tex  sectionFACILITY_OPER.tex  sectionOPERATION_EVE.tex  figures/beam-plot/beam-plot.png  sectionPROPOSED_PRIM.tex  sectionPROPOSED_SECO.tex  diff --git a/sectionOPERATION_EVE.tex b/sectionOPERATION_EVE.tex  deleted file mode 100644  index 77f1d40..0000000  --- a/sectionOPERATION_EVE.tex  +++ /dev/null 
...
\section{OPERATION EVENT LOGGING}   In order to apply an operation metric one needs data.   There are substantial differences how the different facilities determine abnormal operation events, and how these events are recorded.   We will explain the differences with some examples from our facilities.  \subsection{ALBA Event Logging}   There are two event logging system at ALBA in use.   One is automatic and is the so called PANIC application.~\cite{Rubio_2012}  PANIC will register any alarm that has been defined as such.   Examples are a faulty power supply but also an abnormal beam size.   These alarms are automatically generated and require an acknowledge by the operator to be reset.   PANIC is a TANGO~\cite{Goetz_2003} package which can be easily customised.   The second event logging system is the electronic logbook (elog) used to keep track of the operation.   The elog receives input data from the operators.   As an event logging system is not yet automatic, but there are a number of entries which are standardized and a template is available to the operators: shift start/end, injection, and beam incidence.   Beam delivery times are recorded from the time that the interlock signal that prevents the beamlines from opening their shutters is cleared.   The operator supplies the elog with information about every fault identified during the operation.   Once a beam incidence is registered in the elog the operators feed in information about the system, the equipment, how and when the incidence was solved and the group responsible of the sub-system causing the beam incidence receives automatically an e-mail.   In a beam incidence entry there is also a drop down menu from which to select the consequences that the incidence had on the beam.   \subsection{BESSY II Event Logging}  The comprehensive data store available for any analysis task is provided by the EPICS channel archiver.~\cite{Kasemir_2001}   In addition Alarms, device and human interactions are logged to other databases (CMlog, CAputlog).   Moreover any violation of the top-up conditions as well as any beam loss has to be documented by the operators (elog).  \subsection{Elettra Event Logging}  The TANGO archiving system~\cite{Goetz_2003} is used at Elettra.   Right now the up-time and statistics is automatically calculated based on the parameters saved in the HDB.   At the same time a post processing of the data is necessary in order to attribute the reason to each downtime.   \subsection{LNLS-UVX Event Logging}  The UVX logging system is implemented in ASP and uses the PARADOX database management system.  The system was originally part of the UVX high level control system and user interface developed in a Delphi/Windows platform.  The event logging system receives input data from the operators and directly from the high level control programs, which automatically record a few beam related events such as beam delivery, beam trip and injection time.   Since injection takes place at low energy the beamline shutters are closed during injection and a `no beam' fault starts only if injection takes longer than the scheduled period.   A beam delivery event is recorded when the interlock that prevents the beamlines from operating is cleared.   A beam trip event is recorded every time the current drops below the `no beam' threshold.   The operator supplies the database with information about every fault identified during the operation shifts.   Events leading to beam outage and those leading to delays in the beam delivery to users, events that have some impact on the machine and even  those that have no impact at all but are somehow connected to the operation routine are all recorded by the operators.   Once a fault is registered in the database the operators feed in information about the event and the technical groups are notified.   The amount of entries in the e-log is large and makes the analysis time consuming.   A web interface supplies several use and performance parameters of the machine.  Sirius is intended to have a more automated system so as to reduce the workload for data evaluation.   The control system will be based on EPICS/Linux~\cite{Dalesio_1994} platform.   The studies for Sirius data logging system are still in the preliminary stages.   \subsection{PETRA III Event Logging}  Currently at PETRA III no automated event logging system is used.   Every entry into the availability data base is done by the technical coordinator, based on archived beam parameters, an alarm archive and elog entries by the operators.  An automated event logging system is in use for PETRA's booster DESY II and is currently being tested for PETRA III.  \subsection{SLS Event Logging}  Failure data based on operator input is often not very precise: while a beam outage was always documented, the duration was not always correctly estimated.   Minor problems, like short outages of the injector were sometimes not documented at all.   The evaluation of the logbook entries for the yearly status report was time-consuming.   Therefore we desired a more automated approach: to create precise, reliable data and to minimise the workload for data evaluation.  A very simple programme records a handful of different event types into the oracle database.   Every event can later be assigned to a course, a system or group that is responsible for the occurrence of that event.~\cite{L_deke_2009}  Already in the first year this system saved more time for the evaluation of the yearly failures than it took to programme.   As a bonus, the automated statistical evaluation of the event data takes care that the data is precise and always evaluated in the same way.