General overview of control systems and philoshophy Richard Farnsworth

1. General overview of control systems and philoshophy Richard Farnsworth Lead Controls systems Engineer

2. We have a small team delivering beamlines controls and instrumentation services – therefore standards are critical. Five permanent Instrumentation and Controls staff planned– four Engineers and one IT specialist. Much will be outsourced

3. Two Instrumentation Controls specialist engineers are working on specifications at the moment: Dr Mark Clift – a background in similar systems in research and commercial IT Mr Wayne Lewis – A background in large distributed industrial control systems.

4. The essential dilemma: The controls team wants standards because Software support is greatly reduced. Hardware spares and logistics are easier. Expertise on Beamlines is transferable. Off the shelf solutions are less expensive. Integration is easier.

5. The essential dilemma II: The users like non standard solutions because; The standard hardware is not always the best device for the job The standard software may not drive the device in an optimum fashion The complexity for a given task is greater – therefore less reliable

6. Insisting on standards all the time will only lead to “Tears” and “blood on the floor” But without any standards will lead to Late delivery, interface problems, and difficult to use software

7. As usual in most Engineering, a compromise is the way forward: the philosophy being: Standardise where you can; Customise where you must;

8. Drivers of standards include: Generic Technology e.g. Communications standards TCP/IP, Ethernet, RS232 Hardware standards (e.g. PCI, VME, VXI) Wiring standards (Red or Brown ?) Interface standards (active high or low)

9. Drivers of standards include: Site specific technology choices e.g.: Stepper motor Controllers Supervisory software (e.g. EPICS) GUI Software GUI style (red = danger, green = safe vs Red = stop, green = go) Operating systems (Unux, Windows)

10. We are here discuss these issues. Our agenda will include the possibilities of standardisation where possible AND convenient, but not eliminating the possibilities of other standards or choices

11. However: The Accelerator is using EPICS and it is very suitable for much beamline work. However we are not using traditional EPICS hardware – we are using Linux and PC based hardware.

12. In consultation with the Beamlines Scientists EPICS has been chosen as the most suitable control system for the Protein crystallography line (PX).We will prefer, but not mandate Hardware. The User Interface will be Blu-ice. Many of the stepper motor controllers will be Standardised.

13. The PX beamline will be beamline 1 and will be a “Production” type beamline – that is the beamline itself will not be experimental. The user interfaces will be regular and controlled The machine control will be a service to the user and not exposed.

14. There are two common types of systems across most Beamlines These are the Personnel Safety Systems (PSS) and the Equipment Protection systems (EPS) These systems will be separated from the rest of the Beamlines and are prime candidates for standardardisation.

15. The Accelerator is using Pilz SIL3 rated safety systems and Schneider PLC based equipment protection systems, We have standard software interfaces from EPICS to Modbus devices also to Labview and applications. Others interfaces are around. Possibilities

16. Systems Development planning • - System requirements - Systems plan in first release • Development model – least risk, most important features first

17. System Engineering Support

18. Systems Engineering iterative

19. Documented over 500 control systems requirements: • Components e.g. Timing, vacuum, RF, EPS…(bulk) • Functional requirements e.g. Safety, stats, Operator interface..) • Non Functional (e.g. Network, Comms, Time synch, security, standard System Engineering – requirements for accelerator

20. Summary of Accelerator contracts • Levels of integration requirements will vary depending on capability of supplier • EPICS is now common enough in the community for it to be leveraged on, industry can supply. • EPICS is being specified to ease integration problems and risk. This approach is consistent with the general project approach. • IOC’s - in general will not be free issued • Suppliers if not capable can now seek independent help .

21. EPICS details Using late version (n-1). Next major release due after first turn. Training - Epics course included Industry reps – EPICS collaboration Meeting. Hardware – will use commercial off the shelf as much as possible IOC selection - favour RT Linux

22. The development system • Purchased hardware – still being configured • Includes dedicated build machines • Configuration Management (Perforce – Front end to CVS), • bug tracking (Bugzilla – integrated browser), Webserver, • specialist coding machines and • Machines Simulator.

23. EPICS Toolbox selections • EDM for simple displays, bulk displays • Linux + Windows OS • Matlab – MCA, rewritten by us, incredibly powerful, for complex displays and high level control (e.g. SOFB) • Archivers – latest version very powerful • EPICS CA Gateways for security and separation • Standard Alarm Handling until after commissioning, others may be required later.

24. Driver developments • Bench development of Controllers • Varian • Gamma • HPS guage controller • PLC Modicon (Schneider + Pilz) • Now it only takes few days to get most simple devices talking to EPICS

25. Work on MCA • Removed 1000 Channel Limit • Matlab “Monitor Callbacks” now fully supported • Is favoured by our Accelerator Physicists • Will use for complex displays and some processing • Slots into Accelerator Toolbox - Important for us to simulate as we have no machine. • Lets us be “close” to the AP MCA - Matlab Channel access

26. Simulate everything at the start and then replace. Separate development and production Systems engineering, Configuration management Development and Support System