Figure 1. Time Evolution of APLKey Requirements
S096.4.14 1
The SOE Keyword File Generator:
A Rapid Prototyping Example from NEAR Mission Operations
William P. Knopf* & A. R. Molloy**
* The Johns Hopkins University Applied Physics Laboratory
Johns Hopkins Road, Laurel, MD 20723. Fax: 301-953-1093. Email:william_knopf@jhuapl.edu
** Telos Information Systems
320 N. Halstead St., Pasadena, CA 91107. Fax: 818-351-0751. E-mail: A.R.Molloy@jpl.nasa.gov
ABSTRACT. Mission Operations (MOps) for the Near Earth Asteroid Rendezvous (NEAR) is conducted by The Johns Hopkins University Applied Physics Laboratory (APL). APL uses the National Aeronautics and Space Administration (NASA) Deep Space Network (DSN), managed by the California Institute of Technology Jet Propulsion Laboratory (JPL), for spacecraft communications during the NEAR mission. The DSN levies a requirement on all NASA projects to adhere to a standard Flight Project interface for mandatory Sequence of Events (SOE) transmittal to the Deep Space Communications Complexes (DSCCs). The SOE expresses both ground and spacecraft information pertaining to DSN station configuration and tracking events in support of real-time operations at the DSCCs. Existing SOE keyword generation software developed at JPL was investigated for use on the NEAR project, but cost and schedule constraints prohibited its inclusion in the NEAR Mission Operations system. An alternative approach was implemented, utilizing rapid prototyping and feedback through a two-person developer/analyst team at APL. The resulting product generated a SOE keyword file that was successfully interpreted by DSN's system on the first attempt. Details of the development tools, the rapid prototyping implementation, and the reuse potential of the APL SOE Keyword Generator will be discussed.
1. BRIEF INTRODUCTION TO THE SOE AND ITS PURPOSE
The SOE keyword file is an ASCII file expressing events (both ground and spacecraft) pertaining to DSN station configuration and tracking requirements. A set of standardized keywords are used for ground station configuration and personnel/procedural instruction on a per track basis. All project provided SOE keyword files are forwarded to DSN for processing. This processing includes validation of the keyword file for keyword variable syntax, final comparison/differencing to the real-time schedule, and station-specific information relay to the appropriate Deep Space Stations (DSSs). The processing also serves as a final verification of APL's use of DSN planning products in comparison to the actual as-run schedule, since scheduling disagreements between the APLKey SOE and the as-run schedule would be flagged by the DSN software process.
2. EARLY STAGES OF DEVELOPMENT
2.1. SELECTION OF THE ENVIRONMENT
It was decided at the onset to develop APLKey in an environment decoupled from the core NEAR Ground System components, specifically the Mission Operations (MOps) workstation hardware and networks which were being utilized for MOps procedural development, spacecraft testing, and training. Intel-based personal computers were selected as the hardware development platform for several reasons: numerous systems were readily accessable and available for development via the departmental network across the APL facility; the PC environment could provide an APLKey module that would deliver satisfactory performance in the operational generation of SOEs; detachment from the core ground system components during development provided a more stable development environment than the developing NEAR network (NEARnet); and the development tools available in the PC environment were both inexpensive and reliable.
2.2. SELECTION OF THE DEVELOPMENT TOOLS AND START OF DEVELOPMENT
The actual development of the SOE Keyword File Generator began late in the NEAR program, with the initial evaluation of DSN interface requirements and NEAR Mission Operations user requirements starting in late August 19951. To meet a mid-February 1996 launch schedule and minimize development costs, a simple set of development tools were selected, namely Microsoft's Visual Basic 3.0, Microsoft Access 2.0 for database definition/connectivity, and Microsoft Windows 3.1 for Workgroups. These tools were selected for a number of reasons. Their capability to rapidly build graphical user interfaces (GUI) and demonstrate significant levels of prototype functionality proved to be of immesurable use in the daily developer/analyst interactions. In addition, the "textual" nature of the SOE product, its inputs, and the envisioned design of its user interface contributed to the selection of these particular development tools.
The interface specification to the DSN for SOE keywords follows a well-defined format that is conveyed through an 80-character per record ASCII file. Records contain an assortment of information to identify the spacecraft, DSS involved, Universal Time Coordinated (UTC), and a keyword. A keyword may have 0 to 4 variables associated with it, and each variable may contain a number of subvariables. The construction of a keyword and its variables/subvariables must result in a DSN-approved format or the SOE will be rejected by DSN software.
Although the list of all possible DSN-approved keywords and their formats were defined by DSN, the list of NEAR mission specific keywords, their permitted range of values, and the sequencing of these keywords were not yet defined in the October 1995 timeframe. This drove a design of a SOE Keyword Generator capable of interactivly building a keyword sequence from an expandable database containing the complete list of available keywords and associated variables/subvariables, with various levels of automation options built in to generate known sequence templates from a definable base keyword sequence.
3. RAPID PROTOTYPING PARALLEL DEVELOPMENT STAGE
Due to the dynamic nature of evolving requirements by NEAR MOps and the DSN, a spiral design, rapid prototyping development approach for APLKey was accepted by the MOps management. This approach permitted a two-person customer/developer core "buddy" team to efficiently proceed in its development efforts with minimal management oversight. The customer member of the team maintained necessary contact with the NEAR-cognizant DSN engineer responsible for the software project interface to the DSN (the DSN Network Operations Project Engineer, or NOPE,) while the NOPE was negotiating an appropriate streamlined subset of valid keywords for the NEAR mission. This philosophy allowed the APLKey software engineer member of the team to develop the appropriate database design, logic/flow, and user interface with daily feedback from the MOps customer while specific NEAR issues were iteratively addressed by MOps and the DSN NOPE in parallel. To illustrate the philosophy implementation, Figure 1 provides a summary description of the relative time evolution of APLKey requirements and associated product development.
Figure 1. Time Evolution of APLKey Requirements
For the APLKey invocation of the spiral design and development approach, it was acknowledged that an ongoing goal of functional prototype capability allowed for extensive testing throughout the product evolution, resulting in design improvements, performance enhancements, and increased flexibility. These benefits were particularly appreciated as the customer witnessed such progress on a daily basis. As user interface design issues gradually evolved (a browser keyword list of top-level keywords, an editing workspace area, a variable display presentation of keyword variables and parameters, mission default selections, automatic generation of station configuration keyword events), interfaces with other processes and tools were defined. For example, the NEAR Mission Design Team generated a ground station geometric view data product (based on projected trajectory and physical station coordinates, where a view is defined to be greated than 6 degrees in elevation; a subset of that is the 10.5 deg elevation view set as dictated by the 34m HEF network transmitter elevation constraint). An implementation to interleave these data with best available DSN-provided schedule data (provided in a variety of existing DSN tracking file formats), along with an interface to NAIF-provided SPICE kernels for appropriate spacecraft ephemeris and round trip light time (RTLT) determination, provided a means to automatically determine station-specific tracking schedule events while taking into account all geometric view possibilities. Future interface with a key planning product of the NEAR Mission Operations Team, the Model of Spacecraft, Environment, and Subsystems (MOSES), will allow for automatic generation of keyword parameters based on the predicted spacecraft configuration in the timeframe of the SOE being produced. Figure 2 provides the current perception of top-level interface requirements for APLKey.
Figure 2. Top-Level Interface Requirements for APLKey
4. OPERATIONAL EXPERIENCE
Several weeks prior to the scheduled NEAR launch, an APLKey-generated SOE keyword file was delivered to the DSN for ingestion by the DSN systems. The delivered SOE was successfully interpreted by the DSN computers on the first attempt. The process provided the DSN an opportunity to fine-tune their requirements on the NEAR project one step further, allowing for tailoring of APLKey database defaults and another successful trial run with an operationally approved NEAR-set of keywords, formats, and mission-specific SOE representation.
Although a complete description of the APLKey operational product is beyond the scope of this paper, a representation of its top-level user interface is provided in Figure 3 for illustrative purposes.
Figure 3. APLKey Top-Level User Interface
5. REUSE AND FUTURE ADAPTATION
APLKey was developed to allow easy adaptation to other projects requiring DSN interface. The keyword format database can be expanded to provide default behavior for other missions as necessary, and APLKey can easily be adapted to filter availability of project-specific keyword sets on a project-by-project basis. Its flexibility allows the user various entry points into the SOE generation process, providing the capability to customize the SOE as necessary.
Throughout the APLKey rapid prototyping development, a final target environment of the MOps UNIX-based workstations was considered. Design similarities in the database implementation and user-interface to another NEAR Mission Operations planning tool, called the Activity Builder, were coordinated at the earliest stages of the development. If desired by MOps, the APLKey design can be adapted to an Oracle 7 database and XVT-environment generated product on the UNIX platforms. Future implementation considerations include full automation of input aquisition, SOE generation, and product delivery to DSN/JPL/MOps users.
6. SUMMARY
APLKey has been generating SOEs for the NEAR project in a practical sense continuously since its scheduled mid-February 1996 launch date. The rapid design and development of this product required less than 5.5 months from start to operational use, with less than one man month per month dedicated to the project during that 5.5 calander month period. The product can easily be adapted in near real-time for the MOps team as spacecraft configuration and ground system availability changes dictate. Through streamlining of requirements definition and support of management to proceed with this prototyping approach, the NEAR project was able to integrate into a mature system (DSN) in very short period of time. In an era embracing "faster, better, cheaper" as a paradigm for tomorrow's missions, this product development should be considered as a demonstration of that paradigm.
The authors would like to acknowledge the cooperation of the entire NEAR Mission Operations Team, and the efforts of the following individuals: Kenneth Williams and Jim McAdams of the JHU/APL, and Alan Short of the DSN/JPL. Your cooperation lended to the successful development and use of this product.
7. REFERENCES
1. DSN/JPL Document 820-13; Rev. A, DSN System Requirements Detailed Interface Design; OPS-6-13, Flight Project Interface to the DSN for Sequence of Events Generation, Change 1, dated 31 August 1995.