ICALEPCS2011 - List of Authors (Baggiolini, V.)

Paper

Title

Page

The LHC Sequencer

300

R. Alemany-Fernandez, V. Baggiolini, R. Gorbonosov, D. Khasbulatov, M. Lamont, P. Le Roux, C. Roderick
CERN, Geneva, Switzerland

The Large Hadron Collider (LHC) at CERN is a highly complex system made of many different sub-systems whose operation implies the execution of many tasks with stringent constraints on the order and duration of the execution. To be able to operate such a system in the most efficient and reliable way the operators in the CERN control room use a high level control system: the LHC Sequencer. The LHC Sequencer system is composed of several components, including an Oracle database where operational sequences are configured, a core server that orchestrates the execution of the sequences, and two graphical user interfaces: one for sequence edition, and another for sequence execution. This paper describes the architecture of the LHC Sequencer system, and how the sequences are prepared and used for LHC operation.

Poster MOPMN027 [2.163 MB]

WEPKS005

State Machine Framework and its Use for Driving LHC Operational States*

782

M. Misiowiec, V. Baggiolini, M. Solfaroli Camillocci
CERN, Geneva, Switzerland

The LHC follows a complex operational cycle with 12 major phases that include equipment tests, preparation, beam injection, ramping and squeezing, finally followed by the physics phase. This cycle is modeled and enforced with a state machine, whereby each operational phase is represented by a state. On each transition, before entering the next state, a series of conditions is verified to make sure the LHC is ready to move on. The State Machine framework was developed to cater for building independent or embedded state machines. They safely drive between the states executing tasks bound to transitions and broadcast related information to interested parties. The framework encourages users to program their own actions. Simple configuration management allows the operators to define and maintain complex models themselves. An emphasis was also put on easy interaction with the remote state machine instances through standard communication protocols. On top of its core functionality, the framework offers a transparent integration with other crucial tools used to operate LHC, such as the LHC Sequencer. LHC Operational States has been in production for half a year and was seamlessly adopted by the operators. Further extensions to the framework and its application in operations are under way.
* http://cern.ch/marekm/icalepcs.html

Poster WEPKS005 [0.717 MB]

WEPMS003

A Testbed for Validating the LHC Controls System Core Before Deployment

977

J. Nguyen Xuan, V. Baggiolini
CERN, Geneva, Switzerland

Since the start-up of the LHC, it is crucial to carefully test core controls components before deploying them operationally. The Testbed of the CERN accelerator controls group was developed for this purpose. It contains different hardware (PPC, i386) running different operating systems (Linux and LynxOS) and core software components running on front-ends, communication middleware and client libraries. The Testbed first executes integration tests to verify that the components delivered by individual teams interoperate, and then system tests, which verify high-level, end-user functionality. It also verifies that different versions of components are compatible, which is vital, because not all parts of the operational LHC control system can be upgraded simultaneously. In addition, the Testbed can be used for performance and stress tests. Internally, the Testbed is driven by Bamboo, a Continuous Integration server, which builds and deploys automatically new software versions into the Testbed environment and executes the tests continuously to prevent from software regression. Whenever a test fails, an e-mail is sent to the appropriate persons. The Testbed is part of the official controls development process wherein new releases of the controls system have to be validated before being deployed operationally. Integration and system tests are an important complement to the unit tests previously executed in the teams. The Testbed has already caught several bugs that were not discovered by the unit tests of the individual components.
* http://cern.ch/jnguyenx/ControlsTestBed.html

Poster WEPMS003 [0.111 MB]

WEPMS007

Backward Compatibility as a Key Measure for Smooth Upgrades to the LHC Control System

989

V. Baggiolini, M. Arruat, D. Csikos, R. Gorbonosov, P. Tarasenko, Z. Zaharieva
CERN, Geneva, Switzerland

