Figure 1. Photograph of the SOFIA aircraft
Gary M. Heiligman1, David R. Brock1, Steven D. Culp1, Paul H. Decker1, Juan C. Estrada1, John B. Graybeal1, Sheldon D. Jordan2, Dan M. Nichols1, Peter R. Paluzzi1, Russell J. Pampell2, Barry L. Papke2, Richard D. Salovich2, Steven B. Schlappe2, Peter J. Sharer1, Karla K. Spriestersbach2, and Gary Lee Webb2
A display paper for the
194th meeting of the American Astronomical Society
June 1, 1999
Abstract published in the Bulletin of the American Astronomical Society, Vol. 31, No. 3, 1999, p.884.
The Stratospheric Observatory for Infrared Astronomy (SOFIA) will be delivered with a computerized mission control system (MCS). The MCS communicates with the aircraft's flight management system and coordinates the operations of the telescope assembly, mission-specific subsystems, and the science instruments. The software for the MCS must be reliable and flexible. It must be easily usable by many teams of observers with widely differing needs, and it must support non-intrusive access for education and public outreach. The technology must be appropriate for SOFIA's 20-year lifetime.
The MCS software development process is an object-oriented, use case driven approach. The process is iterative: delivery will be phased over four "builds"; each build will be the result of many iterations; and each iteration will include analysis, design, implementation, and test activities. The team is geographically distributed, coordinating its work via Web pages, teleconferences, T.120 remote collaboration, and CVS (for Internet-enabled configuration management).
The MCS software architectural design is derived in part from other observatories' experience. Some important features of the MCS are:
This paper reports on work in progress, with the final product scheduled for delivery in 2001. This work is being performed for Universities Space Research Association for NASA under contract NAS2-97001.
The Stratospheric Observatory for Infrared Astronomy (SOFIA) will consist of a 2.5-meter reflecting telescope mounted in the fuselage of a modified Boeing 747SP aircraft. SOFIA will have the largest optical telescope ever to leave the earth's surface; SOFIA's instruments will enable astronomers to conduct a wide variety of observations that are impossible from the ground. A photograph of the SOFIA aircraft is shown in Figure 1.
To support scientific operations on board, the modified aircraft will house a Mission Controls and Communications System (MCCS). Figure 2 is a cutaway view of the aircraft interior showing the crew workstations of the MCCS.
The MCCS will consist of
MCS will be the primary means by which the astronomers control and monitor the observatory while in flight. Figure 3. shows the hardware architecture of MCCS and MCS.
MCS is currently a work in progress; this paper describes development of software for MCS to date.
MCS communicates with the science instrument (SI) and its support computers in two different ways:
Both these communication strategies require simple, transparent interfaces employing widely used standard protocols.
MCS monitors almost all observatory systems and controls many of them. The observatory systems most concerned with astronomical observations are listed below:
MCS will have network communications with the SOFIA Science and Mission Operations Center (SSMOC) over a high-speed link while SOFIA is in its hangar.
The context diagram for MCS is shown in Figure 4.
MCS provides integrated high-level control for the SOFIA observatory. The MCS software ties together the individual subsystems of the SOFIA aircraft.
MCS provides the data system for SOFIA. MCS must monitor, record, and display data from the observatory subsystems and physical quantities derived from them.
MCS provides most of the user interface for SOFIA. The MCS software must facilitate use of the observatory, through both graphical user interfaces and digital network interfaces.
Ease of use is a primary requirement for MCS. SOFIA will have a complement of facility instruments, which should enable astronomers to make use of SOFIA even if they are not experts on either the facility instrument or the observatory.
MCS must support many different types of users. The education and public outreach interface to MCS poses a particular challenge because it must be as informative as possible without becoming intrusive.
MCS must be reliable, i.e., failures should be rare. MCS must be robust, i.e., recovery from failures should be rapid and benign. SOFIA has a goal of 960 successful science flight hours per year; MCS must be able to support this.
Because flight time is so valuable on the observatory, fast throughput of time-critical data is essential. The MCS command and data handling latency must be negligible compared with the latencies of other subsystems.
MCS must be flexible and expandable, because it must support wide range of instruments, flight profiles, and operation modes for the observatory.
MCS must be maintainable. It should use long-lived technology, so that it will not require extensive re-engineering to achieve the observatory's 20-year lifetime.
The MCS team has chosen a software process that re-uses knowledge learned during the early design and implementation stages to refine the requirements for the later stages. MCS is being developed in a series of four major iterations, or Builds (numbered 0-3); each Build in turn consists of 8-12 smaller iterations. Each iteration provides more capability than the last, but is released as a coherent product. Context development and iterative development may occur in each iteration. A schematic view of this process is shown in Figure 5.
Context Development defines the boundaries of the problem, identifies high-level use cases to be supported by the product, lists the Stakeholders and their interest in the product, and compiles the available information sources including documentation, existing software, and other information. The observatory-level specifications ("B-specs")--a list of "shall" statements for the MCCS--are used to build the high-level use case list.
Iterative Development begins with the high-level use cases. Use case decomposition and prototyping refine the use cases and nonfunctional requirements. These form the basis for object oriented analysis (OOA). The analysis models--package, class, sequence, activity, and state diagrams--define the "problem space", the true requirements of the product. The analysis models form the basis for an object-oriented design (OOD), which specifies the "solution space." The models of OOD refine the products of OOA, adding attributes, methods, and deployment diagrams. Implementation is the coding and integration of the models defined during OOD. The resulting code is tested using procedures derived from the use cases.
The feedback from testing into analysis and context development takes two forms: the development of prototypes and iterative development of the final system.
The MCS team built several prototypes to reduce the technical risks of development. Among these prototypes are:
Iterative development has several advantages over the grand design ("waterfall") methodology:
The methodology chosen for development is based on Object Oriented Software Engineering: A Use-Case Driven Approach (Jacobson, Christerson, Jonsson, and Övergard, 1994). Each use case describes the system as viewed from the outside. A use case driven approach serves many goals in the development process:
UML has become the de facto standard for graphical notation of object-oriented software (c.f. UML Distilled, Fowler and Scott, 1997). UML combines the advantages and features of several earlier object-oriented notations, e.g., Booch, Rumbaugh, and Coad-Yourdon.
The MCS team is geographically distributed between Moffett Field, CA and Waco, TX. To coordinate the work between these two sites, regular teleconferences have been essential. In addition, four internet techniques have proven particularly effective: (1) active maintenance of an extensive internal web site for documentation; (2) electronic mail (majordomo) distribution lists, for circulation to teams and working groups; (3) internet-enabled tools for configuration management (CVS with server-client protocol) and problem tracking (GNATS with the wwwgnats front end); and (4) T.120 interchange using the NetMeeting and SunForum shared windowing applications.
With the process described above, the MCS team has produced a five-layer software architecture. An abstract view of this architecture is shown in Figure 6.
This view illustrates two important aspects of the MCS software architecture:
The lowest architectural layer of software is the operating system. Two operating systems have been chosen for MCS: UNIX for the workstations and VxWorks for the real-time interface processors. UNIX and VxWorks were chosen because they are widely used and available for many hardware platforms. In addition, UNIX is based on an open set of standards.
The middleware layer provides operating-system independence, supports distributed computing, and provides fast throughput for time-critical data. Three products constitute this layer.
ACE is a real-time open-source framework of C++ macros, templates, class libraries, and applications, developed by Dr. Doug Schmidt of Washington University. Among the facilities ACE provides are containers, iterators, wrapper classes, and reference-counting memory allocation. Using ACE requires training, but it eliminates the need to develop many general-purpose facilities.
ACE has been implemented for VxWorks, most UNIX variants, and many other operating systems. ACE allows the same software to run on both UNIX and VxWorks.
TAO is an implementation of the Common Object Request Broker Architecture (CORBA). TAO is built upon ACE. CORBA provides a means of distributing and accessing objects across a network of heterogeneous machines. The advantage for MCS is robustness: if one workstation fails, then another can quickly take over its responsibilities.
Like ACE, TAO is an open-source product and using TAO requires training. TAO is expected to become the first ORB to be certified compliant with the new CORBA 2.3 standard.
Java 1.2 is used to run platform-independent Graphical User Interfaces (GUIs). At present Java applications communicate with C++ applications via TCP/IP sockets. In the future, Java applications may interface to other components through CORBA using the idltojava compiler.
Preliminary timing estimates indicate that Sun's Java interpreter is fast enough to meet most MCS user interface needs.
The infrastructure layer holds the most generic software that the MCS team has developed. The classes and applications in this layer use Java, ACE, and TAO to build a robust distributed data system. Classes and applications are grouped into packages using object-oriented methodology:
Figures 7. and 8. show parts of the infrastructure in UML notation.
 |
 |
