USING THE LHC CONTROL SYSTEM 2016 RETROSPECTIVE ANDSHORT TERM PLANS

Switzerland

The paper will discuss the LHC control systemperformance during 2016 operation. It aims to answer thefollowing questions: In retrospect, which controlsfacilities, if any, were missing and what could beimproved? How did we perform on follow-up of requestsfrom Evian 2015? Human errors committed whileinteracting with the control system are discussed andsuggestions made for possible mitigation measures.Looking forward to EYETS (the extended year endtechnical stop), the planned control system changes andtheir impact will be presented.

- -

An OP perspective on LHC controls was presented atEvian 2015 [1]. This paper established a list of the topfive priorities of software improvements. These prioritieswere later re-evaluated in follow-up discussions [2].

- -Improved filling diagnostics.Improve integration of QPS, PIC, EquipState.Improve automation of sequencer and scripting.Know the state (of the machine) at a given time.Improve window management on consoles.

USING THE LHC CONTROL SYSTEM 2016 RETROSPECTIVE ANDSHORT TERM PLANS

Switzerland

The paper will discuss the LHC control systemperformance during 2016 operation. It aims to answer thefollowing questions: In retrospect, which controlsfacilities, if any, were missing and what could beimproved? How did we perform on follow-up of requestsfrom Evian 2015? Human errors committed whileinteracting with the control system are discussed andsuggestions made for possible mitigation measures.Looking forward to EYETS (the extended year endtechnical stop), the planned control system changes andtheir impact will be presented.

- -

An OP perspective on LHC controls was presented atEvian 2015 [1]. This paper established a list of the topfive priorities of software improvements. These prioritieswere later re-evaluated in follow-up discussions [2].

- -Improved filling diagnostics.Improve integration of QPS, PIC, EquipState.Improve automation of sequencer and scripting.Know the state (of the machine) at a given time.Improve window management on consoles.

USING THE LHC CONTROL SYSTEM — 2016 RETROSPECTIVE ANDSHORT TERM PLANS

G. Crockford, CERN, Geneva, Switzerland

AbstractThe paper will discuss the LHC control system

performance during 2016 operation. It aims to answer thefollowing questions: In retrospect, which controlsfacilities, if any, were missing and What could beimproved? How did we perform on follow-up of requestsfrom Evian 2015? Human errors committed whileinteracting with the control system are discussed andsuggestions made for possible mitigation measures.Looking forward to EYETS (the extended year endtechnical stop), the planned control system changes andtheir impact will be presented.

INTRODUCTIONThe LHC Control System was very stable in 2016.

During five full years of operation with beam, the LHCsuite of applications, fixed displays and feedbacks haveevolved and matured to a high level of efficiency andreliability. All critical problems were cured in a veryreactive manner (e.g. Early in the year some problems ofslowness when re-generating setting for beam-processeswere temporarily mitigated by increasing the databasecache size). Nevertheless, some ideas and requests forimprovements remain which will be discussed in thefollowing sections.

PRIORITIES SET AT EVIAN 2015An OP perspective on LHC controls was presented at

Evian 2015 [1]. This paper established a list of the topfive priorities of software improvements. These prioritieswere later re-evaluated in follow-up discussions [2].

Topfive priorities

The following priorities were established followingdiscussions within BE-OP-LHC.

Improved filling diagnostics.Improve integration of QPS, PIC, EquipState.Improve automation of sequencer and scripting.Know the state (of the machine) at a given time.Improve window management on consoles.

SOFTWARE DEVELOPMENTS 2016This is a non-exhaustive overview of some key new

software developments used for the first time during the2016 Run.

Improvedfilling diagnosticsAt the top of the list, following a discussion of applicationsoftware priorities, was a need for improved fillingdiagnostics. Much time was lost in previous yearsdiagnosing injection problems between the SP8 and LHC.To improve this situation an application was developedwith a generic architecture in mind. The analysisframework can be reused in other applications. A betaversion of this application was available for tests towardsthe end of the 2016 physics Run.

InputA i 4 .

Input 8

Ana|y5Is output

\jv lnputC '

Figure 1: Analysis framework

