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-EPC Daniel Calcoen Stephen Page 1/12/2015

CERN Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback General comments 3 What worked well? PowM1553: people's predisposition and collaboration. FGCD: collaboration model.

CERN Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback General comments 4 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback General comments 5 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback General comments 6 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Planning and organization 7 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Planning and organization 8 Tools and processes The tools used: Jira, Confluence, s and phones are adequate. We are familiar with these tools.

CERN Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Planning and organization 9 TE-EPC influence on setting deadlines PowM1553: major for FESA 3 development. FGCD: first operational use of RDA 3.

CERN Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Technical 10 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Technical 11 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Technical 12 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback LS2 13 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback LS2 14 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback LS2 15 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback LS2 16 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 Raul Murillo Garcia BE-CO LS1 review – TE-EPC feedback Final notes 17 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 ?