Now that the LHC is operational, a big challenge is to upgrade the control system smoothly, with minimal downtime and interruptions. Backward compatibility (BC) is a key measure to achieve this: a subsystem with a stable API can be upgraded smoothly. As part of a broader Quality Assurance effort, the CERN Accelerator Controls group explored methods and tools supporting BC. We investigated two aspects in particular: (1) "Incoming dependencies", to know which part of an API is really used by clients and (2) BC validation, to check that a modification is really backward compatible. We used this approach for Java APIs and for FESA devices (which expose an API in the form of device/property sets). For Java APIs, we gather dependency information by regularly running byte-code analysis on all the 1000 Jar files that belong to the control system and find incoming dependencies (methods calls and inheritance). An Eclipse plug-in we developed shows these incoming dependencies to the developer. If an API method is used by many clients, it has to remain backward compatible. On the other hand, if a method is not used, it can be freely modified. To validate BC, we are exploring the official Eclipse tools (PDE-API tools), and others that check BC without need for invasive technology such as OSGi. For FESA devices, we instrumented key components of our controls system to know which devices and properties are in use. This information is collected in the Controls Database and is used (amongst others) by the FESA design tools in order to prevent the FESA class developer from breaking BC.

WEPMU023

External Post-Operational Checks for the LHC Beam Dumping System

1111

N. Magnin, V. Baggiolini, E. Carlier, B. Goddard, R. Gorbonosov, D. Khasbulatov, J.A. Uythoven, M. Zerlauth
CERN, Geneva, Switzerland

The LHC Beam Dumping System (LBDS) is a critical part of the LHC machine protection system. After every LHC beam dump action the various signals and transient data recordings of the beam dumping control systems and beam instrumentation measurements are automatically analysed by the eXternal Post-Operational Checks (XPOC) system to verify the correct execution of the dump action and the integrity of the related equipment. This software system complements the LHC machine protection hardware, and has to ascertain that the beam dumping system is ‘as good as new’ before the start of the next operational cycle. This is the only way by which the stringent reliability requirements can be met. The XPOC system has been developed within the framework of the LHC “Post-Mortem” system, allowing highly dependable data acquisition, data archiving, live analysis of acquired data and replay of previously recorded events. It is composed of various analysis modules, each one dedicated to the analysis of measurements coming from specific equipment. This paper describes the global architecture of the XPOC system and gives examples of the analyses performed by some of the most important analysis modules. It explains the integration of the XPOC into the LHC control infrastructure along with its integration into the decision chain to allow proceeding with beam operation. Finally, it discusses the operational experience with the XPOC system acquired during the first years of LHC operation, and illustrates examples of internal system faults or abnormal beam dump executions which it has detected.

Poster WEPMU023 [1.768 MB]

THBHMUST04

The Software Improvement Process – Tools and Rules to Encourage Quality

1212

K. Sigerud, V. Baggiolini
CERN, Geneva, Switzerland

The Applications section of the CERN accelerator controls group has decided to apply a systematic approach to quality assurance (QA), the "Software Improvement Process", SIP. This process focuses on three areas: the development process itself, suitable QA tools, and how to practically encourage developers to do QA. For each stage of the development process we have agreed on the recommended activities and deliverables, and identified tools to automate and support the task. For example we do more code reviews. As peer reviews are resource-intensive, we only do them for complex parts of a product. As a complement, we are using static code checking tools, like FindBugs and Checkstyle. We also encourage unit testing and have agreed on a minimum level of test coverage recommended for all products, measured using Clover. Each of these tools is well integrated with our IDE (Eclipse) and give instant feedback to the developer about the quality of their code. The major challenges of SIP have been to 1) agree on common standards and configurations, for example common code formatting and Javadoc documentation guidelines, and 2) how to encourage the developers to do QA. To address the second point, we have successfully implemented 'SIP days', i.e. one day dedicated to QA work to which the whole group of developers participates, and 'Top/Flop' lists, clearly indicating the best and worst products with regards to SIP guidelines and standards, for example test coverage. This paper presents the SIP initiative in more detail, summarizing our experience since two years and our future plans.

Slides THBHMUST04 [5.638 MB]

