[Top] | [Previous] | [Next]

A-6. Mission Planning Performance Drivers

Although the FRD does not explicitly define requirements for activities associated with mission planning, performance of mission planning functions was assessed in order to establish a timeline for planning satellite maneuvers. A number of typical maneuver planning activities were used to define benchmarks for mission planning. No cases were particularly stressing, even for a 486 PC. The cases included both orbit and attitude maneuver planning with and without optimization on a number of criteria. The most stressing case took less than a minute on the PC, which is equivalent to about 10 seconds on a Sparc 20 class computer. The results were generated using an AST Premmia 4/66d microcomputer and the program On-Line Orbit Mechanics (OLOM) which was developed by The Aerospace Corporation. For attitude maneuver planning, the program Attitude Maneuver Planning (AMP), developed by The Aerospace Corporation for use by spin stabilized spacecraft, was used.

In generating benchmarks associated with orbit maneuver planning, impulsive, and finite burn models were employed. The maneuver planning simulation advances an initial state of a vehicle to a new epoch and then simulates an orbit adjust maneuver. The maneuver can be defined in the form of an impulsive velocity increment or addition of a velocity increment over a finite time interval. In the former, an instantaneous change in the magnitude and direction of the vehicle's velocity is introduced. In the latter, a series of small instantaneous changes are introduced in succession to simulate application of a constant and continuous thrust over a finite interval of time.

The direction of the applied velocity increment can be defined using various conventions or reference frames (e.g. tangential, radial, in-track, cross-track, inertially-fixed, attitude-dependent, or velocity dependent). Benchmark data was generated for maneuvers across a range of orbit classes (low earth, medium altitude, geosynchronous, and highly elliptical) and maneuver scenarios (orbit injection, stationkeeping, and rendezvous). For each scenario, a spacecraft's post-maneuver orbit and status (i.e., fuel usage) for 100 unique deltaV opportunities were generated and displayed in tabular form. Performance data reflecting maneuvers using solid, as well as liquid-propulsive systems were incorporated into the benchmark exercise.

In an attempt to define the most stressing conditions for Mission Planning, solutions were optimized in favor of such parameters as fuel usage or "time-to-station." Sample results from the benchmark exercise for orbit maneuver planning are displayed in Table A-1.

Table A-1. Performance Benchmarks for Orbit Maneuver Planning

Activity (Model)

Data Products Generated
Execution Time for Processing (sec)
Predict Post-Maneuver Orbit (Impulsive Model)
Formatted Tabular Listing of Post-Maneuver Orbital Element Set (including Epoch, Orbital State, Sun-Vehicle-Earth Geometry, Orbit Period) and fuel usage.
10.5
Predict Post-Maneuver Orbit
(Finite Model)
Formatted Tabular Listing of Post-Maneuver Orbital Element Set (including Epoch, Orbital State, Sun-Vehicle-Earth Geometry, Orbit Period) and fuel usage.
50.3
Optimize Orbit Maneuver to Minimize Fuel Usage
(Impulsive Model)
Same as Above
33.2
Optimize Orbit Maneuver to Minimize Time-to-Station
(Impulsive Model)
Same as Above
43.8

In generating benchmarks associated with attitude maneuver planning, a system which uses "pipper" pulses from a liquid propulsion system to reorient the inertial attitude of a spin-stabilized spacecraft was simulated. This concept for spin axis reorientation is fully developed and used by many space systems (e.g., DSCS and GPS) during launch and early orbit operations. The maneuver planning simulation uses information about the spacecraft's spin rate, initial mass properties, thruster efficiency, and total precession angle to compute the number of pulses for the maneuver, the time delay between pulses and the post-maneuver mass properties. Data regarding thrust profile, time-to-centroid, and pulse shape are modeled as well. The practicality of sun-oriented precession maneuvers forms the motivation for rhumb line steering of the spin vector to reorient it. Physically, rhumb line steering is achieved by timing the reaction jet thruster pulses for direction control and queuing pulses for displacement control. The "pipper" pulse sets the zero reference for timing the thruster pulse. The discrete control signals carrying the timing information are called time-delay commands.

Table A-2. Performance Benchmarks for Attitude Maneuver Planning

Activity (Model)

Data Products Generated
Processing Time (sec)
Compute Number of Pulses to reorient the spin axis of a spin-stabilized satellite 180 degrees
Formatted tabular listing of Number of Pulses, time delay between pulses, post-maneuver mass properties (including tank pressures, tank temperatures and fuel usage)
12.0

This benchmark exercise assessed the computational requirements and needs of current satellite programs. Given the results of the exercise, coupled with expected growth in performance of microcomputers and workstations, it is anticipated that the Mission Planning functional area will not be a stressing factor on the architecture selected for the SSCS. While a 486 class PC will meet the maneuver planning needs of today's satellite programs, using of a mid- to high-powered workstation class computer to provide growth potential for current and future satellite systems is recommended.

In addition, the in-room scheduling function, which will employ an automatic scheduler may require more power than the PC can offer. Benchmarks using the Request Oriented Scheduling Engine (ROSE) indicate that scheduling 350 events took approximately 3 minutes on a Sparc 10 computer. This represented only about one-third of the requested events, so ROSE's performance is suspect. In addition, it should be noted that performance of automatic scheduling algorithms varies dramatically with the algorithm. This fact, coupled with the need for a sophisticated user interface, suggests using a high-powered workstation class computer for this function. This recommendation is further supported by the need for interoperability with other SSCS functions and the desire to have a suite of workstations capable of performing multiple functions.