1. Accelerator Systems Integration Stephen Molloy Section Leader for Accelerator Integration www.europeanspallationsource.se April, 2016

2. Overview Introduction to the Integration Section – Roles/responsibilities – Task division amongst the team Examples of recent work – Electronics racks for the RF Gallery – Installation, testing, & commissioning schedule – Interface requirements – Protection and Safety coordination – Accelerator controls Future plans 2

3. Integration Section Within the Linac Group (see the talk by Håkan) A document describing the roles & responsibilities of the Integration Section was distributed on 20th January – ESS-0049135 A relatively formal document, so I’ll summarise the main points in the next few slides 3

4. Roles and Responsibilities Headline items – Requirements Owner of L3 & L4 top-down requirements Owner of L3 interface requirements Monitoring of the L4 interface requirements authored by the WP’s – Coordinator of MPS/PSS/TSS activities within AD – Integration within Gallery and Stubs – Installation, Testing, and Commissioning (ITC) schedule Deliberately absent – No technical responsibility for any ACCSYS systems/components – No direct input to any IK contracts Indirect input via L3/L4 reqs 4

5. Division of work within the Section Owners of L3 & L4 requirements – Each section of the accelerator needs a high-level “owner” – Most of this has been completed – only maintenance and baby-sitting is needed Interfacing with other divisions – TGT Interface requirements (for TGT & beam dump) – ICS Advising ICS & AD management on prioritisation of tasks Reporting on foreseen problems Flow of data from AD to ICS databases (e.g., naming of devices, configuration control, etc.) MPS/PSS/TSS Working Group coordinator Development of operational strategy for these systems Authoring of requirements to ACCSYS – CF Gallery/Stubs integrator 3D envelopes, component placement, cable routing, etc. Must be coherent with the ITC schedule ITC sequence/schedule – Collaboration with Division Planner & WP’s – Our role is to drive this sequence/schedule 5

6. Division of work within the Section 6 Iñigo Alonso ●L3/L4 owner for SPK-->A2T (& DMPL) ●Align ICS strategy with AD ●Build database of ICS projects relating to AD ●Advise AD & ICS management on prioritisation of ICS projects ●Rationalise information flow between ICS & AD ●WP6 responsibilities Aurélien Ponton ●Coordinator of WG on MPS/PSS/TSS ●Development of operational strategy for these systems ●Owner of L3/L4 requirements relating to MPS/PSS/TSS ●Owner of L3/L4 requirements for ISrc-->DTL Stephen Molloy ●Section leader ●Controls strategies for ACCSYS equipment ●TGT & Beam Dump interface Edgar Sargsyan ●Integration of ACCSYS equipment in the gallery & stubs ●Negotiation of 3D envelopes for equipment belonging to other divisions in G02 & Stubs ●Development of ITC sequence & schedule (in collaboration with WP’s and AD Planner) ●Magnet-related responsibilities

7. Some examples of current work Racks in the RF gallery – Distribution – Expected heat load Integrated Testing & Commissioning schedule (ITC) – Detailed in another presentation Coordination/monitoring of interface requirements MPS Working Group – Scope – Members Control systems – Blinky light test 7

8. Rack count review (Edgar Sargsyan) Review of the rack count, rack power requirement and heat dissipation – Meeting with a representative from each WP and ICS – Determine the rack equipment, power, heat dissipation – Eliminate double counting (e.g. ICS equipment in BI racks) Reduced values for the heat dissipation (cooling needs) – from 2 MW down to 830 kW total – Extra 250 kW to be added if contingency racks are considered Reduced number of racks – from 778 down to 572 – Extra 32 racks to be added for the PSS 8

9. Integrated Testing & Commissioning schedule (ITC) (Edgar Sargsyan) See the talk by Edgar Sargysan 9

10. Coordination/monitoring of Interface requirements (Iñigo Alonso) 10 See the talk by Håkan Danared

11. Safety Sytems implementation and interfaces with ACCSYS (Aurélien Ponton) The Integration Section is the main point of contact within AD for the following safety systems deployed at ESS: MPS, PSS and TSS. The Integration Section: Offers expertise on the accelerator systems Develops the interfaces requirements Coordinates the implementation plan PSSMPSTSS ACC-MPS Working Group Looking at how to protect the accelerator components from beam induced damages due to off-normal behaviors of the beam. Deliverables: 1.The range of beam parameters to run the accelerator safely (ie in normal conditions) 2.The ACC to MPS protective interfaces: protective functions, thresholds, time (devices: BCT, BLM, etc) 3.The MPS to ACC inhibit interfaces: inhibit functions, time, scenarios (devices: ion source magnetron, LEBT and MEBT choppers) Members: A. Ponton (Accelerator Scientist, Chairman), E. Bargallo (Reliability expert), one representative from BPOPBD and from MPS. Bi-Weekly Meetings Kick-off: April 2016 Weekly meeting for: Identification of the accelerator components potentially source of hazards for the personnel (radiations, HV, magnetic field) → done Identification of mitigation devices to turn off the beam in case of unauthorized access to the tunnel (ion source, RFQ) → in progress Definition of safe access to the tunnel (no RF, no HV for the ion source, light on magnets, etc) → in progress Development of the PSS to ACC interfaces → in progress Review on accelerator PSS in July 2016 Meetings when required by the TSS team: Identification of mitigation devices to turn off the beam (ion source, RFQ) → in progress Development of the TSS to ACC interfaces → in progress

12. Controls Systems From previous review – Continue with “Blinky Light Test” – Get your hands dirty Official Blinky Light Test ran into trouble – Reorganisations of ICS & AD altered prioritisation Staff moved to other tasks Two of three ICS staff left the organisation – Most importantly -- we got bogged down in requirements gathering A restart was needed 12

13. Blinky Lights: Redux Problem: – Requirements analysis paralysis – Solution: The initial target should be extremely simple – But the architecture should be properly scaleable Problem: – Staff retention & prioritisation of the project – Solution: System should be such that: – A team of one or two people should suffice – Only a few weeks are needed to build something that works 13

14. Blinky Lights: Redux 14 ●EPICS + StreamDevice + ASYN + SLAC EPICS Archiver ●Both of the above running, initially, on a single CPU, but later work moved the archiver to its own computer ●Target system controlled with a microcontroller ●Simple system allowed exercising of various features, e.g., ○Sets & gets ○Feedback loop implemented in EPICS or directly on the microcontroller ○Archiving

15. Summary Integration Section started work in January Responsibilities split amongst various tasks: – Technical requirements – Coordination with other Divisions – Alignment of the interface with ICS 15