Paper	Title	Page
MOPMN027	The LHC Sequencer	300
	R. Alemany-Fernandez, V. Baggiolini, R. Gorbonosov, D. Khasbulatov, M. Lamont, P. Le Roux, C. Roderick CERN, Geneva, Switzerland
	The Large Hadron Collider (LHC) at CERN is a highly complex system made of many different sub-systems whose operation implies the execution of many tasks with stringent constraints on the order and duration of the execution. To be able to operate such a system in the most efficient and reliable way the operators in the CERN control room use a high level control system: the LHC Sequencer. The LHC Sequencer system is composed of several components, including an Oracle database where operational sequences are configured, a core server that orchestrates the execution of the sequences, and two graphical user interfaces: one for sequence edition, and another for sequence execution. This paper describes the architecture of the LHC Sequencer system, and how the sequences are prepared and used for LHC operation.
	Poster MOPMN027 [2.163 MB]

WEPKS005	State Machine Framework and its Use for Driving LHC Operational States*	782
	M. Misiowiec, V. Baggiolini, M. Solfaroli Camillocci CERN, Geneva, Switzerland
	The LHC follows a complex operational cycle with 12 major phases that include equipment tests, preparation, beam injection, ramping and squeezing, finally followed by the physics phase. This cycle is modeled and enforced with a state machine, whereby each operational phase is represented by a state. On each transition, before entering the next state, a series of conditions is verified to make sure the LHC is ready to move on. The State Machine framework was developed to cater for building independent or embedded state machines. They safely drive between the states executing tasks bound to transitions and broadcast related information to interested parties. The framework encourages users to program their own actions. Simple configuration management allows the operators to define and maintain complex models themselves. An emphasis was also put on easy interaction with the remote state machine instances through standard communication protocols. On top of its core functionality, the framework offers a transparent integration with other crucial tools used to operate LHC, such as the LHC Sequencer. LHC Operational States has been in production for half a year and was seamlessly adopted by the operators. Further extensions to the framework and its application in operations are under way. * http://cern.ch/marekm/icalepcs.html
	Poster WEPKS005 [0.717 MB]

WEPMS003	A Testbed for Validating the LHC Controls System Core Before Deployment	977
	J. Nguyen Xuan, V. Baggiolini CERN, Geneva, Switzerland
	Since the start-up of the LHC, it is crucial to carefully test core controls components before deploying them operationally. The Testbed of the CERN accelerator controls group was developed for this purpose. It contains different hardware (PPC, i386) running different operating systems (Linux and LynxOS) and core software components running on front-ends, communication middleware and client libraries. The Testbed first executes integration tests to verify that the components delivered by individual teams interoperate, and then system tests, which verify high-level, end-user functionality. It also verifies that different versions of components are compatible, which is vital, because not all parts of the operational LHC control system can be upgraded simultaneously. In addition, the Testbed can be used for performance and stress tests. Internally, the Testbed is driven by Bamboo, a Continuous Integration server, which builds and deploys automatically new software versions into the Testbed environment and executes the tests continuously to prevent from software regression. Whenever a test fails, an e-mail is sent to the appropriate persons. The Testbed is part of the official controls development process wherein new releases of the controls system have to be validated before being deployed operationally. Integration and system tests are an important complement to the unit tests previously executed in the teams. The Testbed has already caught several bugs that were not discovered by the unit tests of the individual components. * http://cern.ch/jnguyenx/ControlsTestBed.html
	Poster WEPMS003 [0.111 MB]

