FRD requirements indicated that the orbit determination process must be completed within 20 minutes of the completion of a tracking pass. It was assumed that the orbit data preprocessing functions would be sufficiently automated to allow the human intervention required for orbit determination to be limited to 15 minutes. This implies that there is a highly automated tracking data processing capability with some data editing capability. This leaves five minutes for the computer to process the data.
To test this assumption, a DSP orbit fit and trajectory were performed with the Aerospace TRACE program on three different platforms. The case examined was a weighted least squares orbit fit over 40.5 days (5.79 weeks) with a 32day prediction from the end of tracking. There were 6200 range observations collected from nine tracking sites. The run took four iterations (three sets of corrections) to converge. A 12th degree and order gravity field was used. This is rather high for a GEO satellite where 4th, 6th, or 8th degree fields are more common. A radiation pressure coefficient was estimated along with several station biases. The predicted ephemeris file was generated at hourly intervals. The CPU times for this stressing benchmark (for various platforms) are listed in Table D1 in ascending order.
Platform and Model No.

CPU
time (sec)

Sun
Sparc 20, Model 51

306.7

Silicon
Graphics Indigo 2

315.5

Sun
Sparc 10, Model 30

555.7

Two medium altitude benchmark cases from different sources were also run. One, run at Aerospace, is for single vehicle orbit determination and ephemeris generation. The subject orbit was at 900 km altitude and 99 degrees inclination. The fit span was approximately one day followed by a oneday prediction with ephemeris outputs at fiveminute intervals. This case processed 32 passes of range, azimuth, and elevation data from nine sites with a total observation count of 8112. Although the number of passes is unrealistically high, it is useful in establishing a conservative benchmark. Perturbations included a 12th degree and order gravity field, drag, and lunar and solar gravity.
Type

Clock
Speed

RAM

CPU
Time
(sec)

Sparc
20/51

50
MHz

32
MB

64.5

Sparc
10/30

36
MHz

32
MB

123.8

Sparc
10/30

36
MHz

8
MB

261.4

Sparc
LPC

25
MHz

32
MB

378.1

Sparc
SLC

20
MHz

8
MB

491.4

Starting with offset initial conditions, the run took six iterations (five sets of corrections) to converge. This case was run on several Sun workstations with various clock speeds, RAM, and hard disk sizes. However, because the workstations are all on a LAN, disk space is shared over the network and individual machine disk size is not significant. Comparative CPU times are shown in Table D2, starting with the fastest hardware.
The other medium altitude benchmark was provided by the Naval Research Laboratory (NRL). This benchmark was for simultaneous estimation of three 600nmi satellites. The orbit determination software used was the Orbit and Covariance Estimation and Analysis (OCEAN) program. The platform was a DEC Alpha 3000/800. There were 8000 Doppler observations from five ground stations. A 28x28 geopotential model was used. The fitting arc was three days. Convergence took four iterations. Including ephemerides for each satellite, the run time was thirty minutes. Dividing by three would infer ten minutes per satellite. NRL personnel stated that they had made no attempts to optimize the running time and they felt that considerable improvement in timing could be obtained.
Benchmark comparisons were also obtained for a Kalman filter application to orbit determination.
Sequential filters generally perform an orbit update after every observation. Linear filters work from a previously determined reference trajectory, using both precomputed states and partial derivatives. Extended Kalman filters recompute the trajectory and partials at each measurement time. Thus, the latter filter type would have longer running times and would provide the more conservative estimates. An example was obtained with the Logicon/Ultrasystems, Inc. RealTime Orbit Determination (RTOD) extended Kalman filter running on a DEC 486 personal computer. The system hardware characteristics were a clock speed of 66 MHz, 32 MB RAM, and a 2GB hard disk. For this application the software language was primarily Ada (plus some C). The operating system was Santa Cruz Operations (SCO) UNIX.
The example involved simultaneous estimation of five satellites using a 41x41 gravity field for two low altitude satellites and a 6x6 gravity field for three GEO satellites. There were 35 ground antennas. In addition to the six state parameters for each satellite, the estimation included two bias parameters for each station and each crosslink, plus radiation pressure coefficients for high altitude satellites and drag parameters for low altitude satellites. Trajectory integration from point to point utilized Runge Kutta numerical integration. The latency for a state update after each observation (obtained every 30 seconds during visible contact) was 12 seconds. The ratio of CPU time to real time was about 3% for straight number crunching with the filter. Adding on the overhead for displays brings the ratio up to about 10%.
Another example from Logicon/Ultrasystems Inc. involved a single geosynchronous satellite processed with RTOD/GEO written in FORTRAN. An Austin 80486 DX2 (66MHz) computer was used with the DOS operating system. This test used AFSCN tracking at eight seconds granularity. The results are presented in Table D3.
Test #

Real
Time
Processed

Wall
Clock Time (minutes)

Ratio

1

5
days (7200 min)

14

0.19%

2

2
days (2880 min)

7

0.24%

In Table D3, the ratios are CPU time to real time. The average ratio was 0.22%. There was another computation of the ratio during a measurement pass. Four tests were performed and the average during a pass was 4.0%. In regard to latency, the filter processed one measurement in about 0.4 seconds. The latter number is regarded as somewhat slow and is attributed to the graphics package and the DOS 640 Kilobyte memory limitation.
Logicon Ultrasystems, Inc. has several versions of their RTOD package running for various applications on different platforms, and in different languages (C, C++, FORTRAN, and Ada). It is expected that the DEC 486 CPU to realtime ratio performance cited above will significantly improve with a 32bit Pentium processor.
Given the expected growth in performance of the workstations and PCs used in these benchmarks, there is no appearent problem in satisfying the five minute processing time requirement with a highpowered desktop workstation.