Hello, welcome to Clear Sky Institute, Inc.

My name is Elwood Downey. I am the founder and president of Clear Sky Institute, Inc. I would like to describe our experience and explain that we offer complete observatory control system implementations and engineering services targeted to the astronomical community.

It has been my joy and privilege to be involved with telescope and observatory control systems since my days as a programmer at Kitt Peak National Observatory beginning in 1979. You may already know of the venerable XEphem, my labor of love with roots going back to 1981.

From 1993 to 1998 I had the good fortune to collaborate with Dr. Robert Mutel on a project which became the Iowa Robotic Observatory where I honed my skills at the following topics:

The system was entirely successful and remains in full use today allowing some 300 astronomy students every semester to utilize a telescope 2,000 miles from the University of Iowa. After that experience I incorporated CSI Inc in 1999 as a vehicle for full time work in this fascinating area.

Over time I have been improving my approach to control architectures. My latest package is built around INDI, the Instrument Neutral Distributed Interface language I invented expressly for efficient remote observatory control, although it may be used in any domain, not just astronomy. I have successfully deployed INDI at such facilities as the 2.4m Magdalena Ridge Observatory in New Mexico, USA, and the Fabra-ROA Baker-Nunn refurbishment project in Spain. INDI is fully supported by XEphem, is used by other applications such as kstars, has its own independent developers web site and is in use by other other projects around the world.

From these and other experiences, I now have a stable and robust code base upon which I can easily and efficiently build more such systems. Please contact me if you would like to discuss how I may assist in your next observatory automation project.

INDI Control System Architecture

The following diagram shows the basic architecture of an INDI control system.

Start at the bottom to see several individual INDI Drivers. Some of these bridge the uniform world of INDI messaging with the details of a particular device. But Drivers may also offer abstract services, such as scheduling or target prediction, so they are not limited to hardware interfaces. Think of an INDI Driver then as any kind of resource that is useful to an observatory.

Next skip to the top and notice the boxes representing INDI Clients. An INDI Client is any process that wishes to utilize the services provided by INDI Drivers. It is not limited in any other way. Clients can be rich GUI applications, command line scripts, watchdogs, or any other applications. They may be written in any language, from GUI's written in Java or Qt, to scripts written in shell, Python or Perl. The only requirement they share is a need to communicate with INDI Drivers to access the observatory services they require.

In the middle, between Clients and Drivers, is the INDI Server. Think of this as an intelligent router. It filters and directs INDI messages between Clients and Drivers so only those messages for which they have an interest are sent to a given Client or Driver, thus eliminating extraneous traffic. The INDI Server does not otherwise interpret the INDI messages it handles and thus it can operate in a very efficient manner. Over time my implementation of the INDI Server has improved to the point where it consumes less than 2% of a typical PC-class machine even with a full complement of Clients and Drivers at a busy observatory.

It is useful to note that it is possible to chain together multiple INDI Servers. Since the INDI protocol is nearly symmetric, an INDI Client may in fact be another INDI Server. This can be useful in order to deploy an INDI Driver on a machine optimized for a piece of hardware, such as a camera, and yet provide the functionality of that Driver seamlessly on a wider INDI network. Note also that each INDI Server can be configured as to the INDI Drivers for which it allows communications. This allows, for example, certain highly critical Drivers to be rendered invisible to outward facing nods on an INDI network.

INDI Server produces complete logs of all activities from Clients and Drivers. The level of detail can be configured to four levels, from simple connection requests to full message protocol details. Drivers can also add their own messages to these logs. The logs are stored in simple ASCII format and each entry is automatically time stamped and marked as to module of origin.

The connection between an INDI Server and an INDI Driver is simply the stdin, stdout and stderr channels common to all POSIX processes. The INDI Server forks each Driver and arranges file descriptors for all subsequent communications. This arrangement also allows for easy debugging during Driver development. The INDI Server also serves as a watchdog by automatically restarting any Driver if it should fail for any reason.

The connection between an INDI Server and an INDI Client is a tcp/ip socket on a well-known port, 7624, which has been officially recorded with IANA. This allows complete worldwide network interoperability among Clients and Servers. Although INDI itself does not address security, secure connections from Clients to Servers can be accomplished by simply using ssh tunneling of this port. Our GUI client contain this ability inherently without need for prior tunneling setup. Using tcp/ip also provides for a heterogeneous computing environment, for example clients might be running on Windows and Drivers might be running on Linux; the only requirement is that all message traffic adhere to the INDI protocol.

A variety of telescopes, cameras, motion controllers, domes and other devices already have INDI Drivers. There were either developed at CSI Inc and many other are being developed by the active INDI user community at community These can be leveraged to reduce development effort for all new applications.

The code base includes rich modular GUI clients that can be modified to present specific information to users in a pleasing and efficient manner. These can be tailored for basic users to the most sophisticated engineering personnel or scientific users. These are written in pure J2SE Java for the ultimate in portability to all major desktops including Windows, Mac OS X and Linux.

There is also a standard suite of command line tools. These set or get atomic INDI messages and can be utilized by any scripting language to create arbitrarily complex applications written entirely by knowledgeable users on top of the core observatory infrastructure.

A word about the scheduler. The idea is it accepts individual observing requests, sorts them in an order that optimizes for minimum zenith angle, performs the observation and collects the results for subsequent dissemination and analysis. Each request may specify a variety of constraints, including group priority, minimum solar separation, maximum solar altitude, minimum lunar separation, maximum lunar illumination percentage, maximum lunar altitude, minimum target altitude, a specific UTC start time and tolerance or a bracket of no-sooner-than and no-later-than dates and times. The requests are collected in a queue. The queue is resorted after each request completes so it can react to changing circumstances and accommodate Targets of Opportunity. The actual work to be performed during an "observation" is completely general so long as it can be expressed in terms of INDI messages. In this way, the scheduler can perform any functions available on the observatory INDI network, such as utilizing difference instruments or accessing INDI services, without ever being rewritten.

In short, INDI provides the following advantages:

Consulting Services

I am well aware that all observatories are different, both in terms of hardware implementation and operational objectives. But as you can see, I have a mature framework ready to work for you and the experience to fit it into your situation. If you are interested in discussing further how we can work together, please contact me directly.

A working relationship I have found to be particularly productive is to be involved early in your project, so together we develop a common set of expectations. This eventually leads to a list of devices to be controlled and specific performance criteria. This can be as simple as a new camera driver, or as complex as a complete observatory with dome, telescope, weather station and remote robotic scheduled operation. I can also function as a chief consulting engineer, contributing to the writing of Statements Of Work, contract evaluation criteria and participating in selection committees. I have accumulated experience at over a dozen major observatories so I can help define a vision, suggest hardware and refine functional requirements, as required. I can charge by the hour or by the project.

While I am the principal human resource at CSI, Inc, I have well-established relationships with expert electrical, mechanical and software engineers with whom I have worked well in the past who can be brought in as required for specific projects.

Thank you for your time and attention. I hope to hear from you soon.

Sincerely,

Elwood Downey
President, Clear Sky Institute, Inc.
8274 North Sunset Ranch Loop
Tucson, AZ 85743
Email: ecdowney@clearskyinstitute.com
Cell: 575-835-1325

Last edited 9 April 2010.