WEPMS007	Backward Compatibility as a Key Measure for Smooth Upgrades to the LHC Control System	989
	V. Baggiolini, M. Arruat, D. Csikos, R. Gorbonosov, P. Tarasenko, Z. Zaharieva CERN, Geneva, Switzerland
	Now that the LHC is operational, a big challenge is to upgrade the control system smoothly, with minimal downtime and interruptions. Backward compatibility (BC) is a key measure to achieve this: a subsystem with a stable API can be upgraded smoothly. As part of a broader Quality Assurance effort, the CERN Accelerator Controls group explored methods and tools supporting BC. We investigated two aspects in particular: (1) "Incoming dependencies", to know which part of an API is really used by clients and (2) BC validation, to check that a modification is really backward compatible. We used this approach for Java APIs and for FESA devices (which expose an API in the form of device/property sets). For Java APIs, we gather dependency information by regularly running byte-code analysis on all the 1000 Jar files that belong to the control system and find incoming dependencies (methods calls and inheritance). An Eclipse plug-in we developed shows these incoming dependencies to the developer. If an API method is used by many clients, it has to remain backward compatible. On the other hand, if a method is not used, it can be freely modified. To validate BC, we are exploring the official Eclipse tools (PDE-API tools), and others that check BC without need for invasive technology such as OSGi. For FESA devices, we instrumented key components of our controls system to know which devices and properties are in use. This information is collected in the Controls Database and is used (amongst others) by the FESA design tools in order to prevent the FESA class developer from breaking BC.

WEPMU023	External Post-Operational Checks for the LHC Beam Dumping System	1111
	N. Magnin, V. Baggiolini, E. Carlier, B. Goddard, R. Gorbonosov, D. Khasbulatov, J.A. Uythoven, M. Zerlauth CERN, Geneva, Switzerland
	The LHC Beam Dumping System (LBDS) is a critical part of the LHC machine protection system. After every LHC beam dump action the various signals and transient data recordings of the beam dumping control systems and beam instrumentation measurements are automatically analysed by the eXternal Post-Operational Checks (XPOC) system to verify the correct execution of the dump action and the integrity of the related equipment. This software system complements the LHC machine protection hardware, and has to ascertain that the beam dumping system is ‘as good as new’ before the start of the next operational cycle. This is the only way by which the stringent reliability requirements can be met. The XPOC system has been developed within the framework of the LHC “Post-Mortem” system, allowing highly dependable data acquisition, data archiving, live analysis of acquired data and replay of previously recorded events. It is composed of various analysis modules, each one dedicated to the analysis of measurements coming from specific equipment. This paper describes the global architecture of the XPOC system and gives examples of the analyses performed by some of the most important analysis modules. It explains the integration of the XPOC into the LHC control infrastructure along with its integration into the decision chain to allow proceeding with beam operation. Finally, it discusses the operational experience with the XPOC system acquired during the first years of LHC operation, and illustrates examples of internal system faults or abnormal beam dump executions which it has detected.
	Poster WEPMU023 [1.768 MB]

THBHMUST04	The Software Improvement Process – Tools and Rules to Encourage Quality	1212
	K. Sigerud, V. Baggiolini CERN, Geneva, Switzerland
	The Applications section of the CERN accelerator controls group has decided to apply a systematic approach to quality assurance (QA), the "Software Improvement Process", SIP. This process focuses on three areas: the development process itself, suitable QA tools, and how to practically encourage developers to do QA. For each stage of the development process we have agreed on the recommended activities and deliverables, and identified tools to automate and support the task. For example we do more code reviews. As peer reviews are resource-intensive, we only do them for complex parts of a product. As a complement, we are using static code checking tools, like FindBugs and Checkstyle. We also encourage unit testing and have agreed on a minimum level of test coverage recommended for all products, measured using Clover. Each of these tools is well integrated with our IDE (Eclipse) and give instant feedback to the developer about the quality of their code. The major challenges of SIP have been to 1) agree on common standards and configurations, for example common code formatting and Javadoc documentation guidelines, and 2) how to encourage the developers to do QA. To address the second point, we have successfully implemented 'SIP days', i.e. one day dedicated to QA work to which the whole group of developers participates, and 'Top/Flop' lists, clearly indicating the best and worst products with regards to SIP guidelines and standards, for example test coverage. This paper presents the SIP initiative in more detail, summarizing our experience since two years and our future plans.
	Slides THBHMUST04 [5.638 MB]