This architecture assumes a comprehensive orbit analysis capability that can perform tracking data processing, orbit determination, orbit ephemeris and events generation, and antenna tasking. Data flows provide a logical breakdown of functionality and performance benchmarks provide evidence supporting the allocation made in the hardware architecture in the main report.
The real -time or non-real-time nature of Orbit Analysis is not addressed in this architecture. The only aspect of this architecture that tends toward the non-real-time mode is that certain interfaces are handled through data stores rather than real-time message passing. There should be little difference in the material presented for the two modes of operations. Implementation details will, however, differ significantly.
The Orbit Analysis architecture is driven by the need to rapidly update orbit knowledge as new tracking contacts are completed. The updated orbit state is then propagated forward and must meet prediction accuracy requirements associated with the particular satellite class.
The FRD requirements include timeline issues in processing tracking data as well as some orbit prediction accuracy requirements. The timeline issues are discussed in Section D-5.2.1 and later in Section D-6 of this appendix. The principal requirement was that the orbit determination process must be completed within twenty minutes of completion of a tracking pass. The main assumption was that orbit determination processing functions would be sufficiently automated to allow the human intervention required for orbit determination to be limited to fifteen minutes. This would then allow five minutes for data processing. Several benchmark tests have been performed at Aerospace for the data processing times using current workstations for medium-altitude and geosynchronous satellites, which are discussed later in Section D-6. These timeline assumptions were found to be reasonable even under stressful conditions.
The FRD prediction accuracy requirements were for medium altitude and geosynchronous satellites. There was a 36-hour prediction accuracy requirement of 460 m intrack with 95% probability for a medium altitude satellite. Also, for the medium altitude satellite there was a two-revolution prediction requirement of 30 m radial, 90 m intrack, and 30 m crosstrack, again at 95% probability. This should apply to a wide range of medium altitude satellites, but there may be some exceptions for particularly low altitudes.
The geosynchronous requirement was 200 m spherical error probable (SEP) for a one-revolution prediction, with a goal of five revolutions. This was based on current DSP requirements. GPS may have more stringent requirements.
There is a requirement for real-time transfer of antenna pointing angles, as well as a low accuracy backup using North American Aerospace and Defense Command (NORAD) Two-Line Mean element Set (2LMES) data, to be sent from the SSCS to the Range for prepass operations. Real-time antenna pointing employs a real-time 2-way communication link in which the user transmits pointing angles until autotrack is established, and receives range, range rate, azimuth, and elevation tracking measurements, as well as telemetry. Pointing angles can be generated in advance from an ephemeris file as needed. They can be stored at the ARTS controller to reestablish autotrack, if necessary. The ARTS controllers are also able to process a NORAD Element Determination Set (NEDS) (which is simply a 2LMES) that is sent out pre-pass. It is converted by software to pointing angles that subsequently are used to generate the appropriate slave data.
Assumed (and admittedly conservative) data transfer rate requirements were 10 points/second (40 Kbps) for real-time tracking and antenna angle pointing data. Storage requirements are dictated by file sizes, file generation rates, and retention times for iterative processing, mission planning, and post-flight analysis. Orbit predictions may be used for up to 45 days. The resulting storage and access assumptions are: 1) 5-GB distributed disk storage for each SV for ephemeris, tracking, and other files; 2) 7-GB archive storage for each SV, allowing 45-day archives; 3) 3-GB distributed storage for each SV for static information bases; and 4) 9-GB total distributed storage for applications, common database information, and solar-lunar-planetary (SLP) ephemerides. Overall, these numbers should not stress current technology, but they can add up if enough SVs are being processed or a great deal of "what-if" analyses are being performed.