Title: Bag stu8ff
1General 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.
15Possibilities
- 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.
16- Systems Development planning
- - System requirements - Systems plan in first
release - Development model least risk, most important
features first
17System Engineering Support
18Systems Engineering iterative
19System Engineering requirements for accelerator
- 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
20Summary 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. - IOCs - 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
22The 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.
-
-
23EPICS 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.
24Driver 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
25MCA - Matlab Channel access
- 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
26Development and Support System
Simulate everything at the start and then
replace. Separate development and
production Systems engineering, Configuration
management