Next: The Gemini Core Instrument Control System
Previous: The Design of the Gemini Observatory Control System
Table of Contents --- Search ---
PS reprint
John T. McGraw, Nebojsa Duric
Institute for Astrophysics, University of New Mexico,
Albuquerque, NM 87131
Michael Sjulin, Scott Slezak
Sandia National Laboratories, Albuquerque, NM
David Westpfahl
Department of Physics, New Mexico Institute for Mining and
Technology, Socorro, NM 87801
Astronomy is a unique science because everyone can relate to it, if given the opportunity. A unique New Mexico astronomy consortium was recently awarded a federal grant matched by funds from the State of New Mexico and the City of Albuquerque to reinstate science and technology back into society. Led by the Institute for Astrophysics at the University of New Mexico, the LodeStar Project (L*) includes three educational institutions, three governments, and three national laboratories. Consortium members include the University of New Mexico (UNM), New Mexico Institute of Mining and Technology (NMIMT), the Albuquerque Public Schools (APS), the State of New Mexico, the City of Albuquerque, the Pueblo of Acoma, Sandia National Laboratories (SNL), Los Alamos National Laboratory (LANL), and the Air Force Phillips Laboratory (PL). It is the goal of this consortium to use the universal appeal of astronomy to attract students to scientific and technical careers, to help establish a scientifically literate populace, and to support astronomical research, a clean, high-technology industry, into the next century. In this paper we discuss the critical issue of how scientists, students and the general populace can be given access to astronomy using computers, networking and technology developed at the SNL, UNM and NMIMT.
In New Mexico, every culture in the state has a long history of astronomy. The Anasazi ancestors of current pueblo cultures were, a millennium ago, the best astronomers in North America. Their culture, which produced more than 10,000 villages roughly centered on the Chaco Canyon complex, depended upon astronomical timekeeping. The Spanish explorers who traveled the Camino Real decades before the Pilgrims ``settled'' the New World relied upon celestial navigation and timekeeping for navigation. Certainly, the history of northern European science is critically dependent upon astronomy. In short, astronomy provides a unique cultural basis, as well as an attractive, generalist's science, by which other science and technology can be related in a manner understood by all.
An issue key to the success of L* is the ability to communicate efficiently among people, to control telescopes and other assets remotely, and to transfer data of several forms, all in a robust, secure and efficient manner. An obvious, but perhaps under-appreciated statement of our intent is to use (digital) electronic communications techniques to allow people to interact with each other and with the assets of L* as if they were physically present at the same site. This sets limits on interaction bandwidth, both in terms of what is desirable and what is acceptable---that is, what can be accomplished with current technology. The communications goals of this project are not simply a nicety---they are necessary to maximize the benefit-to-cost ratio of the investment made by taxpayers who would like their students to benefit from their investment. Because L* is a statewide initiative, it is legitimate to base these communications, at least initially, in wide-area networks, such as the Internet. This, of course, implies far wider communications are immediately possible.
The L* needs for robust, secure communications parallel requirements for any remote system used to operate telescopes for the professional community. Involvement of a national laboratory can ensure long-term support for the system. In short, the command, control and information system necessary to support the LodeStar Project has embedded in it the major requirements for a standard, supported, remote telescope operation and data communications system. We suggest that with input from the community, the L* command, control and information system (CCIS) might be adopted by the professional astronomical community as a standard for remote operations.
To set the scale and perspective of the CCIS, note that L* incorporates three sites in central New Mexico, each separated from the others by approximately 100 kilometers. The first site is in Albuquerque, near Old Town, and is a hands-on learning center. The second site is based in Socorro on the NMIMT campus, and provides a small hands-on learning center and a 70-cm remotely operable telescope equipped with a CCD camera. The third site is in Cibola County near Acoma Pueblo and the towns of Grants and Milan. This site, the precise location of which is being determined by astronomical site testing, will become Enchanted Skies Park, the first park commissioned to provide public access to the night sky. This site will host another remotely operable telescope for student use as well as an array of professional research telescopes. All of these telescopes will be remotely operable from any other site and from any classroom in the state. By extension, these telescopes can be operated from any site equipped with communications and computing capability, such as a PC or workstation on the Internet.
This paper deals with contributions to L* provided by SNL and integrated and developed to support remote control of telescopes and remote multimedia communications. SNL participation results, quite literally, in ``swords'' developed for government and military purposes being transformed into ``plowshares'' with which to till the fertile ground of education in the public domain. This is precisely a role into which Congress directed the national laboratories to expand. With this single development, SNL will enable educational access to their own extensive outreach programs, as well as to the assets of L*, for more than 200,000 students statewide, and ultimately many more than this nationwide. For the professional astronomical community, this exercise will result in a system we propose as a national standard for remote access to telescopes. Certainly, the system can be used by the astronomical community for other purposes, including new educational and outreach programs.
We first describe the assets to which this CCIS system must provide access and estimate the bandwidth required to establish communication. The various modes of communication and the audience to which they are directed are next discussed, again with the goal of deriving data rates and communication bandwidth. We next discuss the user interfaces and their roles in efficiently allowing access to assets and resources and in the broadest sense, for education to occur. Finally, we describe some scenarios in which the system will be used.
One modern view of telescopes is that they are robots with typically two (angular) degrees of freedom which can be directed (within limits) to observe any position in the sky. The third motion is focus, normally achieved by moving a secondary mirror along the optical axis. Certainly, remote access is incorporated into many telescope control systems, allowing observers in Chicago, for example, to access the ARC 3.5-meter telescope on Apache Point without having to leave the dreary, bright skies of Illinois to come to the clear, dark skies of New Mexico. This is, for various reasons (some of them valid), generally recognized as a desirable mode of observing with telescopes in any wavelength domain. The first generic system we propose to access with the L* CCIS is any equatorially or alt-az mounted telescope and its software-based control system. Examples of such systems include the telescopes of the VLBA (Napier et al. 1994) and the ARC telescope (Gillespie, Lowenstein, & York 1995) and are widely understood by the astronomical community.
In general, a telescope has one or more instruments mounted on it to provide appropriate modes of observations. A telescope with two Naysmith foci, for example, might have mounted a spectrometer and an imager with the capability to switch the telescope beam between the two as observing conditions or programs dictate. Again, we consider the instrument as a single system including both its hardware and software control system. Operable components of a spectrometer, for example, might include one or more shutters, a slit selector, slit width and length adjustment, collimator focus, and emission line and continuum lamps for calibration. In general, these functions are controlled by software in an instrument control computer. In most instances, the telescope and instrument control computers are physically separate.
In many cases, the detector is controlled separately (at least logically) from the instrument. This is driven by the need for monitoring the detector during exposures and the rather large data volumes and rates which can derive from area-format or spectrally-sensitive detectors. For example, charge-coupled devices (CCDs) with 4K X 4K formats now exist. Mosaics of these and smaller CCDs can produce focal plane arrays with, say, 100--500 million pixels. The dynamic range of CCDs justifies digitization to at least 16-bits per pixel, resulting in data volumes per focal plane readout of 32 Mbytes typically, and 0.5 Tbytes in more extreme cases. Clearly, the architecture and software structures for managing these data must be carefully designed. As carefully designed must be the data transmission systems which convey these data from the telescope to the remote observer. These data require lossless data compaction schemes and error detection/correction to ensure that the dynamic range of the data is maintained and that all-important noise bits are robustly transmitted for later assessment of S/N. While the data volumes per focal plane readout are large, the data rates required for transmission are moderate, because the focal plane is only accessed once per integration on the sky. While observing, this interval is typically one to 30 minutes. Flat-field, bias and calibration frames are acquired at a higher rate, typically zero to 10 minutes of integration. In these cases, the time to read out the focal plane is often longer than the integration time. This operational mode then sets an upper limit to the average data rate: the focal plane data volume divided by the time to read the array. For a typical readout time of five minutes, a 32 Mbyte focal plane results in a 107 kbytes/sec data rate. A 0.5 Tbyte focal plane results in a data rate of 1.7 Mbytes/sec with the same readout time. These data rates can approximately be halved by implementing even single-level Huffmann codes for lossless data compaction.
Detectors often need to be read without making changes to the instrumental configuration, but the telescope might be moved to a new object. Of course, perhaps the observer changes everything---telescope pointing, instrumental configuration, and detector parameters---at once! In this case, a robust computer architecture which implements detector readout while the instrument is reconfigured and the telescope is repositioned allows maximum efficiency.
A note on efficiency is in order. Typically instrument designers will expend tremendous efforts to get the last fraction of a percentage of throughput from their instruments. Great effort will be put into increasing the quantum efficiency and decreasing the noise in detectors. Similarly, anything less than optimum efficiency in communicating with and controlling the telescope systems adversely and immediately effects observational efficiency. The duty cycle of observing must be maintained at optimum levels to preclude minimizing the efforts made to enhance throughput and dynamic range from the primary mirror to the detector.
In fact, one must consider efficient and robust remote operation of an entire observatory, including the dome or telescope building and auxiliary instrumentation such as finding/guiding cameras, power monitors/UPS systems, weather stations, cloud monitors and various possible surveillance cameras. Remote operation of an entire facility requires additional communications bandwidth.
While the goal of remotely operating telescopes is to obviate the necessity for people to attend the site, for the foreseeable future there will be a requirement for person-oriented communications to the site. These communications might be between an on-site observer and a remote technical support person, or the converse. It might be between scientists on- and off-site, or among an on-site docent and several classes she is instructing in the remote use of telescopes. In any event, video and audio communications must be built into the broadly-based communications system.
The data rate from a video camera operated at standard frame rate (30 Hz) and eight bits per pixel is 8 Mbytes/sec. Various techniques exist for compressing these data without materially affecting the visual appearance. The simplest technique is logarithmic compression, which results in factors of 10 to 100 in data rate. Video data might derive from cameras which view: the night sky, the exterior of the observatory, the telescope and instrument, the control room, the finding field, and a guiding field. In practice, we anticipate using a software-controllable video switch to select but one video source at a time. Thus, the bandwidth requirement for video data can be maintained at values of approximately 80 kbytes/sec for a single, compressed channel. Reducing the frame rate to 10 Hz, a reasonable rate for the majority of the scenes we shall transmit, results in a video data rate of about 27 kbytes/sec.
A necessary adjunct to the video signal is audio. Alternatives are to digitize, compact and transmit the audio data on the same channel as the video, or, perhaps simpler, to provide a second channel, such as a telephone line. A reasonable estimate of the bandwidth needed to maintain audio communications derives from an audio sampling rate of one kHz at 8 bits per sample or a one kByte/sec (continuous) data rate. A lower sampling rate results in somewhat degraded audio quality but also requires a lesser data rate and may be acceptable in many situations, at least initially.
A second class of LodeStar asset is archives. Certainly, LodeStar will maintain an archive of all raw and processed data for use by all participants. The issues with respect to science data archives have been suitably addressed by the community. We shall adopt archival procedures which retain the raw data, instrumental signature and engineering data, calibrated data and metadata in such a way that raw data can be recovered from calibrated data by ``backing out'' calibrations and instrumental corrections. Raw science data, calibration and signature data will be directly archived to tape (Exabyte or DAT), optical or magnetic disk at the telescope control center. These may later be compiled and transcribed to optical disk, or other more stable medium which also provides quicker access time when these data are requested. The majority of our users will access the calibrated data, which will be maintained on disk at the L* headquarters in Albuquerque.
There are, of course, other L* archives which must be accessible. For example, L* will maintain a set of curriculum aids, including demonstrations and experiments, which can be accessed remotely by teachers. They will be able to request these materials from a catalog, just as an astronomer would request data from an archive. These materials will have different forms, however, ranging from computer-accessible information sheets to entire exhibits which must be transported by truck to the requesting location. Requests for speakers or the Visiting Scientists program will be handled by the same mechanism. Scheduling, queuing, locating, shipping and inventory maintenance will be automated. All transactions will, of course, be recorded so L* can both assess the utility and popularity of its assets and prove its value to its various audiences and supporters. We anticipate that communications data rates for these functions will be minimal and easily handled by Internet communications. The paradigm for this function is WWW forms submission and/or e-mail communications. These typically occur with low duty cycle and significant information can be exchanged at data rates of only 100 bytes/sec.
Perhaps the most significant communication task to be supported by this system involves allowing scientists to visit classrooms electronically. This is nothing new---the communications industry is rapidly moving towards low-level routine video conferencing. L* intends to take advantage of advances in this area. Our goal is to enable real communication to take place by ensuring that the Internet connections, telephone lines, microwave or satellite links, or whatever communications channels are required, actually truncate in machines to which students have access. L* will work to bridge the chasm between the eyes, ears and minds of students and the useless communications outlets on the wall somewhere in the school by providing the computers and communications capabilities to make connections possible. We envision connecting the knowledge, skills, creativity and enthusiasm of the scientists, engineers and technicians of New Mexico's national laboratories and universities directly to the students of our state---especially those students K--6 who have not yet had a love for the natural universe driven out of them.
We have experimented with bi-directional video teleconferencing and find that small video windows of, say, 200 X 200 pixels work well in many near real-time applications. A refresh rate of 10 frames per second provides near-realistic movement. Thus, we require bi-directional transmission of 400,000 pixels per second. While each pixel is normally digitized to eight bits, we anticipate realizing approximately a factor of 10 in bandwidth reduction using logarithmic compression. Thus, real-time video conferencing will require a bidirectional bandwidth of approximately 400 kBytes/sec. Lower video data rates can be applied to stationary images, such as projected images, viewgraphs and static displays.
The system by which L* communications will occur is SNL's Technical Control, Automation, Maintenance and Support (TCAMS) system. TCAMS answers the L* requirements by providing multiple access control and status reporting capability for all system assets. It provides a graphical user interface (GUI) with multiple window support and point-and-click functionality. Communications and control occur using a message-based protocol. The system provides message authentication and security.
TCAMS views all facilities---telescopes, archives, people, etc.---as system assets. All system assets are comprised of devices. Devices represent single system elements that can be controlled or polled for status. All device control is based on a message-based protocol. All message traffic handled under this protocol is authenticated prior to execution and all system actions are logged for review at local control points. The system used to implement TCAMS is built on industry standard hardware and software.
System circuits represent prestored command sets. These provide a simple mechanism to recall often used assets, devices and device settings for further use. Circuits provide a graphical means to establish (device independent) communications between the control system and assets and devices. For example, communications can be established with an observatory simply by connecting icons in the GUI. Obviously, similar techniques are used at lower levels to enable communications among the telescope, instrument, detector, dome and other assets of the observatory. This technique allows a high-level icon-driven selection system for research needs and for student use.
TCAMS is built in a workstation environment using UNIX at the controller hosts. It is coded in Ada and C++, which supports objet-oriented programming. The user interface is built on X Windows. All information about system resources are made available by SQL queries to a relational database. The system supports interfaces such as RS-232, Ethernet, etc., as required by the system. Network communications are based in TCP/IP, or others, again a required by the system. The operating system for assets and devices is UNIX or VxWorks if real-time response is required. For example, a UNIX-based archive manager is perfectly acceptable, but telescope operation requires real-time control and will use VxWorks. TCAMS messages are authenticated by the Digital Signature Standard (DSS) protocol, and encryption is based either in RSA or DES techniques.
Because TCAMS is message based, control and status messaging can use any transmission media---Internet, telephone (modem), satellite link, microwave link, etc. File traffic, including science data images, can use any transmission medium because (in most cases) it is not time-critical. Lossless compression with error detection/correction significantly aids this function. Real-time data pose the greatest problems for transmission and may require dedicated transmission lines to fully support this function. The obvious example is video conferencing, for which relatively high frame rates must be achieved to make this a satisfactory experience. In this instance, however, extreme compression techniques can be used to good effect. The compression scheme for data of different types can be remotely selected from a device control GUI screen. Because the data volume is very small, compression is not required in basic control and status messaging. As a practical detail, note that the Internet is not always acceptable for control and status messaging because the transmission time delays are not well defined. Internet might be the medium of choice for science data and image transmission, but a slower, dedicated telephone line with predictable latency might, for example, provide better service in real-time applications.
System security is implemented in layers. System access controls (login and password) provide the first layer of security. DSS message authentication provides the second layer of security to assure that a valid user is commanding the system. Data encryption provides the third level of security by preventing en route messages from being read by non-system access. Encryption can be selected based upon user capabilities, data types and asset value, and is tied to the authentication mechanism. A limited-time access mechanism will be implemented to require periodic re-authentication of users.
Most of the functionality described here is transparent to the user. A grade school student, or research astronomer will log onto a control terminal which can be a PC-class machine. The user will establish communications with an asset and its devices through a connection screen or the TCAMS circuit screen. The user will then log on to the remote site and authenticate themselves to the remote site. Using either a preset configuration or the TCAMS device driver screen, the user selects the remote assets to be controlled. The system encrypts the message generated by this process and sends it. The remote site decrypts the message, authenticates it and acts on the request. The remote site then transmits a status message that is signed and encrypted reporting the success or failure of the request and the resulting system configuration information for logging at the control terminal. The user can use as many device drivers as necessary to control the archives, video cameras, telescopes, instruments and detectors necessary to carry out the desired function. In addition to controlling physical devices, the user can establish the response channel(s) for information being returned. Each channel includes specifying the transmission path, any compression, the encryption algorithm if one is needed, etc. The response, an image obtained from a telescope, perhaps, could then be sent to anyone at any location in the world, provided the recipient knows the decryption key.
Access to L* assets to which electronic access is enabled must pass through a user interface. This interface is crucial to successful user interactions. It is our intent to integrate all aspects of communication into a high-level graphical user interface. Perhaps the most visible aspect of the interface will be the system used to interface students (and professional astronomers) to telescopes. This system, adapted from a robotics system developed at SNL to allow robots to work in hazardous environments, provides many functions necessary to successful remote operation of telescopes.
Using structural models of the observatories, telescopes and instruments to be controlled, for example, models created by AUTOCAD, this system will allow users to see realistic representations of the entire system they are operating. This system can be run as a stand-alone model as a training tool, allowing students to learn how to command a telescope to point to a certain location, to move filter wheels and shutters, to rotate the telescope enclosure to allow an unvignetted sky view, and to simulate actual observations.
Because the models are accurate and fully realistic, they can be used to pre-test programmed motion prior to the command being executed by hardware. Thus, in near real-time, the software system can test to see if a third-grader in Clovis has just inadvertently commanded a telescope to point below the horizon. If a tested motion is unsafe or otherwise not allowed, the system will preclude that motion and will provide feedback to the user about why the motion cannot be accommodated. Thus, another function of the user interface is to safeguard the assets being accessed.
The telescope control user interface is a 2.5-D representation of the actual telescope environment. Students will be able to ``walk into'' the control room and ``reach'' the telescope control panel to operate switches and dials, as appropriate. We will strive for a common user interface so that telescope control is uniform across the project, independent of which existing or future telescope is being accessed. The environment, layout and buildings will, however, be realistic with respect to specific sites. The goal is to create at finite cost a virtually real scientific domain for students to explore. We intend to have students searching for novae and other real disasters, rather than searching for more artillery to use on the villains in Doom! We feel the experiences brought to students by L* will ultimately be somewhat more useful.
To illustrate the operation of the entire communications/user interface system, we describe scenarios in which it will be used.
Ms. Stockton, a third-grade teacher from Clovis, has attended a L* three-week summer school at NMIMT and has been certified as a (remote) telescope operator. She has been telling her class about the structure of the Milky Way and how astronomers can estimate the mass of our entire Galaxy. Now, Ms. Stockton's class has returned from a field trip to Enchanted Skies Park, where they have toured the site, enjoyed a program presented by former Acoma Governor Pasqual under the early evening skies---the topic was the formation of the Milky Way, as it was told to him---and seen an array of research telescopes in operation. Now these students want to learn more about the Milky Way! The L* hardware/software/networking system will provide this opportunity.
Ms. Stockton sends an e-mail request to L* headquarters requesting information on research possibilities related to the Milky Way. The computer and network connection she uses to do this were provided to her by L* upon completion of her earlier training in Socorro. L* personnel reply that there is, indeed, an astronomer, Jack Wetterer, at UNM who is trying to measure the mass of the MW, and that this person will contact the teacher to describe his work. Jack exchanges e-mail with Ms. Stockton and an arrangement is made for him to address her class using video teleconferencing. The result of Jack's presentation and a subsequent question and answer period is that Ms. Stockton's class requests participation in Jack's research. Their contribution will be to photometrically monitor some of the brighter RR Lyrae stars he described as probes of the Galactic mass distribution. Jack needs confirmation and accurate periods for 50 newly discovered RR Lyrae candidates, so a mutually-beneficial arrangement is struck: Jack will help the class learn about what he is doing and the class will help get data on Jack's candidates. The class needs access to the remotely-controlled 0.7-m telescope on South Baldy, so with Jack's help they prepare a proposal to L* to get the required telescope time. Upon review by L* astronomers, a review certainly leaning towards education rather than criticism, the class is awarded 40 hours of CCD imaging for the spring quarter. The class prepares for the observing by accessing the virtual telescope system to simulate observations. These are set up in queue for future observations. Because third-graders are rather young, they are not expected to be physically present in the classroom when their observations are done. As the observations are queued and accomplished, data are archived by L* and simultaneously returned to Ms. Stockton's class. Using image processing software, the class produces magnitude and uncertainty estimates relative to field comparison stars previously selected by Jack. Light curves of the RR Lyrae candidates and multiple comparison stars are plotted so the class can see the results of their work. These data are returned to Jack, who will obviously re-check the data and reduction procedures. Certainly, these results will be sufficient to identify true RR Lyrae stars, though he may well have to follow up on others. Periods can be determined by the class, and additional data can be used to refine and confirm the periods. Again, these are reported to Jack. Finally, Jack merges the data and results from Ms. Stockton's class with his own spectroscopy to estimate a Galactic mass. In the resulting paper he acknowledges Ms. Stockton's class for their help. In fact, if their help is sufficient, Jack may elect to include the class in the author list.
In other cases, especially with older students, real-time control of the telescope might be desirable or required. In that case, students would actually be in the classroom and would access the virtual system. They would ``walk'' into the control room, ``turn on'' the appropriate switches, access the observatory, telescope, instrument and detector control windows, and do their observations. A video window can be switched to view outside conditions prior to opening and to watch the dome open and position itself. The window can be switched to display a view of the telescope as it is moved and as the filter wheel and autoguider are positioned. After acquisition, the window can display the science field, and finally the autoguider field. A second video window will allow video conferencing with the participating astronomer, if the students feel this useful or necessary. After the allocated series of observations are made, control of the telescope is transferred either to the next participating site or to queue observing.
Obviously, the goal of this part of the L* experience is to allow students to actively participate in the processes of science, and usefully to involve them! Multiple experiences can be arranged for schools, classes or individuals as a reward for continued participation in L* programs.
It is clear that all of the requirements, including features not usually considered in astronomical communication systems, such as encryption, security, data compaction, transaction logging and archiving, all usefully apply to a system for remote observing by professional astronomers. We suggest that many of these features of the L* software/hardware design make our supported, integrated communications system a candidate for a standard remote observing system for astronomy, in general. We contend that with little or no modification, the story of Ms. Stockton's third grade class parallels that of a professional astronomer accessing a remotely-operable telescope anywhere in the world. L* will use this system to allow remote access by professional astronomers to its research telescopes.
Mr. Garcia, the high school science teacher in Carlsbad, is teaching a physics section on light. Having previously heard of L*, he accesses the database of demonstrations, projects and curricula on the L* WWW page. Going through the list and descriptions of demonstrations, he encounters ``Listening to Light.'' This demonstration involves students building an inexpensive photon counting detector which pulses a speaker as photons are detected. He realizes that there are several layers of learning available with this demonstration. The goal of the demonstration is to dim the lights in an enclosed room to the point where individual photons are arriving and can be ``heard'' as separate clicks from the apparatus. Mr. Garcia understands that this demonstration will illustrate the particle nature of light for his students.
Mr. Garcia clicks on the demonstration order form and enters the details of when and where he needs the demonstration. He indicates that in addition to the documentation, he would also like L* to send a kit containing the electronic components from which his students can construct a detector. The L* inventory control system checks to ensure that a kit is indeed available and logs the transaction. A docent at L* headquarters is alerted to shipment of the required kit two weeks prior to Mr. Garcia's requested start time. He packages and ships the kit and enters this into the shipment database. Inventory control is automatically updated and if the supply has been depleted by this order, a request for new kits is posted. Nominal billing is made to the school according to the terms of a previously-executed agreement.
Three weeks later, Mr. Garcia is happy as his students experiment with classroom light levels and try to hear the arrival of individual photons. This is possible because, again using video conferencing, his students were able to consult with Bill Miller, the L* electronics technician, who spotted the diode placed backwards into the circuit and was able to help them finish and debug their experiment. And Mr. Garcia has been back on the Web where he has found a great solar spectrum experiment which provides an introduction to quantum mechanics for high school seniors!
In New Mexico, as in most states, the higher education authorities prescribe many of the fundamental subject areas which elementary teachers must address. L* will help to ensure its utility and success by addressing these key areas, in New Mexico known as ``competencies.'' The competencies are given by grade, so L* personnel will develop curricula including topics, demonstrations, activities, test questions, teacher support aids, and other material to help teachers effectively and efficiently address required topics in all the natural sciences at appropriate levels. These curricula will be available to teachers on the WWW and by special order. Access to these resources will be enabled by computers and networks provided by L*. Many of the curricula will include ``visits'' by New Mexico scientists made possible by the L* integrated teleconferencing system.
Gillespie, B., Lowenstein, R., & York, D. 1996, in New Observing Modes for the Next Century, A.S.P. Conf. Ser., Vol. 87, eds. T. Boroson, J. Davies, & I. Robson (San Francisco: ASP), 97
Napier, P. J., et al. 1994, The Very Long Baseline Array, Proceedings of the IEEE, Vol. 82, No. 5, 658