Figure 2: Injection diagnostic GUI

Luminosity Scan Client and ServerThis application (and its underlying server) is areplacement for the previous luminosity scan application.A central server provides a reservation system for theinteraction points, thus removing the possibility ofconflicting trims. Introduced at the beginning of the 2016Run and heavily used throughout the year, this applicationimproved efficiency for routine optimisation of collisionsand emittance scans (1P5), as well as facilities forautomated Van Der Meer scans.

3

Figure 3: Luminosity Scan Client

Power Converter Interlock GUIThis application maintains a survey of power convertercurrents in tolerance at a given time in a beam process. Itis linked to the Software Interlock System. The mostrecent improvement on this system provides an interlockon Quadrupole currents, to ensure that the phase advancebetween the beam dump kicker and tertiary collimators atthe experiments is respected. The GUI display alsoprovides a means to monitor the time remaining in atransitory beam process, such as the ramp or squeeze.

Figure 4: Power converter interlock GUI

To improve the robustness of this facility, there remains arequirement for an improved state machine to be able tofollow the state of the machine at a given time (ratherthan relying upon time elapsed following the broadcast ofa timing event, as is currently the case).

Chromaticity and Tune EstimateMeasurements and corrections of Tune and Chromaticityare frequently performed in routine LHC beam operation.A new application was introduced in 2015, and furtherdeveloped in 2016, to make carrying out these routinemeasurements and trims more fast and convenient.

Figure 5: Tune and Chromaticity estimate

Sequencer Multi-TaskingThe Sequencer was very heavily used in 2016 and provedto be robust and reliable. For stability and to focus onother priorities it was agreed to freeze furtherdevelopments on the Sequencer in 2016. The currentversion of the sequencer provides the possibility tomanually pull out sequences for parallel execution. Thisrequires some inside knowledge as to what tasks can beexecuted in parallel, and may vary depending on theworking practices of individuals. A systematic timesaving could be achieved if the parallel execution ofsequences could be automated. However due care shouldbe taken to ensure that the operator remains fully aware ofthe sequences being executed. Figure 6 shows theexample of the sequence to prepare the ramp. The task toremove injection protection collimators takes a fewminutes and can be executed in parallel.

Figure 6: Sequencer, Prepare Ramp

Window Management on ConsolesTo improve configuration and management of the uppertier of fixed display screens in the LHC island of theCCC, start-up scripts were implemented to define theapplication displays and their window positioning, to beexecuted upon re-start or reboot.

Figure 3: Luminosity Scan Client

Power Converter Interlock GUIThis application maintains a survey of power convertercurrents in tolerance at a given time in a beam process. Itis linked to the Software Interlock System. The mostrecent improvement on this system provides an interlockon Quadrupole currents, to ensure that the phase advancebetween the beam dump kicker and tertiary collimators atthe experiments is respected. The GUI display alsoprovides a means to monitor the time remaining in atransitory beam process, such as the ramp or squeeze.

Figure 4: Power converter interlock GUI

To improve the robustness of this facility, there remains arequirement for an improved state machine to be able tofollow the state of the machine at a given time (ratherthan relying upon time elapsed following the broadcast ofa timing event, as is currently the case).

Chromaticity and Tune EstimateMeasurements and corrections of Tune and Chromaticityare frequently performed in routine LHC beam operation.A new application was introduced in 2015, and furtherdeveloped in 2016, to make carrying out these routinemeasurements and trims more fast and convenient.

Figure 5: Tune and Chromaticity estimate

Sequencer Multi-TaskingThe Sequencer was very heavily used in 2016 and provedto be robust and reliable. For stability and to focus onother priorities it was agreed to freeze furtherdevelopments on the Sequencer in 2016. The currentversion of the sequencer provides the possibility tomanually pull out sequences for parallel execution. Thisrequires some inside knowledge as to what tasks can beexecuted in parallel, and may vary depending on theworking practices of individuals. A systematic timesaving could be achieved if the parallel execution ofsequences could be automated. However due care shouldbe taken to ensure that the operator remains fully aware ofthe sequences being executed. Figure 6 shows theexample of the sequence to prepare the ramp. The task toremove injection protection collimators takes a fewminutes and can be executed in parallel.

