|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass98/sallkb/
Дата изменения: Sat Jul 17 00:46:35 1999 Дата индексирования: Tue Oct 2 06:51:05 2012 Кодировка: Поисковые слова: п р п р п р п р п р п р п р п р п |
Instrument Remote Control (IRC) is a joint effort between NASA/GSFC's Advanced Architectures and Automation branch (Code 588) and Century Computing; it will enable trusted infrared astronomers around the world to easily access infrared astronomical instruments located in remote, inhospitable environments.
The long-term goal of the Instrument Remote Control (IRC) project is to develop a distributed framework from science user to instrument which will provide robust interactive and reconfigurable control and monitoring of remote instrumentation. It is crucial that the next generation of astronomical instruments be largely free of the constraints imposed by specific operating systems and rigid computer hardware configurations that are likely to need to be changed many times during the lifetime of the instruments. IRC promotes the idea of distributed environment with processes assigned to the CPU and hardware best suited to the task. Our assumption is that better equipment will appear soon after commissioning; we must therefore be able to accommodate changes easily. Our software methodology is characterized by several key goals and principles:
To accomplish our goals, we are developing a comprehensive instrument description based on Extensible Markup Language (XML),1, a World Wide Web Consortium standard. This description will drive nearly all of our software development efforts. We will make use of automated tools to assist in the definition of this description, as well as in incorporating changes to the description. Our ultimate system will interpret the descriptions at runtime, where performance allows. In other cases, we will generate code from the latest instrument description.
Our initial prototype was a Java application developed for the Center for Astrophysical Research in Antarctica (CARA) that ran on a Mac Quadra to control heaters for SPIREX at the South Pole in early 1998. IRC is currently focusing on the design and implementation of the control software for HAWC, the High-resolution Airborne Wideband Camera, for SOFIA (Stratospheric Observatory For Infrared Astronomy). Our second SOFIA instrument will be the Submillimeter And Far InfraRed Experiment (SAFIRE). Both HAWC and SAFIRE are SOFIA First Light Instruments.
We believe our techniques will also be applicable to ESA's SPIRE (Spectral and Photometric Imaging REceiver for FIRST - Far InfraRed and Submillimetre Telescope) as well. These three instruments have some features in common (e.g., their detectors) which make them good candidates. However, we emphasize that our techniques can be extended to any astronomical instruments. In fact, our solution can only become truly general if we have a diverse set of data points; we encourage members of the astronomical community who share our concerns to contact the authors to contribute in some manner to this development effort.
Our long-term focus is to develop an extensible framework to which new instruments can be added with relative ease. This will eventually be accomplished by implementing our own AIML2 based on a custom Document Type Definition (DTD) which will evolve over time, as a direct effort of NASA/GSFC and Century Computing. Since AIML is an XML vocabulary, it will be well suited to describing hierarchical, structured information. AIML will be used to describe control capabilities, data streams, message formats, and communication mechanisms, as well as for online documentation and the association of housekeeping metadata with acquired images. Some of these aspects of instrument control will be reflected in Java graphical user interfaces, generated from the instrument descriptions. Other sections of the instrument description will be applied to data capture and data pipeline algorithms, as well as to other instrument subsystems. Different parts of the description can be used by different components of the software architecture, and even by separate applications. Furthermore, once we collect a number of instrument descriptions from a variety of observatories, astronomers will be able to specify what characteristics they need for a particular proposal and generate a query that will return a list of suitable instruments.
The hierarchical, structured markup of XML facilitates many aspects of instrument description, algorithm description, and documentation.
Down the road, we expect to expand AIML to encompass:
The following examples are meant to be illustrative of our approach.
The AIML example below is a simple description of an element we call an Image which consists of two parts: (1) the data itself, stored in a separate file; and (2) the metadata which defines the circumstances under which the data was collected. Although the example specifies FITS, our notion of an Image is independent of any particular binary representation. A key advantage of this approach is that the metadata portion can be processed by any XML-aware tool and is fully searchable, regardless of the binary format which the metadata describes.
<Image>
<Data href="m42th1a.fits" type="FITS" series="1247"/>
<Metadata>
<ObjectName>M42, Orion Nebula, Theta-1</ObjectName>
<TimeStamp>
<Date month="09" date="16" year="2001" />
<Time hrs="17" min="24" sec="13" msec="145" />
</TimeStamp>
<Integration duration="20" filter="300micron" />
<FlightInfo ra="5:33" dec="5:25" />
<Notebook>This stellar image was taken on our maiden voyage.
Weather conditions were...
</Notebook>
</Metadata>
</Image>
We recently learned of Astronomical Markup Language by Guillaume & Murtagh, which describes astronomical objects, articles, tables, set of tables, images, and authors. We hope to coordinate our efforts with those of Guillaume & Murtagh, however, our AIML description is aimed at the wider domain of instrument description and control, as well as data collection and pipeline algorithms.
The next example describes two Commands, HeatSwitch and HeatSwitchCurrent, both of which accept exactly one argument. Note that the ``current'' argument of the HeatSwitchCurrent command has Valids (constraints) defined. This results in a GUI component which will guarantee input only within the constrained range.
<Control id="HAWC.ADR">
<Command id="HeatSwitch">
<Argument id="state" type="boolean" required="true"/>
<!-- other Arguments would go here -->
</Command>
<Command id="HeatSwitchCurrent">
<Argument id="current" type="float" required="true">
<Valids>
<Range low="0.0" high="200.0" units="amps" />
</Valids>
</Argument>
</Command>
<!-- other Commands would go here -->
</Control>
We have attempted to convey the significant advantages gained by describing astronomical instruments and data pipeline algorithms using AIML, our XML vocabulary. Separation of GUI descriptions from application logic has long been a favored practice in the software industry. It is time for the astronomical community to favor an approach that similarly separates out as much of the instrument details from the code as possible. By so doing, we can develop and modify instruments far more quickly than those created by conventional software development techniques. We will also produce a database of instrument descriptions that can greatly simplify the task of locating the right instrument for achieving specific proposal goals. To join our low-volume XML for astronomy mailing list, send the one-line message subscribe xml your_email_address to majordomo@pioneer.gsfc.nasa.gov.