cern raul murillo garcia be-co ls1 review – te-epc feedback be-co ls1 review te-epc feedback raul...

CERN

Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback

BE-CO LS1 review

TE-EPC feedback

Raul Murillo Garcia on behalf of

TE-EPCDaniel Calcoen Stephen Page

1/12/2015

CERN

Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback 3

General comments

What worked well?• PowM1553: people's predisposition and collaboration.

• FGCD: collaboration model.

CERN


General comments

PowM1553: what did not work well?• FESA 3 was not mature. The validation was not complete.

Many issues appeared when deployed on the real machines. We became alpha testers.

• During the integration tests many changes were added at the same time (hardware, software, OS, drivers, configuration, etc.) making it difficult to diagnose problems.

• Coupling between the accelerator and the software tailoring (i. e. telegram interpretation and timing fields is accelerator dependent).

CERN


General comments

FGCD: what did not work well?• Planning of 3/4 days tests was not realistic.

• Would have been nice to have RDA 3 available earlier.

CERN


General comments

PowM1553: why it did not work well?• The LS1 schedule was too tight.

• Integration and commissioning ended up being a daily fire-fight with no apparent planning. It worked because of the effort from all people involved and the working hours spent. This should not be repeated for LS2 !!!

CERN


Planning and organization

Planning, communication and follow-up• The communication and follow-up were good. However, the

planning was not very effective as it ended up being a "let's do what we can" attitude.

• FGCD: renovation of SPS mugef was not covered by CO's LS1 planning. Commissioning was a direct collaboration with OP, outside of CO planning. Again, good collaboration (Greg) meant it went well.

• FGCD: testing on PSB became an ad-hoc procedure from the CCC. The original planning (3/4 days slots) were sometimes abandoned due to things being unpredictable. When they were used, that was useful.

CERN



Tools and processes• The tools used: Jira, Confluence, emails and phones are

adequate. We are familiar with these tools.

CERN



TE-EPC influence on setting deadlines• PowM1553: major for FESA 3 development.• FGCD: first operational use of RDA 3.

CERN


Technical

Impact of the CO work on our activities• PowM1553: as a gentlemen's agreement we dedicated 1

FTE to develop this class and help as alpha testers. This will not be the case for LS2.

• FGCD: alpha testers for RDA 3. Migration was smooth.• End of Life issues or API changes in the libraries forces us to

perform updates on our side.• Quality assurance does not seem to be the same on all the

software packages. • The support provided was excellent.

CERN


Technical

PowM1553: CO communication regarding the impact• New software products, front-ends, OS, etc. meant LS1 was

no longer an upgrade but a new control system.• The impact on us was underestimated.• Each accelerator is unique. Software must be validated on

each machine individually.

CERN


Technical

Notice from CO regarding changes• PowM1553: due to the unrealistic planning, testing was

performed only when trying to deploy in pre-operation.• FGCD: was good.

CERN


LS2

An acceptable model for changes• Developers should avoid API changes. If unavoidable, the

impact has to be clearly defined and announced. Migration guidelines should be provided.

• (1) New upgrades should be tested prior to deployment. (2) These changes should then be validated in each machine if necessary/possible. (3) If all is ok, it should be approved for operation.

• A slot should then be made available for our testing with experts on site and representatives in the CCC.

CERN


LS2

Coordination of changes with equipment groups• Meetings.

• Specify the impact of the change to the equipment groups.• The CO3 working group is a good approach.• Provide a wiki with EOL dates, upgrades, etc.

CERN


LS2

How to facilitate the implementation of controls upgrade• From our perspective, the controls system is a single entity,

which should be operational and stable throughout LS2.• Changes should be added adiabatically with new releases based

on planned milestones.• Provide documentation and the impact of these milestones

(API changes, configuration files, new features, etc.).• When a new release is ready, a slot should be agreed for us to

do testing with CO experts. No rigid planning as in the LS1.

CERN


LS2

How to make the controls upgrade part of our own planning

• The CO planning should be made public in advance.• The impact of every change should be highlighted. • Based on this we can adapt our planning and provide feedback. • The integration of the equipment's software with the controls

software should be included in the planning. Dry runs should only focus on the commissioning of the equipment + controls software with the machine.

CERN


Final notes

• Again: provide a test environment that is always operational throughout LS2 and can be used to changes introduced adiabatically.

• We have FGCs and a FESA (PowM1553) test-stand you could use to validate your software in a systematic manner. We would be more than happy to help you set things up.

• It would be very useful to nominate a person who would be the liaison between BE-CO and TE-EPC. Marine ?

cern raul murillo garcia be-co ls1 review – te-epc feedback be-co ls1 review te-epc feedback raul...

Documents