ALMA Controls Workshop

March 9, 2004

Keck Control System and InterferometerExperience with EPICS and CORBA

Keck Software Overview

Frameworks and Common Middleware

Could Existing Keck Systems be interfaced to ACS?

Could observatories collaborate by defining common abstractions for components?

Outline for the Talk

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 …

New Instrumentation HIRES CCD

KIRMOS

OSIRIS

NIRES

CASS ADC

Keck Software Overview

Duty Cycle Metrics - Events

Duty Cycle Metrics - Activities

Duty Cycle Metrics – Totals for the Night

Who’s Who

Al ConradAl Honey Doug Summers Erik Johansson

Kellee Summers Kevin Tsubota Liz Chock

Paul Stomski Richard Cohen Scott Hartman

Shui KwokWayne Dahl

Myrna Tsubota

Frameworks and Common Middleware

• Consider the following table:

GUIimage displayFITS writerclient/server APIIPCloggingengineering GUIalarmsmotor controldetectorastrolibdatabases

acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi

The telescope … And its instruments …

Frameworks and Common Middleware

GUIimage displayFITS writerclient/server APIIPCloggingengineering GUIalarmsmotor controldetectorastrolibdatabases

acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi

The telescope … And its instruments …

• The columns form a partitioning of Keck software into subsystems.

•The rows are layers that might benefit from common infrastructure.

Frameworks and Common Middleware

GUIimage displayFITS writerclient/server APIIPCloggingengineering GUIalarmsmotor controldetectorastrolibdatabases

acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi

The telescope … And its instruments …

How can Keck’s use of EPICS be viewed in terms of this table?

EPICS

Frameworks and Common Middleware

Where to KTL/keywords fit in this picture?

GUIimage displayFITS writerclient/server APIIPCloggingengineering GUIalarmsmotor controldetectorastrolibdatabases

acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi

The telescope … And its instruments …

client/server API

EPICS

KTL/keywordsclient/server API

Frameworks and Common Middleware

GUIimage displayFITS writerclient/server APIIPCloggingengineering GUIalarmsmotor controldetectorastrolibdatabases

acs gdr ao dcs if laser nirc lws nspc nrc2 lris hires dmos esi

The telescope … And its instruments …

EPICS

MUSIC+ (?)RPC+ (?)

KTL/keywordsclient/server API

Are there other significant ‘rectangles’ at Keck?

RTC

Frameworks and Common Middleware

Framework or middleware

Horizontal Coverage

Vertical Coverage

Comment

KTL/Keyword 98% 5% Restricted vertical coverage is by design; similar to IDL?

EPICS 25% 25% Only real frameworks in use at KeckRTC 80% 10%

MUSIC+ 15% 10% More inheritance than a framework

RPC+ 15% 10%

• 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!)

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.

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.

Frameworks and Common Middleware

• 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?)

Could Current Keck Systems be interfaced to ACS?

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.

• 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).

Conclusions