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 my 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.

Here are some of the larger projects for which I made significant contributions:

Thus, 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. INDI is fully supported by XEphem, is used by other applications such as kstars and has an active community web site.

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 core of INDI is the idea that all information is captured in Properties. Properties are small typed XML packets that contain anything from telescope azimuth to current wind direction to a camera image.

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

Start at the bottom to see several individual INDI Drivers. Drivers bridge the details of a device to the world of INDI Properties. Some drivers provide Properties related to a particular hardware 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 an interface to any kind of resource that is useful to an observatory. The Driver bridges the details of the service to the world INDI Properties.

Next skip to the top and notice the boxes representing INDI Clients. An INDI Client is any process that wishes to utilize the Properties 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 Properties to access and control 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 yet generic 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 Client or Driver 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 clients contain this ability internally without need for separate 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.

Through a simple fast-cgi gateway mechanism, INDI web clients are now easily created using a Javascript library. These allow universal deployment through any modern web browser and can replace dedicated INDI client applications for all but the most time critical applications.

Also, all INDI status and commands may be programmed and scripted through a simple but very flexible python library.

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. New drivers can be developed in a straight forward manner against a simple API.

Our 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 properties 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. The tools can be scripted in python, c/sh, perl or tcl to name a few.

Scheduling

A word about the scheduler. The idea is it accepts individual observing requests, sorts them in an order that optimizes for minimum zenith angle subject to constraints, performs the observation and collects the results for subsequent dissemination and analysis. Each request may specify a variety of constraints, including:

Any set of INDI properties may also be specified as constraints. For example one might specify a minimum seeing value if this data is available on the INDI network.

Requests are described in an XML format. A GUI client is provided for making simple requests, or more sophisticated requests can be generated with any XML editor or generated from customer web pages using php. All requests are collected in a queue. New requests can be added or deleted at any time. 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 by a request is completely general so long as it can be expressed in terms of INDI properties. In this way, the scheduler can perform any functions available on the observatory INDI network, such as utilizing various instruments or accessing INDI services, without ever being rewritten.

Summary

In short, INDI provides the following advantages:

Consulting Services

A young man is eager to test drive his new car. He finds a deserted road and guns it up to 120 mph. But then the car sputters to a stop. He tries and tries but it will not start. Frustrated he starts walking. He finds an older man sitting on his porch sipping tea. The old man agrees to help, gets his tool box, and they walk back to the car. The old man opens the hood, looks around for a short while then picks up a hammer, gives a single hard tap then asks the young man to try it again. The car starts right up. The young man is amazed and asks how much. The old fellow says "That will be five hundred and one dollars." The young man says that's a lot for just a tap. The old man says "Oh the tap is just a dollar, the rest is for knowing where to tap".

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.

Although 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 18 April 2014.