ALMA Controls Workshop March 9, 2004

1. Keck Control System and Interferometer Experience with EPICS and CORBA ALMA Controls Workshop March 9, 2004

2. Outline for the Talk • Keck Software Overview • Frameworks and Common Middleware • Could Existing Keck Systems be interfaced to ACS? • Could observatories collaborate by defining common abstractions for components?

3. Keck Software Overview Current activities plus short term and long term plans • Software for Diffraction Limited Science Modes • Keck-Keck Interferometer Modes: V-squared & Nulling • Adaptive Optics: Laser and Next Generation WFC. • Software for Seeing Limited Science Modes • Continuous Focus Correction (short term) • Next Generation software for technical cameras (long term) • Several other obsolescence/replacement projects. • New Instrumentation and Metrics …

4. Keck Software Overview New Instrumentation HIRES CCD CASS ADC NIRES OSIRIS KIRMOS

5. Duty Cycle Metrics - Events

6. Duty Cycle Metrics -Activities

7. Duty Cycle Metrics – Totals for the Night

8. Who’s Who Al Honey Doug Summers Erik Johansson Al Conrad Kellee Summers Liz Chock Kevin Tsubota Scott Hartman Paul Stomski Richard Cohen Shui Kwok Myrna Tsubota Wayne Dahl

9. The telescope … And its instruments … acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi GUI image display FITS writer client/server API IPC logging engineering GUI alarms motor control detector astrolib databases Frameworks and Common Middleware • Consider the following table:

10. The telescope … And its instruments … acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi GUI image display FITS writer client/server API IPC logging engineering GUI alarms motor control detector astrolib databases Frameworks and Common Middleware • The columns form a partitioning of Keck software into subsystems. • The rows are layers that might benefit from common infrastructure.

11. The telescope … And its instruments … acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi GUI image display FITS writer client/server API IPC logging engineering GUI alarms motor control detector astrolib databases Frameworks and Common Middleware How can Keck’s use of EPICS be viewed in terms of this table? EPICS

12. The telescope … And its instruments … acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi GUI image display FITS writer client/server API IPC logging engineering GUI alarms motor control detector astrolib databases client/server API EPICS Frameworks and Common Middleware Where to KTL/keywords fit in this picture? client/server API KTL/keywords

13. The telescope … And its instruments … acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi GUI image display FITS writer client/server API IPC logging engineering GUI alarms motor control detector astrolib databases Frameworks and Common Middleware Are there other significant ‘rectangles’ at Keck? R T C RPC+ (?) MUSIC+ (?) client/server API KTL/keywords EPICS

14. Frameworks and Common Middleware

15. Frameworks and Common Middleware • With this background, we can now address the topic Gianluca suggested for this portion of the talk. • Given that we are using common middleware (EPICS, among others), and that we interface Keck Keywords to CORBA, … • What is good about using common software? • Developers can focus on their application; users see consistency; less re-inventing of the wheel. • What is bad? • Splinter groups; potential for compromised performance; keeping developers in lockstep delays the project. (All of these can be overcome!)

16. Frameworks and Common Middleware • What were the lessons learned? • A common client/server API (KTL/keywords) is a good idea. (Even common frameworks can come and go). • More vertical commonality is good for the long term; but cream-skimming pressures sometimes motivate a ‘flexible approach’ • The common client/server API (KTL/keywords) allows (wrongly encourages?) more flexibility in the layers above and below. • The common client/server API (KTL/keywords) depends too heavily on C-language bindings.

17. Frameworks and Common Middleware • When we interfaced CORBA to our legacy systems. • What were our requirements? • Get it done soon! • What problems did we encounter? • Originally tried a sophisticated method utilizing derived classes; we got stuck. • Chose to simply build a client acting as a bridge; we got unstuck. • How is CORBA based common software helping us? • Polymorphism. • Interface documentation (ICD) and interface implementation are one in the same.

18. Could Current Keck Systems be interfaced to ACS? • Yes • What potential problems would we foresee? • Yet another rectangle? • We would need to demonstrate the benefit to using ACS for, for example, the next generation guider effort (HTP?)

19. Could observatories collaborate by defining common abstractions for components? • Emphatic yes! … a wiki to collaboratively define IDL for a generic telescope mount or weather station (as discussed yesterday) seems like a good place to start.

20. Conclusions • Keck experience with common software has been mixed, but generally positive. • The goals that motivated KTL/keywords 10 years ago are similar to those being voiced now for collaboration via common abstractions for components (like telescope mount). • Migrating KTL/keywords toward IDL for an equivalent CORBA interface may be a good strategy internally for Keck. • Collaborating with other observatories on CORBA/IDL for common abstractions for components (like telescope mount) seems promising, but Keck resources are limited. • Use of ACS at Keck is possible, but not likely in the near future (but the guider upgrade project presents a possibility, depending on the bang-for-the-buck).