| Figure 7. Top-level package diagram for MCS Build 0 |
Figure 8. Class diagram for the Data Acquisition package |
Figure 7 is a package diagram for the first MCS build: it graphically describes the major content areas for development and their relationships. Figure 8 is the class diagram for the data acquisition package.
This layer includes the specifics of each SOFIA subsystem and the astronomical algorithms needed for the observatory.
GUI packages in the infrastructure layer provide a consistent human interface--a "look and feel"--for SOFIA. At the domain-specific layer the GUI packages provide panels for individual subsystem control and access to domain-specific data. Many GUIs are even more specialized; they support individual user roles and tie together subsystems so that the observatory appears coherent to the user.
The MCS team uses several computer-based drawing tools to produce UML diagrams, including Rational Rose from Rational Software, Visio from Visio Corporation, and Visual Thought from Confluent, Inc.
The MCS team originally believed that it might be possible to maintain the implementation of MCS in an object-oriented software design tool like Rational Rose. This proved to be impossible for several reasons:
The MCS team therefore uses a manual process to create the implementations from the UML models.
The primary programming language for MCS is C++; however, several other languages will form a part of the final deliverable:
XML provides a notation and framework for self-describing data. It enables computers to store the nature of the data (the "metadata") together with the data set. XML parsers are now available for both Java and C++.
The MCS configuration is an example where XML is used. Early analysis decomposed the "configuration" use case into at least 12 small configuration tasks, each with heterogeneous data. To support all these use cases the MCS team chose XML as the storage format.
XML has great potential for simplifying the data interface to new subsystems. For SOFIA, it now appears possible that the subsystem descriptions may be in XML. Defining the data interface of a new subsystem could involve nothing more than reading the associated XML file.
The first build, Build 0, provides the infrastructure to collect, store, and distribute data, and to process commands; it implements packages in all five areas of the infrastructure layer and a few GUIs. Build 0 was the product of eight iterations, each lasting about a month; it was completed in May 1999.
This work is being performed for Universities Space Research Association for NASA-Ames Research Center under contract NAS2-97001.
1
Sterling Software SOFIA Projects
NASA Ames Research Center, MS 207-1
Moffett Field, CA 94035
2
Raytheon Systems Company
7500 Maehr Road, MS 1260
Waco, TX 76704
3 This IDL prototype was available for demonstration at the SOFIA booth at the conference.