INDI 18 June 2007
Page 1 of 15
INDI: Instrument-Neutral Distributed Interface
Protocol Version 1.7
Document Version 1.3
© 2003-2007 Elwood Charles Downey
Abstract
A simple XML-like communications protocol is described for interactive and automated remote control of
diverse instrumentation. INDI is small, easy to parse and stateless. In the INDI paradigm each Device
poses all command and status functions in terms of setting and getting Properties. Each Property is a
vector of one or more named members. Each Property provides timing information about how it might be
sequenced with respect to other Properties to accomplish one coordinated action and provides hints as to
how it might be displayed for interactive manipulation in a GUI. Clients learn the Properties of a
particular Device at runtime using introspection. This decouples Client and Device implementation
histories. Devices have complete authority over whether to accept commands from Clients. INDI
accommodates intermediate servers, broadcasting, and connection topologies ranging from one-to-one on a
single system to many-to-many between systems of different genre. The INDI protocol can be nested
within other XML elements such as RTML to add constraints for automatic scheduling and execution.
Introduction
Modern astronomical instrumentation places high demand on its software infrastructure. Mounts, detectors and auxiliary
equipment have many control points and configurations vary greatly across facilities and over time, creating an atmosphere of
constantly changing software. Yet in the midst of this change users want consistent local and remote real-time access,
freedom to use their favorite computing platforms, and ways to participate in the creation and use of clever automated
scheduling techniques for efficient utilization of equipment and reduced operating costs. Keeping everything synchronized
involves at least significant configuration management effort if not completely new development projects as these factors
change.
This paper presents an architecture that eliminates the need for client software modifications when equipment or usage
patterns change. The key feature is a communication protocol which allows a facility to describe itself in terms of devices in
sufficient detail so they can be operated from a GUI for real-time command purposes or captured in a request file for later
automated execution. This dynamic discovery process means that, except for the lowest level device drivers, none of the
software components need to be rebuilt if and when the equipment being controlled changes. Conversely, clients may change
as often as desired because they are not tied to particulars of the instrumentation. All networking and file formats use a
simple subset of XML
1
which promotes freedom of choice for implementation languages and operating systems at each part
of the system.
Other attempts involving XML for control purposes, such as AIML
2
, differ from INDI in that they use XML to describe
existing command and control channels. Our design uses XML directly for this purpose. Other attempts at capturing static
observing requests in a file in XML format, such as the evolving RTML
3
, intentionally restrict themselves to the control of
canonical instruments. This prevents scheduling instruments with functionality that differs from its standardized conceptual
framework without changing the standard. Our design captures commands for diverse and even esoteric instrumentation with
no changes in tools whatsoever.
剩余14页未读，继续阅读
资源评论
staratomy
- 粉丝: 0
- 资源: 6