Figure 6: Sequencer, Prepare Ramp

Window Management on ConsolesTo improve configuration and management of the uppertier of fixed display screens in the LHC island of theCCC, start-up scripts were implemented to define theapplication displays and their window positioning, to beexecuted upon re-start or reboot.

flu

Figure 3: Luminosity Scan Client

Power Converter Interlock GUIThis application maintains a survey of power convertercurrents in tolerance at a given time in a beam process. Itis linked to the Software Interlock System. The mostrecent improvement on this system provides an interlockon Quadrupole currents, to ensure that the phase advancebetween the beam dump kicker and tertiary collimators atthe experiments is respected. The GUI display alsoprovides a means to monitor the time remaining in atransitory beam process, such as the ramp or squeeze.

Pow (5' mm may.“ w”an. a 12

a W. momma...“ HQ

Figure 4: Power converter interlock GUI

To improve the robustness of this facility, there remains arequirement for an improved state machine to be able tofollow the state of the machine at a given time (ratherthan relying upon time elapsed following the broadcast ofa timing event, as is currently the case).

Chromaticity and Tune EstimateMeasurements and corrections of Tune and Chromaticityare frequently performed in routine LHC beam operation.A new application was introduced in 2015, and furtherdeveloped in 2016, to make carrying out these routinemeasurements and trims more fast and convenient.

:aaa "' :35“:was ‘aaamas. »- “ '56; I -

1353 H ' i656 “ ‘55":

Figure 5: Tune and Chromaticity estimate

Sequencer Multi-TaskingThe Sequencer was very heavily used in 2016 and provedto be robust and reliable. For stability and to focus onother priorities it was agreed to freeze furtherdevelopments on the Sequencer in 2016. The currentversion of the sequencer provides the possibility tomanually pull out sequences for parallel execution. Thisrequires some inside knowledge as to what tasks can beexecuted in parallel, and may vary depending on theworking practices of individuals. A systematic timesaving could be achieved if the parallel execution ofsequences could be automated. However due care shouldbe taken to ensure that the operator remains fully aware ofthe sequences being executed. Figure 6 shows theexample of the sequence to prepare the ramp. The task toremove injection protection collimators takes a fewminutes and can be executed in parallel.

”\q vo-wunox ranlw| rum: m mtumn n a 9mmmu um

Figure 6: Sequencer, Prepare Ramp

Window Management on ConsolesTo improve configuration and management of the uppertier of fixed display screens in the LHC island of theCCC, start-up scripts were implemented to define theapplication displays and their window positioning, to beexecuted upon re-start or reboot.

4

HUMAN ERROR AND CONTROLS

Different studies focus on the interplay of humans withcomplex systems and the resulting system failure modes[3]. The general conclusion is that human variability is aforce that can be relied upon, and therefore should beharnessed. This is particularly true in a control roomenvironment involving shift work, 24 hours a day, as wellas an often busy working environment with manyincoming phone calls and visitors to the control room.Therefore when an instance of human error occurs, ratherthan blame the individual, it should be seen as anopportunity to analyse why the control system defencesdid not catch the error. An analysis was made of instancesof human error in LHC operations in 2016. Machineprotection defences against these incidents proved to bevery robust, and in all instances errors were caught withclean protection dumps of the beam. However downtimeincurred due to human error could be improved.

in 2016, distributed over different operational phases, asillustrated in Fig .A protection dump at injection may have a small impacton downtime. However, the further along the operationalphases in preparing beams for physics, the greater theimpact.

Figure : Distribution of Operational Mistakes

Human Error ExamplesThe following is a non-exhaustive list of instances ofhuman error, showing the most common mistakes.

Errors while overriding the Safe Beam Flag(SBF) with Setup beam. Unintentionally forcingSBF to false. Errors with masks and hiddeninterlocks. Intensity over allowed threshold withrespect to energy.Incorrect sequence execution. For example,switching on the ALICE Dipole instead of theSolenoid.Errors in MD setup and recovery from MD. E.g.loading coarse collimator settings withoutBETS-TCDQ mask set.Preparing a Hypercycle change with circulatingbeam, resulting in changes to Safe BeamParameters.

Human Error and EquipStateA frequently occurring task in LHC beam operations in2016 was the recovery from power converter faults. Thisprocess requires an interplay between three separateapplications. Equip State, the QPS Circuit Synoptic andthe PIC controller (see list of prioities from Evian 2015[1]) During this process of re-arming and resetting, thereis, amongst others, a non-negligible risk of switching offthe power converters in a complete sector by mistake, asEquipState has no requirement to confirm global executecommands. In such cases the impact on downtime can beone extra precycle taking 40 minutes.

Human Error DefencesWhile human error can never be completely eradicated,attempts can be made to catch commonly occurring errorsbefore they provoke a protection beam dump or haveother impact on machine downtime. Mitigation measureswere already added to the Sequencer and SoftwareInterlock System in reaction to some operationalmistakes. The following are some more suggestions basedon the errors experienced in 2016.

Confirmation of critical or global executecommands. Popup confirmation should be usedwhere (and only where) there is a risk of errors.Improved checks from state machine orsequencer when Safe Beam Flag is overriddenshould be implemented.Working in pairs as a team can often helpprevent mistakes and is highly recommended.This is especially important outside normalworking hours, during the night or during specialmodes of operation which break from the normalroutine.

PLANS FOR EYETSPlans for the Extended Year End Technical Stop are

outlined as follows [4].Controls maintenance from 5th to 13th January.CO services will not be available during thisperiod.Development on core controls services to befrozen by 8th March 2017.All application software will have to be ported tothe CBNG build tool. Training is required forapplication software developers and will begiven in due time.

Figure : EYETS Controls Schedule

HUMAN ERROR AND CONTROLS

Different studies focus on the interplay of humans withcomplex systems and the resulting system failure modes[3]. The general conclusion is that human variability is aforce that can be relied upon, and therefore should beharnessed. This is particularly true in a control roomenvironment involving shift work, 24 hours a day, as wellas an often busy working environment with manyincoming phone calls and visitors to the control room.Therefore when an instance of human error occurs, ratherthan blame the individual, it should be seen as anopportunity to analyse why the control system defencesdid not catch the error. An analysis was made of instancesof human error in LHC operations in 2016. Machineprotection defences against these incidents proved to bevery robust, and in all instances errors were caught withclean protection dumps of the beam. However downtimeincurred due to human error could be improved.

in 2016, distributed over different operational phases, asillustrated in Fig .A protection dump at injection may have a small impacton downtime. However, the further along the operationalphases in preparing beams for physics, the greater theimpact.

Figure : Distribution of Operational Mistakes

Human Error ExamplesThe following is a non-exhaustive list of instances ofhuman error, showing the most common mistakes.

Errors while overriding the Safe Beam Flag(SBF) with Setup beam. Unintentionally forcingSBF to false. Errors with masks and hiddeninterlocks. Intensity over allowed threshold withrespect to energy.Incorrect sequence execution. For example,switching on the ALICE Dipole instead of theSolenoid.Errors in MD setup and recovery from MD. E.g.loading coarse collimator settings withoutBETS-TCDQ mask set.Preparing a Hypercycle change with circulatingbeam, resulting in changes to Safe BeamParameters.

Human Error and EquipStateA frequently occurring task in LHC beam operations in2016 was the recovery from power converter faults. Thisprocess requires an interplay between three separateapplications. Equip State, the QPS Circuit Synoptic andthe PIC controller (see list of prioities from Evian 2015[1]) During this process of re-arming and resetting, thereis, amongst others, a non-negligible risk of switching offthe power converters in a complete sector by mistake, asEquipState has no requirement to confirm global executecommands. In such cases the impact on downtime can beone extra precycle taking 40 minutes.

Human Error DefencesWhile human error can never be completely eradicated,attempts can be made to catch commonly occurring errorsbefore they provoke a protection beam dump or haveother impact on machine downtime. Mitigation measureswere already added to the Sequencer and SoftwareInterlock System in reaction to some operationalmistakes. The following are some more suggestions basedon the errors experienced in 2016.

Confirmation of critical or global executecommands. Popup confirmation should be usedwhere (and only where) there is a risk of errors.Improved checks from state machine orsequencer when Safe Beam Flag is overriddenshould be implemented.Working in pairs as a team can often helpprevent mistakes and is highly recommended.This is especially important outside normalworking hours, during the night or during specialmodes of operation which break from the normalroutine.

PLANS FOR EYETSPlans for the Extended Year End Technical Stop are

outlined as follows [4].Controls maintenance from 5th to 13th January.CO services will not be available during thisperiod.Development on core controls services to befrozen by 8th March 2017.All application software will have to be ported tothe CBNG build tool. Training is required forapplication software developers and will begiven in due time.

Figure : EYETS Controls Schedule

HUMAN ERROR AND CONTROLS

Different studies focus on the interplay of humans withcomplex systems and the resulting system failure modes[3]. The general conclusion is that human variability is aforce that can be relied upon, and therefore should beharnessed. This is particularly true in a control roomenvironment involving shift work, 24 hours a day, as wellas an often busy working environment with manyincoming phone calls and visitors to the control room.Therefore when an instance of human error occurs, ratherthan blame the individual, it should be seen as anopportunity to analyse why the control system defencesdid not catch the error. An analysis was made of instancesof human error in LHC operations in 2016. Machineprotection defences against these incidents proved to bevery robust, and in all instances errors were caught withclean protection dumps of the beam. However downtimeincurred due to human error could be improved.

There were 52 events classified as “operational mistake”in 2016, distributed over different operational phases, asillustrated in Fig. 7.A protection dump at injection may have a small impacton downtime. However, the further along the operationalphases in preparing beams for physics, the greater theimpact.

Squeeze

Figure 7: Distribution of Operational Mistakes

Human Error ExamplesThe following is a non—exhaustive list of instances ofhuman error, showing the most common mistakes.

0 Errors while overriding the Safe Beam Flag(SBF) with Setup beam. Unintentionally forcingSBF to false. Errors with masks and hiddeninterlocks. Intensity over allowed threshold withrespect to energyIncorrect sequence execution. For example,switching on the ALICE Dipole instead of theSolenoid.

- Errors in MD setup and recovery from MD. E.g.loading coarse collimator settings withoutBETS—TCDQ mask set.Preparing a Hypercycle change with circulatingbeam, resulting in changes to Safe BeamParameters.

CS!

Human Error and EquipStateA frequently occurring task in LHC beam operations in2016 was the recovery from power converter faults. Thisprocess requires an interplay between three separateapplications. Equip State, the QPS Circuit Synoptic andthe PIC controller (see list of prioities from Evian 2015[1]) During this process of re-arming and resetting, thereis, amongst others, a non-negligible risk of switching offthe power converters in a complete sector by mistake, asEquipState has no requirement to confirm global executecommands. In such cases the impact on downtime can beone extra precycle taking 40 minutes.

Human Error DefencesWhile human error can never be completely eradicated,attempts can be made to catch commonly occurring errorsbefore they provoke a protection beam dump or haveother impact on machine downtime. Mitigation measureswere already added to the Sequencer and SoftwareInterlock System in reaction to some operationalmistakes. The following are some more suggestions basedon the errors experienced in 2016.

Confirmation of critical or global executecommands. Popup confirmation should be usedwhere (and only where) there is a risk of errors.Improved checks from state machine orsequencer when Safe Beam Flag is overriddenshould be implemented.Working in pairs as a team can often helpprevent mistakes and is highly recommended.This is especially important outside normalworking hours, during the night or during specialmodes of operation which break from the normalroutine.

PLANS FOR EYETSPlans for the Extended Year End Technical Stop are

outlined as follows [4].0 Controls maintenance from 9" to 13‘“ January.

CO services will not be available during thisperiod.Development on core controls services to befrozen by 8th March 2017.All application software will have to be ported tothe CBNG build tool. Training is required forapplication software developers and will begiven in due time.

Controls Operation requests during EYETS — 01 2017

. Martan Feb

WL 3 Upgrade:lrozen forlNJECTDRS

, .

Mm LHC,7. , isotahwa.; r m 41 SOURCEELENA

Figure 8: EYETS Controls Schedule

C“!

Work in the LSA TeamThe main work plans within the LSA team is as follows.

Introduction of Functions and Function Listtypes in FESA3, CMW and FGCs.Better setting archiving, to properly resolve theslowness issues experienced with settingregeneration. Maintain reasonable limits ondataset cache size.Consolidation of LSA Suite. With a view to theeradication of individual applications.

Work in the OP Software TeamThe main focus of the OP software team will be onfurther developments to the Luminosity Scan client andserver, with a view to eradicating the old LuminosityScan application (which was still required in 2016 forluminosity levelling in the separation plane). It will laterbe extended to include facilities for crossing-anglelevelling and Beta* levelling.

Figure : Luminosity Levelling (old application)

OP Software Teamwork ApproachDuring 2016 it was decided to try a teamwork approach tosoftware development within the LHC operations section.A group of five volunteers was formed. While being slowto get started using a new approach and workingtechniques, it was agreed that this approach will be ofbenefit in the long term. One significant issue faced bysoftware developers is the ever increasing burden tomaintain software following the author s departure fromCERN. A teamwork approach to developing newsoftware will alleviate this problem in the long term.

Figure : Teamwork

When developing new software, care is taken to maintaina layered control system, where the application clientlayer can remain thin and light, and tools from theunderlying business layer can be easily reused bydifferent applications.

Figure 1 : Layered Control System

CONCLUSIONThe LHC Control System has reached an excellent level

of stability and efficiency in 2016. New tools arecontributing to fast and efficient operation. The humanfactor should be kept in mind, and attempts made toanalyse and catch errors before they have an impact ondowntime. A teamwork approach to software development projects is the way forwards. There is much work inprogress during EYETS 2017. Notably for CBNG buildtool, consolidation of LSA suite and further developmentsto the luminosity scan facility.

ACKNOWLEDGMENTSThe author would like to thank the following for

valuable discussions and contributions to this paper.K. Fuchsberger, L. Ponce, M. Solfaroli, D. Jacquet, G. H.Hemelsoet, M. Hostett er, G. Papotti, J. Wenninger, M.Albert, R. Gorbonosov, M. Gourber-Pace, G. Kruk.

REFERENCES

K.FProceedings of the 2015 Evian Workshop on LHCBeam Operation, ERN-ACC-2015-376.

S. Gangulyhttp://www.iracst.org/ijrmt/

pers/vol1no12011/3vol1no1.pdfM.Gourber-Pace, le 2016-https://wikis.cern.ch/display/SUWG/EYET 2016-2017

[1]

[ ][ ]

[ ]

Work in the LSA TeamThe main work plans within the LSA team is as follows.

Introduction of Functions and Function Listtypes in FESA3, CMW and FGCs.Better setting archiving, to properly resolve theslowness issues experienced with settingregeneration. Maintain reasonable limits ondataset cache size.Consolidation of LSA Suite. With a view to theeradication of individual applications.

Work in the OP Software TeamThe main focus of the OP software team will be onfurther developments to the Luminosity Scan client andserver, with a view to eradicating the old LuminosityScan application (which was still required in 2016 forluminosity levelling in the separation plane). It will laterbe extended to include facilities for crossing-anglelevelling and Beta* levelling.

Figure : Luminosity Levelling (old application)

OP Software Teamwork ApproachDuring 2016 it was decided to try a teamwork approach tosoftware development within the LHC operations section.A group of five volunteers was formed. While being slowto get started using a new approach and workingtechniques, it was agreed that this approach will be ofbenefit in the long term. One significant issue faced bysoftware developers is the ever increasing burden tomaintain software following the author s departure fromCERN. A teamwork approach to developing newsoftware will alleviate this problem in the long term.

Figure : Teamwork

When developing new software, care is taken to maintaina layered control system, where the application clientlayer can remain thin and light, and tools from theunderlying business layer can be easily reused bydifferent applications.

Figure 1 : Layered Control System

CONCLUSIONThe LHC Control System has reached an excellent level

of stability and efficiency in 2016. New tools arecontributing to fast and efficient operation. The humanfactor should be kept in mind, and attempts made toanalyse and catch errors before they have an impact ondowntime. A teamwork approach to software development projects is the way forwards. There is much work inprogress during EYETS 2017. Notably for CBNG buildtool, consolidation of LSA suite and further developmentsto the luminosity scan facility.

ACKNOWLEDGMENTSThe author would like to thank the following for

valuable discussions and contributions to this paper.K. Fuchsberger, L. Ponce, M. Solfaroli, D. Jacquet, G. H.Hemelsoet, M. Hostett er, G. Papotti, J. Wenninger, M.Albert, R. Gorbonosov, M. Gourber-Pace, G. Kruk.

REFERENCES

K.FProceedings of the 2015 Evian Workshop on LHCBeam Operation, ERN-ACC-2015-376.

S. Gangulyhttp://www.iracst.org/ijrmt/

pers/vol1no12011/3vol1no1.pdfM.Gourber-Pace, le 2016-https://wikis.cern.ch/display/SUWG/EYET 2016-2017

[1]

[ ][ ]

[ ]

Work in the LSA TeamThe main work plans within the LSA team is as follows.

0 Introduction of Functions and Function Listtypes in FESA3, CMW and FGCs.

0 Better setting archiving, to properly resolve theslowness issues experienced with settingregeneration. Maintain reasonable limits ondataset cache size.

0 Consolidation of LSA Suite. With a view to theeradication of individual applications.

Work in the OP Software TeamThe main focus of the OP software team will be onfurther developments to the Luminosity Scan client andserver, with a view to eradicating the old LuminosityScan application (which was still required in 2016 forluminosity levelling in the separation plane). It will laterbe extended to include facilities for crossing-anglelevelling and Beta* levelling.

Figure 9: Luminosity Levelling (old application)

0P Software Teamwork ApproachDuring 2016 it was decided to try a teamwork approach tosoftware development within the LHC operations section.A group of five volunteers was formed. While being slowto get started using a new approach and workingtechniques, it was agreed that this approach will be ofbenefit in the long term. One significant issue faced bysoftware developers is the ever increasing burden tomaintain software following the author’s departure fromCERN. A teamwork approach to developing newsoftware will alleviate this problem in the long term.

Figure 10: Teamwork/_\(\

fir: /— —LA A /, l f - \j

~“ ,3 \ -,\ / k»\ /.V/

When developing new software, care is taken to maintaina layered control system, where the application clientlayer can remain thin and light, and tools from theunderlying business layer can be easily reused bydifferent applications.

LSA(Settings management) CALS

LSA DB Equipment

Figure l l: Layered Control System

CONCLUSIONThe LHC Control System has reached an excellent level

of stability and efficiency in 2016. New tools arecontributing to fast and efficient operation. The humanfactor should be kept in mind, and attempts made toanalyse and catch errors before they have an impact ondowntime. A teamwork approach to software develop-ment projects is the way forwards. There is much work inprogress during EYETS 2017. Notably for CBNG buildtool, consolidation of LSA suite and further developmentsto the luminosity scan facility.

ACKNOWLEDGMENTSThe author would like to thank the following for

valuable discussions and contributions to this paper.K. Fuchsberger, L. Ponce, M. Solfaroli, D. Jacquet, G. H.Hemelsoet, M. Hostettler, G. Papotti, J. Wenninger, M.Albert, R. Gorbonosov, M. Gourber-Pace, G. Kruk.

REFERENCES

[1] K.Fuchsberger “LHC Controls, and OP Perspective”,Proceedings of the 2015 Evian Workshop on LHCBeam Operation, CERN-ACC-2015-376.

[2] K.Fuchsberger, “LHC OP Software Priorities 2016”[3] S. Ganguly “Human error vs. Work place Management

in modern Organizations”, http://www.iracst.0rg/ijrrnt/papers/volln012011/3vollnol.pdf

[4] M.Gourber-Pace, “EYETS Schedule 2016-2017”,https://wikis.cern.ch/display/SUWG/EYETSZO16-2017

6