1 / 21

E. Matias Canadian Light Source University of Saskatchewan

CLS Control System Overview. E. Matias Canadian Light Source University of Saskatchewan. Introduction ( § 1.0) CID Staff Goals Background Comparisons Major Projects Functionality ( § 2.0) Architecture ( § 3.0) OPI Software ( § 7.0) IOC Software ( § 8.0) Device Level ( § 9 & 10).

zuzana
Download Presentation

E. Matias Canadian Light Source University of Saskatchewan

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CLS Control System Overview E. Matias Canadian Light Source University of Saskatchewan

  2. Introduction (§1.0) CID Staff Goals Background Comparisons Major Projects Functionality (§2.0) Architecture (§3.0) OPI Software (§7.0) IOC Software (§8.0) Device Level (§9 & 10) Other Interfaces (§11) Timing System (§12) Secondary Sys. (§13) Tools (§14, 5, 6) Servers (§15) Networking (§16) System Software (§17) Anticipated Changes Syn-apps Conclusions Agenda

  3. Students – Intern (3) Students – Summer (1) CID Department Controls & Instrumentation Development Department Manager Elder Matias Systems Analyst/Control LeadsRuss Berg Tony Wilson Glen Wright Dioni Medrano (Term) Control System Engineer/Lead Hao ZhangDavid Beauregard (Term) RF Technologist Jonathan Stampe Controls Systems Engineer/Lead Robby Tanner Electronics Technologist Heinz Buchmann Staff Scientist (Instrumentation) Johannes M. Vogt Software Specialist (EFD) Ru Igarashi Control System Engineer/Lead Mike Mckibben Electronics Technologist Denis Beauregard Electrical Engineers/Controls Lead (ETS) Neil Johnson Wade Dolton Computer Technologist Carl Finlay Electrical Technologist Wayne McWillieDoug StarnsRF Technologist Glen PeggFuture (1) Instrumentation Technologist Carl JansenCarmen Britton Electrical Technologist/Foreman Neil Hovdestad

  4. Goals • Review our existing design. • Identify areas that we can improve. • Identify functionality that is needed. • Identify options that we should explore. • The architecture should be: • Maintainable • Flexible • Reliable • Support our functional requirements • Low cost to maintain and support (labour) • Once a system is deployed and commissioned we provide on-call support during scheduled beam time.

  5. Background • SAL (1964 to 1999) • Linear accelerator, EROS ring, Experimental Areas 1, 2 and 3 • Control system based on CAMAC, Digital PDP, VAX and Sun with some NeXT and Amiga computers. • LUCID data acquisition program • CLS (1999 ….) • Highly distributed system (extensive use of RTEMS, single board computers, and optical links to VME crates) • Based on EPICS • Diagnostics beamlines (2) • phase I beamlines (7) • phase II beamlines (7) • phase III beamlines (TBD)

  6. Making Comparisons • Scope • Initial build project $5 M (equip) + labour • In operations approximately $2 M /year + special projects • Comparisons • Larger Staffing Level than MAXLab • Smaller Staffing Level than APS • Good Comparisons • SPEAR 3? - similar parameters • BESSY? – similar size • other mid. size regional/national machines? • SAC, and others compare us to APS; is this reasonable? ….

  7. APS = 110 CLS = 20 Accel Software (??) Building Services (?) Beamline Controls (11) Diagnostics (17) Conv. Facilities (?) Power Systems (13) Controls (26) RF (20) Safety Interlocks (17)

  8. Leveraging Our Size • Perhaps APS and CLS are not the best comparison. • We need to take advantage of our size • Innovative, decisive, cross-disciplinary • Leverage technology and design choices across systems • Technically evaluate our design choices • Adopt best-practice, from both within and outside of the EPICS and synchrotron community • Move more towards a “software engineering” paradigm • Provincial Legislation for “certification” of system analysts -software engineers became law in 2005, as a first step towards licensing • The “software engineering” methods are intended to reduce development costs and improve quality

  9. Major Projects • Phase I and Accelerator Operational Support • Phase II beamlines • CANARIE Remote Access • Infrastructure • VME Monitor Program Upgrade (Russ, Neil J. + Intern) • CS-Studio Tree Explorer (Glen W. + Intern) • Data Acquisition Program Upgrade (Glen W, & Ru) • Next Generation Motor Control (Mike M. & Tony W.) • Upgrades • Diagnostics Kicker, X-ray BPM and time resolve (Johannes) • Linac Gun &RF (Neil J. & Hao) • Linac ACIS System (Robby) • Replace remaining pre-1980 controls (Hao + summer student)

  10. Introduction (§1.0) CID Staff Goals Background Comparisons Major Projects Functionality (§2.0) Architecture (§3.0) OPI Software (§7.0) IOC Software (§8.0) Device Level (§9 & 10) Other Interfaces (§11) Timing System (§12) Secondary Sys. (§13) Tools (§14, 5, 6) Servers (§15) Networking (§16) System Software (§17) Anticipated Changes Syn-apps Conclusions Agenda

  11. System Architecture (3.0) MS-SQL Server MS-Win OPI Linux OPI Linux OPI Linux Touch Panel OPI Linux Network Server (bootp, dhcp, auto restore) Linux Data Archive Server Linux Alarm Server MS-Win VLANs for: each beamline, machine control, development, office, visitors PowerEdge IOC Linux VME Crate (Reflective Memory) EROC IOC RTEMS IOC Step Controller RTEMS PS Boards IOC RTEMS EROC IOC RTEMS IOC Linux 1Gig Bridge MicroStep Field Dev. RS-232 Devices MicroStep Power Supplies Ethernet Devices PLC & GPIB Profibus PLC Motors Field Dev. Motors Magnets Field Dev. Field Dev.

  12. Introduction (§1.0) CID Staff Goals Background Comparisons Major Projects Functionality (§2.0) Architecture (§3.0) OPI Software (§7.0) IOC Software (§8.0) Device Level (§9 & 10) Other Interfaces (§11) Timing System (§12) Secondary Sys. (§13) Tools (§14, 5, 6) Servers (§15) Networking (§16) System Software (§17) Anticipated Changes Syn-apps Conclusions AgendaTurning to the design document….

  13. Tools • PV Crawler • Cables Database • Sequencer • MKS Source Integrity • CS Studio • Rational Software

  14. Network

  15. Syn-apps • Considered in 2001 • reviewed as part of EPICS fact finding • part of the EPICS versus Altersys ECR • Considered (partially) in 2004 • an option for Mono-control • Considered in Feb. 2005 • see memo from E. Matias. • Considered again in Nov. 2005 • see ECR

  16. The Next Step… • Deploy MKS Problem Tracking and the New MKS • This should provide more responsive and predictable operational support • More advanced and configurable access control • Participate in Building and Deploying CS Studio • This tool will provide the ability to permit users and beamline scientist more direct access to configure PV variables • Provide automation for the generation of configuration files (db files, alarm handler, gateway, data archiver, auto-save-restore, edm screens) • Better support for re-factoring • Exploit Lessons Learned from CANARIE Project • First major project based strongly based on UML • First major project to make extensive use of CASE tools • First major project to use Java and Web Services paradigm • Enhance VME Monitor Program • Improved performance • Improved data collection • Improve Data Acquisition Program • Move to Next Generation Motor Control (perhaps based on ESRF design?) • Improve capability for time resolve and diagnostics

  17. Development Process E. Matias

  18. Some recommendations? • Should we get rid of requirement gathering? • If anything the reverse is true, we need to improve our requirements capture process… • Should we get rid of P&ID drawings? • They have become critical to our design process. We are moving to add more not less information to P&IDs…. • Should we get rid of Wiring Diagrams? • Without them (or something equivalent) we can’t maintain a system this size with the staff we have. • Should we get rid of design standards? • They have been critical to being able to maintain a system this size with the staffing levels we have. • Should we get rid of ECRs & ECOs? • As part of our license renewal applications the CNSC was concerned we did not give them sufficient detail and asked for more. • Should we remove access controls? • For the most part, the beamline administrator accounts provide a great deal of control. • Difficult to justify after trying to undo changes in the middle of the night.

  19. Winter at the CLS

  20. Moving Forward • Current CLS Control System • Built on a common design (circa 2000 and 2002) • Homogonous – Common structure and design across the facility • Built on 6 years of EPICS experience • Built on SAL (30 years) of accelerator and nuclear physics science • Critical Questions • Does it represent best industry practice? • How can we improve quality (scientific capability and the user experience)? • How can we improve efficiency? • Is it safe and ethical? • How Do We Answer These Questions? • Collectively (cross-disciplinary) • Open to new ideas and methods • Invite people from inside/outside of EPICS to help us…. • Invite people from inside/outside synchrotrons to help us… • Built on our in-house experts… • Decisions to change are technically driven with backup (ECR) • Exploit automation to reduce costs and increase reliability • Shift in approach, from just-in-time make-it-work building well designed, structured reusable applications support highly configurable applications configured just-in-time

More Related